Started cleaning up my working directory and sorting out various files and images for the project; my projects always begin very haphazardly, as I throw files into the game folder just to get stuff working. However, the FishEd project taught me an awful lot about staying organised and filing things in their proper place.
Did a small amount of tinkering with the game: I noticed that the status display I'd mocked up was obscuring a little too much of the playing area. The solution, that of making the lower parts of the status display smaller, was relatively quick, but the status did seem to lose some of its appeal (such is the often case in artistic endeavours). The remainder of today's session was spent sketching out ideas on my trusty notepad, which included some rather tasty new weapon ideas. :)
Monday, August 28, 2006
Sunday, August 27, 2006
Sunday 27th
Managed to get the OO stuff working today in about 20 minutes (one of those classic situations where taking a break from coding will actually help in the long run). I'd also made a couple of silly errors while transposing code from Blitz+, so there was plenty of head-slapping amidst the cheers. Rounded of the day's session by going through my huge collection of fonts to find something suitable for the game.
Saturday, August 26, 2006
Saturday 26th
Today is the semi-unofficial start date fro the Citadel project (unofficial because I was supposed to be writing the game two years ago!). I already had a very rough framework set up in Blitz Max, but today I set about going through some OO tutorials to learn the ins and outs of types, methods, and things of that ilk.
I've always hated the initial stages of learning a new language, even though I know that perseverance reaps its own rewards. After about 4 hours glued to the PC, I finally began adding type-based bullet code to my existing scroller. And, naturally, the bloody thing didn't work...
I've always hated the initial stages of learning a new language, even though I know that perseverance reaps its own rewards. After about 4 hours glued to the PC, I finally began adding type-based bullet code to my existing scroller. And, naturally, the bloody thing didn't work...
Monday, July 31, 2006
Monday 31st
Another few days of tying up loose ends. First up came the creation of the icons for the various EXE files; after a lot of searching and experimentation, I settled on using Icon Workshop from Axialis, which enabled me to knock out the icons in next to no time. Next came a welcome diversion in the form of the Press Release and supporting materials, which will be mailed out to various news sites and organisations on release day (tomorrow...!).
A couple of tweaks to the cursor routine were necessary due to the fact that the "hand" cursor (used to represent Move Mode) wasn't always being displayed properly. I also made a slight change to the Main Window layout, shifting things down a little so that renamed Layer tabs don't interfere with the checkboxes.
After tweaking the installer files and ensuring all debug code is firmly out of the way, it looks like the Editor is finally ready for its official release tomorrow. It's hard to believe this journey started almost two years ago; indeed, reading back over the Blog makes interesting reading, although it's reassuring to see that most of the planned features made it into the final version.
I'd like to take this opportunity to thank everyone who helped out along the way, either with moral support, advice, suggestions, encouragement, or slices of actual code when my brain quite literally refused to work. Particularly, FishEd would not have been completed without the support and encouragement from Paul Maskelyne and Mark Hennessy-Barrett; Paul contributed code and advice in abundance, while Mark chipped in with ideas, feedback, and most importantly, an artist's perspective.
Notable mentions must also go out to Paul Snart, Richard Olpin, Paul Robertshaw, Gary Tonge, Stoo Cambridge, Peggy Parkes, Christine Robinson, everyone on the Blitz Forums, the regulars at YakYak, and not forgetting everyone who has pre-ordered the Editor over the last few days.
This isn't the end of this Blog: I still have a game to write, and there's every chance that a Blitz Max version of FishEd (with Mac support) will make an appearance. In the meantime, pop over to The Official Fished Website for more information.
A couple of tweaks to the cursor routine were necessary due to the fact that the "hand" cursor (used to represent Move Mode) wasn't always being displayed properly. I also made a slight change to the Main Window layout, shifting things down a little so that renamed Layer tabs don't interfere with the checkboxes.
After tweaking the installer files and ensuring all debug code is firmly out of the way, it looks like the Editor is finally ready for its official release tomorrow. It's hard to believe this journey started almost two years ago; indeed, reading back over the Blog makes interesting reading, although it's reassuring to see that most of the planned features made it into the final version.
I'd like to take this opportunity to thank everyone who helped out along the way, either with moral support, advice, suggestions, encouragement, or slices of actual code when my brain quite literally refused to work. Particularly, FishEd would not have been completed without the support and encouragement from Paul Maskelyne and Mark Hennessy-Barrett; Paul contributed code and advice in abundance, while Mark chipped in with ideas, feedback, and most importantly, an artist's perspective.
Notable mentions must also go out to Paul Snart, Richard Olpin, Paul Robertshaw, Gary Tonge, Stoo Cambridge, Peggy Parkes, Christine Robinson, everyone on the Blitz Forums, the regulars at YakYak, and not forgetting everyone who has pre-ordered the Editor over the last few days.
This isn't the end of this Blog: I still have a game to write, and there's every chance that a Blitz Max version of FishEd (with Mac support) will make an appearance. In the meantime, pop over to The Official Fished Website for more information.
Thursday, July 27, 2006
Friday 27th
Bug hunting was on today's agenda, and it wasn't long before problems started to present themselves. First came a problem with the Tile Range exporting function; on closer inspection, the wrong variable was being used by the routine, which made me wonder how it ever worked in the first place (unless I made some drastic changes along the way). After changing just one character to fix the bug, I updated the Docs to make a couple of things clearer.
Next came a slight problem with the Toolbar when running the Editor under Windows XP; essentially, the wrong value seems to be detected by the Editor, even though it works fine under Windows 2000. I popped a post on the Blitz forums to see if it's possible to detect the user's O/S, as that's the easiest way to fix the bug.
Next I noticed a small problem with brushes not being clipped properly at the bottom of the map; this turned out to be a missing "=", and is probably a throwback to the tweaks I made to the Brush routines recently.
A more serious bug reared its head later in the day, with the Map Properties system failing to resize maps correctly. I've had trouble with this routine on a number of occasions, so naturally I didn't feel like delving into the code yet again (particularly as I assumed it had already been fixed). After tweaking variables, testing, tweaking, and more testing, I finally managed to iron out most of the problems; I'll probably sleep on the changes and test it thoroughly tomorrow.
Finally, a breakthrough with regard to the Toolbar problem. I'd noticed that the version compiled on the Win2k machine worked fine on the XP machine - this led me to deduce that my copy of Blitz on the XP machine wasn't updated properly (and therefore contained an old Toolbar bug). After a quick installation, the compiler was updated and the Toolbar working. Good job :)
Next came a slight problem with the Toolbar when running the Editor under Windows XP; essentially, the wrong value seems to be detected by the Editor, even though it works fine under Windows 2000. I popped a post on the Blitz forums to see if it's possible to detect the user's O/S, as that's the easiest way to fix the bug.
Next I noticed a small problem with brushes not being clipped properly at the bottom of the map; this turned out to be a missing "=", and is probably a throwback to the tweaks I made to the Brush routines recently.
A more serious bug reared its head later in the day, with the Map Properties system failing to resize maps correctly. I've had trouble with this routine on a number of occasions, so naturally I didn't feel like delving into the code yet again (particularly as I assumed it had already been fixed). After tweaking variables, testing, tweaking, and more testing, I finally managed to iron out most of the problems; I'll probably sleep on the changes and test it thoroughly tomorrow.
Finally, a breakthrough with regard to the Toolbar problem. I'd noticed that the version compiled on the Win2k machine worked fine on the XP machine - this led me to deduce that my copy of Blitz on the XP machine wasn't updated properly (and therefore contained an old Toolbar bug). After a quick installation, the compiler was updated and the Toolbar working. Good job :)
Wednesday, July 26, 2006
Wednesday 26th
More progress over the last few days, after the Demo received a very warm response from those who downloaded it. First up came a tweak to the cursor routines, as I noticed that the Brush outline wasn't pulsing properly when certain panels were being viewed; while tweaking the routines slightly, I noticed a teensy amount of duplicate code which caused one cursor to flash twice as fast, so after writing a separate function everything was running a little bit more efficiently.
Next came a small change to the Test Map system, as there was no on-screen indication that the user was in Test Map mode (this took slightly longer to implement due to the fact that there are two sets of control code, and I was looking at completely the wrong one! ).
Following some feedback from the YakYak forum regarding CPU usage, I tweaked the event system so that switching to another application suspends the editor and frees up valuable processing time.
The final job on my list was a slight tweak to the INI file routine (again!) in order to store the window size (FishEd's main window can be resized to suit larger displays). This also involved tracking down a small problem with the resizing routine, which for some reason wasn't accurately centring the window vertically. Further questions arose regarding the window setup: do I create the window then resize according to the user's preference, or set up the window correctly from the outset?
After a couple of hours scratching my head, trying new things, and tweaking values, the system was working perfectly, thanks in part to the numerous initialisation routines which allow all manner of variables and arrays to be changed on the fly.
Next came a small change to the Test Map system, as there was no on-screen indication that the user was in Test Map mode (this took slightly longer to implement due to the fact that there are two sets of control code, and I was looking at completely the wrong one! ).
Following some feedback from the YakYak forum regarding CPU usage, I tweaked the event system so that switching to another application suspends the editor and frees up valuable processing time.
The final job on my list was a slight tweak to the INI file routine (again!) in order to store the window size (FishEd's main window can be resized to suit larger displays). This also involved tracking down a small problem with the resizing routine, which for some reason wasn't accurately centring the window vertically. Further questions arose regarding the window setup: do I create the window then resize according to the user's preference, or set up the window correctly from the outset?
After a couple of hours scratching my head, trying new things, and tweaking values, the system was working perfectly, thanks in part to the numerous initialisation routines which allow all manner of variables and arrays to be changed on the fly.
Saturday, July 22, 2006
Saturday 22nd
Another furious coding session today, as I'm pretty determined to get the new demo released as soon as possible. Kicked off by checking the setup routines for the Undo/Redo routines, to ensure that the buffers used are always the right size (especially important in the Resize Map routines).
Then I set to work on putting together the installer; I'd already done lots of groundwork on this, so it was a simple matter of putting the right files in the right place and hitting the "compile" button. A few tweaks were needed here and there (the demo version, for instance, has its own set of cut-down I/O routines), but the process was pretty straightforward.
As is usual when I start delving into old code, I realised I'd neglected to include a couple of variables and setup calls in the INI file routines; this was a useful experience, as I then realised one variable wasn't being stored or read properly (not that anyone would notice unless they were really paying attention...).
Next I tackled some website issues, adding an introduction page, ensuring that the various email forwarders were set up, and tweaking the download page to suit the new installer.
Then I set to work on putting together the installer; I'd already done lots of groundwork on this, so it was a simple matter of putting the right files in the right place and hitting the "compile" button. A few tweaks were needed here and there (the demo version, for instance, has its own set of cut-down I/O routines), but the process was pretty straightforward.
As is usual when I start delving into old code, I realised I'd neglected to include a couple of variables and setup calls in the INI file routines; this was a useful experience, as I then realised one variable wasn't being stored or read properly (not that anyone would notice unless they were really paying attention...).
Next I tackled some website issues, adding an introduction page, ensuring that the various email forwarders were set up, and tweaking the download page to suit the new installer.
Friday, July 21, 2006
Friday 21st
After a frantic few days clearing the decks in "the real world", I spent almost two solid days in total tackling the Undo/Redo functions. My logic seemed impeccable, but problems occurred when the user switched to a different Layer. After repeatedly tracing through the code step by painstaking step, it became apparent that an extra step needed to be inserted.
When a project is first started (or loaded), the first action performed will also save out the initial state of the current Layer; thus, when Undo is triggered, the user can step back to the start. With me so far? Now, this is all well and good until the user changes Layers and then makes an edit; using Undo to step back caused the program to miss out a critical step, that of saving the initial state of the Layer that was just activated. And then, of course, the Undo and Redo routines need to be told to ignore this extra step under certain circumstances.
To cut a very long and tedious story short, and after re-writing the routine more times than I care to remember, I finally got everything working (a number of bugs crept in, but this was down to the various Tool routines not calling the Undo Store function properly).
Once this was done, I removed a small piece of code I'd added to allow the user to change the number of Undos; after careful thought, I decided to fix the number at 99, as the invisible steps stored by the program also count towards the total and things could potentially get a bit confusing (especially for me!). Next came the task of checking all Drawing Modes to ensure that the Undo calls were in their correct spots, then another couple of tweaks to ensure that the precise screen/Layer co-ordinates are saved and restored as part of the Undo process.
With the heavyweight tasks out of the way, I set to work on a number of little tweaks and housekeeping chores: first came a small bug in the Update Map routine, which caused the program to crash if the user used drawing tools on a Layer with no Tileset loaded. Next I added the Circle Mode and Circle Fill Mode to the Tools menu (something of an oversight on my part), and updated the documentation accordingly.
The file and I/O routines underwent some tweaks, first in the form of an Undo Reset function, called whenever a Project is loaded or the user chooses New, for example. While digging through the I/O code, I noticed that the Map Set loading routine fails to accommodate maps that might be smaller or larger than the current ones (something of a throwback to the way the Editor worked in the early days). A few quick tweaks later, and the oversight was rectified.
As well as finalising the Project I/O, the final job of the night involved adding some checks to the Map loading code, allowing the user to Undo if a map file is accidentally loaded over the current Layer (this only works for Map files / single Layers, as opposed to Map Set files which load over all Layers, but is an extremely useful addition).
With just a handful of minor things to tackle tomorrow, including a new Demo Version and putting together the installer, it looks like the light at the end of the tunnel is finally here...
When a project is first started (or loaded), the first action performed will also save out the initial state of the current Layer; thus, when Undo is triggered, the user can step back to the start. With me so far? Now, this is all well and good until the user changes Layers and then makes an edit; using Undo to step back caused the program to miss out a critical step, that of saving the initial state of the Layer that was just activated. And then, of course, the Undo and Redo routines need to be told to ignore this extra step under certain circumstances.
To cut a very long and tedious story short, and after re-writing the routine more times than I care to remember, I finally got everything working (a number of bugs crept in, but this was down to the various Tool routines not calling the Undo Store function properly).
Once this was done, I removed a small piece of code I'd added to allow the user to change the number of Undos; after careful thought, I decided to fix the number at 99, as the invisible steps stored by the program also count towards the total and things could potentially get a bit confusing (especially for me!). Next came the task of checking all Drawing Modes to ensure that the Undo calls were in their correct spots, then another couple of tweaks to ensure that the precise screen/Layer co-ordinates are saved and restored as part of the Undo process.
With the heavyweight tasks out of the way, I set to work on a number of little tweaks and housekeeping chores: first came a small bug in the Update Map routine, which caused the program to crash if the user used drawing tools on a Layer with no Tileset loaded. Next I added the Circle Mode and Circle Fill Mode to the Tools menu (something of an oversight on my part), and updated the documentation accordingly.
The file and I/O routines underwent some tweaks, first in the form of an Undo Reset function, called whenever a Project is loaded or the user chooses New, for example. While digging through the I/O code, I noticed that the Map Set loading routine fails to accommodate maps that might be smaller or larger than the current ones (something of a throwback to the way the Editor worked in the early days). A few quick tweaks later, and the oversight was rectified.
As well as finalising the Project I/O, the final job of the night involved adding some checks to the Map loading code, allowing the user to Undo if a map file is accidentally loaded over the current Layer (this only works for Map files / single Layers, as opposed to Map Set files which load over all Layers, but is an extremely useful addition).
With just a handful of minor things to tackle tomorrow, including a new Demo Version and putting together the installer, it looks like the light at the end of the tunnel is finally here...
Tuesday, July 11, 2006
Tuesday 11th
Yesterday's session threw up a small bug in the system which allows Tile sizes to be changed; everything worked from going from 32x32 upwards, but not down to 16x16. More confusing still, the error was contained in the Map display routine, which should remain completely unaffected by the variables connected with Tile sizes.
I was dreading the impending hours of bug hunting, but luckily after tracing through the code a number of times, the solution suddenly presented itself (and was a quick fix, requiring a couple of variables to be reset). The problem stemmed from the fact that the Map offset wasn't being reset, and as the offsets change depending on the Tile size (because there are more/less Tiles on screen), this was causing the Map display to go a bit wonky.
After this I corrected an oversight in the Close Tileset function, which neglected to reset the Tileset's filename (and therefore, closing a Tileset then choosing Refresh Tileset caused it to pop back up again). This might actually be a nice way of bringing back a Tileset closed by accident, but for now it'll stay as-is.
Next on the agenda came a slight tweak to the Documentation, to include yesterday's new Brush grabbing system (I'm desperately keen to keep on top of these doc changes, as it's a royal pain to do lots of updates in one go).
Finished off today's session by tweaking the I/O routines. First came the task of adding error handling to the Static and Parallax loading code (when a Project file is loaded, the program needs to check that it can actually find the files specified in the paths that were saved when the project was saved). This was something of an oversight, as I'd added the code to do this for Tilesets but neglected Static and Parallax layers.
This also tied in nicely with a small tweak to allow me to specify file locations for the Tileset, Static, and Parallax images. When FishEd is released I want to include example images and an example project file; however, as the program stores the absolute path of all images loaded, and given that the actual installation drive and folder could be different on every machine, I needed to devise a way to always make my example project file look in the fished\graphics folder.
After scratching my head over this, the solution was both simple and elegant: when I save my example file, I can set a special flag that tells the program that this is my special example file. When the images are loaded in, it checks this flag and tweaks the directory so that the file is loaded from the correct place. And, rather neatly, the error handling is still in place just in case the user deletes or moves the example files.
With those tasks out of the way, I only have a handful of things left to do:
1. Finilase Project I/O to cope with any recently-added variables.
2. Remove menu options for incomplete or missing functions (which will probably appear in the next version).
3. The dreaded Undo / Redo functions
4. Test, test, test...
Hopefully I can get everything wrapped up by the weekend, which would give me and my loyal Beta Testers a couple of weeks to iron out any major bugs before the product goes gold. After that, beer and a holiday. :)
I was dreading the impending hours of bug hunting, but luckily after tracing through the code a number of times, the solution suddenly presented itself (and was a quick fix, requiring a couple of variables to be reset). The problem stemmed from the fact that the Map offset wasn't being reset, and as the offsets change depending on the Tile size (because there are more/less Tiles on screen), this was causing the Map display to go a bit wonky.
After this I corrected an oversight in the Close Tileset function, which neglected to reset the Tileset's filename (and therefore, closing a Tileset then choosing Refresh Tileset caused it to pop back up again). This might actually be a nice way of bringing back a Tileset closed by accident, but for now it'll stay as-is.
Next on the agenda came a slight tweak to the Documentation, to include yesterday's new Brush grabbing system (I'm desperately keen to keep on top of these doc changes, as it's a royal pain to do lots of updates in one go).
Finished off today's session by tweaking the I/O routines. First came the task of adding error handling to the Static and Parallax loading code (when a Project file is loaded, the program needs to check that it can actually find the files specified in the paths that were saved when the project was saved). This was something of an oversight, as I'd added the code to do this for Tilesets but neglected Static and Parallax layers.
This also tied in nicely with a small tweak to allow me to specify file locations for the Tileset, Static, and Parallax images. When FishEd is released I want to include example images and an example project file; however, as the program stores the absolute path of all images loaded, and given that the actual installation drive and folder could be different on every machine, I needed to devise a way to always make my example project file look in the fished\graphics folder.
After scratching my head over this, the solution was both simple and elegant: when I save my example file, I can set a special flag that tells the program that this is my special example file. When the images are loaded in, it checks this flag and tweaks the directory so that the file is loaded from the correct place. And, rather neatly, the error handling is still in place just in case the user deletes or moves the example files.
With those tasks out of the way, I only have a handful of things left to do:
1. Finilase Project I/O to cope with any recently-added variables.
2. Remove menu options for incomplete or missing functions (which will probably appear in the next version).
3. The dreaded Undo / Redo functions
4. Test, test, test...
Hopefully I can get everything wrapped up by the weekend, which would give me and my loyal Beta Testers a couple of weeks to iron out any major bugs before the product goes gold. After that, beer and a holiday. :)
Monday, July 10, 2006
Monday 10th
Another hectic few days of work; with the keyboard shortcuts finally completed, I set to work on the docs (which required a few tweaks as tables copied from Word aren't particularly elegant when pasted into FrontPage), bringing everything up to date and ensuring all documentation files were consistent. This also involved adding new screenshots, utilising a tileset kindly supplied by Stoo Cambridge (of Cannon Fodder fame).
The next task involved a few slight tweaks to the toolbar icons, some of which had been "borrowed" from various sources until I found time to draw my own. The "hand" icon for Move Mode also needed a slight touch-up as it used the masking colour, which in turn caused its outline to disappear on occasion.
Unable to focus on my To-Do list, yesterday I started playing with an idea I'd seen in the Jazz Creation Station (the level editor bundled with the Jazz Jackrabbit games), which allows the user to grab Brushes directly from the Tiles Panel. After making some tweaks to the existing grab routines, it was a fairly straightforward process to implement, and now it's much easier to grab chunks of geometry that may be scattered across several Tiles.
The next task involved a few slight tweaks to the toolbar icons, some of which had been "borrowed" from various sources until I found time to draw my own. The "hand" icon for Move Mode also needed a slight touch-up as it used the masking colour, which in turn caused its outline to disappear on occasion.
Unable to focus on my To-Do list, yesterday I started playing with an idea I'd seen in the Jazz Creation Station (the level editor bundled with the Jazz Jackrabbit games), which allows the user to grab Brushes directly from the Tiles Panel. After making some tweaks to the existing grab routines, it was a fairly straightforward process to implement, and now it's much easier to grab chunks of geometry that may be scattered across several Tiles.
Wednesday, July 5, 2006
Wednesday 5th
The past few days have been spent knee-deep in tweaks and refinements, kicking off with the conversion of the HTML documentation to a Word file (which will, in turn, make it easier to produce a proper Windows help file and a PDF).
The next major task was to finish off the keyboard input and finalise the keyboard shortcuts on the various menus. Despite being a relatively simple task, this ended up spanning a couple of days, for a number of reasons; firstly, as the program grew and evolved, certain shortcuts that initially made sense no longer did. Plus, after careful experimentation it became clear than not every menu action needed a keyboard equivalent. And finally, certain features needed to be made more consistent with the likes of, say, PhotoShop.
While changing keyboard logic and moving checks and function calls, I did manage to track down some more obscure bugs, as well as adding and tweaking some of the menu commands (which means that my lovely docs are now out of date...!).
The next major task was to finish off the keyboard input and finalise the keyboard shortcuts on the various menus. Despite being a relatively simple task, this ended up spanning a couple of days, for a number of reasons; firstly, as the program grew and evolved, certain shortcuts that initially made sense no longer did. Plus, after careful experimentation it became clear than not every menu action needed a keyboard equivalent. And finally, certain features needed to be made more consistent with the likes of, say, PhotoShop.
While changing keyboard logic and moving checks and function calls, I did manage to track down some more obscure bugs, as well as adding and tweaking some of the menu commands (which means that my lovely docs are now out of date...!).
Saturday, July 1, 2006
Saturday 1st
The past few days have been spent sorting out an EULA (End User License Agreement), as well as working on the installation system and chipping away at bugs. Yesterday was spent tracking down a small bug in the Dump Map system, which was consistently failing to dump the correct Layer. The problem? A mis-typed variable. Such is life. :) I also had to tweak the documentation; any slight change now has to be added straight away, lest I lose track and end up with less than adequate documentation (I've spent so much time on them so far, there's no point getting lazy at this stage).
Today saw a couple of tweaks to the Map rotation code, to allow the current Layer, all Layers, or all visible Layers to be rotated. This was a relatively simple addition, and like so many recent tweaks it only came to light when methodically going through the docs and seeing how things worked in practise.
As I was uploading some files today, I noticed that it's now almost two years since FishEd was started (that might sound like a long time, but on average I was scraping only a couple of hours' coding time for an average of five days a week). Regardless, I now have a definite goal in mind: get FishEd released on the second anniversary of its inception (just over four weeks...! ).
Today saw a couple of tweaks to the Map rotation code, to allow the current Layer, all Layers, or all visible Layers to be rotated. This was a relatively simple addition, and like so many recent tweaks it only came to light when methodically going through the docs and seeing how things worked in practise.
As I was uploading some files today, I noticed that it's now almost two years since FishEd was started (that might sound like a long time, but on average I was scraping only a couple of hours' coding time for an average of five days a week). Regardless, I now have a definite goal in mind: get FishEd released on the second anniversary of its inception (just over four weeks...! ).
Sunday, June 25, 2006
Sunday 25th
Spent the afternoon striking even more tasks from the dreaded To-Do list; firstly, I made a couple of changes to the Export menu, allowing specific combinations of Layers (current, visible, or all) to be exported as a BMP. Previously, only the current Layer was exported as a BMP image, which was more than a little restrictive.
Next came a change to the Layer menu, with the option to view just the current Layer, all Layers, or no Layers (the reason for these might not be readily apparent, but after using the Editor at length I was finding their absence more and more annoying).
Next came more tweaks to the Brush thumbnail system, which ensured that only the current Brush is affected by the "Regen" button. Whilst knee-deep in this particular chunk of code, I also added the regenerate current option to the Brush menu (along with a "regenerate all" option, for consistency). And in a similar vein, I also added the option to clear the current Brush or clear all Brushes.
Next came a change to the Layer menu, with the option to view just the current Layer, all Layers, or no Layers (the reason for these might not be readily apparent, but after using the Editor at length I was finding their absence more and more annoying).
Next came more tweaks to the Brush thumbnail system, which ensured that only the current Brush is affected by the "Regen" button. Whilst knee-deep in this particular chunk of code, I also added the regenerate current option to the Brush menu (along with a "regenerate all" option, for consistency). And in a similar vein, I also added the option to clear the current Brush or clear all Brushes.
Saturday, June 24, 2006
Saturday 24th
The past few days have been spent working on the documentation, as there were several areas which, in the cold light of day, needed further expansion. Today involved documenting the various file formats, and I think I'll also put together an example file containing load/save routines. The docs are almost complete, barring a Tricks & Tips section and the A-Z index; once finalised, I can also put together a Word/PDF version.
Creating the documentation has thrown up a number of suggestions and bugs, so today I started whittling down this list. First off was the option to discard the Static or Parallax Layers, which was in the Editor originally, then dropped, and now resurrected again (partly because Static and Parallax information is stored in the Project File, so it makes sense to be able to discard them to prevent the Editor loading unnecessary files). This also threw up an obscure bug in the Map Test code, which thankfully was easily fixed.
Next came a few error checks to the INI file system, as the Editor crashed if there was no INI file present. After making a few tweaks, the program now creates its own INI file if one cannot be found.
After that, I added an ID number to the Project File system; the reason for this will become apparent if (or when?) FishEd is updated for Blitz Max; doubtless there will be differences between the Project Files, so this ID number will allow me to detect if an older file is being loaded and if so, load the information correctly.
Next came a tweak to the checkboxes at the top of the screen; I print an asterisk next to Layers which have unsaved changes, and now any locked Layers are also illustrated by way of an "X" next to the Layer number (locked Layers are shown on the Info Panel, but this is not always visible as it shares a Tabber with the Mini-Map).
The final task involved a tweak to the Animation system; I'd been toying with the idea of putting a limit on the number of frames in an animation sequence, which thus far has been limitless. After careful thought, I decided to cap the system at 256 tiles (I can't really see anyone hand-crafting a sequence more than 256 Tiles in size!).
Creating the documentation has thrown up a number of suggestions and bugs, so today I started whittling down this list. First off was the option to discard the Static or Parallax Layers, which was in the Editor originally, then dropped, and now resurrected again (partly because Static and Parallax information is stored in the Project File, so it makes sense to be able to discard them to prevent the Editor loading unnecessary files). This also threw up an obscure bug in the Map Test code, which thankfully was easily fixed.
Next came a few error checks to the INI file system, as the Editor crashed if there was no INI file present. After making a few tweaks, the program now creates its own INI file if one cannot be found.
After that, I added an ID number to the Project File system; the reason for this will become apparent if (or when?) FishEd is updated for Blitz Max; doubtless there will be differences between the Project Files, so this ID number will allow me to detect if an older file is being loaded and if so, load the information correctly.
Next came a tweak to the checkboxes at the top of the screen; I print an asterisk next to Layers which have unsaved changes, and now any locked Layers are also illustrated by way of an "X" next to the Layer number (locked Layers are shown on the Info Panel, but this is not always visible as it shares a Tabber with the Mini-Map).
The final task involved a tweak to the Animation system; I'd been toying with the idea of putting a limit on the number of frames in an animation sequence, which thus far has been limitless. After careful thought, I decided to cap the system at 256 tiles (I can't really see anyone hand-crafting a sequence more than 256 Tiles in size!).
Monday, June 12, 2006
Monday 12th
After spending quite a bit of time addressing issues with the Demo Version I recently released (it turns out that people were having trouble unZIPping a file...), today I set about tidying up a few issues and getting the docs into shape.
The main task was to find a nice way to bring up the Docs if the user chooses "Help" from the menu; after creating a small browser, and attempting to trigger both online and offline versions of the HTML documentation, I settled on just an online help system which launches in the default browser.
Spent quite a bit of time sifting through the docs so far, and ensuring that all of the information was consistent with the Editor (I'd recently added a few menu commands, for instance, which I'd neglected to add to the docs). I also tinkered briefly with the Toolbar, adding an icon for the Test Map feature which fits in very nicely.
The main task was to find a nice way to bring up the Docs if the user chooses "Help" from the menu; after creating a small browser, and attempting to trigger both online and offline versions of the HTML documentation, I settled on just an online help system which launches in the default browser.
Spent quite a bit of time sifting through the docs so far, and ensuring that all of the information was consistent with the Editor (I'd recently added a few menu commands, for instance, which I'd neglected to add to the docs). I also tinkered briefly with the Toolbar, adding an icon for the Test Map feature which fits in very nicely.
Friday, May 26, 2006
Friday 26th
Took a slight diversion from FishEd today, in order to start working on... FishEd. The Blitz Max version, that is. :) With work on FishEd coming to a close, naturally I've been thinking about what comes next, and with Max sitting idle on my hard drive, I was intrigued to see how much of a task lay ahead; after a couple of hours work, I already had the main window, tabbers, panels, and menus implemented, and it was only a few more minutes' work to get maps loaded and displayed.
While this may seem frivolous (especially as there are bugs to be fixed and docs to be written!), I'm hoping that the next evolution of FishEd will very quickly replace the current one (i.e. people who purchase version 0 will receive a fee upgrade to version 1, the latter being written in Blitz Max as opposed to Blitz Plus). In other words, I'd rather get the Max version up and running than continue to maintain the old version.
The Max version will be faster, smoother, and more powerful, and already I see the potential for more flexible zoom functions, layer transparency and tinting effects, and even enemy placement and so forth. Additionally, I also want to make FishEd available to the Mac community, which is something I can do very easily with a Max version.
While this may seem frivolous (especially as there are bugs to be fixed and docs to be written!), I'm hoping that the next evolution of FishEd will very quickly replace the current one (i.e. people who purchase version 0 will receive a fee upgrade to version 1, the latter being written in Blitz Max as opposed to Blitz Plus). In other words, I'd rather get the Max version up and running than continue to maintain the old version.
The Max version will be faster, smoother, and more powerful, and already I see the potential for more flexible zoom functions, layer transparency and tinting effects, and even enemy placement and so forth. Additionally, I also want to make FishEd available to the Mac community, which is something I can do very easily with a Max version.
Thursday, May 25, 2006
Thursday 25th
Polished off the I/O code today, including all the relevant variables in the Project Load and Save code (a fairly painless process now that I have a system worked out). Once this was done, I set about stripping out the redundant I/O routines ready for the Demo Version. It seems quite strange to finally expose the Editor to the outside World (even though, ironically, that's the whole point of writing it). All that now remains before release is Undo/Redo code, some tweaks to the MiniMap system, bug fixing, and general tidying up and optimising. There's even a chance I might get this done by the end of May; famous last words, I know... :)
Wednesday, May 24, 2006
Wednesday 24th
Today's tasks involved some pretty laborious work, as I needed to sift through the New Project code and the Project I/O code to ensure that all relevant variables were being initialised, loaded, and saved (I'd added a bunch of variables after the code was written, plus I'd noticed a few variables not being set/saved properly). This was a somewhat lengthy and tedious process, but exposed a few bugs and tweaks which needed to be rectified.
Now that I'm pretty close to releasing a Demo Version, I set about tidying up some of the interface loose-ends, mainly adding keyboard shortcuts to the menus and finalising some of the keyboard controls. As a result, I ended up restructuring my Control routine, adding a few extra checks to ensure that the code handles a standard keypress, Shift+keypress, Ctrl+keypress, and Shift+Ctrl+keypress properly.
Now that I'm pretty close to releasing a Demo Version, I set about tidying up some of the interface loose-ends, mainly adding keyboard shortcuts to the menus and finalising some of the keyboard controls. As a result, I ended up restructuring my Control routine, adding a few extra checks to ensure that the code handles a standard keypress, Shift+keypress, Ctrl+keypress, and Shift+Ctrl+keypress properly.
Tuesday, May 23, 2006
Tuesday 23rd
Tackled the Brush Thumbnail system today, as there were still plenty of issues with several routines. The main problem was, what if the program tries to load a Tileset (as part of a Project file) but cannot find it? Ordinarily, after loading the Tileset, the thumbnails for any stored Brushes need to be calculated - this isn't possible if the Tileset isn't found. Plus, what happens if a Brush Thumbnail is defined, but then the user elects to close the Tileset?
Essentially, when a Brush is grabbed from a Layer and stored in a buffer, the thumbnail is generated from the Tileset assigned to the currently-selected Layer (and thus, each thumbnail could potentially be from a completely different Tileset). However, if the Tileset isn't loaded or gets closed, no thumbnail exists and thus, errors creep in.
The first task was to therefore add an array which tracks which Tileset was used to generate the thumbnail. Next, I added some checks to the thumbnail display code, which prevented any un-generated thumbnails from being displayed (along with an appropriate "Thumbnail Error" message). Next, I tweaked the thumbnail routine so that I can tell it precisely which Tileset to use (up until now, it had assumed the same Tileset). And finally, the Load Project code required a few tweaks to integrate these various checks and trap any errors.
The upshot of all this extra work yields the following results; a Brush grabbed from a given Layer and subsequently stored will generate a thumbnail image only if a Tileset is loaded - if not, the Brush is still stored, but an appropriate message is displayed. Should the user close a Tileset used to generate a thumbnail, again an appropriate message is displayed in place of the thumbnail. And finally, when the user loads a Project FIle but a Tileset is missing, any associated Brushes are loaded but not displayed. In any of these instances, as soon as a Tileset is loaded into the right spot, the thumbnails are generated and the error messages disappear. Phew!
Needless to say, today's session was very intense, and what I term an "out of your seat" day (i.e. you spend more time pacing and drinking tea than you do at the keyboard). Thankfully, it nudged me ever closer to getting the Editor out of the door, and threw out a couple of nice tweaks I want to include after Beta.
The final task of the night involved a few tweaks to the Drawing Modes, as I'd neglected to include error trapping if the user, for example, chooses Line Mode while in the middle of drawing a Box. Thankfully, this was as easy as clearing a few variables, and as an added bonus, it's rather nice to be able to change your mind after starting to draw something.
Essentially, when a Brush is grabbed from a Layer and stored in a buffer, the thumbnail is generated from the Tileset assigned to the currently-selected Layer (and thus, each thumbnail could potentially be from a completely different Tileset). However, if the Tileset isn't loaded or gets closed, no thumbnail exists and thus, errors creep in.
The first task was to therefore add an array which tracks which Tileset was used to generate the thumbnail. Next, I added some checks to the thumbnail display code, which prevented any un-generated thumbnails from being displayed (along with an appropriate "Thumbnail Error" message). Next, I tweaked the thumbnail routine so that I can tell it precisely which Tileset to use (up until now, it had assumed the same Tileset). And finally, the Load Project code required a few tweaks to integrate these various checks and trap any errors.
The upshot of all this extra work yields the following results; a Brush grabbed from a given Layer and subsequently stored will generate a thumbnail image only if a Tileset is loaded - if not, the Brush is still stored, but an appropriate message is displayed. Should the user close a Tileset used to generate a thumbnail, again an appropriate message is displayed in place of the thumbnail. And finally, when the user loads a Project FIle but a Tileset is missing, any associated Brushes are loaded but not displayed. In any of these instances, as soon as a Tileset is loaded into the right spot, the thumbnails are generated and the error messages disappear. Phew!
Needless to say, today's session was very intense, and what I term an "out of your seat" day (i.e. you spend more time pacing and drinking tea than you do at the keyboard). Thankfully, it nudged me ever closer to getting the Editor out of the door, and threw out a couple of nice tweaks I want to include after Beta.
The final task of the night involved a few tweaks to the Drawing Modes, as I'd neglected to include error trapping if the user, for example, chooses Line Mode while in the middle of drawing a Box. Thankfully, this was as easy as clearing a few variables, and as an added bonus, it's rather nice to be able to change your mind after starting to draw something.
Monday, May 22, 2006
Monday 22nd
The past few days have been spent bashing the docs into shape ready for the release of a demo version (which will hopefully be within the next week or so). I'd already compiled a huge amount of information, but as I'm planning to put the documentation online, I needed to transfer the docs from Word into FrontPage (this has the added benefit of allowing me to style the website exactly like my Scary Fish website, for maximum consistency).
One of the interesting things about writing the docs is, you tend to forget all the tiny tricks and neat touches you struggled so hard to include. It also highlights additional ideas for areas that may have room for improvement, and helps to flush out obscure bugs.
One such problem surfaced today; when a Layer is flipped, the user is always prompted with a warning that the action affects all Layers when, in actual fact, it doesn't. This prompted the idea of including a menu option to specify whether or not the Flip/Rotate commands affect just the current Layer or all Layers (aside from to 90-degree rotations, which affect all Layers regardless).
One of the interesting things about writing the docs is, you tend to forget all the tiny tricks and neat touches you struggled so hard to include. It also highlights additional ideas for areas that may have room for improvement, and helps to flush out obscure bugs.
One such problem surfaced today; when a Layer is flipped, the user is always prompted with a warning that the action affects all Layers when, in actual fact, it doesn't. This prompted the idea of including a menu option to specify whether or not the Flip/Rotate commands affect just the current Layer or all Layers (aside from to 90-degree rotations, which affect all Layers regardless).
Monday, May 15, 2006
Monday 15th
Not much progress today; started off by tweaking the Test Map system to ensure that the map always starts at the top-left corner (dabbling with different Tile and Map sizes threw up a few instances where the map wasn't being displayed properly). Next came an extension of the Project Stats system, which now allows the user to dump the Project Stats to a text file. Yes, I know I'm not supposed to be adding features at this stage, but time was of the essence, so quick tasks were the order of the day. :)
Friday, May 12, 2006
Friday 12th
Managed to finally conquer my Shift/Scrolling issues today, with a LOT of help from Muttley from the YakYak forum who very kindly knocked up a testbed in Blitz Max. Essentially, I wanted the user to be able to scroll the map freely, but only one block at a time if Shift is held. I was getting close, but no cigar, until (thankfully!) Muttley came up with a very tight piece of code that did the job perfectly. Note to self: don't code when exhausted!
Thursday, May 11, 2006
Thursday 11th
Today's first task involved a tweak to the Zoom function, as I'd noticed yesterday that zoomed tiles weren't being masked (and therefore, their transparent colour wasn't actually transparent). The fix was relatively simple, except that the image resizing (required to created a smaller, "zoomed-out" tileset) interferes with the mask colour and thus, leaves a slight fringe on certain tiles. Sadly, there's not much I can do about this unless I write my own resize routine from scratch.
Next came a slight tweak to the Save routines (specifically for Maps, Map Sets, and Projects). Whenever an edit is made to a Layer, an asterisk appears next to the Layer to illustrate the fact; whenever a Map, Map Set, or Project is saved, these asterisks should clear automatically; thankfully the problem was down to the text routine not being called, partly because I'd inserted some extra checks to ensure that text is only updated when values change. I'm too efficient for my own good. :)
The next task involved getting the Window resizing sorted out once and for all. After taking numerous screenshots and making various measurements in PhotoShop, I managed to get the routines working; now, when the <> keys are used in conjunction with Shift or Ctrl, the user can increase or decrease the size of the Editor in steps of 128 (this is so that no matter what the Tilesize, the main canvas always remains at an acceptable size). I'm still not 100% happy with the centring of the Window - mainly because it isn't precisely centred - but this is something I can hopefully tweak.
The final task of the night involved a slight tweak to my various popup dialogue boxes; I discovered the hidden flags for buttons, which allows Return to act as the OK button and Escape to act as the Cancel button - a few keypresses later, and the GUI is much more intuitive.
Next came a slight tweak to the Save routines (specifically for Maps, Map Sets, and Projects). Whenever an edit is made to a Layer, an asterisk appears next to the Layer to illustrate the fact; whenever a Map, Map Set, or Project is saved, these asterisks should clear automatically; thankfully the problem was down to the text routine not being called, partly because I'd inserted some extra checks to ensure that text is only updated when values change. I'm too efficient for my own good. :)
The next task involved getting the Window resizing sorted out once and for all. After taking numerous screenshots and making various measurements in PhotoShop, I managed to get the routines working; now, when the <> keys are used in conjunction with Shift or Ctrl, the user can increase or decrease the size of the Editor in steps of 128 (this is so that no matter what the Tilesize, the main canvas always remains at an acceptable size). I'm still not 100% happy with the centring of the Window - mainly because it isn't precisely centred - but this is something I can hopefully tweak.
The final task of the night involved a slight tweak to my various popup dialogue boxes; I discovered the hidden flags for buttons, which allows Return to act as the OK button and Escape to act as the Cancel button - a few keypresses later, and the GUI is much more intuitive.
Wednesday, May 10, 2006
Wednesday 10th
More bugfixing on today's agenda (indeed, the majority of the remaining tasks are all bugs or tweaks of some kind). First up was a slight problem with the Project I/O, which was failing to save a couple of important variables - this in itself is no big headache, as I've plenty of variables to add to the load and save routines, but it does mean that I'll need to methodically step through every variable to ensure that, if needed, it's included.
While testing some code, a bug in the Map resizing code reared its ugly head once again (it was a relatively obscure problem which I though I'd seen the back of). The main problem with bugs at this point in development is the fact that so many bits of code are inter-dependant; smaller, more modular routines are called in various places by different functions, and thus, when code is added or tweaked it's very easy to break things that once worked perfectly.
This particular bug, thankfully, turned out to be a small cut & paste error (I'd copied a chunk of code but neglected to change all the variable references). I discovered that, due to the fact I tested the routines in a very linear fashion, the bug only surfaced when I did something I wouldn't try normally. Hopefully my Beta Testers are reading this...!
While testing some code, a bug in the Map resizing code reared its ugly head once again (it was a relatively obscure problem which I though I'd seen the back of). The main problem with bugs at this point in development is the fact that so many bits of code are inter-dependant; smaller, more modular routines are called in various places by different functions, and thus, when code is added or tweaked it's very easy to break things that once worked perfectly.
This particular bug, thankfully, turned out to be a small cut & paste error (I'd copied a chunk of code but neglected to change all the variable references). I discovered that, due to the fact I tested the routines in a very linear fashion, the bug only surfaced when I did something I wouldn't try normally. Hopefully my Beta Testers are reading this...!
Sunday, May 7, 2006
Sunday 7th
Delved into the Drawing Modes once again today, after spotting a small problem with the existing routines. Firstly, the Symmetry values were being derived from the shape being drawn - if part of the shape was masked by a Mask tile, the reflected tile wouldn't be displayed. So, the first step was to ensure that shape tiles and reflected tiles check for Masked tiles independently. Confused? I was. :)
Next came the task of splitting a couple of pieces of logic; rather stupidly, I'd put a check in to stop tiles off the edge of the map from being processed, which also caused reflected tiles to disappear. Thankfully, this was a case of simply moving some checks outside of other checks. Finally came the task of ensuring that all tiles and reflected tiles didn't attempt to Peek or Poke values outside of the current map (again, the logic was there, just in the wrong places due to the countless tweaks and additions I've made over the last 18 months).
So, after a few hours' tinkering, the Editor looks pretty much the same as it did, but thankfully the Symmetry system and Drawing Tools are much more robust than they were before.
Next came the task of splitting a couple of pieces of logic; rather stupidly, I'd put a check in to stop tiles off the edge of the map from being processed, which also caused reflected tiles to disappear. Thankfully, this was a case of simply moving some checks outside of other checks. Finally came the task of ensuring that all tiles and reflected tiles didn't attempt to Peek or Poke values outside of the current map (again, the logic was there, just in the wrong places due to the countless tweaks and additions I've made over the last 18 months).
So, after a few hours' tinkering, the Editor looks pretty much the same as it did, but thankfully the Symmetry system and Drawing Tools are much more robust than they were before.
Saturday, May 6, 2006
Saturday 6th
More debugging and tweaking on today's agenda: started by further investigating the Brush Thumbnail problem, which will require more than a few braincells to fix - luckily, the problem only occurs (noticeably!) when the user tries to load a Project file but a Tileset is missing; at all other times, there's already significant error-checking in place.
At the risk of running out of creative steam, I turned my attention to some other bugs and issues on my list. First came a tweak to the Duplicate checking system, to ensure that Duplicates can only be checked on Tilesets that are actually loaded (oops, fumbled the ball on that one). Next, a small tweak to the status update ensures that when a Project file is loaded the relevant filename is displayed at the top of the screen.
Next I tinkered with the map scrolling, following a suggestion from a Beta Tester that variable scroll speeds might be a useful addition; however, when the speeds were slowed down (even by half), the result was jerky and ugly. The Editor does feature a Shift-based modifier to the scrolling, which allows you to step through the map a Tile at a time, so I suppose this will have to suffice for now.
The next task involved a small tweak to the existing Drawing Modes to allow a shape to be moved while in mid-draw (for instance, in PhotoShop, the starting point of a shape can be moved at any point by holding Shift). I'd wanted to emulate this for some time, mainly because it's an immensely handy feature, but shied away from it due to the sheer amount of code I'd have to wade through.
However, it proved relatively simple to add to the code (and since I'd already calculated the size of the shape being drawn for use on the Info Panel, all I had to do was throw in a couple of extra checks). Hit a small problem with the code that checks for Masked Tiles, but a simple re-ordering of the logic and everything was working perfectly. There's a possibility that the Line mode may need a tiny tweak, but in general the day's session was extremely fruitful. :)
At the risk of running out of creative steam, I turned my attention to some other bugs and issues on my list. First came a tweak to the Duplicate checking system, to ensure that Duplicates can only be checked on Tilesets that are actually loaded (oops, fumbled the ball on that one). Next, a small tweak to the status update ensures that when a Project file is loaded the relevant filename is displayed at the top of the screen.
Next I tinkered with the map scrolling, following a suggestion from a Beta Tester that variable scroll speeds might be a useful addition; however, when the speeds were slowed down (even by half), the result was jerky and ugly. The Editor does feature a Shift-based modifier to the scrolling, which allows you to step through the map a Tile at a time, so I suppose this will have to suffice for now.
The next task involved a small tweak to the existing Drawing Modes to allow a shape to be moved while in mid-draw (for instance, in PhotoShop, the starting point of a shape can be moved at any point by holding Shift). I'd wanted to emulate this for some time, mainly because it's an immensely handy feature, but shied away from it due to the sheer amount of code I'd have to wade through.
However, it proved relatively simple to add to the code (and since I'd already calculated the size of the shape being drawn for use on the Info Panel, all I had to do was throw in a couple of extra checks). Hit a small problem with the code that checks for Masked Tiles, but a simple re-ordering of the logic and everything was working perfectly. There's a possibility that the Line mode may need a tiny tweak, but in general the day's session was extremely fruitful. :)
Friday, May 5, 2006
Friday 5th
Today's first task was to sort out some of the error trapping which is sadly lacking in a few important areas (like, for instance, what if the user tries to load a Project file but the Editor cannot find any of the requisite Tilesets and so forth?). A few gentle nudges from the Blitz Forum pointed me in the direction of a suitable method, now all I need to do is inform the user in a graceful way.
After digging deeper into potential "What Ifs?", it also became clear that the Brush Thumbnail system was also prone to errors if there is no Tileset loaded - the only way around this will be to store the Tileset used to generate each thumbnail, and check this prior to display.
The final couple of tasks for today involved adding the current cursor mode to the Info Panel (when in Tile Grab Mode, the cursor can either be set to Coarse or Smooth), followed by a small tweak to ensure that the Layer copy/paste buffer is cleared after a Layer is resized or rotated.
After digging deeper into potential "What Ifs?", it also became clear that the Brush Thumbnail system was also prone to errors if there is no Tileset loaded - the only way around this will be to store the Tileset used to generate each thumbnail, and check this prior to display.
The final couple of tasks for today involved adding the current cursor mode to the Info Panel (when in Tile Grab Mode, the cursor can either be set to Coarse or Smooth), followed by a small tweak to ensure that the Layer copy/paste buffer is cleared after a Layer is resized or rotated.
Wednesday, April 26, 2006
Wednesday 26th
After some gentle nudging from my Beta Testers, today I set about bashing the Docs into shape (there is currently no documentation whatsoever for FishEd, which makes the program more than a little daunting for the first-time user). This enabled me to spend a little bit of time fixing some obscure bugs that only tend to show themselves when you're finalising how things need to behave.
First was a teensy bug in the Mask code, which meant that Mask actions were only affecting the current Layer's Tileset, as opposed to the Tileset I was actually looking at. I also realised I'd meant to include an "Invert" button on the Mask GUI, which was a potential pain to fix as it shares a gadget panel with the Tiles GUI, which itself has a "Set" button slap-bang where I wanted my Invert button to go. Thankfully, a bit of lateral thought meant that I could simply change the button's text when the user is on the Mask GUI, and check an existing flag to make sure the proper function is called when the button is clicked. Magic. :)
First was a teensy bug in the Mask code, which meant that Mask actions were only affecting the current Layer's Tileset, as opposed to the Tileset I was actually looking at. I also realised I'd meant to include an "Invert" button on the Mask GUI, which was a potential pain to fix as it shares a gadget panel with the Tiles GUI, which itself has a "Set" button slap-bang where I wanted my Invert button to go. Thankfully, a bit of lateral thought meant that I could simply change the button's text when the user is on the Mask GUI, and check an existing flag to make sure the proper function is called when the button is clicked. Magic. :)
Monday, April 17, 2006
Monday 17th
Today I took a welcome diversion from the Editor and ploughed back into the game itself (if you remember, this Blog / Project started out as a remake of the C64 game Citadel). I had a couple of testbeds already written, one a bullet-firing routine, and the other an initial stab at a map / scrolling / collision system.
However, before I could combine all of these elements, I had to convert the game over to Blitz Max (though the Editor is written in Blitz+, the game itself will be written in Max). This was no easy feat, thanks to the somewhat sparse documentation, and the myriad little syntax changes. Nevertheless, after persevering for an hour or so, my testbed was in and working - after this, it was a simple enough process to throw in map loading, tile graphics, and even a status panel and some basic collision detection. Within just a few hours, the game is already taking shape!
However, before I could combine all of these elements, I had to convert the game over to Blitz Max (though the Editor is written in Blitz+, the game itself will be written in Max). This was no easy feat, thanks to the somewhat sparse documentation, and the myriad little syntax changes. Nevertheless, after persevering for an hour or so, my testbed was in and working - after this, it was a simple enough process to throw in map loading, tile graphics, and even a status panel and some basic collision detection. Within just a few hours, the game is already taking shape!
Friday, April 14, 2006
Friday 14th
A welcome return to the Editor saw me delving into something which previously I'd tried to shy away from - changing the Editor window size. After a suggestion from one of the Beta Testers, I started investigating the possibility of making the window resizeable (or ideally, give the option to maximise to full-screen).
After experimenting with the various window commands in Blitz, it became apparent that resizing the window by dragging it would be both flickery and fraught with problems (mainly because I have to keep the resolution of the main Editor window as a multiple of 128 - that way all tile sizes appear correctly no matter what the canvas size).
The first issue was to get the various Tabbers and windows to stay in the correct place - this was relatively simple, as was setting the minimum window size. However, after much tinkering there was still no graceful way of expanding the window manually without flickers and copious flag checks.
Undeterred, I came up with a simle way around this; the user can use the <> keys (with either control or shift) to increase or decrease the window width by one step (in this case, 128 pixels). Not only does this allow me to set up the variables and resize the gadgets with more precision, it also allows the user to fully customise their editor layout.
After experimenting with the various window commands in Blitz, it became apparent that resizing the window by dragging it would be both flickery and fraught with problems (mainly because I have to keep the resolution of the main Editor window as a multiple of 128 - that way all tile sizes appear correctly no matter what the canvas size).
The first issue was to get the various Tabbers and windows to stay in the correct place - this was relatively simple, as was setting the minimum window size. However, after much tinkering there was still no graceful way of expanding the window manually without flickers and copious flag checks.
Undeterred, I came up with a simle way around this; the user can use the <> keys (with either control or shift) to increase or decrease the window width by one step (in this case, 128 pixels). Not only does this allow me to set up the variables and resize the gadgets with more precision, it also allows the user to fully customise their editor layout.
Friday, February 3, 2006
Friday 3rd
Yesterday was spent integrating the Circle code into the existing framework, and after making a suitable amount of tweaks I had the code in and working, with one small problem; I'd tweaked the code to make the circle draw from the top-left point (rather than the centre), to make it consistent with the other drawing tools.
However, for some reason, the circle would only increase in size in increments of 2. Took a while to work out that, in normal circumstances (when the circle is drawn from a centre point), increasing the width of the circle causes expansion in both directions; hence, the circle was increasing in steps of 2...!
Thus, today's session was spent changing the code back to the centre-based system, then adding the code to display animated tiles, masking, and symmetry. The final task involved creating the Circle Fill mode, which thankfully was a painless task (and merely a case of calling my line draw routine at key points).
With Circle Mode now in and working, the final task remaining (aside from bugs and documentation) is just the Undo/Redo code - hopefully I can get this cracked over the next few days...
However, for some reason, the circle would only increase in size in increments of 2. Took a while to work out that, in normal circumstances (when the circle is drawn from a centre point), increasing the width of the circle causes expansion in both directions; hence, the circle was increasing in steps of 2...!
Thus, today's session was spent changing the code back to the centre-based system, then adding the code to display animated tiles, masking, and symmetry. The final task involved creating the Circle Fill mode, which thankfully was a painless task (and merely a case of calling my line draw routine at key points).
With Circle Mode now in and working, the final task remaining (aside from bugs and documentation) is just the Undo/Redo code - hopefully I can get this cracked over the next few days...
Wednesday, February 1, 2006
Wednesday 1st
Limited time to make a sizeable dent on the remaining tasks, so I kicked off by adding the Save Preferences option to the file menu, which gives the user the option to save their Preferences whenever the program is exited.
The rest of today's session involved sourcing some algorithms and example code for my circle drawing routine, which has never really worked as it should. Luckily, I managed to find some ellipse and circle code in the Blitz Code Archives (definitely the first place to look for specific code and routines).
Rounded off the day's session by adding the Menu commands to the program documentation file (by far the most long-winded of the documentation tasks). With any luck, by adding to the documentation whenever I get chance, hopefully the docs will be finished by the time the Editor hits Beta. Fingers crossed. :)
The rest of today's session involved sourcing some algorithms and example code for my circle drawing routine, which has never really worked as it should. Luckily, I managed to find some ellipse and circle code in the Blitz Code Archives (definitely the first place to look for specific code and routines).
Rounded off the day's session by adding the Menu commands to the program documentation file (by far the most long-winded of the documentation tasks). With any luck, by adding to the documentation whenever I get chance, hopefully the docs will be finished by the time the Editor hits Beta. Fingers crossed. :)
Tuesday, January 31, 2006
Tuesday 31st
Despite a severe storm taking out power for the best part of the night, I managed to chip another task off the To-Do list; tonight it was the turn of the Info panel to get a much-needed nip 'n' tuck, as there was plenty of information which a) wasn't needed on the panel in the first place, b) badly laid out and taking up too much space, or c) not included at all.
After much tweaking, testing, and recompiling, the panel now displays the following information:
1. The current Drawing Mode (eg. Pen Mode).
2. The Currently-selected Layer, along with (L) if the Layer is locked, (D) if being viewed as Decimal, and (H) if being viewed as hex.
3. The cursor's X position, followed by the Map Width (e.g. 5/120).
4. The cursor's Y position, followed by the Map Height (e.g. 6/120).
5. The current Left tile, followed by the number of occurrences of that tile in the current Layer.
6. The current Right tile, followed by the number of occurrences of that tile in the current Layer.
7. The currently-selected Tileset, followed by the Tileset assigned to the current Layer.
8. The Mask status (Off or On).
9. The Grid Status (Off, Normal, or Brush, followed by (S) if grid scrolling is activated).
10. The current Grid X and Y sizes (eg. 5/12).
11. The current Shape X and Y sizes (shapes being any line, box, or circle being drawn by the player, or the current Brush).
12. The Parallax X and Y speeds (eg. 3/3).
13. The current Animation status (On or Off).
14. The current Zoom Level (25%, 50%, 75%, or 100%).
15. The Symmetry status (X, Y, or X+Y).
16. The current Symmetry X and Y values (eg. 5/5).
With that task out of the way, I made a couple of tweaks to the main window layout, adding checkboxes to control the looping for the Static and Parallax Layers (this had previously been tucked away in the Layer menu and wasn't nearly as accessible as it should have been). This tweak also required a minor modification to the Project I/O.
At last, the light at the end of the tunnel seems to be in sight; I have but four tasks left on my Pre-Beta list (Undo/Redo, Circle Mode, Documentation, plus a bug fix in the MiniMap routine), and thankfully most of the items on the Post-Beta list are really just features which I'd like to include but won't really be missed if I run out of time. I won't curse the project by mentioning a release date - but it'll be soon :)
After much tweaking, testing, and recompiling, the panel now displays the following information:
1. The current Drawing Mode (eg. Pen Mode).
2. The Currently-selected Layer, along with (L) if the Layer is locked, (D) if being viewed as Decimal, and (H) if being viewed as hex.
3. The cursor's X position, followed by the Map Width (e.g. 5/120).
4. The cursor's Y position, followed by the Map Height (e.g. 6/120).
5. The current Left tile, followed by the number of occurrences of that tile in the current Layer.
6. The current Right tile, followed by the number of occurrences of that tile in the current Layer.
7. The currently-selected Tileset, followed by the Tileset assigned to the current Layer.
8. The Mask status (Off or On).
9. The Grid Status (Off, Normal, or Brush, followed by (S) if grid scrolling is activated).
10. The current Grid X and Y sizes (eg. 5/12).
11. The current Shape X and Y sizes (shapes being any line, box, or circle being drawn by the player, or the current Brush).
12. The Parallax X and Y speeds (eg. 3/3).
13. The current Animation status (On or Off).
14. The current Zoom Level (25%, 50%, 75%, or 100%).
15. The Symmetry status (X, Y, or X+Y).
16. The current Symmetry X and Y values (eg. 5/5).
With that task out of the way, I made a couple of tweaks to the main window layout, adding checkboxes to control the looping for the Static and Parallax Layers (this had previously been tucked away in the Layer menu and wasn't nearly as accessible as it should have been). This tweak also required a minor modification to the Project I/O.
At last, the light at the end of the tunnel seems to be in sight; I have but four tasks left on my Pre-Beta list (Undo/Redo, Circle Mode, Documentation, plus a bug fix in the MiniMap routine), and thankfully most of the items on the Post-Beta list are really just features which I'd like to include but won't really be missed if I run out of time. I won't curse the project by mentioning a release date - but it'll be soon :)
Monday, January 30, 2006
Monday 30th
I'm now getting down to the final few tasks before beta, two of which - Map Rotation and Undo/Redo - are old friends as far as the development process goes. After trying, without success, to write a fast and shorthand map rotation algorithm, I settled with slower/reliable (after all, it works for Brush rotation, so why reinvent the wheel?).
After toiling for a couple of hours, I managed to get the arrays and buffers talking to each other, but during the debugging process I encountered a bug when small maps (ie. smaller in width/height than the screen) are loaded back into the Editor. This then led me to discover a teensy bug in the Project I/O routine, and for a moment I felt a very overwhelming sense of foreboding.
However, patience was the key, and after fixing the Project I/O (which, thankfully, didn't have an adverse effect on existing project files), I tracked down the map problem to a couple of calls within an existing routine which were resetting variables I was trying to change.
With that out of the way, and after putting in some failsafe checks to ensure that all routines that read the map data are reset properly, the rotation code was in and working. As an afterthought, I added the option to rotate the tiles along with the map - thanks to the way I'd structured my code, this took just a couple of minutes to add, and in the space of a day the Editor has become even more feature-packed and powerful.
After toiling for a couple of hours, I managed to get the arrays and buffers talking to each other, but during the debugging process I encountered a bug when small maps (ie. smaller in width/height than the screen) are loaded back into the Editor. This then led me to discover a teensy bug in the Project I/O routine, and for a moment I felt a very overwhelming sense of foreboding.
However, patience was the key, and after fixing the Project I/O (which, thankfully, didn't have an adverse effect on existing project files), I tracked down the map problem to a couple of calls within an existing routine which were resetting variables I was trying to change.
With that out of the way, and after putting in some failsafe checks to ensure that all routines that read the map data are reset properly, the rotation code was in and working. As an afterthought, I added the option to rotate the tiles along with the map - thanks to the way I'd structured my code, this took just a couple of minutes to add, and in the space of a day the Editor has become even more feature-packed and powerful.
Friday, January 27, 2006
Friday 27th
Brute force urged me to make progress today, so after preparing Non-Disclosure Agreements for my team of Beta Testers, I ploughed ahead with the INI routines and completed the save portion of the routine. This took a while to debug, and on closer investigation it appeared that the file wasn't being touched by the Editor at all.
This led me to realise that some of my string values weren't enclosed in quotes, causing the routine to find a null value and exit; a few little tweaks later, everything was working perfectly. I finished up by adding the save function call at each of the three program exit points (clicking close, choosing Quit, or tapping Esc). I may choose to add a "Save Preferences" option later, but for now the system is complete.
The final task of the night was the Tile Duplicate system; I'd written the bare bones of this with some help from my chum Muttley, but for some reason the routine failed to work properly. Additionally, I'd also had issues with how the data is presented to the user (and over my dead body would I dump the data to an external TXT file).
A couple of days ago I hit upon the idea of using a similar system to that of my Unused Tiles system; basically, if a tile is being used in the current map, it is overlaid with a tick (and if not, overlaid with a cross). This system could also work for duplicates - click on a Tile, and any duplicates are overlaid with a tick.
After setting up the core variables and logic for this, I could then use it to debug the checking routine - after all, I would know what the duplicate tiles were and thus, be able to see precisely when the routine failed to work.
I finally managed to track down the source of the problem mere minutes before going to bed (I usually load my brain with code before I got to sleep in the hope that my subconscious will solve them overnight). The problem stemmed from the way the buffers were being set up and locked for pixel-reading operations. After a bit of tinkering, the routine is now slightly slower at checking, but works 100%. Result :)
This led me to realise that some of my string values weren't enclosed in quotes, causing the routine to find a null value and exit; a few little tweaks later, everything was working perfectly. I finished up by adding the save function call at each of the three program exit points (clicking close, choosing Quit, or tapping Esc). I may choose to add a "Save Preferences" option later, but for now the system is complete.
The final task of the night was the Tile Duplicate system; I'd written the bare bones of this with some help from my chum Muttley, but for some reason the routine failed to work properly. Additionally, I'd also had issues with how the data is presented to the user (and over my dead body would I dump the data to an external TXT file).
A couple of days ago I hit upon the idea of using a similar system to that of my Unused Tiles system; basically, if a tile is being used in the current map, it is overlaid with a tick (and if not, overlaid with a cross). This system could also work for duplicates - click on a Tile, and any duplicates are overlaid with a tick.
After setting up the core variables and logic for this, I could then use it to debug the checking routine - after all, I would know what the duplicate tiles were and thus, be able to see precisely when the routine failed to work.
I finally managed to track down the source of the problem mere minutes before going to bed (I usually load my brain with code before I got to sleep in the hope that my subconscious will solve them overnight). The problem stemmed from the way the buffers were being set up and locked for pixel-reading operations. After a bit of tinkering, the routine is now slightly slower at checking, but works 100%. Result :)
Thursday, January 26, 2006
Thursday 26th
Started on the INI file system, as it was top of my (reformatted!) To-Do list. This was a fairly lengthy task, mainly because I needed to sift through all of the variables and work out which ones should be stored and loaded automatically with the program.
After quite a lot of intensive copying and pasting, I had a structure for the INI file established, and managed to complete the foundations of the initialisation routine (though at present, a number of variables aren't being set properly - one of the joys of using someone else's code, I imagine).
After quite a lot of intensive copying and pasting, I had a structure for the INI file established, and managed to complete the foundations of the initialisation routine (though at present, a number of variables aren't being set properly - one of the joys of using someone else's code, I imagine).
Wednesday, January 25, 2006
Wednesday 25th
Bit the bullet today and decided to finish off the Tile Resize system I'd had trouble with a week ago. The plan was reasonably simple - create executables on the main PC and test them on the laptop, which wasn't too much of an ordeal as the pair are already networked.
Within an hour or so I'd managed to get the routines working properly, and the system required just a few more tweaks and checks to ensure that everything else worked properly (buffers being reset and variables restored, the kind of boring housework that often gets overlooked until someone finds a bug).
The next task was a small tweak to the Zoom routine, as I realised that the Zoom tileset is calculated by loading in the current tileset from disk - this meant that newly-created tilesets which hadn't yet been saved (and thus, had no file or filename) wouldn't be displayed. A few frantic finger flourishes later, the Zoom routine was working perfectly (and as an added bonus, I also tracked down a small bug in my buffer plot routine).
The remainder of today's session was spent adding code to handle INI files, so that preferences can be saved and loaded as required (some of the default settings are beginning to annoy even me!). Managed to find a suitable routine in the Blitz Code Archives, so I'll probably chop this down to the bare minimum for my requirements.
Rounded off by having a think about a Guides system for the Editor; while testing the Brush and Symmetry functions, it became apparent that some artists might need a guide or two, particularly if their maps are very long or tall. However, I've a strict list of things I really have to be getting on with, so the Guides will have to wait :)
Within an hour or so I'd managed to get the routines working properly, and the system required just a few more tweaks and checks to ensure that everything else worked properly (buffers being reset and variables restored, the kind of boring housework that often gets overlooked until someone finds a bug).
The next task was a small tweak to the Zoom routine, as I realised that the Zoom tileset is calculated by loading in the current tileset from disk - this meant that newly-created tilesets which hadn't yet been saved (and thus, had no file or filename) wouldn't be displayed. A few frantic finger flourishes later, the Zoom routine was working perfectly (and as an added bonus, I also tracked down a small bug in my buffer plot routine).
The remainder of today's session was spent adding code to handle INI files, so that preferences can be saved and loaded as required (some of the default settings are beginning to annoy even me!). Managed to find a suitable routine in the Blitz Code Archives, so I'll probably chop this down to the bare minimum for my requirements.
Rounded off by having a think about a Guides system for the Editor; while testing the Brush and Symmetry functions, it became apparent that some artists might need a guide or two, particularly if their maps are very long or tall. However, I've a strict list of things I really have to be getting on with, so the Guides will have to wait :)
Tuesday, January 24, 2006
Tuesday 24th
Finally managed to get the Decimal/Hex display routines finished, along with the tileset for use in 16x16 mode; the feature is reasonably useful if you're working on collision maps and so forth, and also if you're animating a lot of tiles (the decimal/hex numbers also animate accordingly). All that remained was to add the relevant keypresses and menu commands, and I'm one step closer to wrapping this editor up before 2007. :)
Monday, January 23, 2006
Monday 23rd
Started tackling a routine which I'd been meaning to finish for quite some time: the ability to view a layer as decimal or hex (as opposed to tiles). The main reason this was put on hold was due to processing power - Blitz seems to stumble when a huge amount of text is being printed on screen (which is often the case when in 16x16 tile mode), or when drawing a lot of rectangles.
I decided to get around this by a) not drawing a rectangle around each tile, instead just drawing a grid over the entire screen, and b) only printing text in 32x32 tile mode or greater - 16x16 tile mode would use a specially created tileset.
With the core of the routine written, all that remains is to finish the special 16x16 tileset. The final task of the night involved tracking down a bug which meant that the editor wasn't starting up properly when New Project was selected; after nearly an hour of tweaking and bypassing code, I found the culprit: a Return command in the wrong place. Gah!
I decided to get around this by a) not drawing a rectangle around each tile, instead just drawing a grid over the entire screen, and b) only printing text in 32x32 tile mode or greater - 16x16 tile mode would use a specially created tileset.
With the core of the routine written, all that remains is to finish the special 16x16 tileset. The final task of the night involved tracking down a bug which meant that the editor wasn't starting up properly when New Project was selected; after nearly an hour of tweaking and bypassing code, I found the culprit: a Return command in the wrong place. Gah!
Sunday, January 22, 2006
Sunday 22nd
Limited time to tackle any serious coding today, so I took the liberty of adding some simple functions I'd been thinking of for a while. The first of these was the Project stats, essentially a list of all the files currently in memory, along with their relevant paths. It's a fairly simple addition, but enables the user to see at a glance which elements have been saved, and also keep a handle on larger projects.
The final task involved adding inertia controls for the parallax scrolling when using the Test Map module; this enables the user to essentially control how closely the scroll follows the mouse pointer, and basically adds a little more precision if so desired.
The final task involved adding inertia controls for the parallax scrolling when using the Test Map module; this enables the user to essentially control how closely the scroll follows the mouse pointer, and basically adds a little more precision if so desired.
Monday, January 16, 2006
Monday 16th
A glimmer of hope came in the form of some updated graphics drivers for my video card; it transpires that the bugs I've been wrestling with are due to an obscure video card problem (which wasn't an issue with my previous video card, which I swapped out only recently). A quick build transferred to the trusty laptop confirmed that it was indeed a hardware issue. After updating the video drivers, however, my code only worked once before hopping back on the bus to Bug City.
Although this isn't a significant problem (I can now just switch over to the laptop to finish key routines), it did reinstate my faith in the project and drove me to make some progress.
First up was a tweak to the New Project dialogue box - I'd neglected to include a Cancel button (which is something of a problem if you accidentally select the New Project option). A few minutes later, I'd inserted the relevant code and balance was restored.
Next came a tweak to the Tile clear functions, which weren't generating their thumbnails properly (and, thanks to my video card problem, I can't actually test the results!). However, the code uses an existing routine that I know is rock solid, so for now I'll have to work blind.
Next I tackled the Grab function; I'd inserted code a while back to allow lines to be constrained to vertical, horizontal, or diagonal, and similarly, constrained boxes to true squares. This code had never worked properly in Grab Mode when the constrained square went off the edge of the map, mainly because I'd been too elaborate with my checks - after inserting just a couple of tweaks at the start of the routine, everything was working as it should.
The final task of the night involved getting my symmetry code working wish Brushes; this is a lot trickier than it seems, mainly because the brush width has to be taken into account when you're generating the symmetry values. Additionally, the sophisticated clipping also caused chunks of the reflected brush to disappear if the equivalent chunk was off the edge of the screen.
Brute force was the order of the day, however, and after much head scratching and more than a little persistence, the basic code was in and working - now all I need to do is add the plotting code and masking code without breaking the already complex routines.
Although this isn't a significant problem (I can now just switch over to the laptop to finish key routines), it did reinstate my faith in the project and drove me to make some progress.
First up was a tweak to the New Project dialogue box - I'd neglected to include a Cancel button (which is something of a problem if you accidentally select the New Project option). A few minutes later, I'd inserted the relevant code and balance was restored.
Next came a tweak to the Tile clear functions, which weren't generating their thumbnails properly (and, thanks to my video card problem, I can't actually test the results!). However, the code uses an existing routine that I know is rock solid, so for now I'll have to work blind.
Next I tackled the Grab function; I'd inserted code a while back to allow lines to be constrained to vertical, horizontal, or diagonal, and similarly, constrained boxes to true squares. This code had never worked properly in Grab Mode when the constrained square went off the edge of the map, mainly because I'd been too elaborate with my checks - after inserting just a couple of tweaks at the start of the routine, everything was working as it should.
The final task of the night involved getting my symmetry code working wish Brushes; this is a lot trickier than it seems, mainly because the brush width has to be taken into account when you're generating the symmetry values. Additionally, the sophisticated clipping also caused chunks of the reflected brush to disappear if the equivalent chunk was off the edge of the screen.
Brute force was the order of the day, however, and after much head scratching and more than a little persistence, the basic code was in and working - now all I need to do is add the plotting code and masking code without breaking the already complex routines.
Sunday, January 15, 2006
Sunday 15th
Something of a red-letter day in the development of FishEd; after trying for two days to get my Tile Purge / Resize routines finished, it transpires that certain video cards - such as mine - cannot cope with images over a certain size. Not only does this mess up the routines I'm working on, it also means that other functions (such as copying/pasting Tile ranges, dumping the map to a BMP, etc.) also won't function properly.
With this in mind, FishEd is on temporary hold until I can find a way around the problem; there are simply too many changes - and too many compromises - to make to the Editor, given my limited time, and so, gracefully, I may have to hang up my coding hat until further notice.
With this in mind, FishEd is on temporary hold until I can find a way around the problem; there are simply too many changes - and too many compromises - to make to the Editor, given my limited time, and so, gracefully, I may have to hang up my coding hat until further notice.
Friday, January 13, 2006
Friday 13th
Spent the last couple of days making a few modifications to the Test Map system; instead of launching in its own window, the Test Map system now displays in the main window - this keeps everything centralised in one window and minimises confusion.
This also has the knock-on effect of rendering my additional buttons and checkboxes redundant, and also allows me to share parallax scrolling values between the Editor and the Test Map system. To get the system finished, today's tasks involved adding the relevant keyboard controls and adding some checks to ensure that the map cannot be scrolled off the bottom-right of the screen.
This also has the knock-on effect of rendering my additional buttons and checkboxes redundant, and also allows me to share parallax scrolling values between the Editor and the Test Map system. To get the system finished, today's tasks involved adding the relevant keyboard controls and adding some checks to ensure that the map cannot be scrolled off the bottom-right of the screen.
Tuesday, January 10, 2006
Tuesday 10th
Best laid plans being what they are, FishEd didn't reach Beta at the end of December; however, work has continued and good progress has been made over the last couple of days.
The main task in hand has involved finishing the Test Map module, which allows the user to see how their map will look when scrolled smoothly at varying speeds. I'd managed to find some code with a fairly simple scroller, so yesterday I took this code, rewrote it, then tweaked it to mimick how I wanted the Test Map system to operate.
After getting nowhere, I posted a message on the YakYak programming forum - after further investigation today, it transpired that I couldn't manipulate the MouseX and MouseY variables without first assigning them to another variable. These kinds of bugs are painful, mainly because you begin to question your programming ability when it's actually the compiler's fault. Grrr.
With this problem out of the way, today I began integrating the testbed code into the Editor; though this process took a while to debug (mainly due to the fact that the map display routine and logic routine all had to be tweaked to suit), results came thick and fast. I had to change the size of the visible area a couple of times, in order to make sure that all tile sizes can be displayed properly, so I resorted to using the current window size used by the Editor.
After a little more tinkering and debugging, the code was in and working; while holding the mouse button, tracking the cursor across the window will cause the map to scroll proportionally in the same direction (so clicking at the far right/left of the window takes the user to the far left/right of the map). This allows maximum control over the map scrolling, and feels extremely comfortable in practise.
This new system means that I'll no longer need a system for changing the scrolling speed; instead these will be applied to the Parallax layer, so that it scrolls at the correct ratio.
The main task in hand has involved finishing the Test Map module, which allows the user to see how their map will look when scrolled smoothly at varying speeds. I'd managed to find some code with a fairly simple scroller, so yesterday I took this code, rewrote it, then tweaked it to mimick how I wanted the Test Map system to operate.
After getting nowhere, I posted a message on the YakYak programming forum - after further investigation today, it transpired that I couldn't manipulate the MouseX and MouseY variables without first assigning them to another variable. These kinds of bugs are painful, mainly because you begin to question your programming ability when it's actually the compiler's fault. Grrr.
With this problem out of the way, today I began integrating the testbed code into the Editor; though this process took a while to debug (mainly due to the fact that the map display routine and logic routine all had to be tweaked to suit), results came thick and fast. I had to change the size of the visible area a couple of times, in order to make sure that all tile sizes can be displayed properly, so I resorted to using the current window size used by the Editor.
After a little more tinkering and debugging, the code was in and working; while holding the mouse button, tracking the cursor across the window will cause the map to scroll proportionally in the same direction (so clicking at the far right/left of the window takes the user to the far left/right of the map). This allows maximum control over the map scrolling, and feels extremely comfortable in practise.
This new system means that I'll no longer need a system for changing the scrolling speed; instead these will be applied to the Parallax layer, so that it scrolls at the correct ratio.
Subscribe to:
Posts (Atom)
