The Project Gamma Development Progress Blog

Apologies for the long wait

Aug 24, 2013 by DX-MON |
Wow, 2 months already gone since I finished my exams. I am sorry that I've not posted in that time although progress, and very neat progress at that, has been made.

The game splash/login screen is now achieved in 22 lines of C++ and it's characteristics are created through Byte-Code scripting now. This means I can start to really make progress on the game client now the engine is getting near being feature complete.

George has been working away nicely on Odreex which is the package we shall be integrating into GTK++ to upgrade font support finally.

Plans have been made for the next development tool which will allow the creation of layout files properly and make designing and building game screens much easier. While this tool is unlikely to be made available to users, once it has been written then the game's content should be fast arriving.

AutoUpdater is the next tool to complete, however, as once it has been finished then distribution of the developer tools and game builds will be much simplified, and an initial installer is all that will be required.

Next time there will be screen shots!

fcsc and mapping progress

Jun 19, 2013 by DX-MON |
Well, it's been a while but all my Uni exams are finally over. I seem to have nicely offset this with some neat progress in the compiler and scripting engine and mapping.

The compiler, fcsc, now understands how declarations of variables work and how basic assignment works. This might not sound like much but this changes the compiler completely from a toy to a serious tool and makes it very useful. Additional work has yet to be done to make it understand the generation of code for operations such as accumulation (+= and -= for those C/C++ programmers out there), however this is some good progress.

FC's code running engine, BCE, now understands deep stack operations such as pops and drops from any location from the top of the stack to 256 entries into the stack. I might lift this limit and make it a fully 64-bit system however this was good enough to get it working for the compiler to use to complete the code generator enough to get variables in. A small RAM-like area might be in the works as well if it turns out that the system is too limited or I need a way to map strings from their table into the processor's spaces.

I have been working for a week on the Hoenn map and have made some good progress on getting the final mainland routes in and continuing to optimise and re-optimise the map. I have also completed the transition of several of the sprites, which frees up much-needed textures. The mapping format needs another tweak however to reduce the amount of redundant information stored and the processing load needed to work with the maps in Quad Tree format as this is more important than mapping speed.

I look forward to the introduction of another team member who is a C programmer and the inclusion of George Makrydakis' works on items such as GTK++'s UTF-8 OpenGL font mapping support.

Till next time,

Parser and code generator in fcsc

Mar 21, 2013 by DX-MON |
Further to my earlier post, the compiler now supports assignment parsing leaving just the C-style comma statement left to do (easy enough but requires a working system for scope tracking and variable tracking to make sense to implement).

I'd estimate the compiler to be 90% complete now seeing as it also generates code for the ternary operator and in implementing assignment support I also tied up a pile of loose-ends in the way the parser handled statements, rendering a small portion of parser code redundant pending removal.

Unfortunately, all things to do with compilers and the subject of parsing have a habit of being very technical, so as a summary for the not-so-technically-inclined: the compiler now understands the language I defined for it with the exception of one bit of grammar, and is able to partially generate a computer program from descriptions in that language.

Signing off,

fcsc Code Generation

Mar 20, 2013 by DX-MON |
Well, work has continued on the compiler which is now around 85% complete.

Progress this time has been made in the area of code generation and storage. The compiler successfully generated code for the first test script last night, almost perfectly matching my hand-coding of it. This makes the compiler suitable to replace the hard-codings used so far and brings the project closer to release seeing as this allows the game's screen layouts to be scripted and greatly reduces the design-to-product time for each screen element.

I plan on getting back onto AutoUpdater's case as soon as I have the missing program elements to complete the client side.

Till next time,

Future Consciousness Script

Mar 02, 2013 by DX-MON |
Well in continuation to my post last night, fcsc now parses complex logic and statements, however has yet to get an assignment parser.

This means that the compiler is now around 80% complete pending code generation sequencing which I have been doing manually.
I post about this as it's the first time I've succeeded in building a non-toy compiler as my C compiler efforts became held up when I tried implementing typedef and structs (IE, custom data types) - not helped by the compiler being written in pure C and being my first.

There will be more to blog about soon as there are several tools that are about to have new releases made and it heralds the upgrade to the new-ish VFS architecture which has been held off by AutoUpdater not being ready. This also means we have a way to program game screens without them being hard-coded - something that has been bugging me since the start of the project.


AutoUpdater and engine scripting languages

Mar 02, 2013 by DX-MON |
It has been way too long since my last post, and a lot has happened - more than I'd want to put in a single post.

