[WIP] Donkey Kong conversion

[saimon69]

Originally Posted by Minuous

I know but some bugs were introduced that weren't in the original, also the sprite colours were not fixed.

As if the sprite colors were the only problem! ^______^

[jotd]

Update on the project: completed (except for missing tunes) and all running nicely ... on WinUAE.

As soon as I'm using cycle exact, the game crawls and is unplayable ...

A lot of objects on screen + no palette rework (using 32 colors), no sprites is the reason behind all this.

Currently working on a strategy to use 16 colors only & sprites, hoping to keep 50 fps.

- level 1: using sprites for static barrels & hammers & oil can & flame can save 8 blits
- level 2: using sprites for oil can & flame & hammers & bonuses/hammers can save 5 to 8 blits
- level 3: using sprites for bonuses or elevators can save 6 blits
- level 4: using sprites for bonuses & hammers can save 5 blits

that plus reworking the palette (game displays only 13 colors at once for each level) allows to use 16 colors instead of 32. I hope it's enough.

[DanyPPC]

We hope, I think an A500 is quite good for a Donkey Kong game

[jotd]

After seeing it run perfectly on WinUAE, it would be so frustrating to have to cut it down.

I have other optimization ideas too. Hope is not lost!

[Tsak]

Congrats mate! Would be lovely to get this game on Amiga

Originally Posted by jotd

a lot of blits. Each object is a sprite redrawn every time. There are more than 16 colors.

For the first level:

If you code that brutally (my first approach) you end up with 10 barrels + 5 flames + 6 kong sprites + 2 princess sprites + 2 hammer sprites + mario sprite + 4 barrels beside Kong + oil barrel + flame = 30+ 16x16 objects with 5 cookie-cut bitplanes

Also there is the "delete object" blits too. So 60+ blits * 5 bitplanes = 300 blits per frame.

Unless my blitter routines are underoptimized, that's a lot for the machine to handle.

I wanted to comment on this. Don't know/can't tell if the issue is under-optimized blitter routines (it may as well be). But perhaps it is also the general approach? Let me get to a couple of points:

1) First the elephant in the room : can't understand why you went with 32 colors in the first place. I've downloaded the assets and also counted colors per level and I'm getting max 14 colors in each one (and even less in some). Which means the game can easily fit to 16 colors with zero losses or changes. Blitting 5 bitplanes for assets that can easily fit in 4 (or even less when talking about individual ones) seems like a massive waste.

2) With many of the objects you mention above you don't need to restore the background at all or do a 'delete object' blit as they never intersect with other objects and they stay in place (and there's also no background behind them), meaning these only need a single blit (no mask) to animate (when they do animate). This would be the case with parts of the kong sprite or the princess.

3) Objects that stay in place but do intersect with others is a similar case. F.e. the flaming barrel at the bottom of the first level doesn't need to be restored every single frame, you just need to check when it does intersect with something and only then attempt a refresh. That would also be the case with collectables as well. Place them and then leave them be. They only need updating if an enemy or Mario comes in contact with them.

4) You can do additional optimizations to the tileset and sprites by merging the two for specific stuff. F.e. the arcade assets have the Kong and barrels as separate objects in level 1. But you can merge these and treat them as extra tiles (in which case point 2 above applies). So you're trading Ram for performance in this case (which you probably can afford since the entire set should already fit on 512k alone, several times).

5) Most moving stuff on screen, including Mario, enemies, collectables and fx seem to be 3 colors only and 16x16 (Mario with hammer can be split in 2) which is a perfect match for Amiga sprites. With some effort you could probably do the entire game (except tiles) just with sprites if you went multiplexing. Else 8 sprites are more than enough to cover the majority (and for additional extras you just blit them). This should again give you a massive performance boost.

Anyhow, I'm probably not saying anything new as I've seen you also are considering some of the above

[turrican3]

I didn't connect for a long but when i saw this i had to.
jotd Can't wait to see it running.

[jotd]

@Tsak thanks for the detailed advice. I imagine that there's nothing wrong with the way I'm blitting things, it's just that those old arcade machines have 64 or 128 sprites while the amiga only has 8.

The 32 color display was very useful to "mockup" the display and prove that the game runs properly so it was very useful.

point 1: you're right, and I managed to get down to 4 bitplanes, not that easy as 4 colors of the palette are dynamic, but by luck, used sprites for each level only used 12 colors max. Miracle number one

point 2: yes, I implemented of such optimizations for kong or princess. If no move and no sprite change, then do nothing or just redraw. But it's not going to cut it for the screen where kong moves left & right (pie factory). Another approach could be to have erase size tables for tiles. left corner tile(s) of kong would erase the whole character, whereas others don't erase anything and just redraw. Princess could be done the same way: bottom tile never erases background.

(Like a fighting game, Kong is "animated", not a block but rather 6 16x16 tiles)

point 3: this looks complex. Furthermore, there are no bonuses in stage 1 (which is already causing issues). For the oil barrell, flame & hammers I'm using sprites now.

point 4: yes: there will be a special case for the 4 barrels on top left they will be 2 32x16 sprites, which is cool as they'll only use 1 palette slot (so will hammers, with the blinking to handle, but that can be done with copper as they're never on the same line!)

