Lots of places where coders did not realize our Printer::log with hint adds a ": " string between message and hint
Which caused uglier messages in a few places (added documentation for that, maybe helps?)
Some added info in a few places
Some whitespace unification
Some spelling unification
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6414 dfc29bdd-3216-0410-991c-e03cc46cb475
BurningVideo Shader emulation pp_opengl.frag/vert frag_BFT_385_0xa0194718
- currently only implemented with depth-buffer disabled inside CTRTextureGouraudNoZ2
- special case of not power of 2 RTT TextureSampler without mipmap and no bilinear filter
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6413 dfc29bdd-3216-0410-991c-e03cc46cb475
This got in the way of allowing to move a camera with right-mouse-button while having a context menu.
Hard to tell which way is "more" correct as this break of behavior probably can also mess up some situations.
There also would be 3rd option of only catching the event when highlighting happens.
Anyway - usually if this should be caught it should be caught for all ui elements and people will check focused or hovered.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6412 dfc29bdd-3216-0410-991c-e03cc46cb475
I thought BitDepth was per pixel back then, but it's per channel. So limit could be broken.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6409 dfc29bdd-3216-0410-991c-e03cc46cb475
Also use tab instead of spaces (as usual in Irrlicht)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6408 dfc29bdd-3216-0410-991c-e03cc46cb475
Just useful to understand what's going on.
Also removing the _CRT_SECURE_NO_WARNINGS as I don't get warnings my VS versions and other examples don't do that (so maybe that was fixed otherwise?)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6407 dfc29bdd-3216-0410-991c-e03cc46cb475
Cameras can render even when they are not in the scenemanager or onAnimate didn't get called for example because they are their parent are invisible.
So let's be safe and add another call to updateAbsolutePosition(). Some cost, but usually we don't have that many rendering cameras, so shouldn't matter (if it ever matters I suppose we could override OnAnimate and add a flag if it _was_ animated since last render call. Maybe that's even useful in general for SceneNodes?).
Similar CSceneNodeAnimatorCameraFPS was using getAbsolutePosition which was only updated after animators, so it was one frame behind.
And documented ICameraSceneNode functions a bit. Especially updateMatrices is a bit of a confusing name unfortunately.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6406 dfc29bdd-3216-0410-991c-e03cc46cb475
Also kicked out "Use constexpr for constants" warning in VS analyser ruleset (we haven't switched to c++11 yet)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6402 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, didn't think it through. Seemed to work at first, but works only if sort() ended up creating the same sorting as is used then for search.
While often the case, this is obviously not guaranteed. And can't do sort per type easily (this works with flags which remember if sorting had been done).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6399 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously search functions only worked when called with the same type as the array elements had.
Which forced users sometimes to create dummy objects to be able to search for elements by another type.
linear_search and linear_reverse_search now work with any type for which <T>::operator== is implemented.
Similar binary_search now works when <T>::operator< is implemented in both directions (T < E and E < T).
Note: It might be possible to further improve binary_search so only one operator< is needed (I think STL managed that somehow).
So if someone likes a challenge - have a go at it! :-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6398 dfc29bdd-3216-0410-991c-e03cc46cb475
Avoids lots of const casts and there shouldn't be a good reason to have those non-const.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6396 dfc29bdd-3216-0410-991c-e03cc46cb475
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
Nothing good could come out of putting negative values into any of those functions.
And they are used a lot in image loaders which often can be tricked into passing large enough values to make those functions be called with negative numbers.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6389 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for the original patch (got modified a bit): dbd39120e7
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
Those are the common formats, but rest of image loaders should also call this some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6387 dfc29bdd-3216-0410-991c-e03cc46cb475
It's to allow image loader to check for sane limits for image sizes.
Idea came from this patch from sfan5 for Minetest: dbd39120e7
Thought solution is a bit different.
Image loader checks not yet added (will come soon).
Also note that limit is to s32. While u32 might work mostly it will run into some troubles with color converter for now (which maybe could be changes). Also 2GB ought to be enough for anybody, right?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6386 dfc29bdd-3216-0410-991c-e03cc46cb475
Based somewhat on a patch in Minetest from sfan5 594de99153
There might be more problems which may be the reason they checked for other values in Minetest, but don't have more info for now and so far this works.
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6385 dfc29bdd-3216-0410-991c-e03cc46cb475
Only needs one addItem function when using default parameters for icon.
Add default parameters for setIcon, insertIcon so they can be used easier with pure text.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6384 dfc29bdd-3216-0410-991c-e03cc46cb475
Before the value was checked, but not put into the return variables.
Header update to show that information in kb not bytes (on all systems, was just documented wrong)
Some cleanup of code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6369 dfc29bdd-3216-0410-991c-e03cc46cb475
a) SpriteBank. error check on non existing textureNumber. Seen in broken Fonts. unified getFrameNr
b) CBillboardTextSceneNode. use getOriginalSize
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6368 dfc29bdd-3216-0410-991c-e03cc46cb475
- allow ICameraSceneNode to accept any values and correct in buildCameraLookAtMatrixLH with normalize_camera_direction.
if disabled defaults to the current v1.9 normalize
b) add initial Rotation to MayaCamera Constructor default 0,0
c) switchToMayaCamera in Examples. Clones FPSCamera default disabled
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6366 dfc29bdd-3216-0410-991c-e03cc46cb475
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
I had somewhat rashly removed operator = in [r6280]
But since c++11 implicit defined copy assignment operator is deprecated when a user-declared destructor exists.
Still... alternative would be adding copy assignment operator but neither that nor the virtual destructor seem to be needed.
So rather removind destructor which seems to add an unnecessary virtual function table for it (seems to be just used like a POD throughout the code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6362 dfc29bdd-3216-0410-991c-e03cc46cb475
See no reason for them. And would have to put back operator= and copy constructor otherwise (realized creating those is now deprecated when having a destructor defined).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6361 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously vertex buffer did some invalid casts to references which could cause it to copy whatever was in memory into the vertex-arrays.
Generally it worked up to S3DVertex - but switch from another type to S3DVertex2TCoords or S3DVertexTangents caused it to be filled with whatever was in memory behind it.
Setter functions in IVertexBuffer have now overloads for all known vertex types.
Also adding const version of IVertexBuffer::getData.
And some warnings in comments about using the array functions (if even we mess it up...)
Also de-deprecate IIndexBuffer::pointer() again. I don't like having 2 functions for same stuff, but in the end it doesn't really hurt keeping it around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6360 dfc29bdd-3216-0410-991c-e03cc46cb475
