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
ARM 32
(SBCs like Raspberry Pi / Orange Pi, as ARMV7R EABIHF)		 stalled, scheduled
(intended as stress test for the engine and for bragging rights) 		n/a 2
ARM 64 planned, in case future SBCs drop 32-bit compatibility
RISC-V 64
(SBCs like VisionFive 2)		 planned
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 CPUs GPUs Details
Work in progress Cortex A7 (VFPv4-16) Mali 400 As long as my Raspberry Pi 2B and Orange Pi PC keep working *and* there is a Debian with fpc 3.2 for them. Otherwise, may have raise the bar to aarch64 and higher models of Mali - purely because of software constraint.
Current Dual Core E2140 (SSE3)
Athlon 64 X2 (SSE3)		 GeForce 8500 GT
Radeon HD 2600		 The hardware of 2007 that has reasonable feature support allowing me to develop without too much hassle. I feel comfortable with SSE3, FBO and GLSL. But any video cards without NPOT texture support are excluded (for example, 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 i suddenly realize my dream is not achievable in the limits of GLES2 and have to correct my ways
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 some third party wrapper like GLOVE. I want to make a working game first anyway.


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 and up 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 in 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).
11 Probably I myself won't touch this thing with a three meter pole. As long as it keeps backward compatibility with 10, Chentrah should run.


Free Pascal Versions Supported

Version Supported Details
1.1 No A long, long time ago I laid foundations of my engine using it. Some ugly hacks of that time still linger in my code.
1.9 No A long time ago i was using it but my code outgrew it.
2.6.4 NO This was my primary development platform until 2020 (until the 3.x branch stopped crashing with internal errors at the mere sight of my phtagn sources). But time finally came to bury the venerated dead.
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.
3.0.4 No Worked perfectly fine for x86 and ARM 32, until I incorporated the fcl-stl map into my engine. The x86_64 versions were unusable anyway, with stabs disabled (see bugs 23365 and 34234)
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.2.2 Assessing... Currently migrating to this version - all the while rehauling my sources -- so I won't be able to tell how it works until my code finally compiles.
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