Apr 8-Apr 16, 1999
I've investigated the SS-buffering algorithm a bit, but I'm not really happy with it. It requires that all extra processing per span takes around 10% of the time for rendering a span, to cut 30% of the total rendering time for a frame. Not unrealistic with the SS-buffer algo, but lots of work that will only make a significant difference if the game display is 640x480 or bigger, and the overdraw is far beyond 50%. (You need parallax scrolling and LOTS of sprites to get more than 50% overdraw!) On a fairly average 320x240 display with 20% overdraw, the SS-buffer algo will, at best, be as fast as painter's...

So, I'll drop SS-buffering for now, and use the SCE format only for fast blits and some other things it makes easier/speeds up. Or perhaps I'll move directly to a slightly different format, that is needed for a new, more efficient algo I might use. (Yep, I have another idea. :-)

What does this mean? Well, you can probably forget about 640x480x16bpp full frame rate games on Pentium class computers, but it will still be possible on a Pentium-II 233, at least with an AGP card. (Running at half frame rate [28-45 Hz] is still playable, so the problem is estetical. It's just that I hate unsmooth animation! :-)

Mar 26-Apr 7, 1999
Eastern. Parents. ICQ... Didn't see girlfriend. :-( But we had a few nice chats on ICQ. :-) Well, I didn't get much coding done, but at least I had a few ideas and sorted some details out. One of these ideas lets parts of objects that are not covered by other objects "bypass" the SS-buffering. The result is reduced number of spans to SS-buffer, and the possibility to handle objects that don't move or change very often more efficiently. (That is, overlays don't have to be rendered at full frame rate. They can even be completely static, thus reducing the CPU load instead of increasing it, as overlays usually do.) 

Mar 25, 1999
Made some minor adjustments on this site. Still no copyright notice on the bottom of the pages though! And no "Who's behind all this?" page... (I have no personal home site to link to, as I haven't got time to do anything decent of the kind...) And no link to Lionhead's site!?! Well, check out the "Programming" forum on their discussion board. Harmony is my user name, and I write far too long posts everywhere... :-)

Mar 22-Mar 24, 1999
Hacked some on the SS-buffer, and worked on some tech docs. I needed to sort out the relation between Physic Space, Logic Space and the render destination (the screen in the normal case) more clearly. I decided to have the Logic objects create, keep track of and delete their representations in Physic Space. A Physic object hangs around until it's owner decides to remove it, which means that the engine can keep it's own internal stuff in it as long as it may need to be rendered. That way the need for creating the data needed for the SS-buffer algo every frame is eliminated - now it's only done every now and then, when a Logic Object decides to show up on-screen. The nice abstraction, flexibility and separation of Logic and Physic space is preserved without performance cost! :-) (And if it should turn out to be inefficient anyway, it's easy to change the way Logic objects show() and hide(), so that the Physic objects are never deleted, just added to/removed from the engine's render table.)

Mar 21, 1999
Additions to the SCE protocol: Reference and Relative Reference Spans. The first one is a span command that reads data through the specified pointer, rather than from the position directly following the command. The later use an offset + a pointer in the header structure, so it can be used as a free form viewport into other surfaces.

Hacked some more on this site and published it! :-)

