D.K. VCS

[iesposta]

Looks excellent, but I am curious to know why the stage 1 screen is broken into two separate screens on your screen shots.

The bottom 2/3 of the screen scrolls up & down, so you are seeing the bottom and the top.

[cd-w]

Very impressive work, but I wish it didn't scroll. There are two tricks I used in Chetiry that may help:

• By changing NUSIZ mid-line you can display more score digits, as described here. This would let you put the score, bonus, and level on 1 line.
  
• You can display more than 192 lines by using the overscan region - Chetiry uses way more (around 220 I think) and I haven't had any complaints yet about the screen being cut off.
  

 

Chris

Edited January 15, 2013 by cd-w

[almightytodd]

I really love the scrolling effect. I find it to be a novel solution to the rotated aspect-ratio problem that Donkey Kong suffers from for arcade-to-home console ports. Pac Man ports have the same problem and the Nintendo solution in that case was to put the score and status information to the right of the play-field:

 

 

That solution doesn't "buy you" as much for DK, because in the arcade version, the scoring/status info is integrated into the play-field space rather than being strictly above or below it as it is in Pac Man. I remain very impressed by this effort and am looking forward to its continuing progress.

[Deteacher]

:-o

 

This is simply amazing work. I never thought I'd see DK on the VCS so close to the actual arcade version. Stunned doesn't even begin to describe me.

 

As for the scrolling, I think it's a very cool idea...especially if it makes things more authentic to the original. Great work! Keep it up!

[Joe Musashi]

Very impressive work, but I wish it didn't scroll. There are two tricks I used in Chetiry that may help:

• By changing NUSIZ mid-line you can display more score digits, as described here. This would let you put the score, bonus, and level on 1 line.
  
• You can display more than 192 lines by using the overscan region - Chetiry uses way more (around 220 I think) and I haven't had any complaints yet about the screen being cut off.
  

Chris

 

Thanks for the suggestions, Chris! That's a very interesting use of NUSIZ. I didn't know you could use it for that.

 

Currently, the 25 m stage is 232 lines high (without any score display). With a single score row it would probably become around 238 lines high. That seems a bit much, and I would loose a lot of cycles in overscan. It would also heavily decrease the number of pointers and cycles to maintain the display.

 

I had thought briefly about increasing the resolution by using interlacing, but I decided against it. I don't have fond memories of interlace flickering on the Amiga, and here it would probably be worse.

 

I should also mention that getting the scrolling engine to work together with the sprite multiplexing took me more than 5 months (unlike Pitfall II, enemies can here move across floors). I don't really want to change it anymore

 

For people who don't like the scrolling, it may help to know that if I have some memory left when the game is finished (not unlikely, I currently have more than a bank free) I'm going to use the available data to build a very high pitfall-esque bonus level.

[raindog]

For people who don't like the scrolling, it may help to know that if I have some memory left when the game is finished (not unlikely, I currently have more than a bank free) I'm going to use the available data to build a very high pitfall-esque bonus level.

 

Awesome! One of the new levels from D2K, or have you already thought of something new?

[Joe Musashi]

Awesome! One of the new levels from D2K, or have you already thought of something new?

 

No, that would be far too complex. I'll have to reuse the graphics data that is already there. Adding new graphics costs a lot of memory, a new level map only a few bytes. Maybe, I'll add a few pipes for fun . Maybe! Just thinking out loud.

 

[raindog]

No, that would be far too complex. I'll have to reuse the graphics data that is already there. Adding new graphics costs a lot of memory, a new level map only a few bytes. Maybe, I'll add a few pipes for fun . Maybe! Just thinking out loud.

 

 

Very cute!

 

I think all of D2K's graphics (the arcade hack, not the INTV remake) were actually repurposed somehow from the original DK ROMs, if I remember the writeup correctly. But something original and unique to the VCS version might be even better!

[Omegamatrix]

Great work here, Joe!

 

Currently, the 25 m stage is 232 lines high (without any score display). With a single score row it would probably become around 238 lines high. That seems a bit much, and I would loose a lot of cycles in overscan. It would also heavily decrease the number of pointers and cycles to maintain the display.

 

I have a feeling you and Chris are counting the height differently here. I took a quick peak and looked roughly like the screen was 228 - 41 = 188 lines in height. Line 41 is where the top red line of 1-up is drawn, and line 228 is the line just below the girder.

 

 

 

 

