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. :)
Wednesday, April 26, 2006
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.
Subscribe to:
Posts (Atom)
