Jungle Adventure (Was: My next project, Pitfall type game DPC+)

[+Atarius Maximus]

I've been playing around with the DPC+ kernel for weeks now and would like to use it for my next project. I usually start my projects with a basic game engine and then see if I can come up with a good game concept around it, which is what this is. I have a hard drive full of abadoned projects just like this one that just didn't work out. This demo works perfectly in Stella but loads with a blank black screen on a Harmony cart on real hardware, and I was hoping someone more knowledgable than me might be able to figure out why.

This game is a platformer and there are 15 screens that you can freely roam left to right. My idea was to have random treasures, enemies and ladders on each screen, and all the rooms would connect in a large maze-like world. I don't have any other ideas past that, this is just a proof of concept at this point and the sprites are just placeholders. The ladders probably won't work correctly on any of the screens beyond the initial screen, I haven't gotten that far yet. I've really only worked on the first screen. I'd just like help figuring out why it doesn't seem to work on the Harmony.

Thanks,

Steve

EDIT: The latest version is titled "jadv" (August 2013) and it will run on the Harmony.

game1.bin

game1.txt

game12.bin

game16.bin

jadv.bin

[iesposta]

There is no such thing as "bank 7." Remove that.

Using " return thisbank" will save hundreds of bytes.

 

Just 2 quick tips. Haven't even played it yet or tried on real hardware.

[Cybearg]

If you make the character attack with poisonous farts, you could call it "Poots and Ladders"

[+Gemintronic]

If you make the character attack with poisonous farts, you could call it "Poots and Ladders"

 

I think you need to go back to sleep, man. 4am is no time to try to provide relevent advice R.T. handles the scat related comments here.

[+Atarius Maximus]

If you make the character attack with poisonous farts, you could call it "Poots and Ladders"

[+Atarius Maximus]

There is no such thing as "bank 7." Remove that.

Using " return thisbank" will save hundreds of bytes.

Just 2 quick tips. Haven't even played it yet or tried on real hardware.

Thanks, I forgot about that. I removed 'bank 7'. I'll also make sure and update return calls as needed.

[+Atarius Maximus]

I haven't checked it on real hardware again, but I made a few changes this morning. You can now navigate everywhere on the map and all of the ladders work. I'm assuming the Harmony compatibility problem is just a simple mistake on my part. Now it's time to think about how to make this into an actual game.

game3.bin

game3.txt

[+Atarius Maximus]

I noticed that the player would occassionally get stuck on a ladder. This revision fixes that. I'll probably hold off on posting another revision until I've fleshed this out a bit more as an actual game.

game5.bin

game5.txt

[+Gemintronic]

I noticed that the player would occassionally get stuck on a ladder. This revision fixes that. I'll probably hold off on posting another revision until I've fleshed this out a bit more as an actual game.

 

What's to figure out? This is obviously the game between Pitfall 2 and Super Pitfall

[+Atarius Maximus]

What's to figure out? This is obviously the game between Pitfall 2 and Super Pitfall

Ha. Yeah, this concept seems to be leading to a Pitfall-type sequel. With that in mind, I changed the graphics to more resemble Pitfall. No other changes, I was just playing around with background graphics and colors. It still doesn't work on the harmony and I haven't figured out why yet.

game6.bin

[iesposta]

You have a "return otherbank" when you are only in bank2, should be "return thisbank" and all "return" should be "return thisbank"

If that still doesn't make it run on the Harmony, put "DF0FRACINC = " etc. right before "drawscreen" It is in a gosub.

[iesposta]

You get 216 bytes back changing return to "return thisbank"

At the top, after the rem statements, put (starting each line with a space):

bank 1

temp1=temp1

 

set tv ntsc

set kernel DPC+

set smartbranching on

set optimization inlinerand

set kernel_options collision(playfield,player1)

goto Start bank2

 

My compile now shows bytes left. 391 left in bank 2. With return thisbank 607 bytes left.

283 bytes left in graphics bank. This is my problem with Donkey Kong. Lots of playfield data.

If I or cybearg or anyone could figure out how to use pointers we could PUSH data statements right to the playfield using rom banks for data and getting back graphics bank space.

[iesposta]

I never set playerXheight. Is this needed?

rem it out saves 40 bytes.

It gets into the asm file without setting it. Maybe it is useful if you wanted a height larger or smaller than its data? IDK

 

You have (had) players 1, 2 & 3 as a ladder.

You can define them all once, (but colors still need player1color: player2color: player3color:)

Player1-3:

%10000001

%10000001

%11111111

etc.

end

 

I have lots of programming tips, I just wish I could get a whole game made

[iesposta]

Another tip:

You can define global variables in bank 1. I usually set some, and the score color pretty much fills it.

See the bottom of the pic - you have 93 bytes.

They use up fast with just a few variables and sometimes it may stop reporting bytes left, but it is a little space you can use.

[Byte Knight]

Gotta love a Pitfall-style game! I think I recognize the player.

 

Quick question - how did you make the playfield extend to the horizontal edges of the screen? Is this a feature of 1.1d?

[+Atarius Maximus]

Another tip:

You can define global variables in bank 1. I usually set some, and the score color pretty much fills it.

See the bottom of the pic - you have 93 bytes.

They use up fast with just a few variables and sometimes it may stop reporting bytes left, but it is a little space you can use.

Thank you for all the useful tips, iesposta! I will definitely review everything you've mentioned and make some changes.

 

Gotta love a Pitfall-style game! I think I recognize the player.

