I'd not seen that before - I didn't know anyone had made a game with multi-colour effects in. Well, it takes some of the pressure off trying to get one out first I suppose... :)
No, the clever bit will be trying to free up even a few hundred nanoseconds of processor time to do anything else...
That's the problem - to hold the effect you have to work within a single frame, as the default rendering for the next frame will ruin the effect - just view it in SPIN without Multi-colour rendering enabled to get an idea of what you'd see - and fitting in the precise timing of the redraw, and the game logic, all in a single frame is going to be a tough call.
Some games have presented different colours on alternate screens, such as Gyron & Helichopper. The effect isn't as good, but at least you have more time to play with.
So if this was turned into a full game would pixel-movement be possible for the main sprite? I guess for the rest of the sprites (ships, etc.) the movement would have to restricted to 4 pixels horizontally ?
I think the hardest work is already done by Joe, the game engine would require "only" to move some objects around. Oh and the bullets must still be shown somehow, which is probably possilbe ? :)
What I really would like to see is the display routine.
We could make a buffer where you set the bytes how to display on the screen (in colors) and then call a default routine which would make the display in multicolors.
(I think something similar can be (or has been) done for ZX81 games in Hires.)
Just a little something to look at. Enjoy. Joefish_River_Raid_Tech_Demo_01.tap
Put together using a 48K Spectrum under ZXSpin, but it seems to be stable on most models.
Sadly there are no controls and the river's a bit narrow. I have a few more ideas so may come back to this. Or it might mutate into something else...
Most impressive. If some graphician would care of it - would look even better.
My respect, sir.
_____edit_________
Additionally, I noticed it recognize many Spectrum models automatically, which is even more impressive.
What I really would like to see is the display routine.
We could make a buffer where you set the bytes how to display on the screen (in colors) and then call a default routine which would make the display in multicolors.
See this thread: http://www.worldofspectrum.org/forums/showthread.php?t=24894
It's not quite the same routine. The one I listed there does 16 characters wide, based on a bit of code from gasman. This demo does only 14 characters but includes border switching.
So if this was turned into a full game would pixel-movement be possible for the main sprite?
Not the way it's coloured - those white/yellow stripes on the bi-plane's wings are only 4 pixels in from the wingtips, so you can still get 1x8 attribute clash. It's designed to be positioned in four-pixel steps (at least, horizontally), just like the attribute-based objects.
Additionally, I noticed it recognize many Spectrum models automatically, which is even more impressive.
Clever, isn't it? Especially as it does nothing of the sort! There's just enough flexibility in the timing that it works across all the Speccies that ZXSpin can emulate, but I didn't add any code to adjust the timing.
Great work. Was just pondering what the next step would be - I guess you'd start out by splitting each sequence of PUSHes into two or more runs of a predetermined length:
- then during the upper/lower border, poke suitable values into the 'nnnn' parameters so that the multicolour effect is positioned where it's needed for that particular line. But then, you might find that the timings which currently work for the centre of the screen don't work for the edges (because you end up on the wrong side of the raster scan), and if so, I'm not sure how you'd get around that. Yup, the hard bit is still to come!
I think if the the playing area is reduced (e.g.: using only two thirds, and leaving a big marker below), this could become a game... But I'm not sure how complex the game could be... probably not too much.
I think if the the playing area is reduced (e.g.: using only two thirds, and leaving a big marker below), this could become a game... But I'm not sure how complex the game could be... probably not too much.
Thanks everyone for the compliments.
The playing area is already down to 14 characters wide - less than half. That's the blue channel up the centre of the screen. The extent of the road is just regular Spectrum graphics and border effects.
Great work. Was just pondering what the next step would be - I guess you'd start out by splitting each sequence of PUSHes into two or more runs of a predetermined length:
LD SP,nnnn; PUSH AF; PUSH BC, PUSH DE; LD SP,nnnn; PUSH HL...
- then during the upper/lower border, poke suitable values into the 'nnnn' parameters so that the multicolour effect is positioned where it's needed for that particular line.
I think you're suggesting making it so that it can split the colour effect into two columns to fork the river. It would be nice, but I think it's being ambitious. I was just going to make it step right or left by 6 characters.
If you split it into two, with the time you'd lose with the extra LD SP,nnn , you'd be down to 12 characters total or 6 in each half, which doesn't give you a lot of room to move.
But I wouldn't have to re-write all the addresses all the time, I just need to follow the scroll down and change one at a time. I already worked this out for the side-to-side shift.
The playing area is already down to 14 characters wide - less than half. That's the blue channel up the centre of the screen. The extent of the road is just regular Spectrum graphics and border effects.
I meant vertically, to get some precious time to develop the game control & logic. I already know the horizontal area is limited by the technique. :smile:
Sorry, misread the post. Thought you meant cut it back more in both directions. But yes, taking some off the height will save time, but the more you take away the more rubbish it looks. It could at least lose one line for scores, but for looks that section would probably have to extend into the border too.
What I really need to do is streamline the code so I don't have to keep re-writing values and addresses before each main pass of the colour routine. That will free up the top border time for drawing more sprites.
I think I need to make it alternate between two functions. The first pass it could draw a fixed number of sprites during the top border phase, then do some game logic in the bottom border phase.
In the next pass it would do some more game stuff during the top border, then erase the sprites and update the scrolling data pointers during the bottom border, ready for the next redraw.
The hard part is making game logic that can execute in a constant time (for when we're waiting in the top border), as by its very nature it branches a lot. You have to make every case equal to the worst case so you always know how long it will take. For example, to draw sprites, you always draw the same number of sprites, even if you throw some away by writing them to address 0. Perhaps the collision detection, or polling the keyboard could be adapted.
Well, you could try the turbo version if you like...
In an emulator or with a multiface, or just hack the loader and do:
POKE 32909,1
The demo actually refreshes completely in one frame, but I slowed it down to look more like the original game. That poke controls the number of frames before it scrolls the screen. Typically 2, but it can do 1. Any higher number will slow it down. 0 makes it go mental, in case you're wondering, as it will no longer wait for the interrupts.
I'm working on another game using a similar colour system - I have been for some time. But having tried out gasman's PUSH system I now have some major re-writing of that one to do.
Take a look at my avatar - that's an actual Spectrum sprite from the game. In it, the attributes only vary every two lines, with the right side attributes offset from the left by one pixel vertically. It took a hell of a lot of work to design to those requirements, and there are ten different creatures in total. They were designed for an LDI-based colour system that only wrote to every other attribute each line. With the PUSH system they can now have a separate attribute on each 1x8 pixel row, so I can colour and animate him as I originally intended to. I'll be working on this game for the moment.
As for this demo, I've been playing River Raid again recently and it's not that much of an exciting game to be honest. There's not a lot of challenge in that all it seems to do to increase the difficulty is make the refuellers further apart. That and I can't render the colours in a wide enough block to do anything like River Raid.
I'm optimising the colour-scrolling system, but I'm also working on ideas for a vertical-scrolling shooter better suited to a narrow colourful play area. Rather than waste the remaining space on scores or black space I want to put it to use, like the scanner HUD in Scramble or a map, so it's a feature of the game rather than a problem to ignore. But I want to keep the code optimised to make the colour area as large as possible - chopping 1/3 off the height is not something I want to do, nor is resorting to 128K-only effects.
So for the moment, this demo is done. I don't plan to make it do any more as I don't think there's much to be gained from producing a very restricted clone of River Raid. If you're worried there's a lot of code going to waste here, there really isn't. It's just the colour routine I already listed with one of the PUSH statements swapped for an OUT(254) to control the border, and a big table of pre-prepared colour data. It's a long way off an actual game.
I'd not seen that before - I didn't know anyone had made a game with multi-colour effects in. Well, it takes some of the pressure off trying to get one out first I suppose... :)
No, the clever bit will be trying to free up even a few hundred nanoseconds of processor time to do anything else...
Before that one from gasman, I couldn't name a single game that uses in-game multicolour effects. I'd like to see them if you know of any.
Uridium has some multi colour effects at the start, but not ingame. Hell of a neat scroller though!
You can try joefish's routine out in BASIC for yourself with ColorPRINT-48 (see rainbow processor thread). I'd advise turning the mode off except at run-time though as it really does slow down BASIC.
The only way I can write code that can synchronise with 48K, 128K and Pentagons is to do all the colour PUSHes for each line in the 96 T-states of side border; then my code can run in completely uncontested time on all machines and I can synch up the same code with any of them. There isn't enough memory to provide alternatively timed row-copy routines.
What this means is, I don't have time to do extras like the border colour swap in the middle of the PUSHes any more, as that then nudges the last PUSH into contested time and would mean I would have to treat the different machines differently. So, I can do Pentagon compatibility, but without the border effects.
As for 'other clones', if they don't synchronise, tough. You really can't have manual tuning without going in and editing the source code by hand. I can test it on the various machines emulated in ZXSpin, and provide a user option to switch between the various pre-programmed synch rates, but if I can't emulate it for testing and it's out of step with any of the more common models, then it's not going to be supported. Someone needs to make some better clones...
Comments
No, the clever bit will be trying to free up even a few hundred nanoseconds of processor time to do anything else...
Before that one from gasman, I couldn't name a single game that uses in-game multicolour effects. I'd like to see them if you know of any.
- IONIAN-GAMES.com -
lol, this must be it, I didn't see it for myself just read it in a thread. And I thought it was a flying bat :)
That's the problem - to hold the effect you have to work within a single frame, as the default rendering for the next frame will ruin the effect - just view it in SPIN without Multi-colour rendering enabled to get an idea of what you'd see - and fitting in the precise timing of the redraw, and the game logic, all in a single frame is going to be a tough call.
Some games have presented different colours on alternate screens, such as Gyron & Helichopper. The effect isn't as good, but at least you have more time to play with.
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
I've told you a hundred million times - I never exaggerate!
;-)
As for the TV game Gasman was talking about, I can't pass the square test...
So if this was turned into a full game would pixel-movement be possible for the main sprite? I guess for the rest of the sprites (ships, etc.) the movement would have to restricted to 4 pixels horizontally ?
I think the hardest work is already done by Joe, the game engine would require "only" to move some objects around. Oh and the bullets must still be shown somehow, which is probably possilbe ? :)
We could make a buffer where you set the bytes how to display on the screen (in colors) and then call a default routine which would make the display in multicolors.
(I think something similar can be (or has been) done for ZX81 games in Hires.)
Most impressive. If some graphician would care of it - would look even better.
My respect, sir.
_____edit_________
Additionally, I noticed it recognize many Spectrum models automatically, which is even more impressive.
http://mister_beep.republika.pl/
http://www.worldofspectrum.org/forums/showthread.php?t=24894
It's not quite the same routine. The one I listed there does 16 characters wide, based on a bit of code from gasman. This demo does only 14 characters but includes border switching.
Not the way it's coloured - those white/yellow stripes on the bi-plane's wings are only 4 pixels in from the wingtips, so you can still get 1x8 attribute clash. It's designed to be positioned in four-pixel steps (at least, horizontally), just like the attribute-based objects.
No, not by a long shot. This was the easy bit.
Clever, isn't it? Especially as it does nothing of the sort! There's just enough flexibility in the timing that it works across all the Speccies that ZXSpin can emulate, but I didn't add any code to adjust the timing.
- IONIAN-GAMES.com -
LD SP,nnnn; PUSH AF; PUSH BC, PUSH DE; LD SP,nnnn; PUSH HL...
- then during the upper/lower border, poke suitable values into the 'nnnn' parameters so that the multicolour effect is positioned where it's needed for that particular line. But then, you might find that the timings which currently work for the centre of the screen don't work for the edges (because you end up on the wrong side of the raster scan), and if so, I'm not sure how you'd get around that. Yup, the hard bit is still to come!
I think if the the playing area is reduced (e.g.: using only two thirds, and leaving a big marker below), this could become a game... But I'm not sure how complex the game could be... probably not too much.
Thanks everyone for the compliments.
The playing area is already down to 14 characters wide - less than half. That's the blue channel up the centre of the screen. The extent of the road is just regular Spectrum graphics and border effects.
I think you're suggesting making it so that it can split the colour effect into two columns to fork the river. It would be nice, but I think it's being ambitious. I was just going to make it step right or left by 6 characters.
If you split it into two, with the time you'd lose with the extra LD SP,nnn , you'd be down to 12 characters total or 6 in each half, which doesn't give you a lot of room to move.
But I wouldn't have to re-write all the addresses all the time, I just need to follow the scroll down and change one at a time. I already worked this out for the side-to-side shift.
- IONIAN-GAMES.com -
I meant vertically, to get some precious time to develop the game control & logic. I already know the horizontal area is limited by the technique. :smile:
What I really need to do is streamline the code so I don't have to keep re-writing values and addresses before each main pass of the colour routine. That will free up the top border time for drawing more sprites.
I think I need to make it alternate between two functions. The first pass it could draw a fixed number of sprites during the top border phase, then do some game logic in the bottom border phase.
In the next pass it would do some more game stuff during the top border, then erase the sprites and update the scrolling data pointers during the bottom border, ready for the next redraw.
The hard part is making game logic that can execute in a constant time (for when we're waiting in the top border), as by its very nature it branches a lot. You have to make every case equal to the worst case so you always know how long it will take. For example, to draw sprites, you always draw the same number of sprites, even if you throw some away by writing them to address 0. Perhaps the collision detection, or polling the keyboard could be adapted.
- IONIAN-GAMES.com -
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
At the bottom I think, definitely at the bottom.
- IONIAN-GAMES.com -
Thermal drift effects over time also needed investigating ;)
In an emulator or with a multiface, or just hack the loader and do:
POKE 32909,1
The demo actually refreshes completely in one frame, but I slowed it down to look more like the original game. That poke controls the number of frames before it scrolls the screen. Typically 2, but it can do 1. Any higher number will slow it down. 0 makes it go mental, in case you're wondering, as it will no longer wait for the interrupts.
- IONIAN-GAMES.com -
Take a look at my avatar - that's an actual Spectrum sprite from the game. In it, the attributes only vary every two lines, with the right side attributes offset from the left by one pixel vertically. It took a hell of a lot of work to design to those requirements, and there are ten different creatures in total. They were designed for an LDI-based colour system that only wrote to every other attribute each line. With the PUSH system they can now have a separate attribute on each 1x8 pixel row, so I can colour and animate him as I originally intended to. I'll be working on this game for the moment.
As for this demo, I've been playing River Raid again recently and it's not that much of an exciting game to be honest. There's not a lot of challenge in that all it seems to do to increase the difficulty is make the refuellers further apart. That and I can't render the colours in a wide enough block to do anything like River Raid.
I'm optimising the colour-scrolling system, but I'm also working on ideas for a vertical-scrolling shooter better suited to a narrow colourful play area. Rather than waste the remaining space on scores or black space I want to put it to use, like the scanner HUD in Scramble or a map, so it's a feature of the game rather than a problem to ignore. But I want to keep the code optimised to make the colour area as large as possible - chopping 1/3 off the height is not something I want to do, nor is resorting to 128K-only effects.
So for the moment, this demo is done. I don't plan to make it do any more as I don't think there's much to be gained from producing a very restricted clone of River Raid. If you're worried there's a lot of code going to waste here, there really isn't. It's just the colour routine I already listed with one of the PUSH statements swapped for an OUT(254) to control the border, and a big table of pre-prepared colour data. It's a long way off an actual game.
- IONIAN-GAMES.com -
Uridium has some multi colour effects at the start, but not ingame. Hell of a neat scroller though!
What this means is, I don't have time to do extras like the border colour swap in the middle of the PUSHes any more, as that then nudges the last PUSH into contested time and would mean I would have to treat the different machines differently. So, I can do Pentagon compatibility, but without the border effects.
As for 'other clones', if they don't synchronise, tough. You really can't have manual tuning without going in and editing the source code by hand. I can test it on the various machines emulated in ZXSpin, and provide a user option to switch between the various pre-programmed synch rates, but if I can't emulate it for testing and it's out of step with any of the more common models, then it's not going to be supported. Someone needs to make some better clones...
- IONIAN-GAMES.com -
Actually it will be enough if all the machines in ZX Spin will work correctly, i think.