The Donkey Kong Make Over Show
CardboardGuru
Posts: 443
Well the other thread was getting a bit long, so I decided to start another all together more colourful one.
For future reference the previous threads in this log are:
205.158.110.70/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=17&t=000122
http://forums.parallax.com/showthread.php?p=646738
So, plenty more progress.
1) I made the barrels go down ladders with 1:11 probability as previously discussed.
2) Kong is a little less like a pendulum and a bit more randomised. The time when he is stood without a barrel is randomised, and also if there are 10 barrels already out he waits in that state for one to become available. So no more disappearing barrels.
3) I then went on to put flames in the oil drum. The flames there flare up every time a blue barrel hits. Then die down.
4) The flames didn't look at all like fire because of the wrong colours, so I decided it was about time I implemented palettes. Sprite palettes were an easy job.
5) I went on to do tile palettes, and that was much harder. It's far too much work for the propellor to calculate a colour for every pixel individually on the fly. So the code worked by doing 2 pixels at a time, looking up colours for the pair from a cog side lookup table. But that didn't make it easy to implement varying palettes. Anyway, to cut a long story short and after a few blind alleys I've got palettes for tiles implemented.
I gave Kong his makeover and the screen then looked awfully brown. So I changed the plaforms to magenta, and the scores to green and white. Oh and the 3 little marios don't look like dig dug any more.
For future reference the previous threads in this log are:
205.158.110.70/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=17&t=000122
http://forums.parallax.com/showthread.php?p=646738
So, plenty more progress.
1) I made the barrels go down ladders with 1:11 probability as previously discussed.
2) Kong is a little less like a pendulum and a bit more randomised. The time when he is stood without a barrel is randomised, and also if there are 10 barrels already out he waits in that state for one to become available. So no more disappearing barrels.
3) I then went on to put flames in the oil drum. The flames there flare up every time a blue barrel hits. Then die down.
4) The flames didn't look at all like fire because of the wrong colours, so I decided it was about time I implemented palettes. Sprite palettes were an easy job.
5) I went on to do tile palettes, and that was much harder. It's far too much work for the propellor to calculate a colour for every pixel individually on the fly. So the code worked by doing 2 pixels at a time, looking up colours for the pair from a cog side lookup table. But that didn't make it easy to implement varying palettes. Anyway, to cut a long story short and after a few blind alleys I've got palettes for tiles implemented.
I gave Kong his makeover and the screen then looked awfully brown. So I changed the plaforms to magenta, and the scores to green and white. Oh and the 3 little marios don't look like dig dug any more.
zip
37K
Comments
PS, just out of curiosity, is the TV renderer going to be freely usable? or are you only allowing your older tv display to be used for other projects?
Cheers in advance.
Baggers
Darts.
JetPac
some form of Manic Miner rip.
Fruit Machine.
Super Sprint
and a few others.
( I'll probably have to modify the render engine anyway. so if it's not going to be freely usable I'll just write mine from scratch, but it just saves re-inventing the wheel, since it's been invented lots of times. and Andre' seems to be snatching them all up for his book. )
Phew! Lots of ideas. Tell you what, pick one, and promise to give us updates on your progress here, and you're welcome to take any of the code from DK and use it how you will. How's that for a deal?
But you'll need good luck and a following wind to modify the rendering code. The cog memory is absolutely full, such that every time I've needed to make a change, I've had to create some space. So it's been getting ever less comprehensible as time has gone on and I've eliminated a named register or done a space optimisation.
Next release has hot-spots for sprites, and a reordering of the bits in the sprite table so the images are the same way round in the SPIN file as they are rendered. So you might want that.
(Maybe I ought to put GPL on it or something so that it's clear what people can do with it.)
I have been thinking about Manic Miner for the HYDRA a bit myself.
Manic Miner is one game which game mechanics should lend itself brilliantly to the capabilities of the HYDRA.
Manic Miner uses a system with an "interpreter" that "interprets" "game data blocks". The interpreter uses this data to build-up the game screen (background) and all the moving elements in it. and how to handle the actions and animation. Creating a game screen then amounts to assembling a game data block.
On the Hydra the data for the "screens" can be stored into the external EEPROM, and only downloaded when needed, so a much larger game is possible than when the whole game has to fit in memory.
Also, the game is especially designed for a screen with just two colors per 8x8 tiles. Adapting a video driver with those capabilities would give a video memory sparse system with plenty of space left for the "interpreter" that interpretes the game data, and buffer space for a single screen.
Also, Manic miner is my all time favorite!
Firstly, Thanks, and yes, I'll keep giving updates like you have with DK.
Thanks for the tip on lack of memory for the cog renderer, I'll see what I can do.
As for the update, yeah I'll look forward to that.
Cheers,
Baggers.
mahjongg,
It seems you do like MM lol. should I go for this one first?
Manic Miner, and it's successor Jet Set Willy both were early examples of games that were built around a "game engine".
This means that if you replicate the "game engine" (a kind of interpreter) for these games then you can use the original game data, and so you can make an exact replica of these games.
Both games were ported to many systems, even by hobbyists, and there is a bulk of information about them.
The wikipedia article about Jet Set Willy is a good starting point en.wikipedia.org/wiki/Jet_Set_Willy.
Also, because the engines for MM en JSW are probably very similar you could start by re-creating the one for MM and then "upgrade" to the one for JSW.
If you can pull this off, then this would by far the most playabe games for the HYDRA to date!
Mahjongg
I need to work out a character set etc. and how to store the screens in such a way it hardly takes up room.
I'll do MM first.
watch this space, ( or its own thread )
Baggers
What needs to be done is:
So the first thing to do is to search the internet for other re-creations of MM or JSW, and either:
or
Mahjongg
Well I've been playing a game of "Just one more thing then I'll release". That way there is no end to the tinkering. So I'll release and be damned.
What's new:
1) In keeping with the theme of the make over, I decided that some small changes to the graphics could actually improve the look. I changed the ladders so the poles are 2 pixels wide. This get's rid of the color artifacts. Likewise the platforms lattice work has been made more substantial. And the bonus box.
2) Then I looked at the barrels. Because the aspect ratio is different from the original they didn't look round. The height is important for gameplay because you need to be able to jump them, so I adjusted the width and simplified the side artwork to just a bung hole. Previous to studying the game to reimplement, I didn't know why there were some blue barrels. It's because they turn into fireballs when they get to the oil drum. The blue barrel with skull never suggested that to me, so I played around with other designs. But ended up with a plain green barrel. It's more suggestive of an oil barrel to me at least. Unleaded perhaps. Also implemented flipped (i.e. upside down) sprites so that I could animate the barrels properly. It's a single image mirrored and flipped to make it look like it rotates.
3) Then I implemented the state engine for the fireballs. All pretty familiar stuff logic is not that dissimilar to the barrels. Though it revealed one or two bugs in the existing functions. It's all probablistic stuff as to whether they change direction or go up or down a ladder. I'll tweak it later if the behaviour doesn't seem quite right. There's a bug ledt where once they get to the top platform they don't come down again. I'll look at that next.
4) I reordered the bits in the sprite and tile definitions, so that they are the same way around they appear on screen. It was the wrong way around because of the limitations of the Tile Studio custom export. Next time I'll use BMP2SPIN or a custom script to do the job.
5) Also got fed up with continually adding 8 and 15 or 12 to the coordinates of the sprites to test what is at their feet. So I added hot-spots to the sprite engine. I did hot-spots as an attribute of the sprite image rather than per-sprite. It seemed like a good idea when I was doing it, however if I'd have added it to the sprite, it'd have made the fireball bouncing action easier. They don't all bounce at the same time, so varying the hot-spot for that isn't an option. Andre, if you're reading, where are hot-spots usually applied? Per sprite image or per sprite?
6) I ran out of sprites. When I did the sprite engine I picked 32 sprites as a likely amount. But I had 4 fireballs, and with a couple of hammers, and a couple of sprites for Pauline, I ws up to 33 sprites. The I realised that actually the original doesn't use seperate sprites for the barrels and the fireballs. Rather the blue barrels transform into flaming barrels, and use the same sprite. So the more fireballs, the less barrels. It also sneaks barrels off the screen when they are below you. Rather than bounce off the sides of the screen, they keep on going. Whilst that works OK on the original, my platforms don't go to the edge of the screen, and I think that might look a bit odd. So instead I'll just make the barrels always take a ladder if it's currently below you on screen. That's a quick way to the bottom.
So next I'll merge the fireball state machine into the barrel state machine and share sprites. And I'll fix that fireball bug. And I'll add the hammers and Pauline. Then we're just about done for the first level.
P.S. Badders, yes, go with Manic Miner. You should be able to use my renderer as-is. It's wide enough, more than high enough, and has more than enough colours. The tile map takes up 1792 bytes - 32*28 with a tile number byte and a palette number byte. You could store the screens in your compresed format and uncompress them into the map for display. Sprites are far larger than you need at 16*16, so you could cut them down if you wanted to save the space.
Suggest you start a new thread for Manic Miner.
so I was going to play through the game, grabbing screens while i went, and then convert them to a Prop char map and then do a new "game engine" ( although i'd call it a map decompressor ) to create maps like the original from small dat statements.
edit : yeah sorry, will start a new thread, once I have something [noparse]:)[/noparse]
Baggers
www.geocities.com/andrewbroad/spectrum/willy/mm_format.html
you can find a complete technical description of the internal data structure of the Manic Miner "room format".
have fun!
Mahjongg
I'll post something soon as I have it on screen.
What I'm going to do is do an SDL displayer first, to make sure it works. [noparse]:)[/noparse]
Then once I'm happy it works on a PC, IE I'm reading the level data correctly, I'll convert it to the prop [noparse];)[/noparse]
Baggers
PS, don't know how to move parts of this thread to another.
but when I post next one it'll be on MM.
The progress on this has been really good, but I must say, I don't like the creative license you took with the graphics (with maybe the exception of making the barrels a darker brown and the thicker ladders).
Dark green text looks bad, make it white.
The green barrel looks horrid, why not just make it like the original? Also if the blue is too harsh, try using a lighter blue. (I miss the skull).
Mario needs some color to him, pink him up a little.
Also I can't put my finger on it, there is something about the fire graphics that look really off.
Also I would recommend making the barrels next to kong, the blue barrel, flames, and kong himself tiles. I know I keep banging this drum, but I think it is the right thing to do so you can added in a sound cog. Even if you don't add sound until way later(or not at all and let someone else do it) you should put in a sound driver because sound would really complete the game.
I hope you don't think I am ragging on you, I'm just putting out some constructive criticism. Keep up the good work.
·
Any and all suggestions and criticism are always welcome.
I'm afraid you're not going to like the way things are going... Whilst my original plan was a pixel perfect remake, I've decided that simply taking the images from the ROM was far from ideal both for copyright and creative reasons. You must have hit this too with Ball Buster. It's suggestive of the Arkanoid look, but it doesn't use the exact same images and colours. So in time, all of the DK graphics will be redesigned. Not drastically, but enough. But it'll still play like Donkey Kong.
The palettes are in a constant state of flux as I tinker with them from time to time. They'll change a few more times yet.
Yes, the fire graphics do look a little odd. In part it's because of the different aspect ratio. And also because they use a lot of single pixels, and so there are colour artifacts. And also the palette isn't the same. And because the frame rate wasn't the same, the flickerin looks different. Since the version you last saw they've improved a little. But still they aren't right.
The Kong/tile thing is definately not needed. A spare cog for sound was always allowed for. I still have one free. There are too many issues with doing Kong as tiles, and I don't need to. Also the oil drum and the flame coming out of it need to be sprites as barrels dissapear behind it and fireballs come from behind it.
Post Edited (CardboardGuru) : 5/12/2007 2:44:44 AM GMT
Lots of progress since yesterday.
1) I merged the barrel and fireball logic. So now if you wait around on the first level, gradually all the barrels will convert to fireballs and you'll have 10 fireballs. That'll never happen in real gameplay though because the bonus counter will run out and you'll die way before that.
2) I fixed the bug with fireballs getting stuck on the top platform. Now they wander around at will.
3) I added Pauline and a state engine to time her animation. And I added a couple of hammer sprites.
4) With that all done, Level 1 is more or less finished. So I decided to do maps for the other levels. They are all now added and accessible in the game, and there's even the intermission screen between the levels. Of course there isn't much happening on those new levels yet. But it's good just having them there at last.
5) I added synchronisation to the vsync. So the game should run at the correct speed now. I did it in a slightly different (and I hope better) way than it normally is. Usually it's one way communication between the TV driver and the app. A flag to say that the vsync is happening. So you can wait for it. But it occured to me that if you just miss flag, then the game will slow to half speed as the game engine waits for the next vsync to happen. What I've done is have the TV driver set a flag and leave it set. The game then sets the flag to zero after it has synced. So if the game engine misses the next vsync, it'll continue processing regardless. So only a slight slow down and not a sudden switch to half speed.
That said there is an intermittent bug where suddenly the screen degrades, just as it would if there weren't enough cogs to render. It's only appeared very recently. I'm not sure where the problem lies yet.
Looking great.
But as I said I might tinker some more with any of the palettes.
Tinker away, it does look better pixel wise, as I seem to have the same problem with some colours too.
Also on the rivet level, I would just put kong in the middle and split the beam that paulina is on.
As for the green text, you might want to try a lighter shade of green inho.
EDIT: File removed now problem has been confirmed
Post Edited (CardboardGuru) : 5/14/2007 12:36:09 AM GMT
It's one of those real nasties. You can comment code out and it'll stop doing it. But you can't be sure if it's because the code was the bit causing the stray pointer, or if you just shifted where everything is in the binary causing the pointer to miss the critical bits.
Deleting the defective source now.
Here's the clues that I found on the way to finding the bug.
1) I wondered if perhaps the fussiness was down to one of the rendering cogs not working correctly. I changed the number of rendering cogs to 4 of which the screen height (224) is a multiple. That meant that each cog was always rendering the same set of lines in each frame. Sure enough first one cog was failing then another.
2) I got to one particular combination of included code where it was failing badly. And I noticed the debug LED came on when it did. But I was pretty sure that by that stage I didn't have any debug lighting code in my source. I search showed that sure enough there remained an OR dira,#1 but no OUTA. Not anywhere in any of the 3 source files. So how was the LED being lit? Looking at the Propellor Manual I see that OUTA is also addressable as cog register $1F4. So it looked like on rare occasions my rendering code was writing where it shouldn't in cog memory.
3) Looking at the rendering code, the obvious culprit is the scanline buffer. The tile code is bulletproof, but not the sprite code. There is no check for the bounds of a sprite. If it's X coordinate is out of range, it'll stomp all over memory.
4) I realised that I had recently added hot-spot support for sprites, so it an X coordinate of zero was given for many of the sprites, it'd take the hot-spot off that and end up writing before the beginning of the scanline buffer. However, none of my active sprites ever got an x-coordinate of 0.
5) But then I remembered that I'd changed the Spin function that sets the collection of sprites for Kong into the different poses. My sprites are each controlled by a single long that contains 4 byte values: flags,tile,x,y. I used to be setting them all with a longmove. Now I was setting them up byte by byte. Kong needs anything from 5 to 8 sprites, so up to 3 of the sprites are set to be invisible every one in a while. And at the same time the X&Y get set to zero.
6) Unfortunatley when I changed to byte addressing, then X got set to zero a moment before the sprite was set to invisible. If a cog came along during that time and tried to render the sprite, it's get written outside the scanline buffer and it would break down.
7) I reverted to addressing a long at a time again, and the bug is gone.
That' the first multiprocessing bug I've hit. The propellor makes multiprocessing seem so easy it's easy to get complacent.