To be Done Before Rotating Cube #21 is Released

Hurdle Status Reason
Finishing moving the entirety of mother GUI locic to a specialized module My work is cut out for me. What I created initially was a mess too complex to support. Unification is in order, so that the mother can only display console with one built-in bitmap font. This would allow support of FreeType in the future.
Rehauling GUI classes Almost done. I failed to make it in time for the annual GUI contest but I have added keyboard navigation in preparation for it so that's a plus.
Weeding out travesty in pointer arithmetics I think I got rid of most of it. At least the x86_64 version is much less crash-happy now. Cardinal! Oh, merciful spirits! So much cardinal!
Perfecting window manager for Linux Gathered enough samples and howtos, so far I need to make fullscreen work, at least. And mouse cfapture. And re-check if pen tablet support still works
Making the RPi version work The only part missing is a working window management for Linux. Raspberry Pi 2/3 is the ultimate test platform, bro. It can barely run Quake 3 at 60..80 FPS. Lowest of the low. My strategy is: if RPi can't support something, that something has to be optional. Optimizations for GTX 1060 and Vulkan support are in the tail end of the queue, right after gaining world-wide popularity and hiring a team of 3d artists.
Getting rid of Immediate Mode OpenGL calls Almost done, it will be gone completely when I release Test #21. That mammoth crap is everywhere in the code, because as I was laying the basics in 2006 I expected to finish around 2008 so slightly obsolete API calls shouldn't have been a problem (and I was aiming at GL 1.2 then. I aim at GL 2.1 now)


Obstacles Left Before The Rotating Cube Curse is Lifted

Hurdle Status Reason
Streamlining the mother-to-module interface API I'm shoveling, and shoveling... Mah eyes are bleeding!
Rehauling text rendering and fonts handling Requires texture atlases The old one was convenient but not extendable (if I ever want support for FreeType or Chinese). Plus I have nice pixel fonts I spent a lot of time drawing many years ago. The old system could not utilize them.
Texture atlases In line... Will serve for both player models and terrain meshes
Md3 and md2 with animation Shoud not begin until I have texture atlases One of the necessary tools
Multitextured, cheaply modifable terrain mesh Shoud not begin until I have texture atlases This will be the staple of terrain rendering
Fisheye viewport with 120 degrees support After I have terrain mesh This is how the game will display, once and for ever
Get rid of OpenAL, add support for ALSA and make the sound system at last! Plans only, for now. This is low priority, but necessary. OpenAL has horrible support all around, has terrible latencies and is generally very limiting. I have to build a sound system anyway, on top of low-latency APIs like DirectSound 8 and ALSA (provided by the mother as an opaque abstraction layer).
OpenCL support Contemplating Let's see how physics turns out, first.


PC Platforms Supported

Platform CPU Support Unicode file path support OpenGL OpenGL ES Vulkan
Windows (XP..10), Wine x86 For now this is the only supported platform where most development is focused. Yes 2.1 2

(only as a test platform to help developing for Raspberry Pi. Uses ANGLE ripped out of Firefox)		 No need
x86-64 stalled, waiting for FPC 3.2 Unnecessary
Linux x86 work-in-
progress		 native utf-8 2.1 Unnecessary
x86-64 stalled, waiting for FPC 3.2
Raspberry Pi 2 and 3 (both as ARMV7R EABIHF, 32-bit) Work in progress.

(intended as stress test for the engine and for bragging rights) 		n/a 2
Android No. Making a Java framework would be too much bother.
Mac OS X, iOS   No. Because I consider all Apple products spectacular waste of money.
Any BigEndian platforms PowerPC, Sparc, ... No. Because the porting cost for my database engine would be prohibitive


Free Pascal Versions Supported

Version Supported Details
2.4 No Missing language features make building the project impossible.
2.6.4 YES, with some limitations Still remains one of the most stable development platforms for Win32. and is still the only version that produces working executables for x86_64. I plan on supporting it for all eternity if I can help it. I even made a patch that allows my engine have full Unicode paths support on Windows, able to work when a Windows XP user choses a user name like "／人◕‿‿◕人＼".
Some things are just plain not possible, though:
  • Compiling for Raspberry Pi doesn't work because the compiler is unable to produce working DLLs
  • The SSE support is crippled for x86_64 (compiler crashes with internal errors on some instances of inline assembler code, I disabled those using conditionals that check compiler version)
  • The AVX support is not possible (that's still far future, though)
  • It maybe a bit slow as this Pascal version's code generator is really ancient now.
2.7 No Mix of new and partially unsupported language features makes a confusing mess out of conditional defines
3.0.0 ARM only The ARM version @ Raspberry Pi seems working fine, for now. This is what is present in Raspbian 9 anyway.
The x86 and x86_64 versions, on the other hand, crash with internal errors, unable to build my project.
3.0.2 Unknown Skipped it
3.0.4 Yes, but with re­ser­va­ti­ons Works perfectly fine for x86 and I gradually migrate my focus of development to it, but the x86_64 versions have stabs disabled (see bugs 23365 and 34234), which makes debugging impossible. I fall back to 2.6.4 for building for x86_64.
Trunk Seems like yes Finally can build my project without crashing but I will postpone exploring it in depth until I create a complete, working executable using the boring but predictable 2.6.4 for Win32.
3.2 I'm waiting eagerly for this version to be reached This will be required to finally have stable support for x86_64.