Commit Graph

30 Commits

Author SHA1 Message Date
cutealien
5451a2a8a0 Switch to 32bit meshes in CPLYMeshFileLoader now at > 65536 vertices.
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
2020-01-08 11:14:57 +00:00
cutealien
bc41211482 CPLYMeshFileLoader now switching to 32-bit meshbuffers when more than 65535 vertices instead of more than 65565.
Thanks @randomMesh for reporting (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52563)

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6052 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-08 10:34:35 +00:00
cutealien
5db5cbadf5 Add another test for gl errors in debug.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6048 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-06 14:27:20 +00:00
cutealien
50f4bdecbe No longer try creating rtt's for compressed image formats
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
2020-01-06 14:05:26 +00:00
cutealien
83d368cef4 Replace compile-warnings for unsupported image formats in writers with a log message warning.
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
2020-01-06 11:54:57 +00:00
cutealien
985997a755 Avoid warning.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6043 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-04 18:51:01 +00:00
cutealien
f1a3995965 Add define IRR_CASE_IIMAGE_COMPRESSED_FORMAT to help getting rid of a few more warnings.
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
2020-01-04 18:42:12 +00:00
cutealien
66b24bb745 Avoid some warnings and unnecessary (slow) check in CImage::setPixel/getPixel
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6041 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-04 18:26:13 +00:00
cutealien
229c827870 Prevent some fallthrough warnings we got since gcc7 in aes
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
2020-01-04 16:22:12 +00:00
cutealien
5d0b042a65 Use f64 version of reciprocal_squareroot in quaternion::normalize for more precision.
The f32 version jumped around more on gcc/linux (didn't do so with VisualStudio, mabye sqrt on VS already uses double internally).


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6036 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-03 17:09:39 +00:00
cutealien
34d09f7c63 Fix: CMeshSceneNode and CAnimatedMeshSceneNode still used wrong material in OnRegisterSceneNode.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6035 dfc29bdd-3216-0410-991c-e03cc46cb475
2020-01-03 16:22:55 +00:00
cutealien
0b71328102 Use BlendFactor only when MaterialType != EMT_ONETEXTURE_BLEND
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
2020-01-03 14:58:46 +00:00
cutealien
473ab1ea58 Unify checks if materials should use transparent render pass with new IVideoDriver::needsTransparentRenderPass function.
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
2020-01-03 11:13:57 +00:00
cutealien
2928a632a4 Material.ZWriteEnable is now of type E_ZWRITE instead of bool and ZWriteFineControl get removed (or merged into ZWriteEnable).
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
2020-01-02 15:34:52 +00:00
cutealien
fc37b383ed Fixing comments for E_ZWRITE_FINE_CONTROL.
(and considering replacing it and breaking binary serialization of SMaterial - having 2 flags for zwrite is simply too confusing).

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6023 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-31 18:21:45 +00:00
cutealien
c661373121 EMT_REFLECTION_2_LAYER and EMT_TRANSPARENT_REFLECTION_2_LAYER on OpenGL now same as D3D9 version.
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
2019-12-17 14:05:34 +00:00
cutealien
28725e137a Update irrString test due to split changes in r6007
We keep separators now in their own tokens.


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6013 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-16 16:51:30 +00:00
cutealien
3280b3319e Add floor32, ceil32, round32 compatibility functions for burnings renderer.
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
2019-12-16 16:15:04 +00:00
cutealien
3acf725ae3 Work on IRRLICHT_FAST_MATH troubles. Document round_ and round32 troubles.
- Add warnings to round_, round32 about different (and sometimes worse) behavior than the standard library, especially at high numbers.
  For example with input 8388609 standard library corrrectly returns 8388609, but we get 8388610.
  But as we still don't use C99/c++11 in Irrlicht 1.9 I have no easy way to fix this.
- reciprocal_squareroot with IRRLICHT_FAST_MATH is less exact than it claims to be. Just commenting it.
- document slightly different behavior of reciprocal with IRRLICHT_FAST_MATH around 0.
- Kick out IRRLICHT_FAST_MATH for floor32, ceil32, round32. Their results are simply wrong, especially for uneven numbers.
  Like floor32(1) will be 0. or ceil32(-1) will also be 0. round32 wasn't as bad, but also down-rounding 0.5 and less exact.
  I know Burnings still wants those functions, so next commmit will add them again, but with new names and only an internal header.

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6011 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-16 15:48:35 +00:00
cutealien
79800125ae No longer try to use __asm on _WIN64 in VisualStudio.
64-bit asm isn't supported on VS (and I suppose we used 32-bit asm anyway).


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6010 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-16 13:57:31 +00:00
cutealien
5c8f0484da Remove clearFPUException which did nothing.
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
2019-12-16 13:49:38 +00:00
cutealien
070d49e63c Update release checklist to avoid getting 2 copies of docs in doc-folder again.
Thanks to whoever reported that to me once (sorry, I forgot who found that, just had this still on my todo).


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6008 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-13 15:45:31 +00:00
cutealien
44fd5d37ea Change string::split once more
- Delimiters now end up in their own token when keepSeparators is true.
- When ignoreEmptyTokens is false we now add a token at the end when the last character is a delimiter.
While this means some changes, the ignoreEmptyTokens=false didn't work correct in 1.8 anyway, so another change shouldn't break much.
Thanks @manni63 for bringing this up in forum: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=51584&p=299634#p299634


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6007 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-13 15:30:07 +00:00
cutealien
421000e00d Avoid warning on gcc/linux.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6006 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-13 11:28:45 +00:00
cutealien
6c5ae22d49 Get rid of gcc warnings.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6005 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-12 18:04:40 +00:00
cutealien
0b92a66c50 Replace list of hwnd -> IrrlichtDevice mapper with an array.
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
2019-12-12 17:31:22 +00:00
cutealien
6ad09a3a25 Remove unused function getEnvMapperFromHWnd
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
2019-12-12 17:16:51 +00:00
cutealien
7061c42008 Avoid warning on gcc
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6002 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-12 17:04:46 +00:00
cutealien
2f84ab0cdc Avoid some gcc warnings.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6001 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-12 16:52:46 +00:00
cutealien
8310a3fbad Avoid warning and make local variable lower-case.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6000 dfc29bdd-3216-0410-991c-e03cc46cb475
2019-12-12 16:32:41 +00:00