Commit Graph

8 Commits

Author SHA1 Message Date
cutealien
dd7020c27b Cleanup: Adding break
Just safer in case we add more cases. Also shuts up code analyser.

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6390 dfc29bdd-3216-0410-991c-e03cc46cb475
2022-05-13 12:31:00 +00:00
cutealien
2d5673a1d4 Switch SMaterial to default copy constructor and assignment operator
It's not 100% identical to what we had as I only copied up to MATERIAL_MAX_TEXTURES_USED before, but I think that was rather premature optimiziation.
(the cost for the extra textures is really in other places, don't think the copy here ever matters).
Was a bit based on Mintest patch, but they messed it up: 4931b34625
(because they didn't notice the difference between MATERIAL_MAX_TEXTURES_USED and MATERIAL_MAX_TEXTURES).

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6363 dfc29bdd-3216-0410-991c-e03cc46cb475
2022-04-26 19:22:45 +00:00
cutealien
0c6385cb92 Replace public header guards to avoid using indentifiers reserved by c++
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
2021-08-27 15:03:34 +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
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