Pascal: what is it and what is it for? (2013)

Libraries
The source code I created, for everyone to use. Includes the CGE components cut out to work independedly.

Cheb's Game Engine:
History
Project summary
Current tasks
Technicals


Miscellaneous bits
I wrote these to simplify my own existence... But they can be useful for you too.

Chentrah

News archive

23.07.2008

I've implemented a workaround for the FreePascal bug #4605 (wrong exception handling in dll). Now instead of using an useless try..except block, the game module (an dll) calls the wrapper procedure of the mother module (an exe) that calls the desired procedure of the game module wrapping it in its own try..except block. Weird? Yes. Perverted? Yes. But it works and it solves the problem.

10.05.2008

I tried to implement the custom mouse pointer support (with ability lo load any image). Well, drawing it using OpenGL is easy. Switching off the hardware system pointer is entirely different matter (And no, I know about ShowCursor(false) but that works for entire screen. I needed something for my window only, something that would not affect another applications)

In the end, the only reliable solution was to load a custom system pointer with a totally transparent image. After implementing it for both Win32 and X, i decided: what the khell? and did the rest of the work.

Now my chentrah has two pointer mechanisms: the usual color one via OpenGL and the hardware 1-bit black and white pointer it uses when fps drops below 30.

19.03.2008

My X server (the Linux graphic shell) started crashing at switching to the terminal via Ctrl+Alt+F1. I used the opportunity to test Chentrah for robustness. Lo and behold, it saves the session with no problem. Ha. Try to find any other engine that would autosave the game at the crash of the entire graphics environment! Try beat this, Micro$oft!

29.01.2008
Lo and behold! A self-debugging program! It can scry the source position by the exception address adding it to the error message. Just like Frankenshtein, I sewn this thing together from the chunks of the dead RTL modules.

25.11.2007
Finally the main execiutable has all its function revamped. The GUI allows reporting error mesages and asking questions without dependence on MessageBox() or xmessage. Also, all the essential files - like the default config or font bitmap - are built into the main executable.

18.11.2007
I hought two weeks ago that I will work on the pixel shaders at last. Bnd what have I done? The text outbut and beginnings of the GUI. To not mention a lot of various ground work.

20.10.2007
I took a look into my window manager, and I felt ill. In no way would I present this bug-ridden crapyard as a part of my coming grand presentation!
There's only one thing I can do: take a scalpel and begin to work... Sheesh! When will I get to the pixel shaders already...?

03.10.2007
It was easier than I expected. The resource manager is up and working, it is a magnitude simpler now. I hope I can prepare the test #13 for the public demonstration soon

24.09.2007
Thinking of it, the resource manager architecture is a total crap. I have to re-create it from the scratch.

Also, I finally got fed with my Linux window manager bugs. This contraption, scrapped together from the pieces of code I don't even fully understand, is beyond any help. I have downloaded the Ogre sources, to read through OgreGLXWindow.cpp and see how to do it right. Now I at least about the existence of such thing as Xrandr X extension. Till now I used Xxf86vm to switch video modes.

24.06.2007
The battle was fierce and seemingly endless, but all the bugs are slain, at last. The resource manager in its minimal configuration is up and running. At last I can continue working on my font/GUI text manager.

Also, accomplised upgrading to Chepersy 0.8.1, full conversion of sources to unicode (utf8), wrapping all function of the exe back-called by the dll into try... blocks (exceptions should *never* cross the exe/dll boundary), and rearranging the folder structure so that it wold be 100% compatible with Linux and Vista (no writing into the program directory).

24.04.2007
Everything is delayed as I move from ASPLinux 11.2 (a heavily patched Russian clone of Fedora Core 4) to Fedora Core 6... Everything is fine and danРІy except the fact that the Russian support is sub-par at best. There is no single font in the Windows cp1251 encoding I use, them all buggers support only koi-8!

13.03.2007
I finished moving from libPng to Vampyre Imaging library. It gives me multitude more — including a lot of supported formats, easy compilation right from the sources, filtering/processing functions et cetera — while the total size of binary files is practically the same. The cge.exe bloated up to 320 Kilobytes (the Linux version up to a Megabyte) but I now don't need to provide the libpng.dll.

04.02.2007
The window manager took the form it will keep for a long, long time. The Linux version now has no fullscreen mode support. The Win32 version performs a complete program restart when you switch from the fullscreen to windowed mode.

This screenshot: Win32- and Linux-versions of CGE coexist peacefully on a single Gnome desktop. What is funny, they both run smoothly, with a full hardware acceleration.

03.10.2006
Test #13 is not ready yet, but I updated Test #12 on the download page, correcting a severe bug that, most likely, caused the test to crash with most of OpenGL drivers. Also its structure updated, to reflect the changes in the engine core. !

