DK Arcade 2600. New 4-Level Demo!

[iesposta]

March 19, 2019 news.

Release Candidate 1

DK_Arcade_2600_RC1.bin

 

I've decided to share "DK Arcade 2600" and post the Release Candidate.

This has sound, item, color differences, along with a fixed Kernel that should eliminate any "flashing ghost playfield pixels" that appear when nearly cycle maximum and that some machines were displaying.

The "latest batari Basic" version from RevEng's thread has this fixed kernel.

 

Reply in this thread any comments and suggestions - they are all considered, no matter good or bad, or not possible to include! Thank you.

 

It is also decided by me, the author, that any "Release" will be through this "batari Basic Forum Thread".

If you expressed desire for a real cartridge in this thread, no need to post again. You will be contacted when I have finished cartridges available later in 2019 or next year 2020. Payment will only be taken when finish cartridges are available - made with AtariAge hardware.

 

This was my first designed game, both because I liked the game, I liked the challenge, and I wanted to show that very good games can be made with the "batari Basic" DPC+ kernel.

 

- iesposta

 

-----------------------------------------------------------------------------------------------------------

 

October 12, 2014
Two Demo binaries!
You can now play as "The Lady" (created for the 2 women on AtariAge!).
By popular demand, "The Carpenter" moves quicker up and down ladders.
Fireballs descend ladders quicker.
Alarm sound when timer falls below 1000.
Numerous sound updates and bug fixes.
Japanese order only (Levels 1, 2, 3 & 4) that end after Level 4.
The title is a selection screen: Up, down, left or right selections. (Note: American selection defaults to Japanese order for these demos.)

Remember to turn Phosphor Effect (Ctrl-p) on in Stella!

DemoE = easy. As will be the first time though the levels.
DemoH = hard. As will be the increased difficulty the next time through the levels.
DK20141011BcDemoE.bin
DK20141011BcDemoH.bin


October 11, 2014
Second Demo Binary(s) soon!
We have listened to comments and suggestions. I think everything done since the last demo has been an improvement in every area. Gameplay, graphics, sound and music, and options.

List of "bugs" that probably are permanent "features":
- Some odd TIA chips cause a few playfield pixels to blink. Does not affect gameplay.
- Cement Factory level with hammer will show ghost garbage pixels when fireballs climb down due to Intelligent Flicker and virtual sprite vertical alignment. Does not affect gameplay.
- Jumping to the left-most part of the center elevator (descending) player becomes unresponsive to joystick. Affects gameplay.
-Jumping a fireball over a rivet can trap the fireball over the gap. One I had trapped later climbed thin air to the level above and started acting normally - except it was a few pixels below the girder.

September 27, 2014
No binary, but we are still working on this!
Latest binary directly below, in March 1.

rem Note: 9-02-14 Made ditty1 note duration shorter, Opening longer, How High tune ends with harmony.
rem Note: 9-09-14. Started adding Pauline Edition.
rem Note: 9-20-14. Moved pies down in three! different locations.
rem Note: 9-21-14. Fixed 'static' in ditty sounds. Added Pauline climb head wiggle. Fixed broke items grab sounds on elevators.
rem Note: 9-22-14 Fixed "Death scene gone bad Elevator Level". Fixed winning Elevator w/Mario and having Pauline appear below.
rem Note: 9-22-14 New PreTitle Screen layout. Removed a redundant ballheight=0.
rem Note: 9-23-14 Needed to add Pauline Colors in skipmario2. PreTitle Screen has left / right joystick player selection.
rem Note: 9-27-14 Difficulty increases by Byte Knight! New Pretitle Screen removed. Added Harmony to Opening Tune.
rem Switched L/R selection and icon. Screen order progression fixed. Sped up prize sound. Fireballs descend faster.
rem set optimization noinlinedata works.

March 1, 2014
DK23Arcade2600.bin
Bug fixes for the demo:
Ramp Level
Mario shouldn't get stuck in girders any more.
Overlapping barrels shouldn't sneak through the hammer any more.
Increased barrel spawn timer to make the level a little easier.
Moved hammer up and right on top level so you can't grab it from the level below and you can jump straight up and get it.
Fixed Mario jumping bug that would kill Mario after 5 jumps in a row.
Cement Pie Level
Kong has less separation anxiety!
Fixed ghosting of the tops of fireballs.
Elevator Level
Mario won't "fall" through girders on Elevator Level.

