As many of you will know, I started working on a conversion of Donkey Kong back in late 2017 / 18 but put it on the back burner. Having learned quite a lot in the interim, I've decided to bring it back to the front hob and heat it up.
I've coded a new sprite engine from scratch to see what can be done. So far so good. I'm looking at giving people the option between duochrome (with minimal clash) and multicolour (with some clash). For those thinking about multicolour, I considered it but the amount of processor time needed for this kind of speed and smoothness mean a multicolour engine just wouldn't be possible here. In general I don't like to sacrifice smooth gameplay for looks. We'll see how it goes.
Anyway, here's a demo video showing both colour modes. It's just a sprite engine test, everything else is just holding graphics to give a better feel.
https://youtu.be/IovZZpeVJ5Q
DKRX new sprite engine
-
bucephalus
- Drutt
- Posts: 29
- Joined: Wed Nov 15, 2017 10:08 am
Re: DKRX new sprite engine
Both are smooth as butter but I prefer the multicolour of the two. The moment the colour change happened at the 31 second mark, it instantly looked more authentic, although the former is also a fine looking game.
There's a nice sense of inertia to the barrels, too. Well done.
There's a nice sense of inertia to the barrels, too. Well done.
-
flatduckrecords
- Manic Miner
- Posts: 796
- Joined: Thu May 07, 2020 11:47 am
- Location: Oban, Scotland
- Contact:
Re: DKRX new sprite engine
Yes, I really like the barrel bounce animation… I can almost hear them thundering down. But yeah both colour options look good to me, the duochrome is nice and clean of course, but I don't think the multicolour clash causes any gameplay issues - the screen still seems 'readable'. Nice work!
Re: DKRX new sprite engine
I don't think there's any real problem with the clash in the lots-of-colours mode. Although we haven't seen the player sprite yet.
Is it possible to do the player in white, though still maybe picking up the red and cyan scenery attributes, but maybe giving his white ink priority over the yellow of the barrels? Or are you forced to have the player the same colour as the barrel sprites?
Is it possible to do the player in white, though still maybe picking up the red and cyan scenery attributes, but maybe giving his white ink priority over the yellow of the barrels? Or are you forced to have the player the same colour as the barrel sprites?
Re: DKRX new sprite engine
Multicolour all the way for me as it's incredibly close to the original. I love the little bounce that the barrels have when they land, great work and I can't wait to play the final version.
Re: DKRX new sprite engine
At this point, the whole thing is done in 1-bit with no colour updating. This effectively means that it's a kind of colour overlay, and the player sprite will just inherit whatever it passes over. Although this is not ideal (and hence the option for the duochrome), it does mean the game will be fast and smooth with fully masked sprites, which help a lot with the fixed colours. However, once I have more of the game running and if there is enough memory left there may be the potential for the player to be coloured white in the empty areas, so to speak. But clashing with the red girders would be horrendous.
Re: DKRX new sprite engine
Well I can already see a few places down the slopes where it should be possible to change the attribute over to yellow without affecting the girders.
I think it's a shame when games have colourful backgrounds but all the sprites are the same colour. It should only take a short bit of logic to insert white attributes where they're already yellow, and restore them afterwards. I do like how smooth it runs though - that's impressive.
I was trying to think of a way of arranging things so you could do the colour of the player logically with a bit-wise AND operation, but that would only work if white was the default and you were setting the attributes of each of the barrel sprites to yellow. (Plus the cyan ladders would then turn green or something).
I think it's a shame when games have colourful backgrounds but all the sprites are the same colour. It should only take a short bit of logic to insert white attributes where they're already yellow, and restore them afterwards. I do like how smooth it runs though - that's impressive.
I was trying to think of a way of arranging things so you could do the colour of the player logically with a bit-wise AND operation, but that would only work if white was the default and you were setting the attributes of each of the barrel sprites to yellow. (Plus the cyan ladders would then turn green or something).
Re: DKRX new sprite engine
I think the key is to accept colour clash and minimize the effect through a good choice of colours.
» White/yellow, red/magenta or black/blue have low contrast between them, so clashing between these is not problematic.
» Yellow/cyan don't contrast, but they are warm/cold colours that can generate a feeling of separation.
» White/cyan also works, but anything beyond that contrasts too much.
If you build your background and sprites with this in mind, colour clash won't be distracting and can be ignored
For example, the yellow girders work much better. White should also work, and you can also play with bright / non-bright attributes (perhaps between girders and stairs, with both being the same colour).
Re: DKRX new sprite engine
I've got a suggestion, which may sound horrendous at first, but if it could be made to work would improve things quite a bit - double the vertical resolution of the attributes. Not 8x2, but 8x4. It won't eliminate clash, and it's not enough to do multicolour characters, but it will reduce it considerably. And if you make the barrels 'hover' one (or cheekily, two) pixels above the girders, even better.
Your main game loop code has to sit in the middle 16K so you can page the alternate screen in at the top of RAM. What you do is copy the screen pixels to both screen RAMs of a 128K Speccy. But you can set the top half of the attributes on one screen, and the bottom half on the other.
Then you write a routine that displays one screen, waits four pixel rows, swaps display screens, then four rows later, swaps them back again. You now have double-res attributes.
The art of using it is to then write code that can run in the timing gaps. It doesn't have to be absolutely perfect, as the screen swap only needs to happen during border time, which leaves a fair bit of flexibility. And for your own sanity it should be a simple and repetitive task. The complication is, when you're drawing sprites, you have to remember to swap from one screen to the other every four pixel rows (which gets highly complicated it you're doing pixel-precise placement). But at least you have the advantage that you always have a 'blank' copy of the background available on those unseen alternate lines, to copy from when erasing sprites. What I'd suggest in this case is you write a sprite erase function that runs in the gaps between timed screen swaps. If it takes two whole character rows to erase a sprite (and do 4 swaps in the meantime) then that's enough to erase all your sprites ready for redraw.
Then you work out how many sprites you can draw during top border time. And maybe you don't have any screen swaps at all during the first 5 character rows, where it's not needed, giving you time to draw more sprites. And you can always start drawing sprites in the lower border time of the previous frame. You also assign your sprites into a rotating buffer, so they're always going to be in vertical height order. So you've drawn all your sprites during the time the top of the screen is displayed. Then as you work down the screen, timing the screen swaps, you erase those sprites in top-to-bottom order as they're no longer needed. By the time the display reaches the bottom of the screen they're all gone, ready to re-draw them in their new positions on the next frame. (Well, maybe the last few on the bottom row still need erasing).
Your main game loop code has to sit in the middle 16K so you can page the alternate screen in at the top of RAM. What you do is copy the screen pixels to both screen RAMs of a 128K Speccy. But you can set the top half of the attributes on one screen, and the bottom half on the other.
Then you write a routine that displays one screen, waits four pixel rows, swaps display screens, then four rows later, swaps them back again. You now have double-res attributes.
The art of using it is to then write code that can run in the timing gaps. It doesn't have to be absolutely perfect, as the screen swap only needs to happen during border time, which leaves a fair bit of flexibility. And for your own sanity it should be a simple and repetitive task. The complication is, when you're drawing sprites, you have to remember to swap from one screen to the other every four pixel rows (which gets highly complicated it you're doing pixel-precise placement). But at least you have the advantage that you always have a 'blank' copy of the background available on those unseen alternate lines, to copy from when erasing sprites. What I'd suggest in this case is you write a sprite erase function that runs in the gaps between timed screen swaps. If it takes two whole character rows to erase a sprite (and do 4 swaps in the meantime) then that's enough to erase all your sprites ready for redraw.
Then you work out how many sprites you can draw during top border time. And maybe you don't have any screen swaps at all during the first 5 character rows, where it's not needed, giving you time to draw more sprites. And you can always start drawing sprites in the lower border time of the previous frame. You also assign your sprites into a rotating buffer, so they're always going to be in vertical height order. So you've drawn all your sprites during the time the top of the screen is displayed. Then as you work down the screen, timing the screen swaps, you erase those sprites in top-to-bottom order as they're no longer needed. By the time the display reaches the bottom of the screen they're all gone, ready to re-draw them in their new positions on the next frame. (Well, maybe the last few on the bottom row still need erasing).
Re: DKRX new sprite engine
Forgot to say, the trick to drawing sprites at the same speed every time, when they cross multiple characters and (in this case) flip between screens every four rows, is to have the address of the pixel rows of the screen(s) in a list, point the stack at the right place in the list for your sprite Y-position, put the X-position in BC and your sprite data pointed to by DE. Then for each row you can do:
POP HL
ADD Hl,BC
to get the screen address, then mask and copy 3 bytes of sprite data from DE to HL. And remember you only need to INC L not INC HL to move across a byte. And the same with INC E instead of INC DE if you know your sprite data doesn't cross a 256-byte boundary in memory. If you want to copy the other way, from HL to DE like an LDI statement, then you need to do:
EX DE,HL
POP HL
ADD HL,BC
EX DE,HL
POP HL
ADD Hl,BC
to get the screen address, then mask and copy 3 bytes of sprite data from DE to HL. And remember you only need to INC L not INC HL to move across a byte. And the same with INC E instead of INC DE if you know your sprite data doesn't cross a 256-byte boundary in memory. If you want to copy the other way, from HL to DE like an LDI statement, then you need to do:
EX DE,HL
POP HL
ADD HL,BC
EX DE,HL
Re: DKRX new sprite engine
I'm not really sure what you mean by duochrome and multicolour.
You should know that "multicolour" has a very scrict and reserved meaning in Zx Spectrum world. It doesn't mean that something
is very colourful but it means that you are using tricks to display more than 2 colours in the area of one character - 8x8 pixels.
Does your engine do something like that? It seems to me that it uses attributes in a standard way.
You should know that "multicolour" has a very scrict and reserved meaning in Zx Spectrum world. It doesn't mean that something
is very colourful but it means that you are using tricks to display more than 2 colours in the area of one character - 8x8 pixels.
Does your engine do something like that? It seems to me that it uses attributes in a standard way.
Re: DKRX new sprite engine
I assumed by 'duochrome' he meant one up from 'monochrome', i.e. only using two colours on a black background.
But I took the way he wrote 'multicolour' twice as having two different meanings. The second part of the demo doesn't rewrite any attributes as it goes. The barrels are simply yellow because that's the colour empty character cells are set to.
But then he referred to the timing overheads of a 'multicolour engine' so I assumed he did know what that meant!
Now someone has already used 'bi-colour' to refer to 8x2 multicolour (which I would have named quad-colour myself), so what would you call 8x4 multicolour, or double attributes? I wouldn't want to shorten "two-times-attributes" to "tw*tributes" for example.
Is it 'half' (demi) sized attribute squares or double (di) the number of attributes? "Demittributes" or "Dittributes"? "Di-colour"? Are rectangular attributes "retributes"?
But I took the way he wrote 'multicolour' twice as having two different meanings. The second part of the demo doesn't rewrite any attributes as it goes. The barrels are simply yellow because that's the colour empty character cells are set to.
But then he referred to the timing overheads of a 'multicolour engine' so I assumed he did know what that meant!
Now someone has already used 'bi-colour' to refer to 8x2 multicolour (which I would have named quad-colour myself), so what would you call 8x4 multicolour, or double attributes? I wouldn't want to shorten "two-times-attributes" to "tw*tributes" for example.
Is it 'half' (demi) sized attribute squares or double (di) the number of attributes? "Demittributes" or "Dittributes"? "Di-colour"? Are rectangular attributes "retributes"? Re: DKRX new sprite engine
Or, and this one really is a brainf*ck, you optimise a multicolour engine around the scenery.
On any one row of the screen you know where the red girder attributes need to start. So you copy up all yellow attributes to the whole character row in advance (or cyan where there are ladders), then when the display gets to that row you copy up red attributes for the four bytes or so where a sloping girder has just appeared. On the next row, you copy up four more red attributes four bytes over, etc. So your girders appear in red. Then copy up yellow or cyan attributes on the rows below. So at most, you're copying up 8 bytes of attribute per pixel row.
And after two character rows containing a sloping multicolour girder, you get two character rows with no effects needed, so you can use that time to erase the 2-3 sprites on the row above, that the raster has just passed, or maybe draw sprites on the next row, depending how quick you can do so. The advantage of having a string of erase functions on hand is, if they're just restoring the screen from a backup copy of the whole screen, then it doesn't matter if you don't need to use all the repetitions, or if some are left over from the previous frame and haven't been re-assigned. They'll just re-restore that bit of the screen and no-one will notice.
Now if you really want to show off, you could arrange to copy another two bytes of attributes per pixel row (or every second pixel row) that you're able to manipulate to move left/right across the screen, and use those to render your hero sprite in his own little personal moving multicolour window! Easy!
On any one row of the screen you know where the red girder attributes need to start. So you copy up all yellow attributes to the whole character row in advance (or cyan where there are ladders), then when the display gets to that row you copy up red attributes for the four bytes or so where a sloping girder has just appeared. On the next row, you copy up four more red attributes four bytes over, etc. So your girders appear in red. Then copy up yellow or cyan attributes on the rows below. So at most, you're copying up 8 bytes of attribute per pixel row.
And after two character rows containing a sloping multicolour girder, you get two character rows with no effects needed, so you can use that time to erase the 2-3 sprites on the row above, that the raster has just passed, or maybe draw sprites on the next row, depending how quick you can do so. The advantage of having a string of erase functions on hand is, if they're just restoring the screen from a backup copy of the whole screen, then it doesn't matter if you don't need to use all the repetitions, or if some are left over from the previous frame and haven't been re-assigned. They'll just re-restore that bit of the screen and no-one will notice.
Now if you really want to show off, you could arrange to copy another two bytes of attributes per pixel row (or every second pixel row) that you're able to manipulate to move left/right across the screen, and use those to render your hero sprite in his own little personal moving multicolour window! Easy!
Re: DKRX new sprite engine
Or, you know, just carry one as you were! But I do prefer the red/yellow one, even if the clash is more obvious. The first half of the video with only pale colours just doesn't look like Donkey Kong.
Do other colour combinations work? If the player did have their own colour (white? yellow?) following them around, at least where it didn't over-write the girders, could you get away with magenta barrels next to red girders? Or is that not distinct enough?
Do other colour combinations work? If the player did have their own colour (white? yellow?) following them around, at least where it didn't over-write the girders, could you get away with magenta barrels next to red girders? Or is that not distinct enough?
-
StanVanman
- Manic Miner
- Posts: 268
- Joined: Wed Dec 15, 2021 9:15 pm
Re: DKRX new sprite engine
Looks terrific, especially in multicolour mode. I like the solution to the screen-height issue.
Re: DKRX new sprite engine
regarding the use of the word multicolour and whether it has a specific or general meaning, I'm pretty sure that you guys can understand the meaning from the context.
In short - I'm not using any kind of raster beam tricks to slice attributes. In fact, I'm already using raster timing for drawing the sprites. I don't claim to be a Z80 master, but I'm pretty sure that combining 16 fully masked, smooth, flicker free sprites with any kind of multicolour engine that will run on a stock 48k machine is not possible. Not to mention full game logic including fairly complex movement code and collision detection on all those sprites
But I'd be delighted to be proven wrong, feel free to give it a go!
In short - I'm not using any kind of raster beam tricks to slice attributes. In fact, I'm already using raster timing for drawing the sprites. I don't claim to be a Z80 master, but I'm pretty sure that combining 16 fully masked, smooth, flicker free sprites with any kind of multicolour engine that will run on a stock 48k machine is not possible. Not to mention full game logic including fairly complex movement code and collision detection on all those sprites
But I'd be delighted to be proven wrong, feel free to give it a go!
Re: DKRX new sprite engine
Please don't treat my comment about multicolour as some attack. I just wanted to explain things a little bit.
As I said multicolour usually means quickly changing atrributes when Spectrum refreshes the screen so more than two colours in one character are are possible. Like for example here: https://www.spectrumcomputing.co.uk/ent ... ietro_Bros
Your engine doesn't do such stuff. But it is great anyway. As you say it's fast, smooth, flicker free and enables a lot of masked sprites. Is it 50 fps or 25 fps?
Please don't stop here and finish the game!
(and I like yellow+white colour combination more, no matter how you call it )
As I said multicolour usually means quickly changing atrributes when Spectrum refreshes the screen so more than two colours in one character are are possible. Like for example here: https://www.spectrumcomputing.co.uk/ent ... ietro_Bros
Your engine doesn't do such stuff. But it is great anyway. As you say it's fast, smooth, flicker free and enables a lot of masked sprites. Is it 50 fps or 25 fps?
Please don't stop here and finish the game!
(and I like yellow+white colour combination more, no matter how you call it
)-
vintage-mike
- Dizzy
- Posts: 64
- Joined: Wed Jul 28, 2021 9:35 am
- Location: Oxford, England
- Contact:
Re: DKRX new sprite engine
I wouldn't worry about colour clash, its part of what makes the Spectrum what it is. Ultimate didn't seem to worry about it (for the sprites at least) and I don't think it did their games any harm. All these 8-bit machines had their pros and cons. The C64 had sprites and the best sound, but a slightly dodgy colour palette and pixels the size of house bricks. The Spectrum had 'high' resolution, a faster processor, but less than impressive sound and some colour clash. Its what makes these 8-bit machines so identifiable, and programming games for them interesting.
Re: DKRX new sprite engine
guys, don't worry, I don't take comments as any kind of attack or criticism, I just answer with a certain amount of brevity. I'm always happy that people are interested. I have a facebook group at https://www.facebook.com/groups/242260226489779 where people can give daily feedback. I also have a patreon page where people can support the development. In exchange they get my full back catalogue of games and mods as well as beta demos of the game in progress. That's www.patreon.com/happycodingzx
Anyway, to answer the question, it's running at 25mhz. I did manage to get all of the drawing routines into once cycle, but then there was no room for anything else
Also, I did look at multicolour, and even did a mockup of a level. But as a I said, the gain in colour would be a huge loss in smoothness and how much is going on. As can be seen in this updated video, I can have 16 barrels at once now, and there should be enough left over for game logic and so forth.
https://www.youtube.com/watch?v=MNmK-c61abY
Anyway, we'll see how it goes.
Anyway, to answer the question, it's running at 25mhz. I did manage to get all of the drawing routines into once cycle, but then there was no room for anything else
Also, I did look at multicolour, and even did a mockup of a level. But as a I said, the gain in colour would be a huge loss in smoothness and how much is going on. As can be seen in this updated video, I can have 16 barrels at once now, and there should be enough left over for game logic and so forth.
https://www.youtube.com/watch?v=MNmK-c61abY
Anyway, we'll see how it goes.
Re: DKRX new sprite engine
The C64 actually had a higher resolution screen than the Spectrumvintage-mike wrote: ↑Thu Jan 27, 2022 12:17 pm The C64 had sprites and the best sound, but a slightly dodgy colour palette and pixels the size of house bricks. The Spectrum had 'high' resolution, a faster processor, but less than impressive sound and some colour clash.
-
vintage-mike
- Dizzy
- Posts: 64
- Joined: Wed Jul 28, 2021 9:35 am
- Location: Oxford, England
- Contact:
Re: DKRX new sprite engine
Granted - it couldThe C64 actually had a higher resolution screen than the Spectrum
- I was thinking more of 'multicolor mode'- I'll own up to not being a C64 expert. Being a Spectrum owner I was always jealous of the hardware sprites, and the sound, but then again, the spectrum's simplicity did have its own unique appeal - just some memory and a CPU really, and when you wrote to a particular part of the memory, things appeared on the screen. So, as a programmer it felt like you could entirely choose how you made the most of its hardware limitations for any given task.Re: DKRX new sprite engine
let's remember what this thread is about chaps, feel free to start your own thread for your playground war, thanks.
-
vintage-mike
- Dizzy
- Posts: 64
- Joined: Wed Jul 28, 2021 9:35 am
- Location: Oxford, England
- Contact:
Re: DKRX new sprite engine
Ouchlet's remember what this thread is about chaps, feel free to start your own thread for your playground war, thanks.
All I was saying was I wouldn't worry about colour clash, embrace it as part of what makes the Spectrum what it is. All 8-bit machines had limitations, its part of the appeal (to me anyway). An unwise comparison, I'll keep my opinions to myself in future...Re: DKRX new sprite engine
in general I think it's always good to nip these things in the bud, but to add my own view...
Working on something like this, I can see from what different people have said that there are wildly differing views about colour clash. I guess this too would be better in its own thread, but there are those who think it's part of the charm of the machine, and I can respect that. The truth is, for me anyway, the game would definitely look better if everything could be its own colour. If there was a way to do that without compromising playability, I would. So although I will never embrace colour clash, I will accept it in certain situations. With no hardware sprites or scrolling, colour clash and a beeper that interrupts the CPU, the 48k Spectrum is a cheap little underdog machine that really has no right to run decent games at all really. The fact that it even gets mentioned in the same breath as a machine like the C64 is a testament to what people have managed to do with it. That's why I love coding on it
Working on something like this, I can see from what different people have said that there are wildly differing views about colour clash. I guess this too would be better in its own thread, but there are those who think it's part of the charm of the machine, and I can respect that. The truth is, for me anyway, the game would definitely look better if everything could be its own colour. If there was a way to do that without compromising playability, I would. So although I will never embrace colour clash, I will accept it in certain situations. With no hardware sprites or scrolling, colour clash and a beeper that interrupts the CPU, the 48k Spectrum is a cheap little underdog machine that really has no right to run decent games at all really. The fact that it even gets mentioned in the same breath as a machine like the C64 is a testament to what people have managed to do with it. That's why I love coding on it
Re: DKRX new sprite engine
This is the most recent layout, still things to work on.
