Today's session started with me hammering away at the power button on the PC and wondering why the machine refused to turn on. I noticed a couple of days ago the power light was on when the PC wasn't, but I attributed this to a recent power outage and the problem went away when I reset the PSU.
However, today's incident brought back echoes from the past where I'd ignored similar tell-tale signs of a dying PSU. Luckily, stores here in Victoria tend to open at 8:30, so I was able to snag a new PSU and get the machine working again within the hour.
My first job was to get my files backed up; I'd negelected to back them up a couple of days previously (thinking, "What's the worst that can happen?"), but today's debacle was all the reassurance I needed that lost files = lost hours.
The bulk of today's session involved tracking down the annoying crashes I'd been experiencing; there were all number of suggestions, including incorrect array sizes, incorrect bank sizes (FishEd uses arrays of Databanks for maps and suchlike), and incorrect variable parameters. After 2 hours trying all manner of things, I threw all my relevant variables up on-screen and noticed a few sinister negative values.
After spotting this problem, it suddenly occurred to me that my new zoom code failed to recalculate two critical variables which control how far the map can be scrolled in any direction. Several keypresses later, the whole caboodle was working like a charm (and what's more, the memory leak issues seem to be a thing of the past). Elated, I did the only thing an ENglish Programmer can do in these circumstances - have a cup of tea. :)
Friday, February 20, 2009
Thursday, February 19, 2009
Softly Softly, Catchy Buggy...
Today's session didn't go quite as planned (I had a nice list of things I was itching to scratch off my ever-expanding To-Do list), but every little helps. The first task of the day was to implement scaling on the Tile panel, in response to a request from Robin, who also asked if I could include 8x8 tiles in the next version (and thus, the reason for zooming the Tile panel becomes obvious - 8x8 tiles are pretty tricky to see on a widescreen monitor running at STUPID x INSANE resolutions.
The scaling was pretty easy to implement, mainly due to the fact that all the code and calculations were self-calculated and not hard-coded (that's a programming lesson we all tend to learn the hard way...). Finished up the scaling by adding a slider gadget to control the zoom, and although a couple of tweaks remain (i.e. making sure the cursors always stick with the relevant tile, not at the relevant window co-ordinates), it was a fairly simple and effective addition.
My final task of the day involved trying to track down a bug in my Update Map routine, which causes errors when scrolling or zooming out to 50% or 25%. After reducing my code considerably (I needed to chop out the old Zoom code anyway), and refining the whole routine, I was still confronted with errors.
I changed tac and tried to explore another bug, which caused the program to crash when my map array was set to a particular size. While tinkering with different vlaues, the bug in my map code disappeared - this leads me to believe all is not well with the arrays (Blitz+ and Blitz Max handle them in subtly different ways), and though my coding session had to be cut short I'm well on the way to fixing two rather nasty bugs. :)
The scaling was pretty easy to implement, mainly due to the fact that all the code and calculations were self-calculated and not hard-coded (that's a programming lesson we all tend to learn the hard way...). Finished up the scaling by adding a slider gadget to control the zoom, and although a couple of tweaks remain (i.e. making sure the cursors always stick with the relevant tile, not at the relevant window co-ordinates), it was a fairly simple and effective addition.
My final task of the day involved trying to track down a bug in my Update Map routine, which causes errors when scrolling or zooming out to 50% or 25%. After reducing my code considerably (I needed to chop out the old Zoom code anyway), and refining the whole routine, I was still confronted with errors.
I changed tac and tried to explore another bug, which caused the program to crash when my map array was set to a particular size. While tinkering with different vlaues, the bug in my map code disappeared - this leads me to believe all is not well with the arrays (Blitz+ and Blitz Max handle them in subtly different ways), and though my coding session had to be cut short I'm well on the way to fixing two rather nasty bugs. :)
Saturday, February 14, 2009
Strictly Speaking...
Today's coding session involved converting the FishEd Max code to SuperStrict mode, where all variables, and their types, are declared (in short, no more temporary variables called "nob" littering my routines). This was an utterly thankless task, at the end of which the program looked no different than it had two hours earlier.
The advantages of SuperStrict are rumoured to be plenty: reduced compile times, less errors, more efficient internal 'garbage collection', and faster compile times. I didn't notice any of these, but it did have the effect of slowing down the memory leak I discovered a couple of days ago (which is precisely why I converted the code to SuperStrict in the first place), so now the program only creeps up by 1Mb per second, as opposed to 2Mb.
The advantages of SuperStrict are rumoured to be plenty: reduced compile times, less errors, more efficient internal 'garbage collection', and faster compile times. I didn't notice any of these, but it did have the effect of slowing down the memory leak I discovered a couple of days ago (which is precisely why I converted the code to SuperStrict in the first place), so now the program only creeps up by 1Mb per second, as opposed to 2Mb.
Wednesday, February 11, 2009
A Thenth of Thcale...
The window scaling has been proving a little tricky, as I reached one of those classic coding moments: my code was working perfectly, then I changed a single line of code and suddenly everything seemed to break. Ultimately it took about an hour to get the code working again, and thankfully it seems a lot more robust than before. Things happen for a reason, I suppose.
The next step was to re-size the canvas properly, which took a little bit of tweaking to get right, but now I have the option of either resizing the canvas on the fly, or when the user resizes the window border and lets go of the mouse (the latter ties in nicely with canvas resizing when the window is maximized and minimized).
As the canvas was being re-sized in chunks of 32x32 pixels (the default tile size for my testbed code), it suddenly occurred to me that this would change according to whatever tile size the user is currently, er, using. Thus, I needed a quick way of changing the current tile size, which at the moment is impossible as many of the old FishEd routines haven't been transposed into FishEd Max just yet.
However, the tile size issue also ties in with the current tile size for the main window; I plan to make the Zoom feature in FishEd Max a proper zoom, in the sense that the user can zoom in or out and still make edits (the zoom feature in FishEd was purely for map inspection purposes). This feature was largely inspired by feedback from "Robin", an artist who had been using FishEd on commercial projects and wanted 8x8 tiles and the ability to zoom up the edit window to avoid going blind thanks to the contrast of the teensy tile size on a huge monitor.
And thus, I decided to wade in and tackle the viewport scaling at the same time; regardless of the current actual tile size, there is now a viewport tilesize, which may or may not be a scaled up/scaled down version of the current tilesize. When the window/canvas are re-sized, the routine now takes into account the viewport tilesize, and adjusts accordingly. I spent a little bit of time adjusting the relevant routines, and barring a few little tweaks, the user can now quickly zoom in and out and make edits to the map. Already, the new editor feels much smoother, slicker, and faster than FishEd.
Mid way through the coding session, I dedcided to add Tracker bars (yum!) to control the scaling; after about an hour of tinkering and head-scratching, my tracker gadgets still wouldn't appear. After a quick trip to the Blitz forums, it transpired that a new build was available. A click or two later, and after rebuilding all my modules, the trackers were working and my editor was running much faster. Result!
Note to self: check for updates a little more often...!
The next step was to re-size the canvas properly, which took a little bit of tweaking to get right, but now I have the option of either resizing the canvas on the fly, or when the user resizes the window border and lets go of the mouse (the latter ties in nicely with canvas resizing when the window is maximized and minimized).
As the canvas was being re-sized in chunks of 32x32 pixels (the default tile size for my testbed code), it suddenly occurred to me that this would change according to whatever tile size the user is currently, er, using. Thus, I needed a quick way of changing the current tile size, which at the moment is impossible as many of the old FishEd routines haven't been transposed into FishEd Max just yet.
However, the tile size issue also ties in with the current tile size for the main window; I plan to make the Zoom feature in FishEd Max a proper zoom, in the sense that the user can zoom in or out and still make edits (the zoom feature in FishEd was purely for map inspection purposes). This feature was largely inspired by feedback from "Robin", an artist who had been using FishEd on commercial projects and wanted 8x8 tiles and the ability to zoom up the edit window to avoid going blind thanks to the contrast of the teensy tile size on a huge monitor.
And thus, I decided to wade in and tackle the viewport scaling at the same time; regardless of the current actual tile size, there is now a viewport tilesize, which may or may not be a scaled up/scaled down version of the current tilesize. When the window/canvas are re-sized, the routine now takes into account the viewport tilesize, and adjusts accordingly. I spent a little bit of time adjusting the relevant routines, and barring a few little tweaks, the user can now quickly zoom in and out and make edits to the map. Already, the new editor feels much smoother, slicker, and faster than FishEd.
Mid way through the coding session, I dedcided to add Tracker bars (yum!) to control the scaling; after about an hour of tinkering and head-scratching, my tracker gadgets still wouldn't appear. After a quick trip to the Blitz forums, it transpired that a new build was available. A click or two later, and after rebuilding all my modules, the trackers were working and my editor was running much faster. Result!
Note to self: check for updates a little more often...!
Sunday, February 1, 2009
To the Max...
So yet again, almost a year transpires between coding stints; I'm starting to realise that these projects simply have to be done whenever time allows - gone are the days where I could set aside chunks of time to tackle this stuff uninterrupted. My brain needs to learn how to learn, as my maths teacher would say.
Although Citadel has been on the back burner for way too long, I'm really interested in updating FishEd to work in Blitz Max, partly to (maybe) make some money by flogging it to other developers, and partly because the previous version of FishEd was written in Blitz+ and will thus be largely incompatible with the Citadel engine (FishEd, if you remember, was written as an editor specifically for the Citadel project).
I have a shell that I started in July 2007, and armed with a pencil and notepad I recently set to work jotting down all the issues, improvements, and changes I wanted to make to FishEd, including feedback from some people who'd been using FishEd extensively. This time, I want to approach development logically and methodically, which means getting organised and planning ahead.
The first stage involved enlisting help from some of my chums on the YakYak forum; I want Blitz to work in Mac and Linux environments, and thus I need to plan things extremely carefully, especially gadget and screen layouts. After exchanging a few emails, my Mac test pilot is raring to go, but Linux development has stalled due to the fact that the test pilot doesn't have Max GUI (a minor hiccup).
Yesterday was the first 'proper' coding session, and my main task (before I get to do the fun stuff) is to get the window/environment working nicely. I experimented with parent/child windows for the tool panels (as PhotoShop does so well), but I can't really abide them in FishEd; I can appreciate that some people like to have multiple windows overlaying their work area, but to me it's just cluttered and hideous and makes everything less intuitive and more like somebody else's messy desk (i.e. impossible to find stuff).
In the end, I decided to keep the main canvas attached to the top left of the window, and the tool panels aligned to the right. Expanding the window (yes, FishEd afficionados, the program window is now minimisable, maximisable, and resizable) will now increase the size of the canvas in chunks according to the current tile size - I just need to tweak the code to get it running flawlessly.
Although Citadel has been on the back burner for way too long, I'm really interested in updating FishEd to work in Blitz Max, partly to (maybe) make some money by flogging it to other developers, and partly because the previous version of FishEd was written in Blitz+ and will thus be largely incompatible with the Citadel engine (FishEd, if you remember, was written as an editor specifically for the Citadel project).
I have a shell that I started in July 2007, and armed with a pencil and notepad I recently set to work jotting down all the issues, improvements, and changes I wanted to make to FishEd, including feedback from some people who'd been using FishEd extensively. This time, I want to approach development logically and methodically, which means getting organised and planning ahead.
The first stage involved enlisting help from some of my chums on the YakYak forum; I want Blitz to work in Mac and Linux environments, and thus I need to plan things extremely carefully, especially gadget and screen layouts. After exchanging a few emails, my Mac test pilot is raring to go, but Linux development has stalled due to the fact that the test pilot doesn't have Max GUI (a minor hiccup).
Yesterday was the first 'proper' coding session, and my main task (before I get to do the fun stuff) is to get the window/environment working nicely. I experimented with parent/child windows for the tool panels (as PhotoShop does so well), but I can't really abide them in FishEd; I can appreciate that some people like to have multiple windows overlaying their work area, but to me it's just cluttered and hideous and makes everything less intuitive and more like somebody else's messy desk (i.e. impossible to find stuff).
In the end, I decided to keep the main canvas attached to the top left of the window, and the tool panels aligned to the right. Expanding the window (yes, FishEd afficionados, the program window is now minimisable, maximisable, and resizable) will now increase the size of the canvas in chunks according to the current tile size - I just need to tweak the code to get it running flawlessly.
Subscribe to:
Posts (Atom)
