Today saw me redesigning the animation interface for the third time, mainly because the layout wasn't entirely user friendly. The one disadvantage of making a mockup in PhotoShop is that you focus on the look rather than the feel - only when this is translated into Blitz can I actually get a good idea of how it works in practise.
As I'd added some extra buttons, I tweaked the setup code as well as the button detection code to make the whole shebang a little easier for me to get my head around.
Next came the addition of the speed controls, as my animations currently run every vblank (i.e. 70-80 times a second, depending on the monitor refresh rate). The speed control is basically a delay, and counts down to zero before animating the tile; although this isn't everyone's idea of how speed should be implemented, the exported data will be flexible enough to translate into most environments.
Next came the text labels, which show the user key details (current frame number, total number of frames, animation number, tile number, etc.). This always seems like a more arduous task than it actually is, but really helps to bring the Editor to life.
Rounded off the night by adding the import function - this allows the user to import the range of tiles between the current Left Tile and Right Tile selectors, and is a very simple way to generate an animation sequence.
Sunday, July 31, 2005
Saturday, July 30, 2005
Saturday 30th
Not much to report for today, apart from a few minor tweaks and bug fixes to the animation code so far. Took the liberty of adding some temporary I/O code, as setting up animations to test the code was taking way too much time - now I can just load in a sequence instantly.
Friday, July 29, 2005
Friday 29th
The last couple of days have been spent laying the foundations for tile animation; I already had a very rough navigation system in place, but today I booted up the trusty PhotoShop and mocked up a more detailed version. There's a lot of information to include, and it's always difficult trying to create an interface that a) is user friendly, and b) ties in with the rest of the package.
A good deal of time - perhaps too much time - was spent sorting out the actual frame navigation, which shows the animation sequence as a continuous strip of tiles. The cursor control logic on this section alone caused more than a few sweary words to fill the air. :)
As well as the navigation, I also added the code which adds or deletes a tile from the sequence and, as a happy extension of this idea, a function to replace the current frame with the current tile (as opposed to adding to the length of the sequence).
To round things off, I wrote a small piece of temporary code to play the animation sequence, as well as plot animated tiles to the map. It's surprising how a tiny little addition can make all the difference, and seeing the animation in action has given me the motivation I need to get this section of the Editor done and dusted.
A good deal of time - perhaps too much time - was spent sorting out the actual frame navigation, which shows the animation sequence as a continuous strip of tiles. The cursor control logic on this section alone caused more than a few sweary words to fill the air. :)
As well as the navigation, I also added the code which adds or deletes a tile from the sequence and, as a happy extension of this idea, a function to replace the current frame with the current tile (as opposed to adding to the length of the sequence).
To round things off, I wrote a small piece of temporary code to play the animation sequence, as well as plot animated tiles to the map. It's surprising how a tiny little addition can make all the difference, and seeing the animation in action has given me the motivation I need to get this section of the Editor done and dusted.
Wednesday, July 27, 2005
Wednesday 27th
Kicked off the day by fixing a small bug in the Meta > Collision routine which I'd started late last night (note to self: don't code when utterly exhausted!). The routine is similar in essence to the Mask > Collision routine, except this takes the Meta Data from the current Left Tile and compares it with each tile on the map.
The routine was easy enough to code, but a small bug in the Meta read/write routines was causing unexpected results; several jabs of the Del key later, everything was working.
The Editor is now pretty much in the final straight heading towards Beta, which was planned for the end of this month (I envisage a few extra days just to tidy things up and write the docs). Once that's done, I'll publicly release the Beta version - possibly with a few feature restrictions - to gain feedback and suggestions, as well as any bugs that people might find.
The routine was easy enough to code, but a small bug in the Meta read/write routines was causing unexpected results; several jabs of the Del key later, everything was working.
The Editor is now pretty much in the final straight heading towards Beta, which was planned for the end of this month (I envisage a few extra days just to tidy things up and write the docs). Once that's done, I'll publicly release the Beta version - possibly with a few feature restrictions - to gain feedback and suggestions, as well as any bugs that people might find.
Monday, July 25, 2005
Monday 25th
Tackled a small bug this morning which was causing some unexpected crashes when maps were resized to make them considerably larger. I narrowed it down to the core of the Undo / Redo routine, which currently works with map buffers of a certain size - naturally I was neglecting to resize these buffers when the maps are resized.
Decided to bite the bullet and finish the map loading completely, specifically the force-load routine which loads a map with dimensions smaller / larger than the current map. I actually had the bulk of the code written already, but kept getting unexpected crashes.
After popping in a Stop command and tracing through using the debugger - something which I never knew was possible until recently - the problem dawned on me in an instant, and now all of the map I/O code is finally wrapped up.
Rounded off the day by tackling the Mask > Collision functionality, which was one of the first ideas I jotted down on my To Do list almost a year ago. Essentially, I wanted the user to have a very quick way to generate collision maps based on the current map (collision maps being 0 for pass-through tiles, and 1 for solid walls and suchlike). This is particularly useful for game engines which don't check the actual tile that the player is colliding with, they check the collision map.
Why? Sometimes it's useful to use collision maps as it allows different entities within the game to react differently to the same tile - specifying the collision properties for each tile takes away such flexibility.
After 20 minutes furious coding, the routine was up and running; choosing the Mask > Collision option now generates a collision map on the currently-selected Layer, with the pass-through tile the currently-selected Right tile, and the solid tile the currently-selected Left tile. Maximum flexibility, easy to use, and extremely useful, even if I do say so myself.
Decided to bite the bullet and finish the map loading completely, specifically the force-load routine which loads a map with dimensions smaller / larger than the current map. I actually had the bulk of the code written already, but kept getting unexpected crashes.
After popping in a Stop command and tracing through using the debugger - something which I never knew was possible until recently - the problem dawned on me in an instant, and now all of the map I/O code is finally wrapped up.
Rounded off the day by tackling the Mask > Collision functionality, which was one of the first ideas I jotted down on my To Do list almost a year ago. Essentially, I wanted the user to have a very quick way to generate collision maps based on the current map (collision maps being 0 for pass-through tiles, and 1 for solid walls and suchlike). This is particularly useful for game engines which don't check the actual tile that the player is colliding with, they check the collision map.
Why? Sometimes it's useful to use collision maps as it allows different entities within the game to react differently to the same tile - specifying the collision properties for each tile takes away such flexibility.
After 20 minutes furious coding, the routine was up and running; choosing the Mask > Collision option now generates a collision map on the currently-selected Layer, with the pass-through tile the currently-selected Right tile, and the solid tile the currently-selected Left tile. Maximum flexibility, easy to use, and extremely useful, even if I do say so myself.
Sunday, July 24, 2005
Sunday 24th
Took some time out to address a bug that had been cropping up occasionally (usually when I'm just playing around with the Editor as opposed to coding). The bug stemmed from the changes I made recently to the Brush code, and it was just a simple case of moving a line of code to prevent the program reading erroneous data off the edge of the map.
This also pushed me in the direction of another bug in the Brush code, which was supposed to prevent masked tiles from being plotted. Essentially, there are two sets of Brush checks, depending on the Brush's handle point (top left or bottom right). In this instance, I'd neglected to copy the working code for the top-left handling to the bottom-right handling. Tsk tsk!
Rounded off today's session by tweaking the Map Set I/O routine to automatically check the map size and resize the project automatically (when loading a single map, the Editor prompts the user to check if they want to resize as it may affect the other Layers - when loading a Map Set, all Layers are being resized and loaded, and thus no need for a prompt). Finished up by adding Map Set Load/Save icons to the toolbar, purely because I was sick of using the menu. :)
This also pushed me in the direction of another bug in the Brush code, which was supposed to prevent masked tiles from being plotted. Essentially, there are two sets of Brush checks, depending on the Brush's handle point (top left or bottom right). In this instance, I'd neglected to copy the working code for the top-left handling to the bottom-right handling. Tsk tsk!
Rounded off today's session by tweaking the Map Set I/O routine to automatically check the map size and resize the project automatically (when loading a single map, the Editor prompts the user to check if they want to resize as it may affect the other Layers - when loading a Map Set, all Layers are being resized and loaded, and thus no need for a prompt). Finished up by adding Map Set Load/Save icons to the toolbar, purely because I was sick of using the menu. :)
Saturday, July 23, 2005
Saturday 23rd
Started implementing 'edit' checks in the code today; essentially, every time the user makes a change to a map, this action is flagged. Should they opt to load in a map or exit the program, the Editor can then check whether or not there are unsaved changes and prompt accordingly.
This sort of checking can be somewhat tiresome, as there are dozens of checks that need to be added, so I concentrated mainly on the basic logic, setting up the necessary flags, putting warnings on the program exit points, and clearing the edit check flags should the user save their map or project.
As an afterthought, the Editor also prints an asterisk next to any layers which have been edited but not saved (like FrontPage, for example), so it's much easier to see which files need to be saved.
Rounded off the night by plucking another task off my list, that of regenerating the Brush Thumbnail images should the user load a new tileset. This was fairly painless thanks mainly to the modular nature of the thumbnail routine. Further tweaks may be required in order to tell each stored Brush while tileset to get its image from. Maybe. :)
This sort of checking can be somewhat tiresome, as there are dozens of checks that need to be added, so I concentrated mainly on the basic logic, setting up the necessary flags, putting warnings on the program exit points, and clearing the edit check flags should the user save their map or project.
As an afterthought, the Editor also prints an asterisk next to any layers which have been edited but not saved (like FrontPage, for example), so it's much easier to see which files need to be saved.
Rounded off the night by plucking another task off my list, that of regenerating the Brush Thumbnail images should the user load a new tileset. This was fairly painless thanks mainly to the modular nature of the thumbnail routine. Further tweaks may be required in order to tell each stored Brush while tileset to get its image from. Maybe. :)
Thursday, July 21, 2005
Thursday 21st
A nice email arrived this morning, with another snippet of code from Muttley; I'd hit a snag with my Tile padding routine, so rather than waste precious time trying every possibility I asked Muttley to explore the problem. It all boiled down to the fact that I was using AnimImages, which produce quirky results when the image is written to.
After a few tweaks, the code was working correctly, albeit with a slight snag - the padding routine creates an Image, not an AnimImage, so none of my Editor code could display the tiles properly. I considered that if a tileset was too short, the user would probably want to save the corrected Tileset anyway, so I got around the problem by saving the corrected Tileset (for future use), then loading it back in as an AnimImage.
Hit upon the notion that Tilesets might also contain too many tiles; thankfully, the padding routine also automatically crops larger images, so the addition of a simple check at the start of the routine now means that over and undersized Tilesets are catered for! :)
Also took the opportunity of adding an Export Tileset function; currently, the Editor can handle either continuous strips of tiles, or images which hold a block of tiles - the Export function now allows tiles loaded as blocks to be saved out as strips.
After a few tweaks, the code was working correctly, albeit with a slight snag - the padding routine creates an Image, not an AnimImage, so none of my Editor code could display the tiles properly. I considered that if a tileset was too short, the user would probably want to save the corrected Tileset anyway, so I got around the problem by saving the corrected Tileset (for future use), then loading it back in as an AnimImage.
Hit upon the notion that Tilesets might also contain too many tiles; thankfully, the padding routine also automatically crops larger images, so the addition of a simple check at the start of the routine now means that over and undersized Tilesets are catered for! :)
Also took the opportunity of adding an Export Tileset function; currently, the Editor can handle either continuous strips of tiles, or images which hold a block of tiles - the Export function now allows tiles loaded as blocks to be saved out as strips.
Wednesday, July 20, 2005
Wednesday 20th
In a bid to stop my brain becoming fried by bugs and problems, my attention turned towards the Map I/O routine and, specifically, adding the map dimensions to the Map files. This was a fairly quick process, and after converting all of my test maps to this new system, I set about the error handling code.
Basically, if the user chooses to load in a Map that is different in size to the current project, they can either opt to resize the map, or to 'force load' the map into the current project (which may result in cropping if the map being loaded is bigger than the project).
After some tinkering, and a couple of tweaks to my Resize Map routine (which I added a few weeks ago), the system was up and running; all that remains is to write the force-load routine.
Basically, if the user chooses to load in a Map that is different in size to the current project, they can either opt to resize the map, or to 'force load' the map into the current project (which may result in cropping if the map being loaded is bigger than the project).
After some tinkering, and a couple of tweaks to my Resize Map routine (which I added a few weeks ago), the system was up and running; all that remains is to write the force-load routine.
Monday, July 18, 2005
Monday 18th
Started tackling the I/O error handling on the Tileset loading routine, thanks to some helpful hints and suggestions from Muttley, one of my test pilots who very kindly mocked up some source code for me to work from. Using this as a template, I popped in some code to calculate that the image dimensions corresponded to the current Tile size.
Next came the code which counts the number of tiles in the Tileset, based on the image dimensions. The next task, which will have to wait until later in the week, will involve 'padding out' the Tileset if there aren't sufficient tiles (the Editor uses 256 tiles, and I'm not changing this unless a) I receive a lot of requests, or b) receive a lot of money!).
Next came the code which counts the number of tiles in the Tileset, based on the image dimensions. The next task, which will have to wait until later in the week, will involve 'padding out' the Tileset if there aren't sufficient tiles (the Editor uses 256 tiles, and I'm not changing this unless a) I receive a lot of requests, or b) receive a lot of money!).
Sunday, July 17, 2005
Sunday 17th
Had a little bit of a tidy-up today, with the I/O routines getting a rigorous revamp (partly because many of my Save/Save As routines were separate, but could easily be combined into a single routine as the code for each was largely the same.
This led on to the addition of the Map Set loading and saving routines, allowing the user to save out all 8 maps as a single file (this is something I'd had on my 'Possibly To Do' list for a while, but a little gentle nudging from one of my Test Pilots convinced me it was a good idea!).
Finished up by fixing a small bug in the Tileset loading routine, which occasionally missed out a specific tile when the Tileset was loaded, but subsequently loaded the tile properly when the Tileset was refreshed. The code for each one was identical, save for one mistyped number, and after a deft slap to the forehead everything was working as intended.
This led on to the addition of the Map Set loading and saving routines, allowing the user to save out all 8 maps as a single file (this is something I'd had on my 'Possibly To Do' list for a while, but a little gentle nudging from one of my Test Pilots convinced me it was a good idea!).
Finished up by fixing a small bug in the Tileset loading routine, which occasionally missed out a specific tile when the Tileset was loaded, but subsequently loaded the tile properly when the Tileset was refreshed. The code for each one was identical, save for one mistyped number, and after a deft slap to the forehead everything was working as intended.
Wednesday, July 13, 2005
Wednesday 13th
Decided to take a delve back into the Undo/Redo code today, with little in the way of progress. I did manage to crack a small problem in the logic, however, which was preventing the Undo going right back to the start of the list; essentially, the Editor needs to call the Undo routine at the start of the program, or if a map is loaded into memory - this 'saves' the initial state of the map, allowing the user to Undo back to the beginning.
Tuesday, July 12, 2005
Tuesday 12th
Tonight's session saw me tackling a task which had never worked properly since it was added many moons ago. In theory, the system seemed fairly straightforward: when the user holds Shift, it constrains lines to 90 or 45 degrees, and constrains boxes to a perfect square.
After delving in with a brain full of caffeine, I managed to track down the problem which was causing unpredictable results - it stemmed from the fact that a line/box is not always drawn from top-left to bottom-right; sometimes, the box is drawn in reverse. Once my code understood this, the routine worked like a dream. Getting this functionality to work with Brush grabbing will be another matter!
After delving in with a brain full of caffeine, I managed to track down the problem which was causing unpredictable results - it stemmed from the fact that a line/box is not always drawn from top-left to bottom-right; sometimes, the box is drawn in reverse. Once my code understood this, the routine worked like a dream. Getting this functionality to work with Brush grabbing will be another matter!
Sunday, July 10, 2005
Sunday 10th
Avid followers of this Blog will recall the Bookmark code I added to the Editor a while ago (which basically allowed the user to store their current position and current map at the press of a button). The feature was coded, but left on the sidelines due to a keyboard conflict.
I'd always liked the system, so today I tied in the functionality to my recently-created Bookmark menu - a deft click of the mouse now allows the user to store and retrieve up to eight different editing positions.
I'd always liked the system, so today I tied in the functionality to my recently-created Bookmark menu - a deft click of the mouse now allows the user to store and retrieve up to eight different editing positions.
Saturday, July 9, 2005
Saturday 9th
After yesterday's bug chasing, I decided to continue with the tweaks and fixes. First of all, I finalised the scrolling system for the Tile window, so that it comfortably copes with tiles of any size. It's likely that the user will be restricted to tilesets of 256 tiles - files smaller than this will be 'padded out' when loaded into the editor.
Fixing the Tile window also forced me to tackle another bug: the inability to load a 128x128 tileset into the editor. After trying - and failing - to load the image back into PhotoShop, it occurred to me that there must be some physical restriction (possibly in MS Windows) that shies away from files over a certain width/height.
Sure enough, I managed to deduce that files over 16384 pixels in width/height will cause problems - luckily, the Editor can handle blocks of tiles as well as strips of tiles, so after a quick snip and paste, everything was peachy.
Rounded off by tweaking the Meta Panel, as the addition of 64x64 and 128x128 tiles means that I needed to drop the Copy/Paste buttons and shift down the Meta Flags display. The buttons were convenient, admittedly, so they now sit nicely in the Tile menu.
Fixing the Tile window also forced me to tackle another bug: the inability to load a 128x128 tileset into the editor. After trying - and failing - to load the image back into PhotoShop, it occurred to me that there must be some physical restriction (possibly in MS Windows) that shies away from files over a certain width/height.
Sure enough, I managed to deduce that files over 16384 pixels in width/height will cause problems - luckily, the Editor can handle blocks of tiles as well as strips of tiles, so after a quick snip and paste, everything was peachy.
Rounded off by tweaking the Meta Panel, as the addition of 64x64 and 128x128 tiles means that I needed to drop the Copy/Paste buttons and shift down the Meta Flags display. The buttons were convenient, admittedly, so they now sit nicely in the Tile menu.
Friday, July 8, 2005
Friday 8th
Started tinkering with ideas for a Zoom function; I've used an editor in the past which allows the user to zoom out to get a better picture of how the whole map looks. This would be ideal for the Editor, particularly as it's just a cosmetic function (no editing takes place when the user is zoomed in/out), and partly because I have much of the code written already.
Finished off the day searching for an elusive bug which causes a quirky problem when in 16x16 tile mode. Still can't work out why it's happening - perhaps I'll just remove the 16x16 option altogether ;)
Finished off the day searching for an elusive bug which causes a quirky problem when in 16x16 tile mode. Still can't work out why it's happening - perhaps I'll just remove the 16x16 option altogether ;)
Thursday, July 7, 2005
Thursday 7th
Not much progress today. Decided to delve into the Undo/Redo code again, as it's been sitting on my To Do list for far too long. Most of the logic was plotted out on paper, which is always helpful, but by the time I reached the keyboard my head was blank (typical!). Not one to waste valuable minutes, I set about creating a Key List, to help me keep track of the assigned keys.
Wednesday, July 6, 2005
Wednesday 6th
After a brief stint yesterday, trying to get my head around the Mini Map and Meta Data functionality, I decided to leave that task momentarily and tackle a few other pressing issues.
First on the agenda was the startup menu; currently, the Editor loads up all my test tilesets, and sets the map at a specific size. Now that the tile size changes have been implemented and - touch wood - should be working properly, it seems appropriate to implement the startup menu (this will allow the user to create a new project with the desired map dimensions and tilesize, or load an existing project).
It's always interesting when a new piece of code is integrated into an existing (and complex) framework - thankfully, the startup screen was a cinch to implement, and fires the Editor up properly every time. :)
Rounded off the evening by adding a few more options to the menus, to cope with the Layer flipping and Bookmark routines (which will hopefully be added this week).
First on the agenda was the startup menu; currently, the Editor loads up all my test tilesets, and sets the map at a specific size. Now that the tile size changes have been implemented and - touch wood - should be working properly, it seems appropriate to implement the startup menu (this will allow the user to create a new project with the desired map dimensions and tilesize, or load an existing project).
It's always interesting when a new piece of code is integrated into an existing (and complex) framework - thankfully, the startup screen was a cinch to implement, and fires the Editor up properly every time. :)
Rounded off the evening by adding a few more options to the menus, to cope with the Layer flipping and Bookmark routines (which will hopefully be added this week).
Monday, July 4, 2005
Monday 4th
Tonight's session saw the addition of some enhanced functionality for the Mini Map. Currently, the Mini Map works on a fixed tile range (all tiles within this range show up on the Mini Map panel). I wanted to extend this capability to make it more user-controllable, so the first task involved adding extra options to the relevant menu.
That done, I added the code to read the Mini Map from the current Tile Mask - although this only gives the user two choices (the tile is either displayed or not), it is quite a useful way to track tile usage.
Next, I wanted to implement a system that allowed the Mini Map to get its information from the Meta Data. I prototyped a pop-up window in PhotoShop, then used this template to code the necessary routines.
This is actually a pretty cool system, as I can read the co-ordinates in PhotoShop and transfer them directly to Blitz, thus saving plenty of painstaking tweaks. With the shell complete, I tied up the functionality ready to write the more serious code tomorrow.
That done, I added the code to read the Mini Map from the current Tile Mask - although this only gives the user two choices (the tile is either displayed or not), it is quite a useful way to track tile usage.
Next, I wanted to implement a system that allowed the Mini Map to get its information from the Meta Data. I prototyped a pop-up window in PhotoShop, then used this template to code the necessary routines.
This is actually a pretty cool system, as I can read the co-ordinates in PhotoShop and transfer them directly to Blitz, thus saving plenty of painstaking tweaks. With the shell complete, I tied up the functionality ready to write the more serious code tomorrow.
Sunday, July 3, 2005
Sunday 3rd
Managed to crack the Brush plotting changes today. Basically, the user can hold CTRL when plotting a Brush to mask out Tile 0 - this allows genuine Brush transparency. However, I hit upon the idea of making CTRL mask out the currently selected tile - that way, the user can specify exactly which tile in the Brush they don't wish to plot.
Confused? Ok, imagine the map is filled with Tile 4, and on top of this the user has drawn a shape with Tile 3. Imagine they wanted to plot this brush on to a background consisting of Tile 8 - plotting the brush as-is will cause the instances of Tile 4 to be plotted too.
Using my new system, once the Brush is grabbed the user simply selects Tile 4, then holds CTRL as they plot their Brush - only Tile 3 is plotted, any instances of Tile 4 in the Brush are ignored (it's much easier to understand when you see it working!).
After toiling away for an hour or so, I managed to override the conflicts associated with Masked Tiles, and the whole system was working perfectly. I'm extremely pleased with the Editor's Brush functions, and it's getting to the point where I'm itching to stop coding and start messing around with maps :)
Confused? Ok, imagine the map is filled with Tile 4, and on top of this the user has drawn a shape with Tile 3. Imagine they wanted to plot this brush on to a background consisting of Tile 8 - plotting the brush as-is will cause the instances of Tile 4 to be plotted too.
Using my new system, once the Brush is grabbed the user simply selects Tile 4, then holds CTRL as they plot their Brush - only Tile 3 is plotted, any instances of Tile 4 in the Brush are ignored (it's much easier to understand when you see it working!).
After toiling away for an hour or so, I managed to override the conflicts associated with Masked Tiles, and the whole system was working perfectly. I'm extremely pleased with the Editor's Brush functions, and it's getting to the point where I'm itching to stop coding and start messing around with maps :)
Saturday, July 2, 2005
Saturday 2nd
Today saw the implementation of a colour cycling routine to pulse my new vector cursors; this took a little longer than expected due to the quirky way in which Blitz handles Data statements. Ok, it's actually perfectly fine, but it's a little different to Commodore BASIC so I'm sticking with my quirky statement :)
The cursors looked so good, I actually tweaked my Brush Grab cursors and converted them to vectors, which now means that they too can have pulsing colour (and makes a big difference to the Editor's look and feel).
Next, I plucked a task from my To Do list which had been negelected for far too long, that of allowing the user to change both the X and Y dimensions of the Grid (previously, X and Y were locked). This entailed creating a custom pop-up window, but the added flexibility is well worth the effort.
The final task involved an amendment to the Brush plotting routine, but with the time approaching midnight, I thought better of delving into one of the Editor's more complex routines and reserved it a spot on tomorrow's schedule. ;)
The cursors looked so good, I actually tweaked my Brush Grab cursors and converted them to vectors, which now means that they too can have pulsing colour (and makes a big difference to the Editor's look and feel).
Next, I plucked a task from my To Do list which had been negelected for far too long, that of allowing the user to change both the X and Y dimensions of the Grid (previously, X and Y were locked). This entailed creating a custom pop-up window, but the added flexibility is well worth the effort.
The final task involved an amendment to the Brush plotting routine, but with the time approaching midnight, I thought better of delving into one of the Editor's more complex routines and reserved it a spot on tomorrow's schedule. ;)
Friday, July 1, 2005
Friday 1st
Work continued on the tile size tweaks today, kicking off with a few changes to the various mouse pointers and cursors (naturally, these were constructed for 32x32 tiles but now need to accommodate all tile sizes).
The main task involved converting my map and tile cursors from bitmap images into actual rectangles drawn by Blitz. This was a simple task, and allowed me to trim out all of the cursor animations (which makes their colours "pulse") from my cursor bitmap image. I finished off by creating cursor bitmap images to suit all tile sizes.
The main task involved converting my map and tile cursors from bitmap images into actual rectangles drawn by Blitz. This was a simple task, and allowed me to trim out all of the cursor animations (which makes their colours "pulse") from my cursor bitmap image. I finished off by creating cursor bitmap images to suit all tile sizes.
Subscribe to:
Posts (Atom)
