D.K. VCS

[gorfcadet]

Sorry to just chime in, but wow. Really, just... wow. That is brilliant!

[snstay]

wow great game but im wondering is the donkey kongs suppose to flicker?

[+Nathan Strum]

Pretty-much everything is supposed to flicker. That's how the multi-colored sprites are achieved. You can minimize flicker in Stella by turning on the phosphor effect (alt+p on Windows, or cmd+p on a Mac).

[Andromeda Stardust]

while I really don't mind sprite flicker, I believe playfield flicker is something to be avoided if at all possible. Remember Pacman VCS with it's seizure-inducing 15Hz flicker? Remember how badly people said it sucked? Part of the problem was the lame maze, but the flickering really gave a lot of gamers headaches after playing, which left players with a bad overall impression of the 2600.

[iesposta]

while I really don't mind sprite flicker, I believe playfield flicker is something to be avoided if at all possible. Remember Pacman VCS with it's seizure-inducing 15Hz flicker? Remember how badly people said it sucked? Part of the problem was the lame maze, but the flickering really gave a lot of gamers headaches after playing, which left players with a bad overall impression of the 2600.

I completely disagree.

Here is my example of the EVERYTHING flickering EXCEPT the Jumpman sprite.

JumpmanELe20121108.bas.bin

The playfield, kong, lady, ball all 30Hz flicker. Plus since everything is done twice, I get 2 balls and 4 missiles. One ball is the elevator blue line, the other ball is the elevator red line.

First you say you don't mind sprite flicker, then you say pacman VCS 15Hz sprite flicker is seizure-inducing. Which is it?

[Thomas Jentzsch]

while I really don't mind sprite flicker, I believe playfield flicker is something to be avoided if at all possible. Remember Pacman VCS with it's seizure-inducing 15Hz flicker? Remember how badly people said it sucked? Part of the problem was the lame maze, but the flickering really gave a lot of gamers headaches after playing, which left players with a bad overall impression of the 2600.

I agree that flicker is something to be avoided *IF* possible. And that PF flicker, because of the area flickering, is worse than sprite flicker.

 

But then your Pac-Man example doesn't fit. Here only the sprites flicker, but not the playfield.

 

IMO the reason why Pac-Man's flicker is so annoying is, that (besides many other flaws) the sprites flicker badly (15Hz!). There are a lot of games that get away with flicker, without people complaining. E.g. Asteroids flickers a LOT, still it is by far not that annoying. Lady Bug, which is one of the best modern homebrews, even flickers the whole playfield. Still people are loving and buying it.

 

So flicker is only bad, when done bad. Flicker when done right extends the capabilities of the Atari 2600.

[Omegamatrix]

Programmers do try to avoid flicker like it's the plague, but sometimes it really is impossible to get more objects on the screen without it. Then we start looking at various methods of trying to make the flicker less painful. This includes changing the luminescence to different values until one seems to flicker less, color blending, and the way we interleave big sprite patterns.

 

 

That being said some things lend themselves to flickering naturally, like ghosts and fireballs. Real fire flickers, why shouldn't a fireball? However, IMHO I find anything below 30Hz flicker very distracting so there are practical limits to it too.

 

 

Joe, This DK is a brilliant version so far and I'm looking forward to watching it go forward.

[Andromeda Stardust]

Okay, I mentioned Pacman as a bad example of sprite flicker. Even Pacman 4k homebrew flickers at 20Hz, but it doesn't hurt the eyes nearly as much, or gameplay at all.

 

Forget I even mentioned Pacman. I was simply stating my opinion that the playfield elements should not be flickered if at all possible. Sprites do not occupy the entire screen so the psycho-visual effects are not that bad. Flickering the entire playfield would extend the strobing effect to cover the entire screen. I think the elevators could easily use the play field graphics rather than sprites and not flicker, even if it means they cycle colors as they pass over colors designated by the ladder/girder scan lines. So what if the elevators have to share color with the ladders/girders? It's the 2600; you've got to make sacrifices somewhere. None of the other stages in the demo ROM flicker the playfield, so I don't believe it's necessary on the 75m stage. The game also needs to maintain a uniform look from one stage to the next. The missile sprites would be very easy to implement "connecting the dots" as the vertical lines which make up the elevator cables. I can't remember if the missile sprites need to be the same color as the player 1/2 sprites. If so, the colors may look odd, or you could use the ball sprite for the elevator cable (which I know can be programmed to an independent color) and use 30Hz flicker to transpose it between the two positions.

 

Overall, I'm well pleased with the developments so far. The flat girders on the 25m stage are fine in my book. As long as the barrels roll as expected in the final version, gameplay will not suffer.

 

Iesposta, I'll load your rom file on Harmony and report back what I think.

 

Keep up the good work people...

 

EDIT: @Iesposta: WOW, THAT ELEVATOR STAGE IS UN-FREAKKING-BELIEVABLE! Forget what I said earlier...

