My friend Jon and I have been busy working at the base rendering engine of Laboratory2D for a while. Today, we are glad to announce the 0.3 release of Phoenix. It was more than a year ago since 0.2, but 0.3 marks a lot of significant changes in the engine overall.
If you want a simple to use, high level c++ rendering engine that supports many platforms, manages windows and input, handles shaders and more - It might be worth checking out.
This post covers two things. Debugging Laboratory2D games from Eclipse and Using Chrome to debug Laboratory2D games.
So, Eclipse.
I was busy working in Flash Builder (which is built on eclipse) earlier today,
And one thing i realised is that I never got around to figuring out why I could not get Eclipse to Run the executable, and then connect to it to debug in one keypress. Later on in the evening I tried my hand at installing some other platform features, like C++, to see if that had any handy tools for doing it, and it turns out it did.
It was called a Launch Group, Where I could even specify a delay on each of the stages. Seeing as I have only 2, it was simple.
What does this give me now?
The same features as before, but all on a single button or shortcut. Now when I press F5 I can tell Eclipse to run the game, connect, and show me the scripts running inside the virtual machine. The file with the little chromium icon is in fact the version 'downloaded' from the Laboratory2D executable, as is in the execution state. If you change this file, you can push the changes immediately back into the virtual machine without restarting anything. Check this out (it will be made better when I have time).
Debugging from Chrome
Since node.js was released, a huge interest in everything Javascript and V8 have been powering development on all fronts. One of these, is called Node-Inspector , which allows you to debug Node.js applications from chrome using the native chrome debugging tools that you normally see in web pages. The cool thing is, I use v8, just like node.js does so it allows me to use the same tools.
You can check out the video of how it works here, which also includes live editing the values running inside the windows application running Laboratory2D.
Hopefully soon when I am finishing up the rest of the video tutorials these will also get nice voice overs, captions and more.
I guess at some point I would need some kind of face to release stuff as, especially If i am teaming up with people. They won't want to go under my nickname and nor would I want that.
Instead I have made some kind of logo thingy that will represent anything I do and release.
So, Why i like it
I like logo's that can be used to represent things in different ways. I wanted the right hand symbol of the D to become the main usage, and stylise it based on what I am doing at the time. For example, Here is some kind of camera, a rad looking older guy, a jet pack guy and a messed up pig.
So far, I am happy with the icon's nature and will be using it for my latest project which is running over on this one month challenge blog at the moment while i develop it. I have mentioned the game before, and will post more soon when I have a little more time to spare on writing up details and videos/screenshots etc. For now, you can see some on my youtube page, and the link to the challenge blog.
If there are any errors in the console ( push ` / ~ key to open the console ), errors with the shader, or maybe a crash or anything, let me know! If everything ran smoothly i'd like to know as well, especially if you can tell me what graphics card you have and what frames per second you get (top left top number).
Should look like this, if things went well (except the red colored text). Oh, and i know that the console edit box is rendering blocks. I will fix that.
Laboratory2D uses the simple to use, but extremely powerful bitmap font generator from AngelCode. You can download the generator and see what I mean, the packing options and per channel settings are really handy.
I have a font from Font Squirrel called Capture It , and I have opened up BMFont and I have selected only the characters I want to use in this example.
Then, I set the options like this below,
Then I went ahead and made sure it suited my memory needs (no more than 512x512 in this case), using the handy Visualise option in BMFont, don't worry about that black background, its the alpha mask and won't show up in the font itself.
Then I opened up an image editing program and I made some detailed changes to the font. Added a bevel and some shadowing, some thing like this :
And finally, i opened up Notepad++ (my favorite editor at the moment) and I added some code to test my new font in Laboratory2D.
And then I pressed Run ( Ctrl - Numpad 0 for me ) and I can see the following.
Another interesting note
Because text comes back as a geometry object, you can actually assign the geometry to a sprite, and use the benefits sprites have (like moveto, pulse, fade, etc). Take a look at this video for an example.
That's all for today.
Though there are more feature posts coming this week - keep an eye out. Still have 2/3 posts on features in depth and more like this.
Hello again! This is where I spam about all the cool things I have been doing. To reward your visit, here is one of the earlier designs I had worked through when coming up with the logo for the engine.
The huge refactor
It has been a long and crazy time with the most recent additions to Laboratory2D. I started tearing out the insides of the code to try and decouple the scripting from the core C++ engine so that I could start binding spider monkey. It took a really long time, somehow over the last 8 months i had managed to litter v8 into the core components of the engine. Not in a terrible way, i managed to remove 99% of it over some simple copy pasting - but the event system and the whole sub script system were heavily bound to v8. This had to be fixed.
The escalation
Well as always, while shifting around some code I found some other ugly code. I refactored it. I found some interesting bugs, fixed and refactored. I changed all the layouts of code to be uniform again, I cleaned out all the random code that had yet to be finished or tested and stuck it in another branch. I finally got around to cleaning up the interfaces and systems and I am proud to be at the end of this stretch with a much cleaner code base on the c++ side, a lot less hackish code that i did about a year ago when learning the systems involved - and most of all - a clear and driving direction for the core itself.
The new features
Again a crazy list I won't post here. I finalised the font support for full bitmap font support, with normal scaling, rotation and coloring. Camera systems got large improvements like being draggable and zoomable with a single flag, sprites got a whole new set of handy features, a few more examples were polished and a couple other useful modules have been included in the core (like a handy edit box, with selection, a history and custom properties). I also finalised the networking support for scripting so that a handful of lines of code later, you can have a chat going over the internet.
What about this Beta 2
Well, beta 2 will be the first mostly public release of the engine. Hopefully it will be soon but work and life and other things tend to get in between - so i won't say a time. Just soon. As of now, Beta 2 is almost 100% complete according to my original goals it is merely a matter of getting the documentation and the examples in line with the monolithic changes I have made over the last month or two. That gives me the next short while to finalise the android, iPhone and browser embedding features that I have been working on in the mean time. As with the post mentioning the way I am doing releases - Beta 2 phase will be fixing all the issues reported by the beta users as well as making even better examples and demos. Sometimes, i can't help myself so I jump ahead and get started on the demos to keep me motivated. Expect to see a lot of interesting things as beta 2 rolls out!
The original reason for Laboratory2D is still alive
As a matter of interest, the project that started Lab2D is actually in progress again. Now that the core is stable and the scripting is mature it is a totally different world to work with - we are moving forward at a rapid pace again which is exciting. The scripting opens up opportunities for team members to help even more than before and to really get involved where the C++ before had just isolated me from having the game i wanted. As I roll out releases for this game, keep an eye out on other forums and indie gaming channels for trailers and gameplay teasers and most likely a playable release. For those who are not aware of it, it is an uplink style game (inspired by) and it is something i have wanted to make for many years.
How to obtain the beta now
Its free, It's javascript driven, its fun (and portable).
In the next 3 posts about Laboratory2D i will be covering some of the things I have been working on in Lab2D for my game, and how they benefit you as a user.
Networking.
Networking in Laboratory2D makes use of the small, lightweight and fast library called ENet. http://enet.bespin.org/ENet is described as "a relatively thin, simple and robust networking communication layer on top of UDP". So, think TCP but over UDP. What this means in non-technical speak is that you can get reliable, in order delivery of packets. For example, a card game. The packets that are sent over the network are critical for the functionality of the card game to make sense. If player one has made a move that is not yet notedon player two side, the game cannot continue. ENet allows packets to be sent and internally it will order them, and ensure delivery for you. If a message gets lost along the way, it will resend if it needs to.
Now on the Lab2D side we have another lightweight wrapper. More specifically, the technology inside the C++ core is exposed directlyas functionality in the script language side. Lab2D supports P2P, as well as 'master server' style networking. One client calls net.host(), and another can simply call net.join() and they can play. All the networking is managed by the scripting, and exploits the dynamic nature of the events and language features of javascript so your networking code will be easy to integrate. And, as it is just online networking it is possible that clients can play cross platform too. An iPhone client can connect to a PC client and be connected via P2P or a server. The details of this are up to the game to implement how it will work - but it is a possibility.
Filesystem.
The file system in Lab2D was built to be as secure as possible. Not that it is possible to eliminate security holes, but to allow better controlover what the client program can change. All files packed into the database use a two way system of encryption and compression. Data like textures, images, font files, and scripts - are all packed into the database. On their way in, they are compressed using LZMA (7-zip) compression, and optionally they can be encrypted using a public/private key pair encryption that is tamper proof. What it means - is that if the client or something else has changed the data in the file system at all - it will not be able to unpack the file. This ensures that the clients are playing fair, and that their client has some sort of integrity checking.
Once your files are packed in, the file system tools will allow you to make a shipping package (like a zip file) and your code wll work as expected.There is nothing special required to load a file from the file system, as it maps itself onto the folders for you. To the average user of your game, your assets and scripts will be secure to an extent, to help distribution on digital portals.
The last interesting feature of the file system is that it is possible to do in place updates of files from a remote server. For example - let's say I had written a client script that fixed some issues in the pause menu. I can run a small dedicated server version of Lab2D with a flag that tells it to be able to serve the files to my game's clients. Instead of needing everyone to redownload everything Lab2D will listen for clients who start up.If a client has chosen to update their game, it will automatically update all the latest changes since the last time they updated by version number.It is almost like a 'push' or a commit to version control. You update the server code with a new minor version and whenever the client starts up,if it can access the server, it will notify them of the updates and allow them to update the game quickly and easily.
That wraps up the first of three posts! While all of the features and systems are written in some form or other, certain parts of the above are still being wrapped up in the script engines. They should be in the beta within the next short while.
Well, one thing is for certain I am grateful to be posting this and not something about giving up or moving on. Let me explain.
The whole hindsight thing.
I chose javascript for many reasons. I also chose v8 because it is extremely easy to integrate. It really is. It is also really fast, and easy to build on other platforms.
See when I started building the technology behind this game, my intention was not to get onto as many platforms as possible, at least not with the core codebase. I built the UI system in such a way that i can connect multiple 'viewers' to see that state of the game I am making. That means a native iPhone app, or a web based php system, all of them have the exact same access to become clients of the game, with little or no porting of the core code. The game mainly runs online, so a connection would be required anyway. Your client is actually hosted on a dedicated server, and your 'viewer' will show you what the client is doing.
As time progressed I found myself really enjoying the base technology, and more so enjoying using javascript to make games. I also ended up moving towards a normal usable 2D engine for other people to use (and quite a few are). I added tilemaps, physics, sprite systems, animations etc. What I realised then is some sort of potential for the cross platform factor to become far more of a reality. Port the code to the platforms as native code, and all my games can be portable (as well as anyone else who wanted to use the technology). I had assumed ( about 9 months after i had started ) that v8 was portable to the platforms I was porting to at the time. Mac? Easy. Linux? Easy. Android? Already there. iPhone? Compiled for arm, success!
What I did when building the iPhone version of Lab2D was something monumentally dumb though -
Make sure you do not test ported code on the simulator and be satisfied.
Why V8 engine does not run on iDevices at all.
This is something that took a while to find the REAL reason. Some complained about the SDK Agreements, not really an issue if you are not downloading the scripts. Some complained about the lack of ARM support but of course V8 grew on that pretty quickly for Android.
iOS has a restriction that basically makes V8 not work. Here is a list of the things V8 can and cannot do on iPhone.
CAN - Compile against device SDK's (4.1 in this case). CAN - Run on the device, the arm code and v8 code works as expected (note, this is just the V8 code) CANNOT - Execute any javascript via the JIT compiler.
Why is that? Some said the ARM JIT of V8 emits the wrong kind of assembly for ARM processors and uses a simulator of sorts on android? No, that is not the reason. The reason is - Writable memory cannot be flagged as executable on iOS.
This is simple to understand. A JIT will compile code into memory, and execute it there. This, cannot happen on the iOS platform. Seeing as V8 is, just a JIT compiler, it makes sense why Invoke/Execute crashes on device and not on the simulator.
And then came GameMonkey
At first I thought I had lost out. I was really blown away at what a stupid mistake I had made by not testing earlier. Secondly, the other problem I realised is that V8 does not compile or run on PowerPC Architecture ( there is a port, but not usable yet ). PowerPC powers XBox360, PS3, Wii. That means the chances of me using V8 on those are so slim its not even funny. It also means that MIPS was not there yet either (think PSP).
The options I had included rewriting the entire engine in another scripting language. Rebinding the core engine to scripts can take half a day, but rewriting all of the game engine script code will take some time. And a lot of it relies on the language features to get things done efficiently, meaning a lot more code than I had in JS. It also meant losing the whole purpose of why i wanted to use javascript etc etc. I looked around, I have used many scripting engines before none of which I would choose for this, but I was linked to GameMonkey by the awesome Dylan Cuthbert from Q-Games. While there was a certain trade off, I was more interested in it because of its JS like syntax and other cool features. I started experimenting with the scripting engine and tweaking the VM here and there. What I did notice is that i could actually add the features of JS that I need to the GameMonkey engine, and continue forward with a language that was definitely portable ( as gamemonkey can be seen on all major consoles and platforms ). Instead of porting everything fully, I kept digging around for more possibilities. Most obviously, I would be looking for a javascript engine that was portable that I could use to add support for on the platforms that need it.
And then came SpiderMonkey
Now that I added some support for game monkey, I only added what was needed to test portablity and viability of using the engine. What came next was seeing someone else had used spidermonkey on iPhone before. I also noticed that the post was made in 2008. A long time for an engine to progress. And to be honest, there was no real competition with spider monkey and game monkey in terms of performance. Spider monkey was dog slow not that long ago. Luckily, they have made progress in leaps and bounds with performance and I didn't want to prematurely optimise anything without knowing if it was slow as an embedded engine. So, i grabbed the spidermonkey source code, I made a new static library project and I built the code using a hybrid of their make files and XCode. I hooked up the output library file into a test empty OpenGLES example , and I copy pasted the getting started tutorial into the main.mm file. 2 minutes later, I deployed to device and had spidermonkey functioning 100% on iPhone. On device this time. This was a huge sigh of relief. I can still move forward as planned, without losing much pace except for adding bindings for spider monkey to the core (only about 60 bindings total it seems).
And then there was the engine code
Obviously, I realised that i need to be testing far more if I plan to support other hardware and platforms. I need libraries and code that will definitely work on specialised hardware. I can't afford to spend more time on something I might not be able to use somewhere. It sucks. And If i plan to be using this code on consoles it needs a lot of refactoring for efficiency. When I started the engine code It was more than a year ago now, slowly over that time I had learnt far more about V8, about C++ and C practices, I had started moving to use C based libraries intentionally as they are the most portable and compatible and easily built, I started removing code that was legacy and tidying up all the weird experiments that I had coded in and around the engine code ( like a UV map editor in the UI system! ). I also learnt far more about writing efficient code, only after the code worked in the first place. The whole get it done, get it working, get it faster, get it clean was working wonders in terms of productivity with the little time I had to give the engine, but it added some ugly code along the way.
Inbetween all this, I have read a huge amount on the topic of portable code, portable games and understanding the architectures of consoles, mobile platforms and game engines. If you haven't - be sure to get http://www.gameenginebook.com and also check out http://www.altdevblogaday.org . Both of these links are incredibly helpful when looking to write console or portable code in general. Especially efficient code, memory management and those things that PC doesn't hate on so much.
And then there was a refactor
This weekend I started a pretty large scale change over the entire core codebase. Switching out libraries for proven portable ones, adding a scripting interface that allows multiple scripting engines to exist at the same time, wrapping more of the engine in spidermonkey and gamemonkey, moving away from code with known bad allocation patterns and starting to add custom memory allocation systems in the places where it would count. Portability for me always meant Windows, Linux, Mac for the most part. Now that there is more of a usable toolset here the value of having this available to independent developers on other consoles and platforms is obvious. Plus, it teaches me immense amounts about writing time critical code in an efficient manner.
And then there is a conclusion
iOS - spider monkey (javascript)
Windows, Mac, Linux, Android - V8 (javascript)
PS2, PS3, PSP, XBox360, Wii - GameMonkey
My plan is to move game monkey language closer to JS in all the ways possible, so that less porting between gm and js files will occur, but since I have yet to even test the engine code on any of these platforms ( due to the cost of obtaining a developer kit ) but until then, it is not much concern. Until then the focus will be on getting the engine embedded in browsers, and onto android in full. That is still a lot of options, and still all using javascript. When I do get onto those platforms with testing, and performance tweaking it might mean something different...
But overall, this side project hobby engine is actually so much fun. It is fun to face these challenges, fun to write and learn more about portable programming practices and most importantly - it is really fun to work with the engine to make my own games (which really, was the intention overall).
For now, the engine is of course still usable, still looking for testers, and the source will be available as soon as the refactor is complete. The code will most likely be hosted publically on github along with all the games and engine side code, there is nothing really magical going on there!
Here in Johannesburg we had an awesome time. Games were made (completed?! hax!), people were met and fun was abundant.
With a total of 15 entrants (16 counting the roaming party), we had 8 teams, 8 completed games. For me that is an amazing achievement, especially because of the games that were created. This is a minor wrap up of each of the games, where www.igda.co.za will have a fuller breakdown of the event in the coming days.
Here is each entry, description, screenshot and link!
Team 2 - Hypoxia - Winner : Community vote - overall coolest game , Judges award - Most Innovative
Hypoxia leads to the extinction of vision. If you can not see, you have to rely on your other senses to navigate a dangerous environment and prevent your own extinction. Perhaps you can save some others along the way. note - This game is driven by sound alone !
Heinrich ( Harsi ) , Frans ( Ditsemo ), Marius ( mpeche ) : Entry Link
Team 3 - PlanetEx -Winner : Judges Award - Most amount of fun award (based on community feedback)
You are a god and have become bored with your creation. Time to clean this place up.
Dave ( DamienWrath ) , Dirkie ( dirkieK ), Remert : Entry Link
Team 4 - Chain Reaction - Winner : Judges award - Most random content
Kill off species one by one to kill off humanity last in a puzzle style game.
TechnoViking is the story of olaf, the disco-loving viking, thawed out by global warming, 2000 years after his birth, he has awoken to find the human race extinct. He must now fend for his survival against creatures of the night, using only a hand gun and flash light.
Team 6 - Project Volcano - Winner : Most technical game (think DX10 geometry shaders and crazy flow maths )
Survive as long as possible against the rage of the volcano.
Charl ( Antagonist ), Bobby ( coldan ), Jonathan ( elyaradine ) : Entry Link
Team 7 - KillSat 9001
The puny humans must die! Our Black Ships fill the sky! We shall turn their orbital laser satellite against them! We shall pulp their pathetic arkships! We will crush their last hopes of survival! We will make them EXTINCT!
Gareth ( Gazza_N ), Sven ( FuzzYspo0N ) : Entry Link
Team 8 - Lygophobia
You are the last surviving human. Survive the onslaught. Stay in the light and keep moving.
That wraps it up
A huge thanks to all the participants, to Microsoft especially for letting us use their great venue and it was an honour to have organised an event like this.
Thanks to the IGDA and to Global Game Jam! It was a great experience and we look forward to more.
Don't let me tease too long. Below is the almost complete home page and identity of the Laboratory2D game tech.
What is left?
There are quite a few minor things to tweak here and there, some weird things in the design, some tech issues.
More specifically the beta / testers / builders / accounts and their functionality. The build system will be tied into this front end, along with the rest of the back end stuff, documentation and samples. Once i have all these finished i will be launching the site, not making a big splash for now - as the site is for the next bunch of good news.
Guest blogs
Firstly, i posted a link to a mailing list for a particular piece of my tech puzzle, and got a really good response. Good enough for a guest blog on their main page, which is a huge deal for me. In preparing for that, i want the home page to be up with all the information, links and details you would expect, including downloads and status tracking etc.
That means that i need to get it up as soon as i can, i would really like the engine to make the impression i have designed it for and I am hoping that the posts will be a good step in getting people to know the reasons for this stuff in the first place.
How the accounts work at the moment
As everyone who knows the details knows - the site uses tracking and remembering for a number of things. I have now implemented using Google Accounts and Twitter sign in to ease that process. Most times, you are one click away from being a registered user and enjoy the benefits without yet another login to remember. The one benefit of this is that it makes it a lot easier to manage for everyone - especially us.
New features
Wow, i think this list would be way too much to post in one go. I will more likely post each sample as i finish it here, along with the features it introduced.
Everything from 100% automated tilemaps (including collision, box2D support, trigger events or callbacks) - all in a single line of code - right up to full physics support for box2D 2.1a and more.