I'm in my final year of Uni, however this has not stopped me from using an hour here and there to take a break from my Uni project and modules to put time into the project.

This post is to cover two major areas:
  • AutoUpdater
  • Game engine scripting

Much work has been put into AutoUpdater to complete the service and improve on it's security.
Safe to say, the version that is shortly to be released is both a complete rewrite of the client and the server.
Client side, rSON was created to parse the server output having identified JSON as a good format to pass update meta-data in, and updating, even of the updater's own executable, is now possible.
Server side, a switch has been made in response format from a custom text protocol wrapped by HTTP to JSON so that integrity of the transmission is better verifiable and assured.

Game engine scripting
For a long time I had been looking for ways to integrate pre-existing interpreters or languages into the engine - the first abortive attempt being made with Python, which although a lovely language for what it's designed to do, was a horrid choice of interpreters to try to integrate with.
Finally, about a year ago, I gave up that search and decided to write my own restricted context Byte-Code Engine. Designed with an extremely simplistic RISC instruction set, and 64-bit registers/stack, this finally allowed the sort of scripting on events I was trying to achieve with the other interpreters and languages I'd trialled and failed with.
But that wasn't good enough - you had to know the instruction set in binary and know how to craft instructions the way people did in the 50's and 60's (yuck!) and an assembler would have been no better really. I wanted a proper language I could write event handlers in that the rest of the team can also use to the same effect. So was born Future Consciousness Script (FCS for short) and it's compiler, fcsc. This C-like language has a mostly working compiler that outputs Byte-Code binaries for the game engine and integrates with the layouts system as a source of events. Much better.
The platform supports read-only use of the game engine VFS, sockets to create network protocols with, a wide array of crypto for password and other hashing and cyphering, and more.
Release of this new language to the team for acceptance testing and tweaking will be done when AutoUpdater is released as the compiler should be finished by then.

Disclaimer: For all those out there now shouting their heads off at me that rolling my own engine language was stupid "because it'll be buggy" - compilers and crypto are my special interests, and the engine itself is designed such that if you hack the game engine with it, you modified the engine yourself outside of an FCS event handler therefore not my bug.

Hopefully this post is not too techy (although imho tech-talk is quite unavoidable when talking about scripting the engine),


Dec 03, 2011 by DX-MON |
Ok, been a while since I last said anything here..
I swear there is a good reason and it's down to a project that has taken 5 months of hell to get to Beta (3 of which were months I was going to spend working on PokÚLegends but that got shot rather, now didn't it.. >_>)

Anyway, onto the meat of things:

It's been known by the team and myself for some time that rendering 24k tile maps (the not-yet-complete Hoenn map in this case) was taking quite some time for our poor computers to accomplish. My original and quite n´ave thought on the matter was that the rendering functions were being called all too often and that the requests were stacking up as a result. Well, this was true to a point but fixing that as best I could didn't fix the terrible render lag.

To explain our previous approach: For speed, when reading the map in, each new tile is a new element appended to a doubly-linked list of all the tiles in the current layer and current region (where a region will eventually become a town, or a route, etc). When we came to rendering this, run through every element in the lists checking if the element was in the current viewport or not and if so, render it.

This works great for small (up to about 5000) tile sets and pumps out reasonable performance at those levels, but give it 24k tiles and you have probably worked it out by now.. laggy is putting it mildly..

Our new approach is to directly load all the tiles into a QuadTree (same splitting patterns as the linked lists in terms of regions, etc, so multiple QuadTrees). This actually affords us an unexpected optimisation: you cannot have two tiles occupying the same space in the tree, it's just impossible, so duplicates of the first have to be dropped! Anyway, the reason for using a QuadTree is that they are just like Binary Trees, only.. rather than allowing you to index only linear (1D) data which has a singular unique key, it allows you to *efficiently* index data that has 2 keys - 2D data. Using this and a neat bit of recursion, we end up with a highly efficient storage and recall structure which allows us, with any given viewport, to render the entire map in the same amount of time as it takes to do a binary search for just the tiles that are inside the viewport.

The results are just brilliant, render times have dropped from ~250ms/frame to ~1ms/frame - a nice, dramatic, improvement.

The other thing about this structure is there are a lot of operations you can do on it that are far speedier than our previous approaches, so they will see very heavy use very shortly.

Till next time,

Bytecode Engine!

