D.K. VCS

[Thomas Jentzsch]

I would add another floor to the playfield if I could, but that would require another 19 bytes of ZP RAM and 10 bytes of SARA RAM, which I don't have. Even if it would be possible to free that much RAM, one would have to change a huge amount of code.

Looks like that's a a limitation which cannot be overcome.

 

What is eating up so much RAM?

[Joe Musashi]

This latest versions looks great. Animation is very well done. My only suggestion would be to implement some kind of bounding box collision detection. It's gets frustrating quickly when getting nicked by one pixel kills you. The arcade version is actually very forgiving when it comes to collision detection and allows quite a bit of overlap between Mario and the enemies.

 

Great work so far!

 

Thanks! There is actually a bounds check, but it's simplified: collision detection is omitted when Mario is higher than 10 pixels in the air. Obviously, this might cause problems with enemies comming from above, so this needs to be more accurate.

[tep392]

I was on a ladder at it seemed that the very top pixel of the fireball got me. I'll post some of the boundry's I've documented from the arcade code. I havn't looked at them in a while but I think they are all less than 10 pixels in the y axis.

[Joe Musashi]

Looks like that's a a limitation which cannot be overcome.

 

What is eating up so much RAM?

 

The SARA RAM would be another enemy state. The more difficult part is the ZP RAM, which is mosty pointers. A floor consists of two bands (girder+corridor) each having its own set of pointers and indices. I would probably try to unify the bands into one, but as said, this would result in a whole load of problems.

 

Anyway, if this is to be tried it should be one of last things to be done, because I want to save room for optimization for potential new features, such as the hammer or elevator rails.

[Joe Musashi]

I was on a ladder at it seemed that the very top pixel of the fireball got me. I'll post some of the boundry's I've documented from the arcade code. I havn't looked at them in a while but I think they are all less than 10 pixels in the y axis.

 

Ah yes. The climbing state is an exception. There it's only HW collision, otherwise the barrels going down the ladders would not hit if Mario is too high.

[tep392]

Ah yes. The climbing state is an exception. There it's only HW collision, otherwise the barrels going down the ladders would not hit if Mario is too high.

 

The boundry height for the enemies in the arcade code is 8-9 pixels. You might want to make it a little less than that even to compensate for the HW collision detection. Is there enough time to check if the object is above Mario in your collision code?

[Thomas Jentzsch]

Anyway, if this is to be tried it should be one of last things to be done...

I hope your code is using a lot of constants (instead of e.g. magic numbers) here. Else it will become quite impossible to change such fundamental stuff that late.

[Joe Musashi]

The boundry height for the enemies in the arcade code is 8-9 pixels. You might want to make it a little less than that even to compensate for the HW collision detection. Is there enough time to check if the object is above Mario in your collision code?

 

Yes, I can do a full box check. I thought of something like a 6x8 box for the fireball.

[Joe Musashi]

I hope your code is using a lot of constants (instead of e.g. magic numbers) here. Else it will become quite impossible to change such fundamental stuff that late.

 

Of course

 

NUM_FLOORS = 4

     ldx #NUM_FLOORS
.loop      jsr DrawFloors
     dex
     bpl .loop

[Thomas Jentzsch]

NUM_FLOORS = 4

ldx #NUM_FLOORS
.loop jsr DrawFloors
dex
bpl .loop

Perfect!

[kaz321123]

Just a random thought...would the 'starpath supercharger' help any with making this game (to allow for more ram or whatever)?

 

or another thought. What if you had 'disk 1, disk 2, disk 3, etc'...

 

So that the first level of donkey kong=disk 1

Disk 2=second level

 

Disk=cartridge of course

 

Would that allow for better programming of donkey kong (if space is an issue)?

 

Just brainstorming randomly.

Edited April 25, 2013 by kaz321123

[kaz321123]

Scrolling donkey kong is a very unique and cool solution that you found also!

[Joe Musashi]

Just a random thought...would the 'starpath supercharger' help any with making this game (to allow for more ram or whatever)?

 

or another thought. What if you had 'disk 1, disk 2, disk 3, etc'...

 

I think the supercharger only has 6KB memory. That would not be enough for a single level. I have to jump across 6 different banks to draw a single in-game frame.

 

Of course, you could dedicate a whole 32KB cartridge to a single level, but then you would have to swap carts all the time. You would also lose your score count.

[kaz321123]

If it came down to 'emulation/arcade accuracy' vs. 'keeping track of my score', I personally would choose accuracy.

 

If even just to see if it helped improve the gameplay. Gameplay should come first, scorekeeping second.

 

I have often played Donkey Kong, for example, just for the fun of it, with no interest in how high my score was.

