Faced with a rare weekend to myself, and not particularly enamored with the idea of watching rain trickle down the window for 3 days, I decided to get my backside into gear and pick up my programming reins once again.
Despite my fondness for FishEd, and the numerous ideas I have for the Blitz Max version, part of me knows that I could easily spend another 2 or 3 years finishing the project at the expense of Citadel (the whole reason for originally learning Blitz some 5 years ago).
Thus, my motive was clear; shelve FishEd for another rainy day and get Citadel done.
Definitely.
For certain.
Another reason to start being more professional in my approach is my imminent move to the East Coast of Canada; Scary Fish will cease to be a UK company, and will be reincarnated as a digital media company in Canada, where I can take full advantage of the generous funding incentives which the provinces of Nova Scotia, PEI, and Newfoundland have to offer. If I'm going to be a fully-fledged developer again, I need to start developing.
The first task on the agenda was to centralize my blog; I had some entries on LiveJournal, some on the Scary Fish website, and some here on Blogger. After several hours of mind-numbing cutting & pasting, I finally had everything converted across to Blogger, which now means that I can update the blog from anywhere - much more convenient.
The next task involved getting my code to a point where I was happy using it as a basis for the game as a whole; with numerous snippets and external files to contend with, it took a couple of hours to sort everything out.
In actual fact, the technique I used was pretty foolproof; starting with a relatively blank file, I ported across various routines one by one, debugging as I went, and thus wound up with a relatively clean, efficient, and bug-free test bed. It was an interesting way to work - akin to an artist producing a neat drawing based on rough sketches - and might come in very useful in the future...
By the end of the session, I had the scroller, control system, rudimentary bullet system, and basic collision working, and also managed to iron out several irksome bugs in the process.
Flushed with success, I booted up FishEd and began expanding my test map; it was an absolute joy to finally be able to switch between FishEd and the game, making tweaks and changes then toruing the level to see the new additions. Despite the fact that I hadn't used FishEd for a long time, the controls and features felt very intuitive, and it was an absolute breeze to use.
At the end of the session, my thoughts turned to the next stage of development; with a notepad brimming with ideas accumulated over the last 4 years, where on earth does one begin? Enemies? Weapons?
After long and careful consideration, I decided on the following:
1. Define the game framework (add title screen & basic transition to and from the game).
2. Develop the camera system (follow player, follow target, free roaming)
3. Add basic editing features (enemy / background placement)
4. Add basic player / background interaction (lifts, teleports, etc.)
Once these features are in place, I can begin developing things such as the enemy and AI, weapons systems, bonuses and pickups, and environmental hazards.
Now all I need is an artist with a similar vision and plenty of spare time... :)
Tuesday, September 8, 2009
Sunday, March 29, 2009
Codename: Alpha
Spent the last couple of sessions looking around the current code for a convenient place to start tweaking and adding, and decided on the various grids that are used as a visual aid. Currently there's the basic Grid (set at the current tile size), the Brush Grid (set to the current brush dimensions), and the Tile Grid (which overlays the Tile Panel).
At the monent these routines are reasonably well-integrated, but I'm torn between making my code streamline and modular (i.e. one routine that prints all 3 grids) as opposed to just slapping the code in where necessary and avoiding wasting cycles on function calls; ultimately it's cycles, not memory, that is likely to be my enemy, but I'm still not sure.
Once I was familiar with the code, I set about adding a transparency value for each of the grids; once it was in and working, the grids looked about a thousand times better (and the little highlighted pixels where the gridlines cross makes the grid appear reminiscent of graph paper). Finished off the session by adding a transparency value to the Brush plotting routine, and converted across the routine that allows the user to rename the current layer.
At the monent these routines are reasonably well-integrated, but I'm torn between making my code streamline and modular (i.e. one routine that prints all 3 grids) as opposed to just slapping the code in where necessary and avoiding wasting cycles on function calls; ultimately it's cycles, not memory, that is likely to be my enemy, but I'm still not sure.
Once I was familiar with the code, I set about adding a transparency value for each of the grids; once it was in and working, the grids looked about a thousand times better (and the little highlighted pixels where the gridlines cross makes the grid appear reminiscent of graph paper). Finished off the session by adding a transparency value to the Brush plotting routine, and converted across the routine that allows the user to rename the current layer.
Friday, March 27, 2009
Fix Bug, Compile, Rinse, Repeat...
The past few days have been spent tidying up the code even further. Merging my two sets of code, I neglected to consider that my old code wasn't running in SuperStrict mode like the newer code, which meant fiddling around with a hefty pile of routines, making minor tweaks and compiling, followed by more tweaks and more compiling. Essentially, I paid the price of not keeping my code organised and properly structured - I learned a vlauable lesson (until the next time...).
However, the process has forced me to deal with a number of issues, particulalry the subtle differences between Blitz Plus and Blitz Max, so much of my upcoming conversion work will thankfully be a little more straightforward. Eseentially, I now have a rock-solid code base, and can now start importing routines one by one from FishEd (which is about time, as I also have a thousand-and-one neat ideas I want to add).
However, the process has forced me to deal with a number of issues, particulalry the subtle differences between Blitz Plus and Blitz Max, so much of my upcoming conversion work will thankfully be a little more straightforward. Eseentially, I now have a rock-solid code base, and can now start importing routines one by one from FishEd (which is about time, as I also have a thousand-and-one neat ideas I want to add).
Friday, March 20, 2009
Or-Ga-Ni-Zation...
Today saw a welcome return to FishEd, and although not a super-long session, I wanted to evaluate the project thus far, and do a little housekeeping. First of all, I tidied up the screen layout a little, as I'd been throwing gadgets on screen and playing around with ideas without a care. I also took a grab of the screen layout and pasted it into PhotoShop - using a grid is a really easy way to quickly knock up button and GUI layouts that adhere to the various cross-platform rules.
Rounded off the session by going through all my junk files; FishEd's directory was a bit of a mess, and the Max directory now has two versions (one the original, one a cut-down version I send to test pilots). It doesn't pay to have two versions, however, and so a little time was spent tidying up the folders and merging files to bring the project back to just one version.
Rounded off the session by going through all my junk files; FishEd's directory was a bit of a mess, and the Max directory now has two versions (one the original, one a cut-down version I send to test pilots). It doesn't pay to have two versions, however, and so a little time was spent tidying up the folders and merging files to bring the project back to just one version.
Friday, February 20, 2009
Back it up, Back it in, Let me begin...
Today's session started with me hammering away at the power button on the PC and wondering why the machine refused to turn on. I noticed a couple of days ago the power light was on when the PC wasn't, but I attributed this to a recent power outage and the problem went away when I reset the PSU.
However, today's incident brought back echoes from the past where I'd ignored similar tell-tale signs of a dying PSU. Luckily, stores here in Victoria tend to open at 8:30, so I was able to snag a new PSU and get the machine working again within the hour.
My first job was to get my files backed up; I'd negelected to back them up a couple of days previously (thinking, "What's the worst that can happen?"), but today's debacle was all the reassurance I needed that lost files = lost hours.
The bulk of today's session involved tracking down the annoying crashes I'd been experiencing; there were all number of suggestions, including incorrect array sizes, incorrect bank sizes (FishEd uses arrays of Databanks for maps and suchlike), and incorrect variable parameters. After 2 hours trying all manner of things, I threw all my relevant variables up on-screen and noticed a few sinister negative values.
After spotting this problem, it suddenly occurred to me that my new zoom code failed to recalculate two critical variables which control how far the map can be scrolled in any direction. Several keypresses later, the whole caboodle was working like a charm (and what's more, the memory leak issues seem to be a thing of the past). Elated, I did the only thing an ENglish Programmer can do in these circumstances - have a cup of tea. :)
However, today's incident brought back echoes from the past where I'd ignored similar tell-tale signs of a dying PSU. Luckily, stores here in Victoria tend to open at 8:30, so I was able to snag a new PSU and get the machine working again within the hour.
My first job was to get my files backed up; I'd negelected to back them up a couple of days previously (thinking, "What's the worst that can happen?"), but today's debacle was all the reassurance I needed that lost files = lost hours.
The bulk of today's session involved tracking down the annoying crashes I'd been experiencing; there were all number of suggestions, including incorrect array sizes, incorrect bank sizes (FishEd uses arrays of Databanks for maps and suchlike), and incorrect variable parameters. After 2 hours trying all manner of things, I threw all my relevant variables up on-screen and noticed a few sinister negative values.
After spotting this problem, it suddenly occurred to me that my new zoom code failed to recalculate two critical variables which control how far the map can be scrolled in any direction. Several keypresses later, the whole caboodle was working like a charm (and what's more, the memory leak issues seem to be a thing of the past). Elated, I did the only thing an ENglish Programmer can do in these circumstances - have a cup of tea. :)
Thursday, February 19, 2009
Softly Softly, Catchy Buggy...
Today's session didn't go quite as planned (I had a nice list of things I was itching to scratch off my ever-expanding To-Do list), but every little helps. The first task of the day was to implement scaling on the Tile panel, in response to a request from Robin, who also asked if I could include 8x8 tiles in the next version (and thus, the reason for zooming the Tile panel becomes obvious - 8x8 tiles are pretty tricky to see on a widescreen monitor running at STUPID x INSANE resolutions.
The scaling was pretty easy to implement, mainly due to the fact that all the code and calculations were self-calculated and not hard-coded (that's a programming lesson we all tend to learn the hard way...). Finished up the scaling by adding a slider gadget to control the zoom, and although a couple of tweaks remain (i.e. making sure the cursors always stick with the relevant tile, not at the relevant window co-ordinates), it was a fairly simple and effective addition.
My final task of the day involved trying to track down a bug in my Update Map routine, which causes errors when scrolling or zooming out to 50% or 25%. After reducing my code considerably (I needed to chop out the old Zoom code anyway), and refining the whole routine, I was still confronted with errors.
I changed tac and tried to explore another bug, which caused the program to crash when my map array was set to a particular size. While tinkering with different vlaues, the bug in my map code disappeared - this leads me to believe all is not well with the arrays (Blitz+ and Blitz Max handle them in subtly different ways), and though my coding session had to be cut short I'm well on the way to fixing two rather nasty bugs. :)
The scaling was pretty easy to implement, mainly due to the fact that all the code and calculations were self-calculated and not hard-coded (that's a programming lesson we all tend to learn the hard way...). Finished up the scaling by adding a slider gadget to control the zoom, and although a couple of tweaks remain (i.e. making sure the cursors always stick with the relevant tile, not at the relevant window co-ordinates), it was a fairly simple and effective addition.
My final task of the day involved trying to track down a bug in my Update Map routine, which causes errors when scrolling or zooming out to 50% or 25%. After reducing my code considerably (I needed to chop out the old Zoom code anyway), and refining the whole routine, I was still confronted with errors.
I changed tac and tried to explore another bug, which caused the program to crash when my map array was set to a particular size. While tinkering with different vlaues, the bug in my map code disappeared - this leads me to believe all is not well with the arrays (Blitz+ and Blitz Max handle them in subtly different ways), and though my coding session had to be cut short I'm well on the way to fixing two rather nasty bugs. :)
Saturday, February 14, 2009
Strictly Speaking...
Today's coding session involved converting the FishEd Max code to SuperStrict mode, where all variables, and their types, are declared (in short, no more temporary variables called "nob" littering my routines). This was an utterly thankless task, at the end of which the program looked no different than it had two hours earlier.
The advantages of SuperStrict are rumoured to be plenty: reduced compile times, less errors, more efficient internal 'garbage collection', and faster compile times. I didn't notice any of these, but it did have the effect of slowing down the memory leak I discovered a couple of days ago (which is precisely why I converted the code to SuperStrict in the first place), so now the program only creeps up by 1Mb per second, as opposed to 2Mb.
The advantages of SuperStrict are rumoured to be plenty: reduced compile times, less errors, more efficient internal 'garbage collection', and faster compile times. I didn't notice any of these, but it did have the effect of slowing down the memory leak I discovered a couple of days ago (which is precisely why I converted the code to SuperStrict in the first place), so now the program only creeps up by 1Mb per second, as opposed to 2Mb.
Wednesday, February 11, 2009
A Thenth of Thcale...
The window scaling has been proving a little tricky, as I reached one of those classic coding moments: my code was working perfectly, then I changed a single line of code and suddenly everything seemed to break. Ultimately it took about an hour to get the code working again, and thankfully it seems a lot more robust than before. Things happen for a reason, I suppose.
The next step was to re-size the canvas properly, which took a little bit of tweaking to get right, but now I have the option of either resizing the canvas on the fly, or when the user resizes the window border and lets go of the mouse (the latter ties in nicely with canvas resizing when the window is maximized and minimized).
As the canvas was being re-sized in chunks of 32x32 pixels (the default tile size for my testbed code), it suddenly occurred to me that this would change according to whatever tile size the user is currently, er, using. Thus, I needed a quick way of changing the current tile size, which at the moment is impossible as many of the old FishEd routines haven't been transposed into FishEd Max just yet.
However, the tile size issue also ties in with the current tile size for the main window; I plan to make the Zoom feature in FishEd Max a proper zoom, in the sense that the user can zoom in or out and still make edits (the zoom feature in FishEd was purely for map inspection purposes). This feature was largely inspired by feedback from "Robin", an artist who had been using FishEd on commercial projects and wanted 8x8 tiles and the ability to zoom up the edit window to avoid going blind thanks to the contrast of the teensy tile size on a huge monitor.
And thus, I decided to wade in and tackle the viewport scaling at the same time; regardless of the current actual tile size, there is now a viewport tilesize, which may or may not be a scaled up/scaled down version of the current tilesize. When the window/canvas are re-sized, the routine now takes into account the viewport tilesize, and adjusts accordingly. I spent a little bit of time adjusting the relevant routines, and barring a few little tweaks, the user can now quickly zoom in and out and make edits to the map. Already, the new editor feels much smoother, slicker, and faster than FishEd.
Mid way through the coding session, I dedcided to add Tracker bars (yum!) to control the scaling; after about an hour of tinkering and head-scratching, my tracker gadgets still wouldn't appear. After a quick trip to the Blitz forums, it transpired that a new build was available. A click or two later, and after rebuilding all my modules, the trackers were working and my editor was running much faster. Result!
Note to self: check for updates a little more often...!
The next step was to re-size the canvas properly, which took a little bit of tweaking to get right, but now I have the option of either resizing the canvas on the fly, or when the user resizes the window border and lets go of the mouse (the latter ties in nicely with canvas resizing when the window is maximized and minimized).
As the canvas was being re-sized in chunks of 32x32 pixels (the default tile size for my testbed code), it suddenly occurred to me that this would change according to whatever tile size the user is currently, er, using. Thus, I needed a quick way of changing the current tile size, which at the moment is impossible as many of the old FishEd routines haven't been transposed into FishEd Max just yet.
However, the tile size issue also ties in with the current tile size for the main window; I plan to make the Zoom feature in FishEd Max a proper zoom, in the sense that the user can zoom in or out and still make edits (the zoom feature in FishEd was purely for map inspection purposes). This feature was largely inspired by feedback from "Robin", an artist who had been using FishEd on commercial projects and wanted 8x8 tiles and the ability to zoom up the edit window to avoid going blind thanks to the contrast of the teensy tile size on a huge monitor.
And thus, I decided to wade in and tackle the viewport scaling at the same time; regardless of the current actual tile size, there is now a viewport tilesize, which may or may not be a scaled up/scaled down version of the current tilesize. When the window/canvas are re-sized, the routine now takes into account the viewport tilesize, and adjusts accordingly. I spent a little bit of time adjusting the relevant routines, and barring a few little tweaks, the user can now quickly zoom in and out and make edits to the map. Already, the new editor feels much smoother, slicker, and faster than FishEd.
Mid way through the coding session, I dedcided to add Tracker bars (yum!) to control the scaling; after about an hour of tinkering and head-scratching, my tracker gadgets still wouldn't appear. After a quick trip to the Blitz forums, it transpired that a new build was available. A click or two later, and after rebuilding all my modules, the trackers were working and my editor was running much faster. Result!
Note to self: check for updates a little more often...!
Sunday, February 1, 2009
To the Max...
So yet again, almost a year transpires between coding stints; I'm starting to realise that these projects simply have to be done whenever time allows - gone are the days where I could set aside chunks of time to tackle this stuff uninterrupted. My brain needs to learn how to learn, as my maths teacher would say.
Although Citadel has been on the back burner for way too long, I'm really interested in updating FishEd to work in Blitz Max, partly to (maybe) make some money by flogging it to other developers, and partly because the previous version of FishEd was written in Blitz+ and will thus be largely incompatible with the Citadel engine (FishEd, if you remember, was written as an editor specifically for the Citadel project).
I have a shell that I started in July 2007, and armed with a pencil and notepad I recently set to work jotting down all the issues, improvements, and changes I wanted to make to FishEd, including feedback from some people who'd been using FishEd extensively. This time, I want to approach development logically and methodically, which means getting organised and planning ahead.
The first stage involved enlisting help from some of my chums on the YakYak forum; I want Blitz to work in Mac and Linux environments, and thus I need to plan things extremely carefully, especially gadget and screen layouts. After exchanging a few emails, my Mac test pilot is raring to go, but Linux development has stalled due to the fact that the test pilot doesn't have Max GUI (a minor hiccup).
Yesterday was the first 'proper' coding session, and my main task (before I get to do the fun stuff) is to get the window/environment working nicely. I experimented with parent/child windows for the tool panels (as PhotoShop does so well), but I can't really abide them in FishEd; I can appreciate that some people like to have multiple windows overlaying their work area, but to me it's just cluttered and hideous and makes everything less intuitive and more like somebody else's messy desk (i.e. impossible to find stuff).
In the end, I decided to keep the main canvas attached to the top left of the window, and the tool panels aligned to the right. Expanding the window (yes, FishEd afficionados, the program window is now minimisable, maximisable, and resizable) will now increase the size of the canvas in chunks according to the current tile size - I just need to tweak the code to get it running flawlessly.
Although Citadel has been on the back burner for way too long, I'm really interested in updating FishEd to work in Blitz Max, partly to (maybe) make some money by flogging it to other developers, and partly because the previous version of FishEd was written in Blitz+ and will thus be largely incompatible with the Citadel engine (FishEd, if you remember, was written as an editor specifically for the Citadel project).
I have a shell that I started in July 2007, and armed with a pencil and notepad I recently set to work jotting down all the issues, improvements, and changes I wanted to make to FishEd, including feedback from some people who'd been using FishEd extensively. This time, I want to approach development logically and methodically, which means getting organised and planning ahead.
The first stage involved enlisting help from some of my chums on the YakYak forum; I want Blitz to work in Mac and Linux environments, and thus I need to plan things extremely carefully, especially gadget and screen layouts. After exchanging a few emails, my Mac test pilot is raring to go, but Linux development has stalled due to the fact that the test pilot doesn't have Max GUI (a minor hiccup).
Yesterday was the first 'proper' coding session, and my main task (before I get to do the fun stuff) is to get the window/environment working nicely. I experimented with parent/child windows for the tool panels (as PhotoShop does so well), but I can't really abide them in FishEd; I can appreciate that some people like to have multiple windows overlaying their work area, but to me it's just cluttered and hideous and makes everything less intuitive and more like somebody else's messy desk (i.e. impossible to find stuff).
In the end, I decided to keep the main canvas attached to the top left of the window, and the tool panels aligned to the right. Expanding the window (yes, FishEd afficionados, the program window is now minimisable, maximisable, and resizable) will now increase the size of the canvas in chunks according to the current tile size - I just need to tweak the code to get it running flawlessly.
Subscribe to:
Posts (Atom)
