Warning: Parameter 1 to NP_Poll::event_PreSkinParse() expected to be a reference, value given in /home/pokelege/public_html/nucleus/libs/MANAGER.php on line 370
The Project Gamma Development Progress Blog
The Project Gamma Development Progress Blog


Dec 06, 2011 by DX-MON |
There has been yet more progress, libAudio's module mixing engine now plays a truckload more songs right thanks to our new member, marinu666.

Further to that, he has been busy generating a small side-site so you have something to play and talk over while the main project continues. The site is called PokčCave. Playing helps to fund this project and the servers we have to run for PokčLegends as we have 4 servers to run to even have the game



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,

October Updates

Oct 29, 2011 by Cthulhu |
Hm, think this is the first time I've done a front page update. Lets make this short and sweet and pray I don't break something in the process.

So, lets see...updates..updates.....ah, here we are.

First and foremost, icon support has been added for GTK++. Essentially, this means our programs will have their icons loaded at runtime once they're finished.

Secondly, as far as the game itself is concerned, full-screen support has been corrected, as well as a bug in the library GTK++ that crashed the game when it attempted to detect and apply the current desktop resolution to the game window. Fairly self explanatory, but this means that you'll be able to run full-screen at your current desktop resolution, or in windowed at a resolution of your choice.

We'll be sure to update the blog here as things go on, so stay tuned for our next update!



Aug 23, 2011 by DX-MON |
Opps, forgot to update the blog all the last month.. though I suppose that sums up how busy I've been with my summer job. That's still not letting up save for two weeks holiday, however..

During the times I've not been at my residence, I've been working on the servers for the project and getting them up to scratch and other wonderful stuff like that. My good piece of news from all this is that I've started a new build of UserSrv and I've nicely revamped ChatSrv including fixing some interesting memory leaks. My bad is that I've still not finished the master server, nor have I even started building WorldSrv, and I've yet to get the main architecture of the servers able to run on any number of computers to form a big network to be able to cope with any kind of load put on them.

Signing off for two weeks,

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)


Progress with MapMaker

Apr 23, 2011 by DX-MON |
As promised in the last entry, I have de-restricted the number of layers MapMaker can use in the creation of maps to 232 layers up from just 2. This means that all current bugs in the Hoenn maps can now be fixed where they were caused by layering issues.

I have yet to attempt a texture registry/index of sorts, but I expect that will not take long once I've got MapMaker building on Windows again.

signing off for the moment

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,


Mar 02, 2011 by DX-MON |
Since my last post, the following has happened, along with the completion of enough of my desktop's Cross-compiled Linux From Scratch builds to allow me to build 32- and 64- bit executables of the various components on it:

MapMaker: glGenericWindow-based code has been ported to Future Consciousness' glGenericWindow. This has actually fixed a load of bugs in MapMaker such as exit bugs caused by the old methods.

GTK++: The legacy Subclass/Unsubclass methods have been removed, which means the library is far less broken than it was. The OpenGL classes rewrite is also complete which provides a much nicer inheritance hierarchy and removes several more methods that were introduced to get around how the old hierarchy worked.

Future Consciousness: Having been highly unsuccessful with Python, and having mashed up some of the code by accident during the move from my laptop to my desktop, I have decided that it'll be easier to completely rewrite things like the layout engine for Future Consciousness, drop Python, and find another, different, scripting language to work with - maybe even make a byte-code language which allows programming the engine for certain handlers and associates a byte-code snippet with an action on a button, etc.. It certainly has the advantage of speed over what Python had/has. During moving the code to my desktop, though, I regrettably have to admit that certain non-Python components do not currently link due to some problems in the build system. I should be able to resolve this, though, through the removal of Python which will be the next thing I do. I can, however, say I know for certain why glMessageBox has a crash in it. (I won't say right here right now, but it has to do with two flags in glGenericWindow and a spurious GTK++ call in glMessageBox) The transparency for the connecting screen, as mentioned last post, will be served though adding one extra image and content descriptor member to the layout format. This image must be a grey-scale bitmap of some kind, stored where the Python table used to be (most likely), which can then be directly used with GTK+'s transparency systems, for which one of the functions should be one that takes a bitmap as a transparency map.

Signing off after what will likely be a slighly cryptic and a fairly hard-to-read post,
PS: Sorry that it is cryptic in places and likely to be fairly hard-to-read, I try not doing posts like this one, but it's the only way I can document this progress this time.


Jan 07, 2011 by DX-MON |
Aside from the post I just made, I've not really been able to keep this blog up to date on the progression of the project. Progress has been sketchy, partially because of some intense workload demands placed on me by my University. The demands are fine - I'm paying for them to educate me after all - but it does mean that I've not got as much done as I'd hoped.

AutoUpdater: The server-side components of the automatic update service are all complete. client-side is a different story. The automatic update program itself (AutoUpdater) builds on both Linux and Windows (and likely, therefore, Mac OS(X) too). It has a database of all the installed software and the version numbering of those installations at hand. It can check the version numbers of all the pieces of software against that held in the database and correctly determine if an update is required. It can correctly ask the server for all the files needed in the update of a package, including Operating System specific ones. But: it cannot download the files - that's just a small task of programming on my part, or actually perform updates yet, only the pre-install component works. There are also questions over how we might structure the game's files so that administrator privileges are not required to run an update on the game itself and where we might store files downloaded from the update server while they are pending placement and/or execution.

MapMaker: It is known to me that the MapMaker version of glGenericWindow is broken (it has been for some while) and that MapMaker needs porting over to the far better and far newer glGenericWindow that the game engine itself holds. As soon as this port is done, some legacy code which is also fairly broken can then be removed from GTK++.

GTK++: This is probably the item with the least number of problems. The OpenGL side of it needs a rewrite to get the structure corrected so I don't have massive duplication of the inheritance hierarchy (which gets worse the further down the tree you go on the OpenGL side). However, that rewrite won't take long and is actually rather trivial (besides needing to make a data pointer abstract in the base OpenGL class that will emerge from the rewrite).

Chat: Although my personal copy is now stable on both Linux and Windows, a new Windows release needs to be made and soon. However, this is blocking on AutoUpdater's completion as I want to get the update service distributed to the project admins. NB: The latest version requires the installation of an extra driver which must not be deinstalled. This driver fixes Microsoft's inability to program a proper operating system with regards to Thread Cancelation and Cancelation Points that can be used by a POSIX Threads implementation such as the one the project uses. This driver fixes a plethora of crashes in Chat.

PokeLegends (the client): This is still pending a total rewrite, blocking on the Future Consciousness test program testLayoutEngine. Once that program works correctly, much of the code from that can be ported directly to the client and finalised into a working product. As per the original designs of the client's "Connecting" screen, GTK++/GTK+ allows, far more easily than native Windows APIs ever did, for us to have a transparency gradient on the screen.

Future Consciousness: Due to my Uni work, I've put almost all development of this core component on hold. After exam week this next week (Monday 10th to Friday 15th), I will have another go at fixing the Layout test application and get Python working. For the purposes of the PokéLegends client itself, however, I will disable all Python support on Linux in order to finish fixing the de-initialisation and exit on clicking the "X" button and answering "Yes" to the "Are you sure?" that appears via glGenericWindow/glMessasgeBox.

Signing off with a clearer mind,