Since my artist is still out of commission (and probably will be for another month), I’ve been doing mainly technical things…
Since I was feeling lazy and didn’t want to add the tutorial code yet (since that’s GUI work, and I hate GUI work), I’ve decided to start porting “Cell.ection” (if I haven’t mentioned it yet, that’s the current name for the game, although we’re still arguing between “Cell.ection”, “Cell.Action”, “Cellection”, with different types of writing styles) to personal computers (Windows, Mac, Linux are the targets).
Decided to start with the easy one: Windows, and I partially succeeded…
Found several problems:
-
A small bug: I deleted an object from itself (“delete this”), but I set the animation of that object to false afterwards… curiously enough, this didn’t raise an exception, but it crashed (or more precisely, Visual Studio raised an exception because it detected memory that should have been free altered) because of memory corruption… This behavior didn’t happen on the mobile version because apparently Marmalade doesn’t use the same trick to track this kind of problems.
On allocation (and on debug mode), VS initializes memory to zero, and when a de-allocation occurs, it sets that space to a familiar pattern (like all bytes set to 0xAE or something like that). When an allocation occurs, the system verifies that all the bytes are set to 0xAE, if not someone messed with that memory address after it was released and raises an exception. It’s a neat trick… In this case, messing with the memory like I was doing wasn’t a serious issue (hence no big issue in the mobile), since I deleted the object and set a boolean value to false, so I couldn’t corrupt any new objects in the process, but it could mean something serious. Ah, obviously enough, the heap is all initialized with that mask (or else the first allocation would raise an exception). -
If you look at the screenshot above, the GUI is all compressed… That was a trick to get it to render at all… I didn’t remember, but the D3D API doesn’t allow for negative values on the viewport settings, and that was what I was using to simplify my multi-resolution, aspect-ratio agnostic system… So I’ll have to change the way this works (probably by shifting the viewport to be all positive, and offsetting the objects there to reach the same visual result).
-
The fonts look terrible, due to the larger screen size… they probably look terrible on the mobile as well, but it doesn’t show because the screens are smaller. Need to work something out on this, probably change my bitmap font generator so that it does some multisampling on the fonts, or maybe integrate OpenType to build the fonts in real time from TrueType fonts, adjusting to the resolution.
-
No cursor… In mobiles, we don’t need/want a cursor, but in a mouse based system, it’s kind of necessary… Not only that, but some feedback on the buttons when the mouse is over them is also a bit necessary… This implies having some “ifdef/endif” blocks in the code, which is kind of ugly… Of course I could do this data driven, but sounds a bit like overkill for something like this.
-
File directory structure… Marmalade assumes that all files in a certain “data” directory will be packed into the package for mobiles… Problem is that if I use the same paths on the mobile and PC version, I need to have some DLLs on that directory (FMod, for example), which sucks big time… Probably need to think a bit better on the directory structure, specially to see if I can sort out some kind of override system so that I can have different assets for different platforms (more resolution on the fonts, for example), while keeping the common part together…
This is one of the reasons why this project is so interesting from a learning perspective… Although the code part of it was ported without needing many changes, just create a new VS project and dump the files there, there are still lots of small issues associated with multi-platform deployments that must be addressed (and now is a good time, since I can still change the way SurgeED works to do a better job at this multi-platform asset management).
I’ve also been working on a second port, this time from PC to mobile… An old (unreleased) casual game of mine:
The game won’t work on smartphones, but it’s a good match for tablets… Currently, I’m just trying to get the old code compiled with the latest version of Spellbook, but even that’s been proving hard, specially because of the font, since I changed it a year and a half ago (so that includes the concept of character metrics). Problem is that the hand-worked fonts of Something Fishy were done with the old system and while they worked well with that, they miss information necessary to work nicely with current Spellbook…
Need to fix that, either by generating the missing information, reverting that component to an old state (if I can find an old version of Spellbook pre-change), or *shiver* adding by hand the information…
Finally, also been thinking a lot on the new Image Bank system for Spellbook… I need a way to make it “multi-layer”, so I can have normal maps with the images aswell (some nifty 2d effects and for use with decals)… To do so, I want to add an Image Bank editor/generator into SurgeEd, but I need to think if an Image Bank is a component or a resource (probably both)… I already have a Font Generator in the SurgeEd, but I don’t like the way that turned out, so I‘m thinking to handle any resource editing as a separate component of the editor, with its own specific subsystems, but I haven’t made up my mind yet…
So stay tuned for more developments!