20.09.2006
Nooooo! FreePascal is 5% slower!

15.09.2006
Here we go...

15.08.2006
I have corrected an idiotic bug, the arrays were accessed via wrong indexes. As a result, after adding a new class or enumerated type, the game loading routine crashed happily with an AV. The test #12 is updated.

Now, why does it incorrectly process the Russian text in the error messages?..

05.08.2006
Test #12 is ready and uploaded ... sort of. Now, where do I get the money to pay for restoring my Internet access?..

03.08.2006
I optimized it at last. Constructor calls during the loading now take 40% of the overall time. It is the limit for the chosen program architecture. I will optimize the constructors too, but at the later stages.

To feel the real performance of the system I downclocked my system to match the planned minimum system requirements: 1000MHz CPU/200 MHz RAM. (I tried to set it at 133MHz, but the system just doesn't start below 200 - damn progress! Cheb, meet the Clear CMOS jumper. Clear CMOS jumper, meet Cheb).

If the class field cast changes, the class loaded via more complex, converting algorithm, which slows the loading down two-three times. Note that this doesn't affect the classes that remain unchanged.

24.07.2006
The day of stress test. On top of completing my long-awaited persistency system, I invented a very simple but precise and effective method of finding bottlenecks in the code ({$include + Asm + RDTSC) and performed a stress-test of my new system, forcing it to save and load complex structure consisting of a million of objects... I wasn't statisfied by its performance: rate of 200 thousands objects per second is very slow in my opinion, the advanced features like automatic resolving deleted/added object fields, converting enumerated types if the values of their constants were changed, etc., do not justify it.

Anyway, the bottleneck testing was a bit shocking to me. One accessing of a field of a record field of a boject of an object array property of an object takes as much time as dozen calls of virtual methods which perform intensive memory copying to/from TMemoryStream object... Anyway, note to self: keep data strucures simple! Otherwise the compiler doesn't have much chances to optimize anything...

Somebody could ask me: why bother so much with performance of this thing?.. It's unlikely, after all, to have the game world of a million objects... True, but I always dreamed to create some advanced spell effects, many of which require storing the game state and restoring it, or spawning a copy of game worlds and running it parallelly, or even creating one snapshot of game world per frame... For example, clairvoyance where you may have a real, functional foreboding, or time travel where you can hop a few seconds into the past to avoid the mob of monsters - and see yourself, fighting the said monsters back.

20.07.2006
I have no words Except the cuss ones
Why the hell does the FPC RTL report the stack overflow as "Unknown run-time error 202"...?! It cost me many hours of debugging before I figured to use {$memory} compiler directive to set the stack limit at 1Gbyte. On top of all, I don't even have my Internet access now, to ask at the forums. Drats.

03.07.2006
It lives! It lives!!! Mwa-ha-ha-ha-ha-ha!!!
My dream, my persistency system comes true...! Look out, one-two days - and I'll upload the Test #12. The test of my persistency system. What it does?.. Oh, it's simple. It store the entire object tree into a stream, then loads it back. What's so fancy about this...? Well, let's just say the stuff has very high backward compatibility, easily surviving the process of adding or removing fields of a class. Add here a scrupulous parser and validator... They won't let me forget about even a tiny field, keeping the system always consistent.

25.06.2006
Just a bit more effort - and my dream of many years will come true...

23.06.2006
I updated the Test #11 archive(s) on the download page. Corrections:
1. GNU GPL license now included, as it should be.
2. Lazarus project file (optional) updated, with "long strings" option turned on, as it should be.
3. Did I forget to announce here that the test is out?.. Uh-oh.

22.06.2006
Beware of validator

29.05.2006
Module manager 90% completed, console is 80% completed. After that I could consider the engine core finished, and move to more interesting task - the modules themselves!

26.05.2006
As people's philosophy says - "Better spend a day on writing the validator than spend a week later on searching for the cause of some stupid screw-up"...

17.05.2006
I was forced to go back to using LibPng. The built-in FPC image loading modules proved absolutely inefficient, it took them twenty seconds to load a tiny 256x256 .PNG...! For the reference: the LibPng decodes a 4096x4096 monstrosity in less than two and a half seconds!

07.05.2006
The engine core is almost finished... Gosh, how much background work...! The Test #10 coming soon.

18.04.2006
пїЅ) I started revising my strategy. What I was doing before was too epic. *Of course* it stalled. Now I'll follow the advice of Occam-jiisan and cut the extra burden out with the said razor. These need to go: 1) the MODding system (I now doubt anyone but me will work on the project); 2) The automatic generation of the methods of saving/loading the object by the class' field list (I can do it manually). 3) The built-in code editor and the possibility to call the compiler from within the engine (at least, for now).
пїЅ) I revized the project of the actual game that will be based on my engine. It will be a cross-breed of Diablo (auto-generated dungeons, magic, castrated RPG system, etc) and Doom II (reusing the models already existing for Doomsday will greatly reduce the cost). The total quantity of monsters and weapons will be achieved via recoloring ang having the several size variations.