Quick question - how did you make the playfield extend to the horizontal edges of the screen? Is this a feature of 1.1d?

I was being lazy using the cave in character sprite. I didn't want to take the time to create a new animated sprite with this demo, I was intending on changing it. The platforms stretch out to the sides of the screen using background colors, it's not actually using the playfield. I like the effect of it looking like a stretched screen.

[bogax]

I know nothing of DPC+

 

Are you trying to minimize code size?

I just assumed you weren't worried about it for a demo.

Theres several places you could squeeze out a few bytes.

 

one bit of code puzzles me.

 

 if collision(player0,playfield) then skip_ud
 if collision(player0,playfield) && player0y=71 then player0y=player0y+1
 if collision(player0,playfield) && player0y=111 then player0y=player0y+1
 if collision(player0,playfield) && player0y=151 then player0y=player0y+1
 if !collision(player0,player1) then skip_ud
dontskip
 p0_y = 0
 if joy0up then p0_y = 255
 if joy0down then p0_y = 1
 player0y = player0y + p0_y
skip_ud

 

The first if statement means the next three will

never be true.

 

 

Your playfields are so simple I think you could

draw them with lines and save some bytes.

It would be a lot slower I'd guess.

[+Atarius Maximus]

I know nothing of DPC+

 

Are you trying to minimize code size?

I just assumed you weren't worried about it for a demo.

Theres several places you could squeeze out a few bytes.

 

one bit of code puzzles me.

 

if collision(player0,playfield) then skip_ud
if collision(player0,playfield) && player0y=71 then player0y=player0y+1
if collision(player0,playfield) && player0y=111 then player0y=player0y+1
if collision(player0,playfield) && player0y=151 then player0y=player0y+1
if !collision(player0,player1) then skip_ud
dontskip
p0_y = 0
if joy0up then p0_y = 255
if joy0down then p0_y = 1
player0y = player0y + p0_y
skip_ud

 

The first if statement means the next three will

never be true.

 

 

Your playfields are so simple I think you could

draw them with lines and save some bytes.

It would be a lot slower I'd guess.

It is just a demo, and you are right about that section of code. I tend to try something out and then never clean up, what you pointed out does seem to be redundant. There are many optimizations that could be made. As the code is written now, the different playfields are necessary for going up and down the ladders & vines. There is an "invisible" hole where you go up and down, you can't see it because the background color hides the hole in the playfield.

[+Atarius Maximus]

There is a bug in the latest posted bin (that changed the colors), you may get stuck on a ladder on the top platform. There's definitely a whole lot of code optimization and changes that need to be made. This demo is a long way from being a playable game.

[iesposta]

With my above changes, it runs on my Harmony.

The player man stops and starts moving left or right what seems like every third animation. In Stella it is just a slight pause.

When you say it doesn't run on Harmony, do you mean not at all?

[+stephena]

With my above changes, it runs on my Harmony.

The player man stops and starts moving left or right what seems like every third animation. In Stella it is just a slight pause.

When you say it doesn't run on Harmony, do you mean not at all?

 

Just a reminder that the DPC+ support in Stella isn't quite the same as on the Harmony. In particular, if you have a section of ARM code that would run past the allowable time on the Harmony, it would probably result in a corrupted image, slowdowns, or some other related issue. But in Stella, it would probably look fine, or just be a slight pause (like you're seeing). This is because Stella doesn't (yet) have any concept of how long the ARM code takes to run WRT the 6507, and essentially always runs in zero CPU elapsed time. This is on the TODO list to fix, and is something to always be aware of when developing DPC+ games.

[+Atarius Maximus]

With my above changes, it runs on my Harmony.

The player man stops and starts moving left or right what seems like every third animation. In Stella it is just a slight pause.

When you say it doesn't run on Harmony, do you mean not at all?

Yes, I meant not at all. It rolls the screen for a second or two and then displays a blank black image. I'm glad your changes at least allow it to show up on the screen on real hardware.

[+Atarius Maximus]

Just a reminder that the DPC+ support in Stella isn't quite the same as on the Harmony. In particular, if you have a section of ARM code that would run past the allowable time on the Harmony, it would probably result in a corrupted image, slowdowns, or some other related issue. But in Stella, it would probably look fine, or just be a slight pause (like you're seeing). This is because Stella doesn't (yet) have any concept of how long the ARM code takes to run WRT the 6507, and essentially always runs in zero CPU elapsed time. This is on the TODO list to fix, and is something to always be aware of when developing DPC+ games.

Thank you for explaining that, Stephen. One of my demos from a few weeks ago in the "Getting started with DPC" thread works initially but after playing for a short while goes to a blank black screen also on the Harmony. I'm sure you have a very long to-do list, and I'm very much looking forward to your distella integration.

[Byte Knight]

The platforms stretch out to the sides of the screen using background colors, it's not actually using the playfield. I like the effect of it looking like a stretched screen.

 

Ahhhh - sneaky!

[+Atarius Maximus]

With my above changes, it runs on my Harmony.

The player man stops and starts moving left or right what seems like every third animation. In Stella it is just a slight pause.

When you say it doesn't run on Harmony, do you mean not at all?

Could you post your modified source that works on the Harmony? I implemented your suggested changes and I'm still having trouble. I'd like to compare what you did to what I did. I made a few more minor changes. Some animation & the pitfall scorpion were added, a few bug fixes, and I moved the specific room changes to individual subroutines. There's no way everything would ultimately fit in bank 2. The score also displays which room number you are in (0-15), that makes it a bit easier for development.

game9.txt

game9.bin