Donkey Kong Remake
CardboardGuru
Posts: 443
I got a Hydra earlier this week and I've decided to do a remake of Donkey Kong.
I'm keeping a log of my progress over on the XGameStation Hydra Forum.
http://205.158.110.70/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=17&t=000122
Very early days, so all the project does for now is draw the first level background tiles. An animation, no interaction.
I'm keeping a log of my progress over on the XGameStation Hydra Forum.
http://205.158.110.70/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=17&t=000122
Very early days, so all the project does for now is draw the first level background tiles. An animation, no interaction.
zip
16K
440 x 275 - 31K
Comments
Andre'
Hope you will post your game here later
Cheers,
Hallomann
Yes, so long as I manage to finish the game, it'll be posted here. I'm intending to post a zip every time I feel it's got to some kind of milestone on the way. And I'll keep on posting a log of what I'm doing, what's going wrong and what's going right, and a bunch of questions over on the XGameStation forum.
205.158.110.70/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=17&t=000122
(If I'd known that forum doesn't accept attachments and this one does, I'd have logged the whole thing here. But since I started there, I'll finish there. - Andre', please switch attachment on on your site!)
OK, this is the next milestone. No picture this time because it looks exactly the same as the last time (apart from a changed palette.) Still no animation or interaction. The difference is that this has a graphics engine that is shared over multiple cogs, which will help when it comes to adding sprites.
If you want to know how to implement multiple cogs for rendering, diff this version with the last.
Post Edited (CardboardGuru) : 4/24/2007 8:56:29 PM GMT
I am very interested in your accomplishments, and in such a short time. Mere mortals need that much time just to read Andre's Hydra book
This new video engine of yours, will it be like Andre's HEL engine, a "blitter based" system that draws on to the "canvas" of the main video generator (with the four colors per tile limitation), or will it be able to use a separate palette of colors to the background tiles. Although most of the animated objects appear on top of a black background, that is not always the case, and the original sprites seem to use more colors than what seems to be possible with the HEL engine.
I am curious how you will solve this problem, one main cog must be the definitive video generator because it controls the phase shift generator needed for the color-burst generator logic.
I will surely keep following this thread! I wish you much success.
By the way, there are people working on sound sub-systems too, so there should no be any problems with adding the original sound too
Mahjongg
It's interesting that you should ask that, because that's the very issue that I'm battling with now. My requirement is for 4 colours per tile and 4 colours per sprite, completely independent of each other. Now as you say, there is a problem there in the standard usage, as used by HEL.
WAITVID [noparse][[/noparse]Long containing palette of 4 colours], [noparse][[/noparse]Long containing 16x4 colour pixels from the palette]
This means that any block of 16 pixels horizontally can only use 4 colours. However, in gfx engine used in Dr Hydra, Remi manages to use a byte per pixel with each pixel independant of the others. Somehow he set it up to do this:
WAITVID [noparse][[/noparse]Long containing palette of 4 colours], [noparse][[/noparse]Long containing 4x4 colour pixels from the palette. Held in the low byte, 2 bits per pixel]
He then always passes in #%%3210 as the second parameter. Which means that the 4 pixels you get are the 4 colours that you gave as the 4 colour palette. 4 pixels, 4 arbitrary colours in the palette. Given that, generating any screen mode is possible. It's all a matter of getting just the right timing parameters (to VSCL), and being sure that the software is faster than the WAITVID requests.
I've been trying to convert my tiles from 4 colours to the 256 colour palette on the fly in my renderer, but things aren't working (yet). I may have to admit defeat and store my tiles and sprites as 256 colour instead, and suffer all the wasted memory that means.
If I do end up using 256 colour mode, I might as well have just used Remi's engine in the first place. (Though I wouldn't have learned as much.)
(I say 256 colours, but I mean 8 bits per pixel, still only the 86ish NTSC colours really available.)
What we actually need is some system that can combine four color tiles with 256 (or at least 16) color sprites.
In theory that should be possible, either by intermixing WAITVID's for 4 color pixels with WAITVID's for 256 color Pixels, or by only using 256 color WAITVID's, and translating four colors per pixel to 256 colors on the fly.
The HEL driver is very nice, and the implementation of the sprite's with the pre-rendering of one single display line is (one of) the right way(s) to do it, but the restriction to the same three colors of the underlaying tile, (plus "transparent") is too great a restriction for many uses. Actually I don't understand why the sprite pixels cannot use a completely independant set of colors, perhaps you can reserve a single 32bit COG-RAM word per sprite for each sprites own pallette.
I have been thinking of another way to do this, by running a second overlaying video driver on a second COG, that would "overrule" the output from the primary video driver, by outputting it's own WAITVID data just after the primary drivers WAITVID data (and thus ""replacing" it), but you need to synchronise both video drivers extremly well, and the second driver cannot modify the color burst phase of the first driver, so I do not see a way to make this work with PAL/NTSC, except for the "colors" black and white, which can temporarily (for one pixel) disable the color burst.
I must admit I still don't understand how the WAITVID command and the colorburst phase control interact together. I asume there is either some hardware trickery going on that causes the output of the phase controlled frequency generator to directly modulate the output of the video level generator (by intermidiately adding or substracting one level (value) to the current WAITVID video level output), or the software reads out the phase modulated counter and adds the result of it to the value sent to the WAITVID data.
Mahjongg
Andre'
Andre'
I tried to run your program on my demo board and 7.5" TFT LCD display but the output is not right. What i can see is your bitmap on Black and white. What should I do to make the image right.
Thanks.
Yes that's pretty much what I thought you meant.
Azmax100,
I'm not at all surprised. I was having trouble myself getting anything to display at all, so it wouldn't surprise me at all if it was malformed NTSC. And from what I understand CRT TVs like mine are far more forgiving than LCDs.
I take it you have tried other programmes and they have displayed correctly? And that you have a proper NTSC device? I'm in the UK and I have two TVs, one is multistandard and works fine. The other is PAL. It displays NTSC in black and white.
Could you try the upload I've just made in a new thread entitles SimpleNTSC. As far as I'm aware that is properly formed NTSC. (I hope.)
The first big thing was that I converted SimpleNTSC into a TV driver that outputs to the screen based on a single scanline buffer. This means that at the moment there are no dependancies on other people's objects. It's all my own code. (Well apart from a couple of small subroutines for multiply and such that were acquired from other objects.)
The second biggy is that my scanline renderer object converts on the fly from 4 color mode tiles to 256 color mode display. As I mentioned before it's a cooperative renderer, and you can add more cogs to give it enough horsepower for the job in hand. In order to just render the tiles it needs 3 cogs, plus the one cog for the TV driver.
At last I have all the groundwork in place to implement my 4 color sprites with a different palette from the tiles behind. That's tomorrow's job.
Keep up the excellent work. it'll be nice to have a sprite based tv system with more than four colours that's free for use and distribution on the forums.. nice 1
Baggers.
What's that in the lower corner of the screen shot? It's Mario!
Well it's been 3 days before I posted an update on the project. But I wanted to have something that actually moved! So, here's what's progressed:
1) Sprites partially implemented. You can use the gamepad to move Mario. As you can see he's masked against the background. And he has a different 4 color palette that is independent of the background. Tiles and sprites are stored as 4 color but are converted on the fly to hi-color.
Still to be implemented is smooth horizontal movement. It's 4 pixel granularity at the moment. Also vertical and horizontal flips of the sprites. These are all needed.
2) Improved efficiency of the scanline renderer. At the last update it took 3 cogs just to render the tilemap. Now it takes 2 even though it has the extra work of the sprite.
3) Put in a rudimentary debugging facility. If you press START, it'll toggle into a debug mode and output some vital numbers. This is done just by changing to a different tilemap, and putting tiles for numbers in there. Note the sprite still works (partially, see below). And if you move the sprite past the numbers, you get funny numbers! This is because the number output is redone every scanline, so if the value changes halfway through drawing the number, you get a bit of both numbers.
4) Put code in to degrade performance of the renderer gracefully if they have too much work. This was something I saw with Remz engine. If the renderers can't keep up they light the LED and do less, like not draw some/all the sprites for example. Mine degrades really nicely, to do something even if there is not enough resource to draw the tilemap (though by that stage you are pretty screwed anyway!) It'll probably never happen in actual gameplay, but it was fun to add the feature. You can test this by changing the COGS constant in the main program. If you reduce to 1 cog, then the sprite will disappear and the tilemap will degrade. If you up it to 3 cogs, then the sprite displays fully.
Best not to look at the code, and certainly DO NOT branch any programs off this version. It's a mess of half implemented functionality and debugging mess. It needs a big tidy up.
One point is that I have wondered why with 512ish registers in each cog, people were still labelling them r0,r1,r2 etc in their code. Well now I know why. I keep running out of space on my rendering cog, partly because I have so many named registers. I need to reuse more.
Well, Andre' challenged me to get it to do something by 1st of May, and for me that means getting something to move on screen. And it does. Hurray! What I didn't know at the time is that this was for potentially putting it on the CD. Way too early for that.
So next jobs are a big tidy up of the code, followed by implementing the missing sprite functionality. Then I guess a bit of fun getting Mario to walk on platforms and climb ladders.
Time for another update. It's taken 3 days to implement the functionality I mentioned last time.
1) I did a partial tidy up of the code. Got rid of all the dead crud at least.
2) I implemented pixel granularity scrolling for sprites. I recall from the old 8-bit days that it was always a bit of a head-scratcher when you're trying to shift little endian bytes and big endian bits. You end up with all sorts of messes on screen. But you spot your errors one by one and then eventually you hit on just the right combination and a lovely sprite appears on screen. And so it was here.
3) Expected mirrored sprites to be a headache as well. But they worked first time. I'd had to split out single pixels in the algorithm anyway to do palette lookups, so reassembling them in the reverse order was a piece of cake.
4) Finally I implemented proper movement for Mario. He runs, he runs up inclines, he jumps, he climbs ladders. The only things he doesn't do as yet is die when falling off platforms and use the hammer (because there isn't one). Programming mario's recognition of exactly where the platforms and ladders are was surprisingly difficult. The inclined girders on a rectangular map mean that the girders and ladder parts although looking the same are put together from a bunch of permutations of tiles. And where the ground level is varies depending on which tiles are used. I aborted my first effort which just had tests for which tiles lay in the direction that mario wants to go. It became a complete mess of special cases. I realised that what I needed was 4 numbers. The Y coordinate of mario. The Y coordinate of the ground where Mario is (might be different if he's jumping). The Y of the top of any ladder Mario is standing in front of. And the Y coordinate of the bottom of any ladder Mario is standing above. Calculating each of these individually in their own functions wasn't too hard. And the tests for permitted movements at any instant in time follow on easily from them.
This was my first proper programming in SPIN, and it's good in some ways, and appaling in others. The worst of it is that they've taken the comparion operators <= and >= that people have been used to in other languages and changed them into assignment operators. Grrrr. Twice I've shot myself in the foot with a bug with that one, and each time questioned SPINs ability to do simple maths! I know that those comparisons are available as =< and =>, but you can't teach an old dog new tricks!
I know some people hate the indentation based blocks in spin, but I quite like it. Or rather I've always hated begin and end delimiters in other languages. And I've done a fair amount of Python programming so I'm used to it. But here's a big tip to make it easier. Get the latest version of the Propellor tool, and go to preferences, and change the tabs to 4 spaces rather than 2. It makes it so much clearer where the blocks are.
Well, I want to be reporting back a bit more often than I have, so I'll not set myself such a bit task this time. I was going to implement the barrels next, but the barrels are set off by Kong, so I ought to do him first. And that means that I need to add a little more to my rendering engine. At the moment it only supports one sprite.
Latest version of software attached. No picture this time, as a still would look the same as last time!
Post Edited (CardboardGuru) : 5/3/2007 11:33:30 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Andre'
Thanks all for the encouragement on this guys. It's really giving me the drive to get on with it.
Well things have really begun to progress rather fast now that all the engine foundations are in place. Here's what got added since yesterday.
1) Support in the renderer for multiple sprites. I'm using 24 sprites so far. Up to about 10 on a scanline. Which needs 5 cogs to render correctly.
2) Kong! Fully animated. He looks like a big sprite, but really all the sprites are 16x16 and he's made of up to 8 of them tiled together.
3) Barrels. These were quite easy to do because they share the girder following code of Mario. The falls and bounces are table lookups of deltas rather than calculations. You'll notice that the barrels disappear about 3/4 of the way down the screen. This is because there are 10 barrels being endlessly recycled. Because I haven't done the code to send them down ladders yet, they are all taking the long way down the screen and taking longer than they should do. 10 barrels should be enough.
The code done today really illustrates the point in the Hydra book about games being state machines within state machines. It's all been state machine code. I added a game state, which will hold what level we're on, whether we're in attract mode etc. There's a Kong state whioch cycles through the diffenrent poses he has, and sets off the barrels. And then the barrels have a state which holds whether they are rolling or falling or bouncing, and which direction they are going. By doing these all as state machines with case statements, getting the behaviours right has been a doddle.
The game logic is all programmed in Spin. Right now it's running at full speed with no pauses or vsync wait. And it's about half as fast as it needs to be. But I've written the code with no consideration for speed for now, so there are bound to be a lot of optimisations I can do. If not, I'll have to do something drastic. I'm already up to 7 cogs, and I was planning on the 8th one doing the sound. And I can't get the rendering cogs to do any more because the cog memory is full.
Don't think I'll be wanting an SRAM for this project though. All of the tiles and sprites are in there, one of the maps, and most of the code (I hope), and the binary is still only about 16K. And I don't need space for a frame buffer. And I'm definately going to stick to the authentic 4 colours per object.
Next thing is to get the barrels to come down ladders. Looking at the original game it's hard to tell how the the logic works for the decision to go down a ladder or continue rolling. It might be probablistic, or it might be a series of fixed paths. I'll see which I fancy doing tomorrow.
BTW, there's something very strange about the MAME rom I have for Donkey Kong. It cycles around just 2 screens rather than 4. Level 1 then Level 4. I've gone hunting for other versions of the rom and they all seem to be 2 level versions. I've got a Crazy Kong rom that has all 4 levels, but that's a bootleg version that appears to use the original graphics but only approximates the logic and placement and movement of sprites. (Sounds familiar!)
So does anyone have a copy of a 4 level donkey kong rom file they could let me have?
Post Edited (CardboardGuru) : 5/5/2007 12:49:12 AM GMT
Second, I would make Donkey Kong a tile BG object because it would free up some sprites.
Third, why is the game only in 4 colors?
Forth, you probably have the 4 level version of Donkey Kong, but I think it goes, 1st level, 2nd level, then goes back to 1st level, 2nd level, 3rd level, then goes to 1st level, 2nd level, 3rd level, 4th level. I think mame has cheat files that can be downloaded, so see if you can find it·and it should have like unlimited lives or something that can be patched into it.
Thanks. You're absolutely right about the ROM! I guess I just gave away the fact that I'm not very good at the game these days.
But with the clue that all the levels are there I attacked the game using MAMEs save position feature, and now I've seen all 4 screen types. I've also noticed that the "L=01" indicator doesn't do what I thought it does. I thought it incremented for each level completed. But now I see it increments each time you're back on the first screen type. It corresponds to difficulty level.
Also the screen order is slightly more quirky than even you recall. If A=barrels, B=conveyor belts, C=bouncing springs, D=rivets, then it goes AD,ACD,ABD,ABCD.
I guess my childhood memories were based around the Crazy Kong bootleg that was common in arcades where I live and Killa Gorrilla which was the clone for the BBC Micro. Also, there was a tactic that we used to use in the arcades, where you climbed a ladder just to the point where Mario was climbing on to the platform, and stayed there. And no barrel would then come down that ladder and you were safe (exept from fireballs). I now see that that tactic only works on Crazy Kong and not Donkey Kong.
I guess the quirky order made sense when arcade games were a new novelty and they wanted to encourage people to keep on putting coins in to try to reach a screen type they'd never reached before. It put the C and the D screen types far enough away from the start to be an achievement to reach. I'm not so sure anyone's going to be that persistent nowadays. So I think I'll go for a simple rotation.
The reason Kong is a collection of sprites is simply because I know it was in the original. He does need to be sprites some of the time because of the introductory screens where he climbs ladders and jumps up and down on the platforms. And now I've been through all the screen types in MAME I see that he needs to be sprites for the conveyor screen where he scrolls from side to side on the top conveyor.
The game as it is now is actually in 7 colours. A set of 4 for all the tiles and a set of 4 for all the sprites, with black in common. But at some point I'll add in proper palettes so each tile and each sprite can have a different palette of 4. And then Kong won't look like the abominable snowman any more.
Post Edited (CardboardGuru) : 5/5/2007 11:29:04 AM GMT
But, very cool, the motion feels pretty good, of course its in slow motion as you said. So that needs to be sped up, but once you do, I think it will be very cool. Also, as noted kong should be tiles, not sprites.
The graphics are dead on (but of course they should be since you got them from the roms), but very impressive.
Andre'
Remember I mentioned about the debugging feature. Press START and it shows a load of debugging information. Well it occurred to me today that this was probably eating up a reasonable chunk of time. So I added in another debug print of the average time taken per game loop. It came out at around 2,430,000 clocks, where the clock is at 80MHz. So that's about 30ms. Or 33 Frames Per Second. Which is about right for the perception that it was half speed. The original going at 60FPS.
Then I took out all the debug prints besides the one that gave me the average time. Result was 440,000 clocks. 5.5ms. 181FPS. 3 times faster than I actually need.
Yes, the debug output was taking up 4.5 times as long as he game itself. Thinking about it, each one is a function call, a loop to print the text, another loop to print the digits, and the real clincher - 10 divides by 10.
So given that I still haven't looked at optimising the game code yet, I don't think I need worry about the speed!
Also alot of the early arcade games were mad hard. I remember playing Donkey Kong as a kid and not liking it so much because it was so hard I couldn't even beat the first level. Yet the home versions were a lot easier. It is funny because I have played more Donkey Kong in places like bars or arcades or what not a lot more then when I was kid. I did like Dig Dug tho since it seemed a little easier.
·
I thought it might be of interest to describe what I did to investigate it in the end.
1) In Mame. If at the start of the level you head left instead of right, you can pass by the oil drum unscathed. And you're safe there for a long time bacause the barrels don't go there. Just the fire balls.
2) From here I recorded a movie using Shift F12.
3) After 3 tries I got a nice long movie.
4) I took a snapshot of the screen, changed black to white, and printed it out.
5) I then played back the movie over and over in animation shop, and for each barrel, I watched for where it went down a ladder and jotted the number down next to the ladder on the screen print.
6) After following 17 barrels his way, it became clear that apart from the ones that got all the way to the bottom of the screen without using ladders, there was no duplication in routes. So this suggests that there are no fixed paths, just probabilistic choices.
OK, a bit of a waste of time, but it taught me something I didn't know.
7) Then using the printout, I followed the paths again with my finger, and tallied up the number of times barrels went down ladders vs the times they continued on. For that run it was about 1:11 ratio. So I have my probability to use in code.
Additionally I made some other observations about Kong's behaviour. At the moment I have him working like a metronome. Back and forth with a fixed period. And every 18th time he does a roar. That's what I observed from looking at him before. This time he seemed to roar more often, and there was no pattern. About a 3:1 ratio this time. I may be that he gets more annoyed if you loiter and don't make progress up the screen. Also I noticed that on one occasion he stopped rolling barrels for longer than usual. Playing that bit back it turns out that there are only 10 barrels, same as I have. And if all the barrels are out, Kong stops until one is available. Good, that makes it easy.
So, with those discoveries to implement, writer's block has passed and I'm ready to turn out some more code.
BTW, I'm not sure why you think I need to change Kong to tiles. My worries about speed (now gone) concerned the game logic, which is running in Spin on one cog. The sprites are rendered on different cogs. Reducing the sprite count won't change the speed of the game logic at all. It'd actually fractionally increase it as I'd have more tiles to change than I currently have sprites for Kong. The only way it'd be useful is if I needed to find an extra cog, in which case I could reduce the number of rendering cogs. But it looks like I'm going to be OK with Cogs. I'll use all 8, but I won't need 9.
Post Edited (CardboardGuru) : 5/6/2007 1:45:59 AM GMT
Andre'
Also I have noticed (in the arcade version)that barrels will more often than not come down stairs if you are standing over or on stairs.