Still can't read it though - reader needs SSkinMeshBuffer which only supports 16 bit so far
(changes in loader are just spelling fixes in comments)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6346 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @Foaly for the patch (https://irrlicht.sourceforge.io/forum/viewtopic.php?f=9&t=51441)
Applied with some minor changes.
Also mesh-type in that loader now set to EAMT_STATIC (was EAMT_OBJ before, probably some copy-pasting going on).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6342 dfc29bdd-3216-0410-991c-e03cc46cb475
Giving the loader it's own enum allowed me to add more options.
EITH_OPTIMAL which reduces buffers back to 16-bit if they don't need 32-bit.
Using that in obj loader.
Also 32-bit meshes with EMT_PARALLAX_MAP_SOLID material should now work in obj loader (untested as I got no test-case)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6340 dfc29bdd-3216-0410-991c-e03cc46cb475
Also added a bit documentation about what it's purpose seems to be (hope I got it right...).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6336 dfc29bdd-3216-0410-991c-e03cc46cb475
CMeshManipulator::createMeshCopy creates new meshes which have copies of the actual meshbuffers instead of copying everything into SMeshBuffers (which didn't support 32 bit or any of the other special features).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6335 dfc29bdd-3216-0410-991c-e03cc46cb475
- IMeshLoader::setPreferredIndexType and getPreferredIndexType allow setting hints for the loaders if users prefer 16 or 32 bit meshbuffers. Loaders are free to ignore those hints (all but .obj will do that for now).
- obj meshloader loads now 32-bit buffers when setPreferredIndexType is set to EIT_32BIT.
NOTE: It's 16 bit meshes use now also an IDynamicMeshbuffer instead of an SMeshBuffer.
That will break the code of people who accessed meshbuffer before by casting to SMeshBuffer*
And might even be somewhat slower (lot's of virtual functions...), but shouldn't really matter and can maybe be a bit improved.
Sorry about that, I considered keeping SMeshBuffer for 16-bit (still considering it), but it would add some overhead in code and I don't think it's worth that. If there are any complains I'll maybe consider it again.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6333 dfc29bdd-3216-0410-991c-e03cc46cb475
Allows to find out which class a meshbuffer has.
I used the same kind of style as ISceneNode::getType. So using four CC codes and virtual functions (instead of type variable).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6330 dfc29bdd-3216-0410-991c-e03cc46cb475
Avoid creating dummy arrays when we work with non array images.
Just a minor speed improvement.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6329 dfc29bdd-3216-0410-991c-e03cc46cb475
1 Meshbuffer with 24 vertices, so each side has it's own vertices.
Normals perpendicular to the cube-sides.
CubeSceneNode accepts now a ECUBE_MESH_TYPE
CubeSceneNode::clone now also clones rotation and scale (not sure why it didn't do that before - hope there was no reason, but can't think of any).
ISceneManager::addCubeSceneNode accepts now a ECUBE_MESH_TYPE and passes it through.
Example 22.MaterialViewer using new cube type. Also a few more beauty fixes there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6313 dfc29bdd-3216-0410-991c-e03cc46cb475
Other functions like getMaterialRendererName got switched to u32 in the past. I can see no reason why this one was left out, so changing it to be same as the rest.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6300 dfc29bdd-3216-0410-991c-e03cc46cb475
So uv-coordinates can now be modified directly (previously only possible via texture matrix).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6299 dfc29bdd-3216-0410-991c-e03cc46cb475
Due an off-by-one error it went wrong where there a special character replacement for the second-last character going on.
So something like "<X" became "<" instead of "<X".
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6295 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer. Could probably do in a lot more places... another time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6293 dfc29bdd-3216-0410-991c-e03cc46cb475
Also avoid potential heap overwrites in there.
Sadly I have no examples for OCT files and it doesn't seem like a very common format as I couldn't even find any examples online.
So just assuming my changes work.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6291 dfc29bdd-3216-0410-991c-e03cc46cb475
Tiny speed hit, but old solution caused warnings.
And it was not very safe by assuming all non _WIN32 platforms would use 32 bit sizes for wchar_t.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6290 dfc29bdd-3216-0410-991c-e03cc46cb475
I don't know enough about DeleD from Delgine to fix this.
But keeping the functions defined out as long as they don't get in the way.
Also I'm a bit suspicious about the license... for use in Irrlicht core only under zlib license?
That's not really zlib license then :-(
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6289 dfc29bdd-3216-0410-991c-e03cc46cb475
- Updates bzip2 to 1.0.8 (which sadly didn't reduce the amount of compile warnings, but let's hope it still improves something)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6282 dfc29bdd-3216-0410-991c-e03cc46cb475
mtllib commands previously used only the first word, now they use the rest of the line.
Different obj format descriptions describe the mtllib command in 2 different ways:
- http://paulbourke.net says it can load several mtl files separated by spaces
- Wikipedia says it can load one mtl file (but there can be several mtllib commands)
We previously loaded 1 file - using the name up to the first space character, so it basically was not correct for either solution. We now go with Wikipedia, because it allows using space in filenames and I tested several other tools and they all handled it like this.
Also COBJMeshFileLoader::copyLine no longer copies the newline character (didn't do that always anyway and we don't need it)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6275 dfc29bdd-3216-0410-991c-e03cc46cb475
Basically fixing original Bug#427 reported by MArkus Elfring.
Unfortunately there are still more defines (in IrrCompileConfig.h) which also are not nice c++
Lots of files touched for very minor cleanup *sigh*
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6253 dfc29bdd-3216-0410-991c-e03cc46cb475
Usually something like __IRR_SOME_GUARD_INCLUDED__ replaced by IRR_SOME_GUARD_INCLUDED.
Removing underscores at the end wasn't necessary, but more symmetric (probably the reason they got added there as well).
While this touches every header it shouldn't affect users (I hope).
Also a few whitespace changes to unify whitespace usage a bit.
And a bunch of spelling fixes in comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6252 dfc29bdd-3216-0410-991c-e03cc46cb475
C++ has undefined behavior for identifiers starting with __ or with _ followed by an uppercase letter.
We still have many more (in IrrCompileConfig.h and in all header-guards), will likely replace those later as well.
As a workaround for users which might use irrlicht defines in their code, I've added the header irrLegacyDefines.h
Including that allows to continue using old defines for a while - or make it easier to have code which compiles
with old and new Irrlicht library versions.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6251 dfc29bdd-3216-0410-991c-e03cc46cb475
clang warned about that and I think warning made sense. Also still works on gcc - will test on VS tomorrow.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6248 dfc29bdd-3216-0410-991c-e03cc46cb475
setTexture functions for single textures (more or less the usual case) IRenderTarget no longer need memory allocations
on each call.
Also calling IRenderTarget::setTexture with a nullpointer no longer sets a rendertarget with an array which contains a single nullpointer but clears the array instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6243 dfc29bdd-3216-0410-991c-e03cc46cb475
Still can't decide on fixing/leaving function names... brr
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6241 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Victor Gaydov for report + patch + very good test cases! (bug #401)
This had been broken since Irrlicht 1.6
The reason was that Irrlicht 1.6 wanted to ensure Irrlicht renders to given parent window instead of creating a child window in the parent window. That still works, but only with SIrrlichtCreationParameters::IgnoreInput set to true.
Added a few comments about further improvements as rendering to the given parent Window is likely also possible for this case, but that will need more work.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6237 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Bate for the patch (patch #175 with minor changes).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6234 dfc29bdd-3216-0410-991c-e03cc46cb475
This was patch #285 from Danyal Zia and is about old radeon cards not supporting npot textures despite claiming so I think.
Was never applied as needed some rewrite first (did string-comparisons a bit too often), so got stuck on patch-tracker.
Well, lets hope this fixes it in case anyone ever needs that specific combination ever again ;-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6233 dfc29bdd-3216-0410-991c-e03cc46cb475
Recently added code to allow using tab-key's inside modal dialogs could also be called when moving the mouse while the tab-key was pressed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6232 dfc29bdd-3216-0410-991c-e03cc46cb475
Problem is that the mouse jumps when users have set a coordinate transformation matrix for their mouse on X11.
XWarpPointer first sets the correct coordinates, but X11 then moves the mouse wrongly to the scaled position on the next mouse event.
On X-Org bugtracker it's this bug: https://gitlab.freedesktop.org/xorg/xserver/-/issues/600
The fix needs compiling with _IRR_LINUX_X11_XINPUT2_ enabled (so far disabled by default)
Note: We only use XINPUT2 so far for touch-input... I hope this patch won't conflict with that.
Also I mix now IInput2 and X11 functions as getting the mouse-position still uses X11. But seems to work in my tests.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6230 dfc29bdd-3216-0410-991c-e03cc46cb475
Also adding some to VS2010 project file (for better project search)
Some empty line removal.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6228 dfc29bdd-3216-0410-991c-e03cc46cb475
Capping the torus also supported.
Bit arguably if caps belong in this function, but default for caps is off and they can be useful.
(one could also code partial minor circles ... but I'm stopping there)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6225 dfc29bdd-3216-0410-991c-e03cc46cb475
This is mainly about getting rid of double error messages for same file.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6221 dfc29bdd-3216-0410-991c-e03cc46cb475
Replace a static variable which was used in error-reporting but wasn't thread-safe.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6220 dfc29bdd-3216-0410-991c-e03cc46cb475
It's no longer enabled by default as it causes some costs to all texture switches.
Thanks @ edo9300 for reporting (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52721)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6219 dfc29bdd-3216-0410-991c-e03cc46cb475
Event got eaten before. It passes it now on partly (enough to arrive at CGUIEnvironment) when the focus will stay inside the modal screen.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6215 dfc29bdd-3216-0410-991c-e03cc46cb475
Add -fPIC to linker flags (additional to compiler flags).
This is sometimes necessary as chronologicaldot reported in the forum:
http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=52708
Also gcc manual says this about the -shared flag:
"For predictable results, you must also specify the same set of options used for compilation (-fpic, -fPIC, or model suboptions) when you specify this linker option."
Add TODO for this about sharedlib_osx as I can't test that.
Add documentation when "make clean" is needed. So far we only have a single set of .o files written in the same folder.
So this has to be called basically on all changes.
Use CPPFLAGS instead of CFLAGS, CXXFLAGS in a few places for options which should be used for all files.
Add CFLAGS and CXXFLAGS for dependency files (not 100% certain about those, just seems to make more sense to me)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6207 dfc29bdd-3216-0410-991c-e03cc46cb475
string has operator== for char_type which can save a lot of string allocations when loading xml's.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6206 dfc29bdd-3216-0410-991c-e03cc46cb475
Otherwise I probably break AmigaOS again (which was the reason to add this parameter in first place)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6197 dfc29bdd-3216-0410-991c-e03cc46cb475
New default is that the system decides itself.
Reason is that X11 didn't like the last change (disabling it on start) too much and we got messed up title-bars.
Or at least on some Window Managers. Which makes sense as X11 really requires Windows to be resizable in Windowed mode.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6196 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @Maksym Hamarnyk for proposing a patch and testing some changes.
May break OSX 10.5 and older (lack of test-system, but probably not much used anymore).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6194 dfc29bdd-3216-0410-991c-e03cc46cb475
Both are already included in -O2 (which is in included in the -O3 we use)
Thanks @randomMesh for reporting: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52692
Note: -fstrict-aliasing also gets removed in debug now where it also was enabled.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6190 dfc29bdd-3216-0410-991c-e03cc46cb475
Discussion to this in https://sourceforge.net/p/irrlicht/patches/322
Basically last solution caused problems as it send fake-mouse events on top of touch-events.
For now we can probably just enable touch-events and clear masks for everything else for all devices
as we only use the XInput2 events for touch-event handling and nothing else.
At least not noticing conflicts with rest of X11 input so far and user TheBrokenRail said this works for him.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6184 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @TheBrokenRail for a patch proposal based on example code from esjeon (patch #322).
See https://sourceforge.net/p/irrlicht/patches/322
Original example code here: https://github.com/esjeon/xinput2-touch
Users have to enable _IRR_LINUX_X11_XINPUT2_ in IrrCompileConfig and link with Xi to make this work.
I rewrote the patch a bit and have no system for testing here, so this still needs some testing.
I also backported EET_TOUCH_INPUT_EVENT for this from the ogl-es branch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6178 dfc29bdd-3216-0410-991c-e03cc46cb475
Thx @TheBrokenRail for report and patch.
Hidden in comments of patch #322: https://sourceforge.net/p/irrlicht/patches/322
(patch is for es branch, so only part of it applied for now)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6176 dfc29bdd-3216-0410-991c-e03cc46cb475
Optimized and avoids problems on Phosh shell
Thanks @TheBrokenRail for a patch (was a tiny part of patch #322).
https://sourceforge.net/p/irrlicht/patches/322
Changed patch slighlty to unify with rest of Irrlicht code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6174 dfc29bdd-3216-0410-991c-e03cc46cb475
- Updates libpng to 1.6.37 (from 1.6.23)
Note: Seems svn can't merge it automatic when a folder was removed and readded with same name.
Easier to update libs by deleting all files - copying new ones over and then check svn stat for differences
and resolve them manually.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6171 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns currently used color - depending on state and if override color is set.
Note: Not adding this to editbox for now as it's a bit more tricky there (selection changing color, so it has no single color).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6165 dfc29bdd-3216-0410-991c-e03cc46cb475
That makes it easier to use partial screens, while using automatic alignment.
Default is still automatic resizing as before, thought it got changed a bit as it looked a bit strange.
Before it only set the lower-right corner, but compared to driver screensizes, so it behaved a bit strange
when the leftTop corner of the rootGuiElement was changed (different than when the rightBottom corner was set).
Could be the idea before was that only clipping matters.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6163 dfc29bdd-3216-0410-991c-e03cc46cb475
Prefer static_cast to reinterpret_cast.
Declare variables later with init values to avoid having uninitialized variables around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6161 dfc29bdd-3216-0410-991c-e03cc46cb475
Basically behavior about that is back to how it was in Irrlicht 1.8 - not perfect, but useable.
So window still jumps a bit when dragging toolbar, but no longer outside the sreen. And it's possible again to alt+tab to other windows.
The problem was caused by a combination of FPS camera changes and that we stopped doing mouse-coordinate clipping in the Linux device in r5593.
Basically that clipping had the side-effect that the fps-camera never considered a mouse "outside" on Linux.
Now on Linux we only update after we get a mouse-event (which we still get when the mouse is outside the window).
On Windows we still grab the mouse in the camera, thought that's likely _not_ the best way to do that. Windows has some mouse-grabbing support,
and I suppose we could use that (or camera should check if that is used as it also can be set by users I think). So maybe in future this can be further improved.
Other operating systems (OSX) should behave like in 1.8 I hope, but as usual I can't test.
Also did a few minor cleanups in the camera.
- Back to using animateNode time instead of real-time. That's because that was not causing the problems I thought back then it might cause as time is only used for keyboard input and not mouse input.
- Moved updating CursorPos to the rest of the code checking CursorControl
Note: A future improvement would be to add support for systems without CursorControl object (could still use mouse-events to get it working usually).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6142 dfc29bdd-3216-0410-991c-e03cc46cb475
Thx @Marko Mahnič for the patch (https://sourceforge.net/p/irrlicht/bugs/449)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6135 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously project file was at 3.2 which seems to no longer work with newer XCode versions.
Patch is from Maksym Hamarnyk, no testing from my side for this.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6131 dfc29bdd-3216-0410-991c-e03cc46cb475
It's never really done much in c++, was deprecated in c++11 and is reserved since c++17.
Thanks @Maksym Hamarnyk for remdinding me about this.
Note: there are few more register commands in third library .c code. It's still a valid keyword there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6130 dfc29bdd-3216-0410-991c-e03cc46cb475
Introduced in r5818. Might be part of the OSX compile troubles.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6125 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @Maksym Hamarnyk for sending those.
Note: More patches are needed and I can only apply, not test, this.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6123 dfc29bdd-3216-0410-991c-e03cc46cb475
The change to the scaling code caused scaling to read outside of original image memory.
Was caused because scaling step factor was based on image-sizes, but has to be based on amount of scaling steps taking (off-by-one error).
Thanks @Maksym Hamarnyk for reporting that there was some problem.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6121 dfc29bdd-3216-0410-991c-e03cc46cb475
Before it crashed when index-count wasn't a multiple of 3, now it just doesn't create the last triangle then.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6110 dfc29bdd-3216-0410-991c-e03cc46cb475
This changes the behaviour on Win32 somewhat when Windows returned a CURSOR_SUPPRESSED state (touch-screen input hiding cursor globally).
Previously we set IsVisible it to false when CURSOR_SUPPRESSED was set.
Also we handle the CURSOR_SUPPRESSED state slightly different now and still try to hide cursors once when requested.
Reason for the change is that the old behaviour made it harder to recover from touch-screens hiding the cursor because Irrlicht didn't
know anymore which state is _should_ have. This also unifies the behaviour on all drivers as the other drivers already returned the visible
flag independent of the system being able to actually show the cursor.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6109 dfc29bdd-3216-0410-991c-e03cc46cb475
UI and scenenodes are often connected. And while it was possible to work around this already by using custom draw functions
or deriving from gui and scene-nodes at the same time, it did already lead a few times to uglier code for me.
So I guess adding one more pass to the engine has it's uses.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6107 dfc29bdd-3216-0410-991c-e03cc46cb475
- 10 year anniversary update
- Lighting model reworked. moved to eyespace like openGL. [Specular Highlights, Fog, Sphere/Reflection Map]
- increased internal s4DVertex to support 4 Textures and 4 Colors [switchable]
- Textures are handled as sRGB during Mipmap Generation. More accurate, less visual disruption
- 2D is drawn as 3D like hardware drivers. [switchable]. enables viewport scaling, material2D
- Texture Spatial Resolution Limiting working. [lower memory consumption,SOFTWARE_DRIVER_2_TEXTURE_MAXSIZE]
- SuperTuxKart 8.0.1 playable
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6086 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, just a hack to make it easier to work around Irrlicht :-(
Would be nice to have a general mechanism to load native gl functions in Irrlicht from apps...
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6074 dfc29bdd-3216-0410-991c-e03cc46cb475
65536th vertex has index 65535 which is still fine, was going 1 too low in last commit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6053 dfc29bdd-3216-0410-991c-e03cc46cb475
Those are not supported by any graphic card and we just end up with invalid textures.
Returning 0 now instead in addRenderTargetTexture for OpenGL and D3D9.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6047 dfc29bdd-3216-0410-991c-e03cc46cb475
Having too many warnings makes it harder to see real warnings.
I know the idea to keep those around was to have them as reminder to work on those.
But going over the formats here - it just doesn't make sense in most cases.
And for the rest (like we could add converts from R8 or so) no-one is going to work on it until someone concretely needs it anyway.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6046 dfc29bdd-3216-0410-991c-e03cc46cb475
Unlikely we ever support conversions with compressed image format.
Define is a bit ugly I guess, but nicest way I could think off.
Can probably be used in some image writers as well, have to check which support/don't support compressed formats first.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6042 dfc29bdd-3216-0410-991c-e03cc46cb475
Interestingly those can be suppressed with simple comments.
Note that I didn't suppress those in zlib code yet as I'll check for updates for those libs before releasing (while we are pretty much stuck with this AES version unless we put in a lot more work).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6040 dfc29bdd-3216-0410-991c-e03cc46cb475
The way this was implemented BlendFactor and MaterialTypeParam could conflict otherwise as they both send the blend functions.
We could probably rewrite all places which use EMT_ONETEXTURE_BLEND+MaterialTypeParam to additionally check for BlendFactor, but it would still set the blend-functions twice.
I'm not sure if BlendFactor works with 2D materials currently? (but we can't set those to shaders yet anyway except in the gles branch...).
I've also started documenting a few things about how I suppose it's working, I hope I got it all right.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6034 dfc29bdd-3216-0410-991c-e03cc46cb475
Fix bug that AnimatedMeshSceneNode ignored ReadOnlyMaterials flag when checking materials for transparent render passes.
Make IVideoDriver::getMaterialRenderer const.
Fix bugs in COctreeSceneNode, CMeshSceneNode and CAnimatedMeshSceneNode where check for transparency in OnRegisterSceneNode() and in render() where no longer identical (those got added after Irrlicht 1.8).
Some notes for future:
- Maybe we should have a getRenderPass instead of just needsTransparentRenderPass, but this way the code didn't need so much changes and behaves (aside from fixes) pretty much as before.
- Still wondering if the default implementation in CNullDriver::needsTransparentRenderPass should always return false when SMaterial.ZWriteEnable is set to EZW_ON.
This might be nicer with another material flag. Thought then we might want a material enum to choose the renderpass and that's more work.
And we get some recursion as needsTransparentRenderPass might want to check result of getWriteZBuffer which calls needsTransparentRenderPass, so we might need a second function or an additional flag there.
But return false when SMaterial.ZWriteEnable == EZW_ON could still be done as EZW_ON is a new flag so existing behavior shouldn't break. I just don't know right now if having an extra render pass for transparent nodes might still make sense even when zbuffer is not written or if that's really the only reason to do that. Any feedback anyone?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6033 dfc29bdd-3216-0410-991c-e03cc46cb475
This breaks compiling. To have old values replace false with EZW_OFF and true with EWZ_AUTO.
There's a bit history to this change. ZWriteFineControl got introduced after 1.8 so it was never in a released version.
Basically it was needed after some changes had been made to allow shaders to have zwrite enabled independent
of the material-type (which worked badly for shaders). This had caused other problems as it was then enabled too often instead.
So to quickly fix those bugs and avoid breaking compatibility I had introduced a new enum ZWriteFineControl in SMaterial.
This worked and didn't break compiling - but I noticed by now that introducing a second flag for this made maintainance for an already
very hard to understand problem (figuring out the implementation of transparency and zwriting) even more complicated.
So to keep maintance somewhat sane I decided to break compiling now and merge those two flags.
The behavior should not be affected by this commit - except for users which set this flag already in their code and have to switch to the enum now.
Serialization is switched on loading old files (so SMaterial has enum already and writes that out).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6026 dfc29bdd-3216-0410-991c-e03cc46cb475
Before OpenGL used GL_SPHERE_MAP instead of GL_REFLECTION_MAP in COpenGLMaterialRenderer.
Not sure why, but documentation mentioned GL not being implemented, so maybe it was forgotten?
Or maybe I'm missing something as this was a big too easy to fix :-)
Anyway - I tested it and with that change they seem to look now identical to the D3D9 version, so I think it's fine.
Obviously means whoever used the material before on OpenGL has now a changed material.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6014 dfc29bdd-3216-0410-991c-e03cc46cb475
To avoid changing burnings now those functions have no IRRLICHT_FAST_MATH anymore,
there's a new header irrMathFastCompat.h which has ..._fast functions doing the old behavior.
With the troubles they have documented.
I changed burnings to use those functions throughout.
Or as much as possible... Burnings probably also uses classes like SColor which also have functions
using those, but I don't plan to adapt them.
Maybe IRRLICHT_FAST_MATH should be a flag exlusive to burnings in the future, I don't think it makes
much sense otherwise anymore (it often expects 32-bit asm).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6012 dfc29bdd-3216-0410-991c-e03cc46cb475
That function just returned true for years not doing anything.
As far as I can see from the web it's about some rare cases in DOS compatibility mode with 32-bit apps.
But not sure why it was called exactly in this place in the past.
So no comments, no idea what it's about and not actually doing anything and probably not needed on any platform anyone still uses ... lets just kick it out.
(it did break compiling IRRLICHT_FAST_MATH on x64 which is why I noticed it)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6009 dfc29bdd-3216-0410-991c-e03cc46cb475
Single inserts/removes per device creating/destruction, but searchs on every event. Arrays are better for that than lists.
Also document a bit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6004 dfc29bdd-3216-0410-991c-e03cc46cb475
I suspect we could also get rid of the EnvMap list, not sure what that is about.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6003 dfc29bdd-3216-0410-991c-e03cc46cb475