I should also mention that getting the scrolling engine to work together with the sprite multiplexing took me more than 5 months (unlike Pitfall II, enemies can here move across floors). I don't really want to change it anymore

 

And you've done a great job so far! This is something to be proud of.

[Csonicgo]

If I could change anything on the title screen, I'd add DPC music somehow.

 

Edit: I just tested this on the Harmony, my CRT isn't showing that "third color" from the flicker as I had thought it would on DK's chest. Looks like it depends on the tube.

Edited January 16, 2013 by Csonicgo

[cd-w]

Currently, the 25 m stage is 232 lines high (without any score display). With a single score row it would probably become around 238 lines high. That seems a bit much, and I would loose a lot of cycles in overscan. It would also heavily decrease the number of pointers and cycles to maintain the display...

 

In that case it wouldn't work without scrolling - Chetiry is already pushing the vertical limits. I like the idea of extra levels that take advantage of the scrolling. Perhaps you could extend the climbing sequence at the end of each level also? Will your engine be able to display the sloped girders in the first level?

 

Chris

 

[roland p]

In that case it wouldn't work without scrolling - Chetiry is already pushing the vertical limits.

I saw that in the Chetiry code and I used that for Ballblazer too I removed a lot of (maybe all) the overscan to create enough screen real estate for the playfields.

 

@Joe

I played a bit with D.K. and it felt like the jumping of jumpman is too fast, at least in the x direction. The movement of jumpman looks a lot like the atari 8-bit version (the arcade verison moves much slower), probably since the resolution of jumpman is the same. In the atari 8-bit version, jumpman slows down in the x-direction while jumping:

Edited January 16, 2013 by roland p

[Joe Musashi]

I have a feeling you and Chris are counting the height differently here. I took a quick peak and looked roughly like the screen was 228 - 41 = 188 lines in height. Line 41 is where the top red line of 1-up is drawn, and line 228 is the line just below the girder.

 

Yes that may be confusing. I counted the total height of the actual game map. For the 25 m stage it's 6 floors (each 32 lines, 8 for the girder and 24 for the corridor) plus Kong (32 lines) and one additonal girder (8 lines), should be 232 in total. So, if one wanted the show that completly it may be too much. Might be fun to try on a PAL machine, but I'm out of pointers anyway.

 

Like the ending sequence, the opening could have been done without scrolling. I did it mainly to better match the animation with the tune. The challenge of making it work may have been another distant reason

[Joe Musashi]

If I could change anything on the title screen, I'd add DPC music somehow.

 

Well, when the game is done I'll release the source. Then anyone who feels up to the task can make a D.K. VCS+ version with extensions.

 

Edit: I just tested this on the Harmony, my CRT isn't showing that "third color" from the flicker as I had thought it would on DK's chest. Looks like it depends on the tube.

 

Yes, it will likely be difficult to find a color combination that works everywhere. When I'm done with the 75 m stage, I'm going to make a title version where the colors can be modified with the stick. Then we can do more tests.

[Joe Musashi]

Perhaps you could extend the climbing sequence at the end of each level also?

 

Hm, that would require additonal code, but could be done. No sure if it would look better though. I'm thinking right now more of having Mario climb to the top when Kong has escaped. I cannot draw Kong and Mario at the same time, but It could draw Mario and the ladders.

 

Will your engine be able to display the sloped girders in the first level?

 

Yes and no, it depends on the slope. The kernel is composed of alternating 8 line and 24 line bands (girder + corridor). The girder band could be used to draw a thinner girder with a slight slope. For example, the MSX version does something similar. I could probably work around the attribute clash (ladder-girder color bleeding), but I still think Ivan's original idea with straight but multi-colored girders looks better.

 

[Joe Musashi]

@Joe

I played a bit with D.K. and it felt like the jumping of jumpman is too fast, at least in the x direction. The movement of jumpman looks a lot like the atari 8-bit version (the arcade verison moves much slower), probably since the resolution of jumpman is the same. In the atari 8-bit version, jumpman slows down in the x-direction while jumping:

 

Ah, I already wondered why nobody had mentioned that.

 

Yes, that is a problem. Mario moves horizontally one pixel every two (60Hz) frames. He can only move every two frames, otherwise we will see color ghosting. This is faster than the arcade version. Unfortunately, the arcade uses fractional positioning and has a 60Hz display, also pixels are only half as wide. (The horizontal speed for jumping and running seems the same).

 