February 19, 2014
There's a new DK in town called DK Arcade 2600, joining AtariAge member Joe Musashi's phenomenal D.K. VCS!
This playable demo features all 4 levels in full-screen goodness, so check it out!
Brought to AtariAge by members "Byte Knight" and myself, "iesposta."
Binary: DK_Arcade_2600.bin



The playable demo features all four levels but will end after the rivet level (Level 4).

Let us know your thoughts and post your high scores!

The release version will feature:
Japanese and US level order.
Difficulty level increases.
The ability to play Mario or Pauline.

Thanks to RevEng and Bogax for technical help, and Atari Brian for beta-testing.

February 12, 2014
Update.
- Dynamic titlescreen has 1 to 4 Stupid Monkeys on How High Can You Try? depending on level.
- Bonus/Countdown timer has color. Score is 6 digits and white.
- Spinning death sound created.
- Japanese and American order selection (difficulty switch).
- Flicker reduced on top of level 1 by adding 2 playfield screen lines and removing 1 line from The Lady, putting her 7 lines above the barrels. Notice I said reduced. It still flickers a lot but that is where everything happens at once.
- Going "over cycles" fixed by adjusting Overscan time, adding scanlines. Currently stable at 270 lines.
- Custom Score Font. (I know it looks like other games, but I did create each number to match the arcade game.)

February 5, 2014
Let it spin, let it spin, let it spin.
No game, just spinning...
DK21y140201bSpin.bas 2.bin

January 19, 2014
This binary plays levels 1, 2, 4 and then properly goes back to level 1.
DK21y140119f.bas.bin

January 15, 2014.
!! Level 2 pie/cement factory done!!
Binary 1-15-2014: DK21yMKH14cr.bas.bin
>>Positive or Negative Feedback appreciated, especially on real hardware during gameplay (rolling or jittering). Note: It does jitter before Level 4.

JumpmanBLU20130826.bas.bin

JumpmanBLU20130826.bas

JumpmanBLU20130915a.bas.bin

JumpmanBLU20130915a.bas

JumpmanBLU20130919a.bas.bin

DK26b.bas.bin

DK2600-2013-12-23.bas.bin

DK2600-2013-12-25.bas.bin

[iesposta]

Nobody wants to help?

Guess everybody is waiting on Joe Musashi's D.K.VCS, I know I am!

Pacman4K can do all those checks for maze locations, such as can I go up, down, left, or right at this location.

This DK Level 4 is much simpler. Left/Right = always so no checks for that.

Only 5 platforms need checking for ladders up or down.

Bottom Platform 0 has 3 locations that a check would return up.

Platform 1 has 7 locations that a check would return up ok or down ok.

Platform 2 has 7 locations up or down

Platform 3 has 7 locations up or down

Platform 4 has 4 locations where down is ok.

 

So I thought the simplest way to check if there is a ladder to go up is player0 collides with Playfield, you are at a ladder.

At a ladder there is a large horiz range where collision is on.

The Center of the first ladder is horiz 18, so if the player is at 17 or 19, make it 18 and then a climb routine.

[+Random Terrain]

Nobody wants to help?

 

I suck at programming and I'm still working on the DPC+ section of the bB page, so I haven't even looked at your code yet.

[RevEng]

Sorry man. I've been meaning to, but just been too busy lately.

[iesposta]

Thanks for the replies.

Bogax did help rewrite my if-thens into loops and data, but since my if-thens were buggy, well it hasn't gone too well.

I still think I'm trying too much complexity at once.

I am going back and start really simple.

[Byte Knight]

I'd love to see this project complete!

 

I haven't looked at the code, but how about if you have Jumpman walk just above the floor (which it looks like in the screenshot) so there's no collision with the playfield, and then allow for vertical movement (climbing) when there's a collision with the playfield (ladder)? The only trouble would be with going down a ladder from the floor above, but maybe you could put the top of the ladder just above the floor and color it black. That way there would still be a collision when you run over the top of the ladder. Anyway, just a thought...

 

The only other way I could think of doing it would be large data tables for each direction of the joystick.

Edited September 1, 2013 by Byte Knight

[iesposta]

I finally made progress!

Well, just a little.

You can now climb up and down and all over the "structure."

