To be Done Before Rotating Cube #21 is Released

Hurdle Status Reason
Crushing truckloads of bugs. Very good progress. Bugs and hair-raising coding horrors are falling left and right. It's a slaughter, not a fight. Integrating the modules into the mother executable made me add things I was neglecting - namely, deinitialization and restarting of my database engine. The DLL reload was taking care of that before, erasing everything to a clean slate. Now I have to reset every state properly.
Making "game modules" for all platforms except Win32 into full-fledged executables (including support for several modules in one application) thus limiting the developer mode to Win32 only. I see light at the end of the tunnel now. I hope it's not a train.
The built-in part is almost done but I haven't touched devmode DLLs yet. And the error processing/reporting mechanism.		 Free Pascal isn't there yet, exception handling in threads created by a DLL in particular and DLL support in general aren't too good. I managed to patch that for Win32 at the cost of titanic effort (and fpc 3.2 patches it as well making my patch redundant) but Linux versions aren't that lucky. I have to work around that and making each module a complete engine executable is a viable method. It removes the necessity of making such patches, which take too much time and effort.
Finishing moving the entirety of mother GUI locic to a specialized module Halfway done. 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 I'm shoveling and shoveling and it doesn't end. Testing my ideas on a mock game menu for a competition revealed many small flaws that have to be addressed. Other than that, it is done, just very alpha. I failed to make it in time for the annual GUI contest of September 2018 but I made it for the one in September 2020.
Catching horrible bugs in the asset loading code Postponed: are there any? I suspect now these were induced crashes due to trashed memory. Even the rotating cube now crashes! The rehaul wasn't kind to my mechanisms of background resource loading.


Postponed for the Rotating Cube #22

Hurdle Status Reason
Laying foundations for layered game world Paradigm, chosen. Specialized memory manager, completed. Now to implement the logic of it. This has to be done for my engine to have any worth. See the "Multiplayer based on lockstep-in-the-past with full-world lag compensation via layered physics: allow for MMO-level numbers of players, also epic floods and epic scale destruction with zero impact on network bandwidth." killer feature.


Postponed til the next one