[Kiwi]

If you're using a SARA chip, would you have 384 byte of RAM including the Atari 2600. I only see 2 page of RAM when I use the debugger, one for Atari 2600 and the other page for 128 byte of RAM. I'm thinking of SARA chip, I think additional 256 bytes. I'm not 100% sure. Or SARA chip comes in different size. Sorry, I was a little confused.

 

When I saw the first screen shot of this game. I was like, this isn't possible for the 2600. I loaded up the ROM for the first time, it blew my mind. I was looking at the girder title screen and wonder how did he do that. This game looks and plays awesome. I really dig the scrolling. I really impressed by the sprite blending technique and it really doesn't look like a Atari 2600 game. It would fool someone if you told them it an Atari 5200(800XL) game. The possibility is almost endless with this wonderful machine. Really awesome job!

[raindog]

Of course, you could dedicate a whole 32KB cartridge to a single level, but then you would have to swap carts all the time. You would also lose your score count.

 

Looking forward to Super Donkey Kong: Harmony Edition ...for the hundred or so of us who actually have a Harmony.

[+Omegamatrix]

If you're using a SARA chip, would you have 384 byte of RAM including the Atari 2600. I only see 2 page of RAM when I use the debugger, one for Atari 2600 and the other page for 128 byte of RAM. I'm thinking of SARA chip, I think additional 256 bytes. I'm not 100% sure. Or SARA chip comes in different size. Sorry, I was a little confused.

 

Yeah, you only get 128 more bytes of ram with the SARA, and not 256. Bit 7 is used as a read/write line for the extra ram, so that's why you lose the other 128 bytes of ram, because half your addresses are lost.

 

Superchip example:

LDA $FF80 ; read from super chip ram location 0

STA $FF00 ; store to super chip ram location 0

[Kiwi]

Yeah, you only get 128 more bytes of ram with the SARA, and not 256. Bit 7 is used as a read/write line for the extra ram, so that's why you lose the other 128 bytes of ram, because half your addresses are lost.

 

Superchip example:

LDA $FF80 ; read from super chip ram location 0

STA $FF00 ; store to super chip ram location 0

 

If he used the RAMplus 256 byte of RAM, does he loses the address 512 bytes of ROM space with 3584 byte available for ROM for each bank? Just curious how the extra RAM works. Thanks.

[Csonicgo]

Looking forward to Super Donkey Kong: Harmony Edition ...for the hundred or so of us who actually have a Harmony.

 

Games like this would sell harmony carts like hotcakes. Arent they already selling like hotcakes?

[+stephena]

Yeah, you only get 128 more bytes of ram with the SARA, and not 256. Bit 7 is used as a read/write line for the extra ram, so that's why you lose the other 128 bytes of ram, because half your addresses are lost.

 

Superchip example:

LDA $FF80 ; read from super chip ram location 0

STA $FF00 ; store to super chip ram location 0

 

Also (assuming that Kiwi was using Stella), you only see 1 extra RAM page in the debugger since that's really all you have. Even though there are two RAM ports (read and write), the debugger only exposes the read port, and when you make changes it uses the write port.

[Greg2600]

WOWZERS! I cannot simply accept that this is a 2600 game. Not possible. I just tried it on the harmony and cannot believe my eyes! The music, graphics, and control! It's controls like an NES game. Probably said already, but one problem on real hardware is that things like DK himself or the ladders in the animated sequence have a LOT of flicker not present when tried on emulator. Also, not sure yet how to beat level 3. All in all, shocked I've missed this one!

[Joe Musashi]

Looking forward to Super Donkey Kong: Harmony Edition ...for the hundred or so of us who actually have a Harmony.

 

You sure can make a lot of cool levels if you do not have to follow the arcade.

 

[Joe Musashi]

WOWZERS! I cannot simply accept that this is a 2600 game. Not possible. I just tried it on the harmony and cannot believe my eyes! The music, graphics, and control! It's controls like an NES game. Probably said already, but one problem on real hardware is that things like DK himself or the ladders in the animated sequence have a LOT of flicker not present when tried on emulator. Also, not sure yet how to beat level 3. All in all, shocked I've missed this one!

 

Thanks. Is there any specific problem with stage 3? Mario jumps pretty far. You can even jump backwards over most gaps.

[raindog]

You sure can make a lot of cool levels if you do not have to follow the arcade.

 

Yes, you can.... the Super Game Boy port and D2K are proof of that.

 

You could always call it Congorilla Deluxe

[Greg2600]

Thanks. Is there any specific problem with stage 3? Mario jumps pretty far. You can even jump backwards over most gaps.

No I just kept thinking there was a spring board on the bottom that I'm supposed to land on.