Byte Knight, I did use invisible playfield pixels. I actually had started exactly that -- invisible PF pixels, (you'll just have to take my word for it).

Bogax, your code worked when I added an additional temp to get the newx value, and then set xp. I don't know why it fails without this?

 checkladder  if !collision(playfield,player0) then return thisbank ; Not touching ladder, fuggetaboutit   rem Climbing and X adjusting code. Thanks to bogax! for u = 0 to 3 temp3 = yp - ydat[u] if temp3 >= 35 then nxty temp1 = u * 4 : temp2 = temp1 + 3 for f = temp1 to temp2  if !xdat[f] then nxty  temp5 = xp temp3 = xp - xdat[f]  if temp3 < 5 then temp5 = newx[f]: xp = temp5: gosub Climb4 nextnxty next  data ydat 122, 87, 52, 17end  data xdat 16, 68, 120, 0 20, 48, 88, 116 24, 68, 112, 0 28, 40, 96, 108end  data newx 18, 70, 122, 0,  22, 50, 90, 118,  26, 70, 114, 0,  30, 42, 98, 110end   if joy0down && yp=16 then goto Climb4  if joy0down && yp=51 then goto Climb4  if joy0down && yp=86 then goto Climb4  if joy0down && yp=121 then goto Climb4

Added a kludge because climbing down goes 1 pixel too far.

Don't know if there is a better way to do this?

 

  if yp = 122 && joy0left then yp = 121  if yp = 122 && joy0right then yp = 121  if yp = 87 && joy0left then yp = 86  if yp = 87 && joy0right then yp = 86  if yp = 52 && joy0left then yp = 51  if yp = 52 && joy0right then yp = 51

I should figure how to stop Left and Right when climbing.

Not much to see, but here are the lastest files:

 

JumpmanBLU20130902.bas.bin

JumpmanBLU20130902.bas

[bogax]

I wonder if the version of bB that you're using deals with

8.8 variables differently than the one I'm using.

(I can't get your code to compile it doesn't recognize player8)

 

Do you have the bB.asm file to post?

 

 

Did you try setting a (the integer part of xp) instead of xp

 

 a = newx[f] : b = 0

Edited September 3, 2013 by bogax

[iesposta]

Can't you just ignore the "player8", I have to click "Yes" to continue with compile.

You have to have DPC+ RevEng 14 or 15 latest version.

 

http://atariage.com/forums/topic/214909-bb-with-native-64k-cart-support-11dreveng/

 

He added single data range for color function. Example: player8-9color:

Any virtual player1 thru virtual player9 range, for data and color. Only need to be defined once.

(and a bunch of fixes!!!)

bB.asm

 

 

Did you try setting a (the integer part of xp) instead of xp

a = newx[f] : b = 0

That just might work too!

[iesposta]

You saved me 8 bytes!

This worked:

 

if temp3 < 5 then a = newx[f]: gosub Climb4

Do you know any playfield compression / expansion code?

I am storing some (most) playfields in rom banks. They only need to be decoded and pfpixel on/off once at the beginning of the bank so it doesn't have to be fast, and is done before the screen is drawn.

[bogax]

As to your climbing too far problem

I assume you're on platforms at some discrete
level(s) so one platform is at 1 and the next is at
say 4 and you allow climbing at 1,2,3 and 4 so if
you're on the upper platform at 4 you can climb up
(too far) to 5 and if you're on the lower platform
you're at 1 and you can climb down (too far) to 0 ?

If that's the case then perhaps you could add a bias
depending on which way you're climbing

So assuming the numbers work for up (you allow climbing
if you're at 1,2, or 3) you could maybe do something
like this to fix down

 for u = 0 to 3
 temp3 = yp - ydat[u]
 if joy0down then temp3 = temp3 - 1
 if temp3 >= 35 then nxty

edit: rats! got my directions mixxed up you need

 

if joy0down then temp3 = temp3 + 1

Edited September 3, 2013 by bogax

[bogax]

I got it to compile.

 

Apparently there's a bug in bB

it doesn't use indexing when

setting xp so it always gets set

to the first byte in the newx table.

Edited September 3, 2013 by bogax

[bogax]

I rearranged your code a little bit.

I added the bias to fix down.

I moved Climb4 to with in branching distance
and set the code to exit the loop when it finds
a collision.

 

I moved the tables out of the code path.

You need a flag or something to indicate when
you're on a platform so you can't move right
or left while on a ladder between platforms.

JumpmanBLU20130902_2.bas

Edited September 3, 2013 by bogax

[iesposta]

Working great! Thanks again.

I had tried adjusting the y value, +1, -1, all over the place, but never found where it would work, it would always break going down. You found a great, easy way.

Rearranging the code and removing the y position kludge saved over 100 bytes.

Got the sound changed when climbing like the original.

 

JumpmanBLU20130903c.bas.bin

[bogax]

I moved the data out of the way on general principles

but I didn't include the noinlinedata optimization

If you don't have any in line data that option should

save a few bytes.

 

I moved Climb4 as close to the loop as possible and

moved the data away from the loop where it's used

but the data is probably short enough (for now) to

branch over if you wanted it closer to the loop between

Climb4 and the loop

(if Climb4 is not close enough to branch to bB will

essentially insert a goto which costs 3 bytes)

Edited September 3, 2013 by bogax

[iesposta]

What is "inline data"?

Isn't "inline data" the playfield, the climb tables and the music??

[bogax]

What is "inline data"?

Isn't "inline data" the playfield, the climb tables and the music??

 

Basically any data statement.

bB inserts the equivalent of a goto (a jmp instruction)

to jump around each data statement so you don't try

to execute the data as instructions.

So for the three tables of the collision code there's

three hidden gotos (even though one would do)

each jmp/goto takes 3 bytes

if you move the data statements to where the code won't

run in to them say after a goto or a return you don't

need to jump around them.

The noinlinedata optimization will make bB leave out

the extra (hidden) "gotos"

 

Even if you don't move the data out of the way

you can use the no inlinedata optimization and put in

your own goto to jump around eg the four playfield

data statements and save 3 "gotos" (9 bytes)

Edited September 3, 2013 by bogax

[iesposta]

Updated Source and Binary files in first post.

I got Jumping started today!

Also blocked moving left or right while climbing, and the climbing sound is slower than the walking.

So some small gains for the game, but big gains for me in programming.

The latest file uses a routine to draw the playfield from data statements.

The data statements are "compressed" by removing the duplicate rows and using another data table to tell where they are to be drawn.

[iesposta]

Really starting to look and play like the Arcade.

Go check out the binary and source code in post #1!

[Byte Knight]

Boy, this is really taking shape! You probably already know this, but you can trigger the climbing sound by pushing up on the joystick anytime, even if you're not in contact with a ladder. If you keep the prizes in this level, won't you be limiting yourself to only 4 fireballs? The behavior of the fireballs will be difficult too - how are you planning to do that?

[iesposta]

Thanks.

I know about the sound.

After a prize is collected I could redefine its player to a fireball??

I don't know how much more I can add, without finding easier ways to do things (less cycles).

I had the code from RT's website to show 2 variables in the score and I noticed that jumping right or jumping left started to change the scanline count. That means I'm out of processing cycles, right?

I will probably have to rewrite it with 2 drawscreens. That slows everything in half, so I'll need to rework the sound and movement.

I thought this level would be simple. I thought wrong.

The Cement/Pie level is easiest.

Originally I set it up to have 2 drawscreens like I need in the Elevator level...

 

EDIT: I can't be out of cycles, I have 1K left ! (I know it doesn't work like that...)

[iesposta]

Sorry man. I've been meaning to, but just been too busy lately.

I just wanted you to note that I couldn't get pfread working. Tried for days. It would make things so much easier!

My numbers were right, and it sort of works, like if I were checking player0x converted to PF, say 3 and player0y converted to PF ( the bottom girder is at 171, I set it to make a sound, but when I move off the left, PFy 255, or off the right, PFy 29, 30, 31 & 32 are off, the sound continued.

I could make it sound at "Y" levels 171, 135, 100, 65 & 30 but moving off the left or right didn't end the sound.

The pfpixel always saw an "on" even when the pixel was off.

[RevEng]

Ok, it definitely works right for lower Y values, so probably I'm running into a negative number problem when it's higher than 127. Or maybe you're reading where PF0 would be?

 

I'll look into it. Thanks for bringing it to my attention.

[iesposta]

Got rivets working!

Playfield read works, so falling off the edge or where a rivet was leads to death, and reboot.

If you win, you float up, and it reboots.

Lives at bottom, countdown bar bonus timer at bottom right.

Also, it goes over cycles jumping, so real TV's will shudder.

Latest binary at top of Post 1.

Comments / suggestions always welcome!

[Andromeda Stardust]

Man, this is quite awesome... Two competing Donkey Kong games. Both different but both very good. I'm a big enough Donkey Kong fan that I may have to get both!