Adapting vertical motion worked quite well so far. E.g., the original Y-jump offsets are

 

; original arcade 60Hz jump Y-offsets

; BYTE -2,-1,-2,-1,-1,-1,-1, 0,-1,-1 ; 39 - 30
; BYTE  0,-1, 0,-1, 0, 0, 0,-1, 0, 0 ; 29 - 20
; BYTE  0, 1, 0, 0, 0, 1, 0, 1, 0, 1 ; 19 - 10
; BYTE  1, 0, 1, 1, 1, 1, 1, 1, 1, 2 ; 9 - 0

 

This table shows what needs to be added to Mario's Y position each frame of the jump. This can be adapted to 30Hz:

 

; 30Hz adapted jump Y-offsets ( 20 double frames air time )

S1_MarioJumpTab:
BYTE -3,-3,-2,-1,-2,-1,-1, 0,-1, 0 ; 19 - 10
BYTE  1, 0, 1, 1, 1, 1, 2, 2, 2, 3 ; 9 - 0

 

For the horizontal motion it seems more difficult to match the arcade speed without ghosting and choppy moving, that's why I decided for a constant speed for now. I'll have another look and try to find a better horizontal mapping when all levels are done. They may be too easy with Mario that fast.

[Raygunn]

Just one word... WOW!!!!! this is what we were wanting when that cartridge came out in 82 (don't get me wrong, Garry Kitchen is to be praised for what he gave us... it looked and played well for what he had to work with) BUT THIS IS WHAT WE IMAGINED WE WOULD BE PLAYING! especially when we looked at that first ad for Colecovision in Electronic Games Magazine back in 82... the ARCADE version is all we had... so that's what we were going to be playing even in the VCS back then... and here it is!!! Great Job, please keep going with it! BTW... I like the scrolling, it builds anticipation and tension in what you're going to see next!

[raindog]

Weirdly enough, even though I had a Colecovision and no Atari, I played the Atari port more because most of my friends had 2600s. It wasn't as good as the "real thing", but it was free (well, for me) and we played the hell out of it.

 

It'll be awesome to have a version of Donkey Kong for the 2600 that's more enjoyable than the Colecovision one, and the way things are going, I think that may actually happen here. Even the NES version didn't have the cement factory level.

[cd-w]

 

For the horizontal motion it seems more difficult to match the arcade speed without ghosting and choppy moving, that's why I decided for a constant speed for now. I'll have another look and try to find a better horizontal mapping when all levels are done. They may be too easy with Mario that fast.

 

You probably need to use fractional positioning (eg 16 bit values) to get the jump offsets to look correct.

 

Chris

[DracIsBack]

Dude - this is absolutely outstanding. Just ran on my 7800 using Cuttle Cart and it's great. Way beyond what I thought 2600 could pull off!

[Vic George 2K3]

Not bad so far.

[roland p]

You probably need to use fractional positioning (eg 16 bit values) to get the jump offsets to look correct.

 

Chris

The atari 8-bit version uses fractional positioning too:

 00A0 = 0001	 ptxl	ds	 1			 ; fractional jumpman X position
00A1 = 0001	 ptxh	ds	 1			 ; integer jumpman X position
00A2 = 0001	 ptyl	ds	 1			 ; fractional jumpman Y position
00A3 = 0001	 ptyh	ds	 1			 ; integer jumpman Y position

 

See http://www.atariage....y kong source for the source.

[DracIsBack]

Not bad so far.

 

"not bad"?

 

That's an understatement if I've heard one!

[sqoon]

Even the NES version didn't have the cement factory level.

 

That has been corrected in Donkey Kong Pie Factory available at Retrozone. Game has all 4 arcade levels but is missing the intermission screens.

[raindog]

That has been corrected in Donkey Kong Pie Factory available at Retrozone. Game has all 4 arcade levels but is missing the intermission screens.

 

Well, the recent Wii/3DS version with the pie factory is out there too... and is about as legal.

 

But the arcade version (and D2K) are out there for MAME, and have been for at least 16 years. So the slightly-more-complete NES version is a curiosity, much like the slightly-more-complete ADAM version of Colecovision Donkey Kong. This, however, is a feat.