Edited February 20, 2013 by stardust4ever

[+Gemintronic]

I completely disagree.

Here is my example of the EVERYTHING flickering EXCEPT the Jumpman sprite.

JumpmanELe20121108.bas.bin

The playfield, kong, lady, ball all 30Hz flicker. Plus since everything is done twice, I get 2 balls and 4 missiles. One ball is the elevator blue line, the other ball is the elevator red line.

First you say you don't mind sprite flicker, then you say pacman VCS 15Hz sprite flicker is seizure-inducing. Which is it?

 

Reading about playfield flicker I thought I'd reject it like a spoiled can of escargot. With that example IF Donkey Kong didn't flicker I could be convinced the playfield is just dark instead of flickery.

[iesposta]

.

 

Iesposta, I'll load your rom file on Harmony and report back what I think.

 

Keep up the good work people...

 

EDIT: @Iesposta: WOW, THAT ELEVATOR STAGE IS UN-FREAKKING-BELIEVABLE! Forget what I said earlier...

 

I thought I could change your mind

Really, Thomas Jentzch said what I was trying to say and what you were saying about the ghosts. Flicker is bad when done bad. When done right, it extends the capabilities of the 2600.

 

Heavy flicker is tolerable for short periods like say a row of objects that you would pick up right away reducing the flicker as the items are picked up would be ok with me. And I think a game redone like Wizard Of Wor where there are so many enemies that they must flicker pretty badly, just having great gameplay makes the annoyance of flickering worth it, plus it flickers less and less the more the enemies are taken out.

[Csonicgo]

I completely disagree.

Here is my example of the EVERYTHING flickering EXCEPT the Jumpman sprite.

JumpmanELe20121108.bas.bin

The playfield, kong, lady, ball all 30Hz flicker. Plus since everything is done twice, I get 2 balls and 4 missiles. One ball is the elevator blue line, the other ball is the elevator red line.

First you say you don't mind sprite flicker, then you say pacman VCS 15Hz sprite flicker is seizure-inducing. Which is it?

 

On my crappy TV that really isn't bad. what's bad is BRIGHT things flickering. that was the problem with pac-man.

[iesposta]

 

 

Reading about playfield flicker I thought I'd reject it like a spoiled can of escargot. With that example IF Donkey Kong didn't flicker I could be convinced the playfield is just dark instead of flickery.

That is the programming challenge. There is so much going on at the top of D.K.'s red levels at the same time. I am compromising by choosing not to display the princess/lady until Jumpman is at the top ready to rescue her. That demo just happens to have her onscreen all the time.

With my batari Basic demo I wanted to show some of what can be done, however I leaped way ahead doing what I am good at - sprites, animation, layout, sound - and have NOT done what I LOVE about the 2600. AWESOME GAMEPLAY.

Gameplay should always come first. A great, challenging, frantic, pulse pounding, tension building gameplay with lots of replay desire far outweighs crude graphics. The mushrooms are rectangles, but the gameplay is great kind of thing.

[+Gemintronic]

That is the programming challenge. There is so much going on at the top of D.K.'s red levels at the same time. I am compromising by choosing not to display the princess/lady until Jumpman is at the top ready to rescue her. That demo just happens to have her onscreen all the time.

With my batari Basic demo I wanted to show some of what can be done, however I leaped way ahead doing what I am good at - sprites, animation, layout, sound - and have NOT done what I LOVE about the 2600. AWESOME GAMEPLAY.

Gameplay should always come first. A great, challenging, frantic, pulse pounding, tension building gameplay with lots of replay desire far outweighs crude graphics. The mushrooms are rectangles, but the gameplay is great kind of thing.

 

Whoa whoa WHOA WHOA!!!!!?! This is batariBASIC? What black magic is this?!? Is there a chance we could see the source?

[iesposta]

The files in Post #1 are Joe Musashi's and are assembly.

The file in Post #130 is my batari Basic demo.

Also in my blog http://www.atariage.com/forums/blog/516/entry-9710-dk-2600-jumpman/

I am going to start a thread in 2600 - batari Basic forum to keep working on my version which has all 4 screens too, but I need to ask about additional memory for graphics, using the push pull stack variables, etc.

[Joe Musashi]

Only a small update this time. There's not much to see, it mostly fixes some loose ends:

• Fixed scan line count fluctuation at the end of stage 4.
  
• Bonus is now correctly added after Kong stops rolling his eyes.
  
• Made the Kong ending animation a bit more accurate. Can you spot what is different to the last version?
  
• And there's now not one but two ending tunes (thanks Perry!)
  

D.K.VCS_130225.bin

[+Gemintronic]

The files in Post #1 are Joe Musashi's and are assembly.

The file in Post #130 is my batari Basic demo.

Also in my blog http://www.atariage....k-2600-jumpman/

I am going to start a thread in 2600 - batari Basic forum to keep working on my version which has all 4 screens too, but I need to ask about additional memory for graphics, using the push pull stack variables, etc.

 