Hurdle Status Reason
Making x86_64 version for windows work Scheduled Will be much easier now that I use built-in modules by default and devmode DLLs not supported with x86_64
Adding a SDL2 framework Scheduled It`s time to let my old X11 framework rest in peace. Only SDL2 will be used in the future (window management only, no video nor sound)
Making Linux version work always Scheduled Requires SDL2 framework implemented and x86_64 version working (Windows first) because Linuxes are exclusively 64-bit nowadays. Building will require Ubuntu 20.10 and newer, for Free Pascal 3.2.0 or newer.
Making the RPi version work Scheduled No more devmode, only built-in modules (and thus horrendous build times).
Raspberry Pi 2 is the ultimate test platform. It could barely run Quake 3 at 60..80 FPS. Lowest of the low. My strategy is: if RPi2 can't do something, that something has to be optional.
Support custom swap files in my class instance memory manager It's already designed with support of this feature in mind I'm afraid I would need this on RPi with its measly one Gigabyte of RAM.


Obstacles Left Before The Rotating Cube Curse is Lifted

FYI: impressed by Fidel Castro's resolution, I swore an oath to never shave until my engine passes the rotating cube stage. After awhile, my beard stabilized at 15cm length, its growth balanced by shortening from me combing snags out, which often ends in tearing a chunk off. I sincerely hope I would not be buried still unshaven like him.

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.


Platforms Supported

Platform CPU Support Unicode file path support OpenGL OpenGL ES
Windows (XP..10), Wine x86 For now this is the only supported platform where most development is focused. This will be the only platform where the developer mode is possible! Yes 2.1 2 (testing only)
x86-64 stalled, scheduled Unnecessary
Linux x86 Dropped: no reason to support, the platform is gone. Major distros only support x86-64 nowadays. native utf-8 2.1 Unnecessary
x86-64 stalled, scheduled
Raspberry Pi 2 to 4 (as ARMV7R EABIHF, 32-bit) stalled, scheduled
(intended as stress test for the engine and for bragging rights) 		n/a 2
Android No. What I created is pointer-based architecture through and through. Porting it to managed platforms is NOT possible.
Mac OS   No. Because of my personal disdain towards Apple: I consider their products spectacular waste of money. Whenever I can spare that much I use it for a vacation at a 5-star Carribean resort instead.
Any BigEndian platforms PowerPC, Sparc, ... No. Because the porting cost for my database engine would be prohibitive


Minimum system requirements

Support Hardware Details
Work in progress Raspberry Pi Model 2 B While it keeps working, I will strive to supportit. May have to change to RPi 4 later, though (I bought a RPi 3 as well but it failed: one tiny capacitor fell off, now the board always trashes filesystem on shutdown necessitating fschk via separate Linux PC each time I turn it on)
Current Core 2 Duo / Athlon X2 / GeForce 8400 GS / Radeon HD 2600 The hardware of 2007 that has reasonable feature support allowing me to develop without too much hassle. I feel comfortable with SSE2, FBO and GLSL. Nothe, though, that any video cards without NPOT texture support are out (including GeForce FX 5xxx)


Graphical APIs Supported

API Versions Support In detail
OpenGL ES 2.0 Target My main target API. Used natively on Raspberry Pi 2, via ANGLE on Windows. It has everything I could think of for my graphical needs, anything above this are just frivolties.
3.0 Maybe If Raspberry Pi 4 drops GLES2
OpenGL 2.1 Yes An efficient substitute of GLES2 for the PC platforms (Windows, desktop Linux). Note that I am intent on mostly using features available in GLES2, with very few exceptions.
3.2 Maybe Just because forward contexts may have better support / optimization. Definitely after I have a couple working games.
Direct3d 9 and up as GLES2 via ANGLE I am currently supporting Google's ANGLE with the Win32 version of my engine. It works well if at a bit lower performance. Future-proofs my engine nicely.
Vulkan ? planned as GLES2 via GLOVE I probably should, someday, support Vulkan natively -- but realistically, I will probably stop at using Think Silicon's GLOVE. I want to make a working game first anyway. Also, Vulkan would definitely NOT be compatible with my debugging killer feature as you cannot share objects created in the mother EXE with a separate DLL.


Sound APIs Supported

Note: the sound subsystem is currently an unimplemented mess that can only do simplest "play a .wav file" as was required for the menu.

My target is implementing my own sound engine with sound effects processed on the GPU to allow effects only usually available to select EAX enthusiasts for everyone and their dog with a piss-poor Realtek chip.

API Support In detail
OpenAL Will remove Whatever little there is now, I will cut it out and drop support. As soon as I implement ALSA so that I have sound in Linux.
ALSA Planned This will be the only sound API supported in Linux.
DirectSound 8 Yes Intended for WinXP, it will stay the sole API for the Windows platform for a while until I get to implementing Core Audio support. Not good on Vista+ due to latency.
Windows Core Audio/WASAPI Planned Intended for Windows Vista and later, this is required for acceptable latencies as DirectSound is a stuffed animal on modern Windozes.


Windows Versions Supported

Version Supported Details
Wine YES I was always aiming at Platinum level of Wine compatibility, from the very beginning: I was using Linux as my primary OS when I was laying foundations for my engine. Runs fine in Wine versions as early as 1.3
98 / Me NEVER It was a cool idea at first but became an unsustainable effort sink as time marched on. I am mortal, I ain&t got an eternity for such frivolities.
2000 Unknown In theory, there is nothing preventing me from supporting Win2k. It's just a hatchling of WinXP, after all. Would require me to install it on one of my Core 2 Duo fossils to check if it works or not, though.
XP YES There is nothing in my code that would prevent it from running in WinXP. I regularly check if Chentrah still runs on my Core2 Duo fossils with their relic video adapters.
Vista Probably Skipped it. There should be no obstacles to Chentrah running.
7 YES It's where my development is focused. I will keep supporting it for as long as I am alive.
8 & 8.1 Probably Skipped these steaming piles. There should be no obstacles to Chentrah running.
10 YES With a few quirks (Chentra reports to Win 10 it is DPI aware while in reality it is not, it just always stretches the game menus to the whole screen).


Free Pascal Versions Supported

Version Supported Details
2.4 No Missing language features make building the project impossible.
2.6.4 (will be) ABANDONED This was my primary development platform until 2020, but time came to bury the venerated dead. 3.x is finally mature enough not to crash on my source code and 2.6 is stifling.
For now support still lingers and I still use 2.6.4 but that's only until I finish the major refactoring.
3.0.0 No Both the x86 compiler and the cross-compiler to x86_64 were crashing with internal errors, unable to build my project at all.
The ARM version in Raspbian 9 @ Raspberry Pi 2 worked fine, but that's historical curiosity now as Raspbian 10 with fpc 3.0.4 superseded it.
3.0.2 Unknown Skipped it
3.0.4 Yes, exclu­ding x86_64 Works perfectly fine for x86 and Raspberry Pi, but the x86_64 versions have stabs disabled (see bugs 23365 and 34234), which makes debugging impossible.
3.2.0 Yes, but com­pi­la­tion is slow Everything works fine except compiler crashing unless I delete all *.ppu from the previous run, thus forcing me to do a full build each time. See bug 37746.
3.3.1 trunk YES Finally compiles without the compiler crashing. It is trunk, though.
3.4 My distant target This would probably be my "recommended" version -- unless some lingering bugs are fixed in 3.2.2