Mar 14-Mar 20, 1999
Designed an extended S-buffering algorithm that i call Shadow Span Buffering. It uses a modified bintree that allows quick merging of nodes, and it significantly reduces the number of operations to find out where to insert new spans. The result is that overdraw is eliminated in a quite inexpensive way, which in turn results in scene complexity having less effect on rendering speed. (That is, twice the number of sprites doesn't result in twice the CPU load.)

The packed/encoded data format I used to refer to as RLE is now called Span Command Encoding (SCE), which is more correct, as it's main task is NOT to encode runs of identical pixels, and it's using real commands rather than color/mode + distance.

Feb 8-Mar 13, 1999
Worked too hard, slept too much, fooled around with this and that... Anyway, I hacked some Win32/DirectX code. Tried out 640x480 16 bpp, and was quite disappointed with the performance. Writing directly to screen RAM is painfully slow even on an AGP card, and DirectDraw hardware support seems to be fake. Can't get an asynchronous blit to work without stealing CPU power, so writing directly to the screen seems to be the fastest way. The problem is that it's hardly fast enough to render full frame rate without any overdraw on a P-166! A P-II-233 with an AGP card seems to handle almost 100% overdraw, which is still anything but impressive...

Feb 6-7, 1999
Wrote command line decoding, and a generic symbol table for the AGC CLI. It can extract symbol names, labels, operators, keywords, and some more stuff. Realized that linking the AGC engine as a DLL and build the developer's GUI in Delphi is perhaps not a very good idea, since the GUI can't be ported, and another point is that... there isn't much point in it! Interfacing Delphi's VCL with the AGC engine and DirectX as well, may cause more trouble than it simplifies development. And the DLL cannot be debugged in Delphi since it's in C++. So I'll code the DirectX interface in C++ and build the GUI using the AGC scripting language and some generic system interface extensions to the AGC engine. It will be lightning fast, look cool and be portable.

Feb 5, 1999
Hacked some engine code...

Feb 4, 1999
The Physic Space interface design is about finished, and most of the "skeleton" code is written. What's left is proper support for the hard coded graphics formats, and of course, lots of optimizing! ;-) Not many classes left when all was sorted out... Still, I can't see that any useful possibilities are lost. The obvious advantage is that the data flow is simpler and more efficient, and the code gets simpler.

Feb 2, 1999
Now I've sorted the classes out a bit. The missing link was the Renderer class, with it's means of communication with the Logic Space: the Render Table. After adding it and removing some other silly glue classes, a straight and simple data flow can be seen; the View picks the visible Objects, transform their Logic Space coordinates into Physic coordinates and deliver the resulting Render Table to the Renderer, which in turn knows about the Display that knows what Surface to render to.

Feb 1, 1999
Realized that somewhere I took a wrong turn! Too many classes and too little work getting done... I saw that by merging two of the "public" classes into one, everything gets much simpler and more efficient. Why transform the 3D scene in Logic Space into a 2D scene in Physic Space, when no one will ever do anything scene related, or in fact anything at all with objects in Physic Space!?

Jan 31, 1999
Thought that it can be useful to group images of the same size and with format and palette in the same surface object. I added the frame argument to paint(). This will be useful for tiles and also for a surfaces that directly map to the video hardware. Realized that multithreading should be planned for from the ground up, as extra instances of the engine could be used for generating special surfaces used in the main display. (Backgrounds will be handled that way to avoid that very detailed maps slow down the engine.)

Jan 30, 1999
Didn't get too much done today. I got a few more things together in Physic Space. Designed the select()/paint()/deselect() system for surfaces, for ease of use and room for optimizations. Clipping is prepared by select(), as well as protecting the destination surface from being deleted by mistake. I like to have things as safe as possible until it's all working, and it's time for speeding it up. After that stage, unnecessary checks may be #ifdefed out in the runtime version.

Jan 29, 1999
Tired today... (Can't see why - I slept for four whole hours last night!!! ;-) Well, anyway, I removed those local coords from Physic Space. After some thought, I realized that the garbage collector for nodes (that is, almost all objects in the engine) must be able to delete nodes as they're collected, when someone requests it, instead of waiting. This is useful in init scripts, level loaders and other non-real-time tasks. Why collect garbage when you have no problem with the risk of object deletion overhead?

Jan 28, 1999
Wrote this document. I hacked a little more on the Physic Space classes, and wrote a few lines of the "Logic Space" classes as well. Realized that groups of Physic Space objects is a useful thing, but all objects in PS should have PS world coordinates! Local coordinate systems are good for a few things, but they belong in Logic Space.

Jan 24, 1999
Looked around for a gcc compatible C++ compiler, since I use that one under RTLinux at work anyway. And with the Linux port in mind as well... Found EGCS-mingw32, threw it into my NT box and after a while I had sorted out how to get a working, relocatable Win32 DLL out of it. :-) I also found a quite cool source editor/IDE, pcGRASP that I'll probably use from now on.

Jan 21, 1999
Started hacking the base class declarations... :-) The low level "Physic Space" classes took form. Physic Space is the 2D layer of the engine, where coords are based on the screen resolution and the z part is used for z-ordering of objects. The higher level layer is called "Logic Space", and works in full 3D for maximum flexibility. The coordinate system is transformed through "view" objects that may do anything from simply transferring coords to Physic Space through to full 3D rotation and true perspective. That should cover most kinds of 2D games, and then some... :-)

Early Jan, 1999
Started detailed design of The AGC Project. First I was tempted to write most of it in Delphi 4, and throw in low level graphics and sound engines written in C++ and asm, but I changed my mind. (Fortunately, I hope...) The new idea was to write a portable engine in C/C++ and a little asm. Target platforms for now are all i386 in 32 bit PM; Win32, Linux and DOS protected mode.

Winter 1998/99
Things begun to get in order again. Met my wonderful girlfriend. :-) And just a few weeks later; The return of Motivation. Serious thoughts of hacking something fun in my spare time came around, and the AGC project was a natural choice, both because of the interesting possibilities with CPUs clocked far beyond 200 MHz, and simply because it's a dream that's actually been there since just a few years after I begun hacking! (And for the near future, I can't see my girlfriend as often as I would like anyway... ;-)

Summer 1998
Worked too hard, hacked on a Linux project all nights, wrote music, practiced my vocal skills, messed around with the harddisk recording system that refused to work, and eventually lost all motivation and gave up hacking in my spare time...

Winter 1997
Played around a bit with Delphi 1.0 and started thinking of using it for building a cross platform game development kit from Windows to DOS protected mode. Ported Project Spitfire from DOS 16 bit PM to Win16 + GDI just to see if it would be possible to test games in a window. It worked quite well, but needed a brutal misuse of the "multitasking" *harharhar!* to run smoothly. The DOS version works fine in full screen mode though, and I had the idea of spawning a DOS protected mode runtime engine from the development system for more serious testing. Anyway, I called the project "The Arcade Game Constructor", but it never came to much more than plans and a few small test programs. I designed the first version of the run length encoding of graphics to get rid of that pixel-by-pixel-zero-test algorithm. (Which is used in Project Spitfire by the way - had just a few weeks to code the whole thing from scratch, including Mode-X and design of the triple buffered hardware scroller. While Ferenc had to wait for my graphics library before he could code the map editor...)

1990-1998
The idea of creating a useful visual game development tool formed. I thought of some different solutions, but never had any time to start any serious designing. The target at the time was the Amiga and STOS (ST), AMOS (Amiga) and SEUCK (Shoot'Em-Up Construction Kit, C64/Amiga) were the main sources of inspiration.