point 5: I'm already using sprites for some objects. You're right, we could put them there and refresh them only if collision, but that's only for the first screen. I'd like a generic approach that will work all 4 screens. And I don't want to go multiplexing. A few games I remade earlier (Pengo, Bagman) used only sprites because the original arcade machine only had 8 sprites to begin with. With some palette grouping & luck, the blitter was completely avoided and I didn't have all those issues. Xevious used a lot of BOBs but it was AGA dual playfield so FMODE=3, no background restore.

Another point I don't want to go into is interleaved bitmap which makes bigger blits so probably faster. But I have 2-bitplane tiles to restore with special palette. I reckon that interleaved works best for full 16 or 32 colors for tiles+sprites.

Those optimizations are made more difficult by the fact that the original code drives the game, not a amiga-specific implementation.

Using some techniques mentioned above, the game now runs much better. I hope I won't have to go 25Hz that would ruin the experience... If you're curious you can check my current state for display routines here: https://github.com/jotd666/donkey_ko...miga/amiga.68k

[Tsak]

Originally Posted by jotd

@Tsak thanks for the detailed advice. I imagine that there's nothing wrong with the way I'm blitting things, it's just that those old arcade machines have 64 or 128 sprites while the amiga only has 8.

The 32 color display was very useful to "mockup" the display and prove that the game runs properly so it was very useful.

point 1: you're right, and I managed to get down to 4 bitplanes, not that easy as 4 colors of the palette are dynamic, but by luck, used sprites for each level only used 12 colors max. Miracle number one

point 2: yes, I implemented of such optimizations for kong or princess. If no move and no sprite change, then do nothing or just redraw. But it's not going to cut it for the screen where kong moves left & right (pie factory). Another approach could be to have erase size tables for tiles. left corner tile(s) of kong would erase the whole character, whereas others don't erase anything and just redraw. Princess could be done the same way: bottom tile never erases background.

(Like a fighting game, Kong is "animated", not a block but rather 6 16x16 tiles)

point 3: this looks complex. Furthermore, there are no bonuses in stage 1 (which is already causing issues). For the oil barrell, flame & hammers I'm using sprites now.

point 4: yes: there will be a special case for the 4 barrels on top left they will be 2 32x16 sprites, which is cool as they'll only use 1 palette slot (so will hammers, with the blinking to handle, but that can be done with copper as they're never on the same line!)

point 5: I'm already using sprites for some objects. You're right, we could put them there and refresh them only if collision, but that's only for the first screen. I'd like a generic approach that will work all 4 screens. And I don't want to go multiplexing. A few games I remade earlier (Pengo, Bagman) used only sprites because the original arcade machine only had 8 sprites to begin with. With some palette grouping & luck, the blitter was completely avoided and I didn't have all those issues. Xevious used a lot of BOBs but it was AGA dual playfield so FMODE=3, no background restore.

Another point I don't want to go into is interleaved bitmap which makes bigger blits so probably faster. But I have 2-bitplane tiles to restore with special palette. I reckon that interleaved works best for full 16 or 32 colors for tiles+sprites.

Those optimizations are made more difficult by the fact that the original code drives the game, not a amiga-specific implementation.

Using some techniques mentioned above, the game now runs much better. I hope I won't have to go 25Hz that would ruin the experience... If you're curious you can check my current state for display routines here: https://github.com/jotd666/donkey_ko...miga/amiga.68k

I think it would probably make better sense to use sprites for stuff that move the most, like Mario or enemies. That would give you the best buck for your money (in regards to performance savings). When you are out of sprites, you can start using bobs then.

Point 3 is not that complex, just a basic check, if object x collides with another -> update. If not then don't. This is basically how the complete screen/map can be covered with collectables in Worthy (plus the player, plus up to 15 enemies, plus effects, plus projectiles, plus the princess) without the game ever dropping a single frame (and it also works on a500 and 50fps). And -mind you- the game doesn't use sprites either, everything is blitted

Going interleaved is probably a good move. I think the only downside might be extra RAM consumption (in which case you should be able to afford it)?

[jotd]

you're right after all. I may be able to focus on moving stuff then fix side background/immobile objects if they fail to display properly on a specific basis and per level. Kludges for cornercases.

That was an interesting discussion.

[jotd]

published a beta on itch today.

Runs fine on A500 config (didn't test on real hardware) until ... you reach "pie factory" level where things crawl. But playable until then. The whole game was like this before I started optimizing so it will be probably okay after a few hours on it!

[Brenry]

Originally Posted by jotd

published a beta on itch today.

I see you updated the thread on https://jotd666.itch.io/donkey-kong-500 an hour ago with download beta unavailable. Eagerly await to see people enjoy this on AmigaLive

[jotd]

yes, sorry, I had ticked the wrong box. Now available.

[T_hairy_bootson]

brilliant work, just tried it on amigalive and didn't remember how much harder the arcade ver was.

[RenegadeFTL]

a small adjustment is necessary for the whdload information

donkey_kong.slave or donkeykong.slave

now works fine! thank you so much!

[DanyPPC]

Thank You very much Jotd,
another brilliant arcade conversion

[ransom1122]

Amazing.. looking forward to trying this on both winuae and my real a500
Thx jotd your amazing

[mrv2k]

I've faked up a bit of Amiga box art if anyone is interested.

[skyzoo73]

Beautiful, the classic of classics.
Really well done, but it's a habit now,
you're spoiling us with these perfect ports!

Congratulations!


p.s. tested on A600 (for now),
I noticed that the audio has a bit of noise.

[zzbylu]

Awesome game! Gameplay:
[ Show youtube player ]

[acidbottle]

Amazing stuff, another long over due port reaching the world's greatest computer!