24.07.2005
How could I be so blind! FreePascal has PNG support among its standard libraries - I didn't need any LibPng!
Am idiot.

05.06.2005
The configuration manager has been corrected and simplified (there were too many unnecessary features).
Then LibPng showed its temper, refusing to run under Windows 98. I tried to replace my current version, I implemented a sofhisticated procedure for checking dependencies... When I was ready to give up, I figured that it just can't find zlib1.dll, which was in the same folder... By intuition, I added a comand SetCurrentDir() - and it instantly loaded... Why the hell it worked under 2000 and XP then?..

15.05.2005
Moving to XP highlighted some problems... Surprisingly, caused not by evil Bill's machinations but by internal mismatches in FreePascal RTL: SetWindowLong declaration conflicted with some constants, Compiler yelled about range checking error while evaluating constant value, then everything runned finely... Until I ran it on XP, which choked with my invalid window and started acting funny at attempts to switch the video mode... Corrected that by adding my own declaration of SetWindowLong (and reported the FreePascal bug #4043), but just discovered a new bug - this time in the configuration manager

05.11.2004
Today is historical day. First time in human history, Linux version of CGE started up and did one-two unsure steps forth... It still can't properly shutdown whithout angry yell of the X server, it ignores window resizing, and can'tswith to fullscreen... But it already can draw using OpenGL, and even receives mouse input!..

27.10.2004
Cadaver had twitched slightly.

25.01.2004
I managed to compile my engine using the last beta version of FPC (1.9.2) and get working results... Crashes were due to my own mistake: I stuffed the compiler with too many command-line switches (hell, I can't even remember what most of them are for!)...  Removed that trash - and program immediately stopped crashing.

18.01.2004 Engine structure is something more or less ordered now, "compiling on the fly" works well, and now the detachable part  of the engine has access to functions of OpenGL32.dll loaded by the main program.
I decided to put MOST of the code to the detachable part (including all the rendering), the host program will control only textures, app. window, OpenGL, etc...
Also, added a console (part of the host program) - it's not for typing, it only shows log contents... Anyway, the engine will contain code editor for editing self, so complex console don't needed. Scrolled by the mouse wheel.

15.01.2004
After a long pause, project is continued.

03.06.2003
The first steps on the way of "recompiling on the fly", without restarting program and OpenGL and reloading resources.
I uploaded test #7. It's raw as hell.

02.06.2003
Dumb Delphi incorrectly works with a unit where one piece of code included with {$include} three times with different compiler switches (a good way to keep all declarations in one place). Farewell, Delphi!

23.05.2003
Starting from this day, the engine can be compiled in the FreePascal as well as in Delphi.

11.04.2003
I decided to cardinally change engine building strategy.
Previously, main goal was to achieve controlability and playability in conditions of extremely low FPS (10..15) - that was because in many years I got used to play on low-end hardware (DungeonKeper II on K62-300 without hardware acceleration and with 32Mb RAM, Kingpin on same machine with VoodooII, Morrowind on Duron-800 with GF2MX) - and thus I adapted entire engine structure for principles of execution physics+control and graphics in two separate threads.
After long, meditative thinking I decided that all described above is very wrong. Now I consider playing with FPS lower 25 as especially perverted version of masochism...
So, new strategy is to hold FPS at least 25 - at any cost. For this, all far 3d objects will be cahed as impostors. Multithreading is only for background tasks like texture loading and game saving.

18.01.2003
+ some optimization: 1000-spruce forest runs at 35 FPS!..

13.01.2003
+ loading and rendering *.CME scripts and *.MD2 models
+ switching texture filtering modes (bi-, trilinear, anisotropic) and LOD bias

20.12.2002
Borland rised Delphi price up to the sky. I started migration of my engine to the FreePascal.

29.11.2002
+ menu classes (currently based on the hypertext class)
+ main menu and video mode selecting menu
 - some bugs.. :) it seems, I repeat myself...

27.11.2002
+ working text aligning: to left, right and width
+ text is now a hypertext with working links
 - some bugs

20.11.2002
+ text output with auto-fitting to specified output frame (can include pictures, too)
+ shows FPSes
+ thanks to FMOD, it now supports music in almost any format: OGG, MP3, S3M, MID...
 - some bugs

12.11.2002
+ working show lists, extrapolation and compensation for low FPSes

10.11.2002
+ it works, it works!!! It even can draw a cube!