Irrlicht Engine

Mel wrote:With regard to the sprite banks. Would be cool to have a simpler way to change the mouse cursor. The sprites thing is okay, but i am wondering if there isn't a simpler way... Like, setCursorSprite(ITexture*) or something...

You have usually a set of mouse-cursors and you shouldn't put them each in an own texture but all on one. That's why the sprite-banks need to have a texture + rectangles to find a sprite and not just a texture. The spritebank itself could maybe be easier - I'm not sure if SGUISpriteFrame really needs to work with indices to textures and rects, at least for now I suppose working directly with texture-pointer and rects wouldn't really cost that much more memory that it's noticeable and it would be easier to work with. But maybe there were more features planned for the spritebank. Or maybe it could get some more tool-functions to make it easier to work with - if you have proposals for that I can try to add them. For now I decided to simply use it as it is and added some tool-functions in the cursor-example instead.

No, is okay, It is best to have all the cursors in a single texture, but the steps to set a cursor are more than expected, and not very intuitive.

Yes, that's what I mean - the spritebank itself could maybe be simplified. Cursors just need a sprite, I don't think there's much to make easier there. But creating sprites is somewhat difficult (also not that much really once you got it) - I think mostly due to the internal structure which needs to be filled, the stuff I mentioned above. I think that the spritebank might have been the last thing Bitplane was working at before his daytime-jobs got more demanding, so maybe there was more planned for it (maybe stuff like rotations, scaling and similar actions etc) and the structures already are planned for that. But I'm pretty much guessing there. I don't want to change that without having a good plan on what to do with spritebanks, so I haven't cared about that part so far. And I didn't want to add more specific-toolfunctions to cursors before sprites are worked out completely as we otherwise get the interfaces in the wrong places. Adding more tool-functions in the example would be fine if you can think of some more.

How about a load function for native cursors? .ani or whatever the format on Windows is.

hendu wrote:How about a load function for native cursors? .ani or whatever the format on Windows is.

I don't have anything against that. Basically I just cared about having hardware cursors and used what was already there in the engine (our sprites) and then added some tool-functions in the example to generate sprites a little easier. Don't know right now where .ani loading would be added (there's also an .ico format and X11 has yet another format or maybe even two) - directly in the spritebank? It isn't something I need right now and I already got a todo that grows way faster than I get items off it, but if someone needs it and implements it well I can add the patch to the engine.

What do You think about drop all currents Irrlicht drivers in a v2.0 and support D3D10+, OGL3+, OGLES 2+ (or 3+). Optionally leave D3D9 and OGL2.1, but with removed fixed pipeline dependencies. I think that started from v2.0 Irrlicht should be more competitive with the current hi-tech engines and drop support for old hardware (< DX10) will be helpful for it (develop process will be easier). Of course v1.9 will have long term support for bug fixes in my scenario.

Actually i think Irrlicht is the engine with best support for old hardware (even better than most commercial engines). doing that will be nice for certain reason but is also a pity. I think that OGL2.1 should not be dropped (well OGL 3.0 can be nice wich is still backcompatible). I'm indifferent at DX.

I don't know, but in my opinion we need to drop:
- Software renderer (we have BurningsVideo witch gives much better results and also a "software renderer");
- DX8 renderer (because i never see the difference in rendering/performance between DX8 and DX9 renderers).

I had asumed that Irrlicht 2.0 will use only the programable pipeline, and that would include DX9 because it is the most stable Windows graphics programming platform right now .I think that the support for DX8 should be dropped already (maybe making a poll for this would be useful to check who actually uses this); Microsoft dropped the support for it long ago.

I think DX8 is kept for people who want to support the old XBox. But no idea how good support for it is anyway by now - I haven't compiled it in a long time. The reason it's kept is mostly that it usually doesn't cost much time (it's basially done anyway and rarely needs any changes). Software renderer is mostly useful for doing dialogs before 3D renderer even starts - for example for selecting your video-driver before program-start in a nice gui.

I see how the argument of "doesn't cost much time" might now no longer be valid when we try switching to a new vertex format. I already wondered how that will work out with the software-drivers...

CuteAlien wrote:Software renderer is mostly useful for doing dialogs before 3D renderer even starts - for example for selecting your video-driver before program-start in a nice gui.

That's right. We have BurningsVideo for this purposes. It is also completely "software" renderer as i know.

If Irrlicht is going to run in Windows 8 Metro style we're going to need D3D11.1 support.

Do those big icons need a PS 5.0 to render?! Oh my!

I'm pretty sure that you don't pass app certification for Microsoft Store if you use anything earlier.

I have a working demo with compressed textures for Irrlicht (openGL only). If some one wanna help making something similiar also for DX Irrlicht will have compressed textures support definitively (wich allows great optimizations both for speedup renderings and using less video memory), if not in the ufficial API at least as extensions.

If in future irrlicht developers want to add the API for compressed textures I'll be glad to write a ufficial patch