I'm afraid I have some slightly more complex requirements for my next few game ideas!
The original Buzzsaw+ sprites were designed with only being able to change the colour every second row, offset down by 1 pixel for the right-hand half of the sprite, as that's all my early LDI-based colour routine could manage. If I ever get round to mastering the 'extras' disk for the tape version you'll be able to see it in all its roughness. If you enlarge the sprites and look closely (particularly at their BRIGHT shading), you can see a lot of them still look like this as I didn't make many tweaks once I got the full colour routine working.
They're done with solid blocks of colour, though I'm quite impressed by the look of some of the sprites people have done on this engine that combine colour switches with stipples and alternate-line colour shading. I can't find those others - is it R-Tape that does really good eyes on his fish sprites? We need to see more of taking the sprites to the edge of the frame to use paper colours though. Looking at that ball with a spot highlight, I can think of a red apple with a yellow or white PAPER section marking out a bite crossing past half-way, then another colour INK for showing the core and pips. Or maybe just two concentric rings of colour offset to one side.
But it has a massive table of addresses to speed up the drawing, then wastes loads of time on scanning the entire keyboard. :-?
I considered using lookup tables, but they would be too massive. Including support for drawing tiles partially outside the multicolor area, this would require 176 lines x 20 columns x 2 bytes per address = 7K for bitmaps and another 7K for attributes. Right now the largest version of BIFROST* is about 8K, these tables would increase its total size to about 22K, thus not leaving much space left for the program code and graphics. A generic tool is not supposed to take over more than half the computer memory for itself :)
I believe BIFROST* got the right balance regarding size versus speed. During the upper border it can draw 2 sprite tiles at arbitrary locations (any pixel row and any character column) and 3 animated tiles at fixed locations (odd char row and column), although I could easily provide a custom version with 5 sprite tiles at arbitrary locations during the upper border, similar to Buzzsaw+, if anyone ever needs it. And after the frame it can both draw and erase at least another 3 tiles at arbitrary locations.
You may want to copy the idea of erasing sprites after the colour routine, by just setting their attributes to black. It means they're there while the colours are rendered but gone by the next frame and can just be redrawn in the new position.
Thanks, it's done already! This is demonstrated in the Buzzsaw-like demo I posted here.
Ah, right. Buzzsaw+ does all 7 sprite draws in the top border. That way it can erase the moving ones after the colour rendering, ready to redraw them in the next frame in a different position.
When it comes to redrawing the entire hopper, the code itself steps in to do 5 more sprites per frame (using a slightly slower stack-friendly version of the sprite routine), allowing 12 blocks (two whole rows of the hopper) to be redrawn per frame.
But yes, it has a massive table of screen addresses to achieve that. All the possible pixel adresses are listed in columns so the sprite routine can just read off 16 sequential addresses.
Needless to say, if I re-wrote it now it would probably be a bit more efficient with the memory...
Notice your main character (Phantomasa?) would work very well for pre-rotated graphics sideways, if you want to consider a more smooth movement. Do you mind if I use your tile to demonstrate how this would look like?
Hmm - maybe it's the emulator, or something's been saved as a JPEG, but enlarging that image there are definitely a few impossible pixels. There are at least four different shades of grey around the blue fish's eyes, and four different yellows around the dragon's belly, mixing BRIGHT and non-BRIGHT in the same 8x1 space. Odd though that only a few pixels are affected.
Hmm - maybe it's the emulator, or something's been saved as a JPEG, but enlarging that image there are definitely a few impossible pixels. There are at least four different shades of grey around the blue fish's eyes, and four different yellows around the dragon's belly, mixing BRIGHT and non-BRIGHT in the same 8x1 space. Odd though that only a few pixels are affected.
Ops!
It's the image. I saved it as BMP using an emulator, then converted to PNG using MS Paint, then Martijn converted to GIF since that's the standard screenshot format at WoS.
These are all lossless formats, but I just checked my PNG and it has the same problems. The culprit was either the emulator or MS. I will check it tonight and upload a fixed version.
EDIT: It turns out these visual defects were caused by setting "ULA Colour Ramping" in ZX-Spin 0.7, that is enabled by default (at least I don't recall activating it myself). I just produced a new in-game screenshot without this setting and uploaded it to WoS.
I'm afraid I have some slightly more complex requirements for my next few game ideas!
The original Buzzsaw+ sprites were designed with only being able to change the colour every second row, offset down by 1 pixel for the right-hand half of the sprite, as that's all my early LDI-based colour routine could manage. If I ever get round to mastering the 'extras' disk for the tape version you'll be able to see it in all its roughness. If you enlarge the sprites and look closely (particularly at their BRIGHT shading), you can see a lot of them still look like this as I didn't make many tweaks once I got the full colour routine working.
They're done with solid blocks of colour, though I'm quite impressed by the look of some of the sprites people have done on this engine that combine colour switches with stipples and alternate-line colour shading. I can't find those others - is it R-Tape that does really good eyes on his fish sprites? We need to see more of taking the sprites to the edge of the frame to use paper colours though. Looking at that ball with a spot highlight, I can think of a red apple with a yellow or white PAPER section marking out a bite crossing past half-way, then another colour INK for showing the core and pips. Or maybe just two concentric rings of colour offset to one side.
That's quite interesting. I'm eager to see that disk :) Here's my apple attempt, but I think this could be done much better.
Notice your main character (Phantomasa?) would work very well for pre-rotated graphics sideways, if you want to consider a more smooth movement. Do you mind if I use your tile to demonstrate how this would look like?
Here's my apple attempt, but I think this could be done much better.
That's excellent. The only thing I'd suggest is keeping the stalk bright green, but making the leaf off to the side not bright. Also you could try making a row of the yellow highlight white for an even brighter effect - just to show off to C64 owners how many colours you can fit in a sprite!
This one is a bit excessive, I reckon, it seems a bitten apple:
It also looks great! Perhaps after the player (or an enemy) picks up and "uses" the original apple with a leaf, it's left as a bitten apple without a leaf...
It would look even better if the bite mark was a little less regular, although I can't see any good way to change this...
I did just mean to darken the bit at the side, as he has done.
That is cunning use of the edge of the sprite though, and would be great for scenery, but I prefer na_th_an's as an iconic apple shape. On the other hand, how about dark yellow for the stalk to emphasise the green of the leaf? Or na_th_an, animate yours so it rotates?
The only thing to be cautious of (I found with Buzzsaw+) is it's always tempting to get carried away and use the full width of the frame to use PAPER colours on both halves, but if you do you can end up with some odd-looking forms when you start packing objects in next to each other. It's always worth checking what things look like when duplicated.
Interesting attempts, we'll end up with the perfect apple, that's for sure ;) I like how the leaf looks when the apple is isolated, but joefish is right - it may look odd when juxtaposed.
About making a better bite, that's the challenge and the joy of drawing pixel art with limitations :)
Interesting attempts, we'll end up with the perfect apple, that's for sure ;) I like how the leaf looks when the apple is isolated, but joefish is right - it may look odd when juxtaposed.
About making a better bite, that's the challenge and the joy of drawing pixel art with limitations :)
I've had a play and I think yours is near perfect, a few lines at the top left look like a leaf but don't add anything. I realise I was being a fusspot now.
Good fun though, I'll have to set some time aside for some more rainbow graphics.
Okay, my take on 'the apple problem':
Sometimes you have to compromise a tiny bit on your perfect shape (there's an extra red pixel snuck in under the bite) and other times you just have to stick with horizontal bands of colour (the bite is just white ink on black).
Agreed, especially for "pick up" items or special details in the scenery. This will help make your game look much more impressive, and BIFROST* will animate them for you for free (it requires extra tiles for the animation frames but there's no cost in terms of processing time).
Okay, my take on 'the apple problem':
Sometimes you have to compromise a tiny bit on your perfect shape (there's an extra red pixel snuck in under the bite) and other times you just have to stick with horizontal bands of colour (the bite is just white ink on black).
I think you nailed it down. That simply looks perfect to me.
About the rotation, I don't get it (I understand that you can auto-animate tiles, that's why I made four water tiles in my set). What do you mean?
About the rotation, I don't get it (I understand that you can auto-animate tiles, that's why I made four water tiles in my set). What do you mean?
First you'd have to make the apple shape a little less symmetrical, but then you could animate it to make it look like it's hanging by a thread and spinning in the air. Most of the animation would be done around the leaf at the top, but the light spot could maybe move up and down a little. It might be too difficult to make it look good though, since you can't move dark red shading across the face of the image.
I get what you mean. It would be doable, but maybe not that colourful.
You could try to rotate the apple using views from front, top, back (upside down) and bottom. I'm not sure if that would look OK, but at least it would give you more distinct views without the need to reduce colors.
No, I think that'd look too bizarre. Just spinning around a vertical axis or nothing. But it would take at least 8 frames to do it justice, making the leaf on top rotate around. It would need to be an asymmetrical shape to give the visual cue that it's rotating too. I may have a go later. But it would probably end up looking like a wobbling jelly blob rather than actually spinning.
No, I think that'd look too bizarre. Just spinning around a vertical axis or nothing. But it would take at least 8 frames to do it justice, making the leaf on top rotate around. It would need to be an asymmetrical shape to give the visual cue that it's rotating too. I may have a go later. But it would probably end up looking like a wobbling jelly blob rather than actually spinning.
Right now BIFROST* only supports either 2 or 4 frames for animations. I can easily provide a custom version that will animate tiles using 8 frames (just let me know), but this will use 8x64=512 bytes per animated tile.
I suppose 1/2 Kb for a single apple is way too much... It would also require sacrificing current colors and it probably won't look great anyway, thus I doubt it's worth the extra effort anymore.
It would be the most expensive apple in the history of ZX Spectrum games! :D
And the most exquisite and beautiful apple in the history of ZX Spectrum games; who could put a price on such things?
It would just have to be a game about an apple going round eating other apples, with maybe bonus points (indicated in apples) for getting to the spinning apples first.
Notice your main character (Phantomasa?) would work very well for pre-rotated graphics sideways, if you want to consider a more smooth movement. Do you mind if I use your tile to demonstrate how this would look like?
Not at all, use them at your will :-)
I have been way too busy in Real Life lately, so I didn't have time to post the next demo any sooner. Now it's finally available here.
Comments
The original Buzzsaw+ sprites were designed with only being able to change the colour every second row, offset down by 1 pixel for the right-hand half of the sprite, as that's all my early LDI-based colour routine could manage. If I ever get round to mastering the 'extras' disk for the tape version you'll be able to see it in all its roughness. If you enlarge the sprites and look closely (particularly at their BRIGHT shading), you can see a lot of them still look like this as I didn't make many tweaks once I got the full colour routine working.
They're done with solid blocks of colour, though I'm quite impressed by the look of some of the sprites people have done on this engine that combine colour switches with stipples and alternate-line colour shading. I can't find those others - is it R-Tape that does really good eyes on his fish sprites? We need to see more of taking the sprites to the edge of the frame to use paper colours though. Looking at that ball with a spot highlight, I can think of a red apple with a yellow or white PAPER section marking out a bite crossing past half-way, then another colour INK for showing the core and pips. Or maybe just two concentric rings of colour offset to one side.
- IONIAN-GAMES.com -
I considered using lookup tables, but they would be too massive. Including support for drawing tiles partially outside the multicolor area, this would require 176 lines x 20 columns x 2 bytes per address = 7K for bitmaps and another 7K for attributes. Right now the largest version of BIFROST* is about 8K, these tables would increase its total size to about 22K, thus not leaving much space left for the program code and graphics. A generic tool is not supposed to take over more than half the computer memory for itself :)
I believe BIFROST* got the right balance regarding size versus speed. During the upper border it can draw 2 sprite tiles at arbitrary locations (any pixel row and any character column) and 3 animated tiles at fixed locations (odd char row and column), although I could easily provide a custom version with 5 sprite tiles at arbitrary locations during the upper border, similar to Buzzsaw+, if anyone ever needs it. And after the frame it can both draw and erase at least another 3 tiles at arbitrary locations.
Thanks, it's done already! This is demonstrated in the Buzzsaw-like demo I posted here.
When it comes to redrawing the entire hopper, the code itself steps in to do 5 more sprites per frame (using a slightly slower stack-friendly version of the sprite routine), allowing 12 blocks (two whole rows of the hopper) to be redrawn per frame.
But yes, it has a massive table of screen addresses to achieve that. All the possible pixel adresses are listed in columns so the sprite routine can just read off 16 sequential addresses.
Needless to say, if I re-wrote it now it would probably be a bit more efficient with the memory...
- IONIAN-GAMES.com -
This looks great!!!
Notice your main character (Phantomasa?) would work very well for pre-rotated graphics sideways, if you want to consider a more smooth movement. Do you mind if I use your tile to demonstrate how this would look like?
Yes, there's an image of his tiles here:
http://www.worldofspectrum.org/infoseekid.cgi?id=0027405
- IONIAN-GAMES.com -
Ops!
It's the image. I saved it as BMP using an emulator, then converted to PNG using MS Paint, then Martijn converted to GIF since that's the standard screenshot format at WoS.
These are all lossless formats, but I just checked my PNG and it has the same problems. The culprit was either the emulator or MS. I will check it tonight and upload a fixed version.
EDIT: It turns out these visual defects were caused by setting "ULA Colour Ramping" in ZX-Spin 0.7, that is enabled by default (at least I don't recall activating it myself). I just produced a new in-game screenshot without this setting and uploaded it to WoS.
That's quite interesting. I'm eager to see that disk :) Here's my apple attempt, but I think this could be done much better.
Not at all, use them at your will :-)
- IONIAN-GAMES.com -
Now let's find this some use.
This one is a bit excessive, I reckon, it seems a bitten apple:
Why are you posting Amiga screenshots on the WOS forum :razz: ?
That is one lovely apple (the first one). Agree with joe's suggestion of trying a leaf.
Here's my poor attempt to add a leaf:
Thanks!
It would look even better if the bite mark was a little less regular, although I can't see any good way to change this...
That is cunning use of the edge of the sprite though, and would be great for scenery, but I prefer na_th_an's as an iconic apple shape. On the other hand, how about dark yellow for the stalk to emphasise the green of the leaf? Or na_th_an, animate yours so it rotates?
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
About making a better bite, that's the challenge and the joy of drawing pixel art with limitations :)
I've had a play and I think yours is near perfect, a few lines at the top left look like a leaf but don't add anything. I realise I was being a fusspot now.
Good fun though, I'll have to set some time aside for some more rainbow graphics.
Sometimes you have to compromise a tiny bit on your perfect shape (there's an extra red pixel snuck in under the bite) and other times you just have to stick with horizontal bands of colour (the bite is just white ink on black).
- IONIAN-GAMES.com -
I think you nailed it down. That simply looks perfect to me.
About the rotation, I don't get it (I understand that you can auto-animate tiles, that's why I made four water tiles in my set). What do you mean?
- IONIAN-GAMES.com -
- IONIAN-GAMES.com -
I suppose 1/2 Kb for a single apple is way too much... It would also require sacrificing current colors and it probably won't look great anyway, thus I doubt it's worth the extra effort anymore.
It would just have to be a game about an apple going round eating other apples, with maybe bonus points (indicated in apples) for getting to the spinning apples first.
- IONIAN-GAMES.com -
I have been way too busy in Real Life lately, so I didn't have time to post the next demo any sooner. Now it's finally available here.