Roadmap

[sfan5]

IrrlichtMt is meant to be copied into Minetest some day, ideally at a point where we can throw away much of the code because we would use SDL2 + our own OpenGL(ES) renderer by then. This issue collects things that should be done.

Cleanup (to be done in any case):

• [x] Unbundle libraries
• [x] Replace build system with CMake
• [x] Drop DirectX, software drivers and unused file formats
• [x] Drop other features we don't use
• [x] Try to identify long outdated code and fix it (ancient Windows/OSX, other API/compiler support or workarounds and similar things)
• Get rid of non-STL containers: (get rid of implementation and ideally also the type)
• [x] + core::map (removed)
• [x] + core::array (wrapped)
• [x] + core::list (wrapped)
• [x] + core::string (wrapped)
• [x] + core::unicode::ustring (removed)
• [x] Remove unused GUI classes
• [x] Remove compressed color formats
• [x] Remove any use of irrAllocator
• [x] Get rid of IrrCompileConfig (#158)
• [ ] sort out the remaining _IRR_COMPILE_WITH_FOOBAR_ defines
• [x] drop methods and things marked as deprecated
• [ ] ...
• [ ] At the very end: Do a cleanup pass over all of the code: make code style consistent, remove IClass / CClass split where feasible, modernize with C++/STL, use MT's way of logging

Features:

• [x] Implement borderless fullscreen
• [x] Fix clipboard Unicode
• [x] OpenGL bindings (#52)
• [x] Make driver implementations use the bindings (remove direct libGL linkage), see #276 for partial work
• [x] Port SDL driver to SDL2
• Feature parity for SDL2 driver:
• [x] + working input, IME
• [x] + OpenGL ES
• [x] + window icon
• [x] + other issues (see #137)
• [x] Use SOVERSION to indicate lack of backwards compat
• [ ] Drop anything but SDL2 (#157)

[rubenwardy]

Shouldn't improving SDL support and removing other drivers be in this list?

[sfan5]

Added.

[JosiahWI]

Minetest does version checking on IrrlichtMt when it calls find_package, but I reckon that isn't being updated on either end to make sure it actually checks for the right version requirements. I got a segfault compiling with the wrong IrrlichtMt/Minetest pair earlier.

[oong819]

will OGLES 2 have dynamic shadow in future?

[rubenwardy]

Wrong repo and issue, see https://github.com/minetest/minetest/issues/11339

[Starconstructor]

Would it be possible to port over Vulkan into this fork? I'd do it myself, but I have a skill issue. Someone else made a Vulkan-supported Irrlicht fork, maybe their code could be brought over here?

[sfan5]

Technically possible, maybe. However if you're thinking of performance improvements or better effects there is a lot of room for improvement if Minetest used OpenGL more effectively / to its full potential. Time is better spent on that instead of a new rendering backend.

[numberZero]

Try to identify long outdated code and fix it (ancient Windows/OSX, other API/compiler support or workarounds and similar things)

See #157 and #158. Also, #160 but that one may deserve its own item (or its own roadmap =). I plan to do #158 and then #160. @sfan5 is that OK?

[sfan5]

I plan to do #158 and then #160. @sfan5 is that OK?

Of course.

[x2048]

If we want to implement normal mapping at some point (e.g. for PBR/detailed reflections/light), we will need vertex tangents from what I know.

[sfan5]

I'll cross that off the list then.

[numberZero]

we will need vertex tangents from what I know.

What’s about fully custom vertex types? With unified, shader-only driver that shouldn’t be too hard. It has some support for that already (see Driver.cpp, lines 34–124 primarily) but for internal use only currently. The interface needs to be sorted out before making that public, though.

Note: for me, support for custom vertex types was among the key reasons to make the new driver.

[x2048]

What’s about fully custom vertex types? 

That would be amazing.

[midn1]

Do I understand correctly that old hardware support is intended to be dropped?

[sfan5]

What are you thinking of when saying "old hardware"?

[midn1]

That answers my question, thanks.