Jun 13, 2011 by DX-MON |
And comes the biggest leap forward and new feature since a long time ago when the project came into being.

I have successfully designed and built a high-speed byte-code engine into the game engine which uses restricted contexts to allow the loaded layouts to "program" (sequence events in) the engine so that, for example, the login screen can sequence that when the close button is pressed, a dialogue pops up inside the window asking if you're sure you want to exit and allowing you to make a decision and depending on the byte-code behind it, do something to stop the closing of the window.

Once the engine is advanced enough to support all the basics of a layout (I estimate by next weekend), I will move all the controller code for layouts internal to the engine, allowing the client when it uses screens which are just layouts to simply load in a layout and run it, collecting on the results of the run as to what to do next

I know this blog entry doesn't do the new component justice, but I cannot say much more otherwise I'll spoil things and may also give too much away about how it works - which of course is a bad thing.

Signing off for now


Jun 05, 2011 by DX-MON |
Although I have yet to make more progress with MapMaker's new features, I have made progress with Future Consciousness and the project in general on Linux.

I have rewritten all Layout engine routines making use of classes to enable a much faster and much easier to maintain architecture that is also far more resilient to error. This, coupled with getting the build systems fully ironed out for Linux has meant I can and am now running various parts of Gamma on my Linux desktop (64-bit with 32-bit support). A screen-shot showing this follows.

I have also been hard at work with other components such as GTK++, getting rid of several bugs that were plaguing the project but which I couldn't fix due to my test platforms keeping on changing weekly due to automatic updates. My desktop, however, runs my own build of Linux - Time-Bomb Linux (TBL) and I've designed it and built it to be stable and update-less, so that the core of the computer's run time doesn't change at all unless I completely rebuild the box. This enables me to debug code in an environment which I can be completely familiar with the operation and quirks it has. Due to this familiarity, I can more quickly pin-point my own misuses of APIs and differentiate bugs in my own code from bugs in APIs I'm using or general hickups on my part which make it seem as if there's a problem with some API I've called.

So without further ado, here is the PokeLegends layout test running the login screen on my desktop under TBL:
PokeLegends running on Linux
(scaled 25%, click to see full size)


It's been too long again >_>

Apr 17, 2011 by DX-MON |
Ok, two major events (for me at least) have occurred with the base libraries that I'm writing to make this game - libImage and libAudio are what are in question:

  • libAudio's MOD Mixing engine is now working bar for a few miss-tunings. This means it's basically suitable for use for truly 8-bit music in the game while rendering that music in unadulterated high definition for the most part (the lesser part meaning the miss-tunings that a few test songs have).

  • I've been hard at work for a week rewriting libImage and it's test suit so it is fully reentrant and has a smaller number of memory allocations per image. Reentrancy is useful here due to it both ensuring I can keep pointers to image data floating about for as long as I like provided I keep the pointer to the opened file about and making it nigh-impossible to leak memory provided my library had none anyway due to all state data now being held at dynamically allocated places in memory that are specific to each opened file and are in no way shared between files.

  • libImage's tests are far far more thorough and far easier to maintain

All this culminates with my now being ready to re-do all libImage-calling parts of the engine and MapMaker. While making these fixes I am planning to:

  • De-restrict MapMaker from being able to create and use two layers to dynamically creating more than one layer as needed (and automatically removing layers as they become empty and are navigated away from) - this will allow us to complete the Hoenn map where the map data had become too complex for even two layers to cope - think Cycle Way.

  • Generate a texture index for each map loaded that as each texture in the map is processed will be used to check the texture is not already loaded and if it is, just use the OpenGL texture index instead of loading it again and if not, add a new index for the map - this will allow us to use less OpenGL Texture memory and will result in faster map loading due to slightly less opening/closing of texture files and having to decoder the image data for OpenGL then load it in.

  • Use the generated texture index to allow that rather than having to browse for at texture all over again while making maps, if the texture is already loaded into the Texture Index, just use the index to locate the texture to add to the current layer which will make mapping much quicker and again reduce memory footprint for textures.

The evolution of the proposed Texture Index is that any images loaded into OpenGL Texture memory will be stored into an engine-wide index and any duplicates will just use the same Texture Index location thereby preventing loading the same texture twice at any time and helping to reduce load-times of maps as people cross from region to region as many of the textures will already be loaded, so the texture indices for the new map will just map to the old Index locations from previous ones

Apart from being a rather techy post, I hope that actually makes some sense..
signing off for now,