The Project Gamma Development Progress Blog

Continuous Integration

Aug 29, 2013 by DX-MON |
Well, been busy setting up continuous integration services for the project as it's got to that sort of time where it's needed, and it fixes a problem the project has had for a while - only a couple of project members are able to complete builds.

Continuous Integration (CI) is a process where, in our case, every time changes are pushed to the master git server it triggers a build of the repository that changed. That build may also trigger other builds, but the primary objective is to have builds of the changed sources made on as many platforms as the CI server can push the build to in order to validate that the source code still builds and that it still passes all tests devised for it.

If CI is used properly, it provides a central to all developers tool to quickly check the state of the code as well. On top of that, it means that complete builds for all desired platforms are available on the build slaves at the drop of a hat, and if pushes to the git server are frozen, the CI server can be instructed to perform a complete release build as well so this doubles up as a production build server.

To all team members I bid you: Enjoy~ particularly those who contribute code.

Till next time!

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),

Progress and exams

May 27, 2012 by DX-MON |
Unfortunately the last couple of months have been taken over by Uni exams, however the last was yesterday.. so..

The progress:

libAudio moved to Git

MapMaker now has QuadTrees implemented for viewing inactive layers, dramatically speeding editing on higher layers up

First tests of behaviour of the software on Eyefinity were done about a month ago, credit goes to Pingu (a member of FragSoc) for this.
Eyefinity Hoenn Map

Once a week's cool-off (maybe less) from the exams is done with and I get things in gear for the summer, I plan to go back to a minimum of once-a-month updates and things should start to take shape pretty quickly especially once I finish proofing out the concept for QuadTrees in MapMaker and in place of the current map loader.

Signing off for hopefully just a week

Progress behind the scenes

Feb 14, 2012 by DX-MON |
Quite a few things to cover really:

Lots of bugfixing for libAudio. The module mixer now implements all sorts of things such as Offset (aka Delay) right, and is generally looking much better for some major rewriting of various bits.

GTK++ has seen being moved from SVN to Git as part of a transfer programme I've started for the team to move from SVN to Git as our Version Control System. It has also seen various additions that allow it to present things like slider bars.

libImage has also been moved from SVN to Git in the last couple of days. This has given us the unique opportunity to merge it's two development pasts into one repository so we can see everything that happened to the entire library via Git's logs.

We now have a clear idea of how to graft MapMaker to the new QuadTree system and once I have time (I have ongoing practical assessments this term of Uni as well as lab-based exams), QuadTree will be implemented into the game engine and MapMaker and the map IO subsystem updated.

Signing off for now as that should be all,

Happy 2012!

Jan 01, 2012 by DX-MON |
To start the year's first post off, Happy New Year everybody!

First things first.. libAudio. In the last week, 16-bit sample mixing has been implemented, tone portamento has been fixed, and channel persistent volume controls have been implemented, meaning that S3M support is nearly complete along with it's own lovely set of bugs (although much fewer in number than MOD had when I completed support for it, and many probably attributable to the missing commands)

With this, I can proudly say that with the help of the programmers in the PokÚLegends team, we can now use chip-tune music in the game.

Secondly, PokÚCave. Please go take a look and sign up as doing so actually helps us accelerate development of PokÚLegends as it'll buy us the much needed server capacity and such as well as allow me to start giving the team some remuneration that they much deserve for all their voluntary work.

With that, till next time,