I'd be pretty surprised if %90 percent of your code wasn't inline assembly. I can't fathom how bB could allow such a worthy port! Is there a chance you'll be posting source sometime?

[iesposta]

I'd be pretty surprised if %90 percent of your code wasn't inline assembly. I can't fathom how bB could allow such a worthy port! Is there a chance you'll be posting source sometime?

The only "inline assembly" would be the "Titlescreen.asm" code that shows the Monkey and "How High Can You Try?" And I made that with the Titlescreen Editor.

I'm leaning toward posting the basic source with the hope that this community could help implement gameplay.

The most complicated routines are the PFPIXEL writes that Bogax proposed, and let me move most of the playfield data into each ROM bank.

Since I can only have 2 playfields in the graphics data (bank 7) ideally I would like to use an extra memory chip to copy the playfields into the graphic data bank for each level. Then I would have all the 5 banks for game code.

[iesposta]

Only a small update this time. There's not much to see, it mostly fixes some loose ends:

• Fixed scan line count fluctuation at the end of stage 4.
  
• Bonus is now correctly added after Kong stops rolling his eyes.
  
• Made the Kong ending animation a bit more accurate. Can you spot what is different to the last version?
  
• And there's now not one but two ending tunes (thanks Perry!)
  

Heard both ending tunes. Good work! Made me smile.

I don't recall the second tune, and I have played machines that say, "How high can you try?"

[+Gemintronic]

Only a small update this time. There's not much to see, it mostly fixes some loose ends:

• Fixed scan line count fluctuation at the end of stage 4.
  
• Bonus is now correctly added after Kong stops rolling his eyes.
  
• Made the Kong ending animation a bit more accurate. Can you spot what is different to the last version?
  
• And there's now not one but two ending tunes (thanks Perry!)
  

 

This conversion is mind-boggling. Minimal flicker too. My only concern is Maryo is dim. All the other objects seem bright and solid. Would making is colors brighter be okay? Or, would doing so emphasize his flicker more?

[Joe Musashi]

Heard both ending tunes. Good work! Made me smile.

I don't recall the second tune, and I have played machines that say, "How high can you try?"

 

Thanks! When you activate cheats in MAME you can access a sound menu and easily listen to all the sound effects. There should even be some hidden tunes, but I don't know how to play them.

[Joe Musashi]

This conversion is mind-boggling. Minimal flicker too. My only concern is Maryo is dim. All the other objects seem bright and solid. Would making is colors brighter be okay? Or, would doing so emphasize his flicker more?

 

That's true. Particularly the blue color is hard to see. Right now the colors are automatically generated by directly matching TIA colors with the MAME output. Flicker is not considered here and that's why they appear only half as bright.

 

It might make sense to make them one or two degrees brighter. The problem is not only that this may cause stronger flickering, but also that TIA colors become less saturated when they get brighter. But I have yet to try.

[LS_Dracon]

Good work as aways Musashi!

 

Probably soon we'll have a potential Donkey Kong kill screen if anyone wanna watch!

[Andromeda Stardust]

Lookin' good! Now, off to load this file on Harmony...

 

Hmmm, interesting... The victory music is different from the NES version. Is that also the way it is in the arcade?

 

Victory music in the NES version (skip to 1:18):

http://www.youtube.com/watch?v=IYrGQ0Nr7oU

 

And in the Arcade version (skip to 3:31):

http://www.youtube.com/watch?v=yMijdY4N2LI

 

Music is not the same! I learn something new every day...

 

Joe, if you can get the enemies/physics right, this will be inline for an even closer to the arcade experience than the DK_Complete Edition leaked by Nintendo a couple years back. All of the animations are perfect!!!

Edited February 27, 2013 by stardust4ever

[BigO]

I'm not a fan of DK in general but was curious about how this looked. So, I downloaded the binary to my SD card. Plugged it into my Harmony cart. Tuned my TV to channel 3. Turned on my heavy 6'er. Selected the game from the Harmony menu. Started the game. As I watched it on my screen with the woodgrained hardware at my feet, my gut reaction was still, "That's fake, that's not a 2600 game".

[Andromeda Stardust]

I'm not a fan of DK in general but was curious about how this looked. So, I downloaded the binary to my SD card. Plugged it into my Harmony cart. Tuned my TV to channel 3. Turned on my heavy 6'er. Selected the game from the Harmony menu. Started the game. As I watched it on my screen with the woodgrained hardware at my feet, my gut reaction was still, "That's fake, that's not a 2600 game".

30 years later and we still haven't tapped the VCS's full potential! Next thing you know, someone will design a game that uses the ARM on a modified harmony board to completely bypass the 6507 by stuffing graphics and sound directly into the TIA, and play back full motion 160x192x60Hz video frames on the Atari 2600. Give 'em another ten years and prepare to have your mind blown all over again...