The Deep

[+KaeruYojimbo]

Several hombrews using DCP+ have been released on cart. I believe it requires the Melody Board. Try asking Albert about it.

[iesposta]

Albert can put your DPC+ Kernel game on a cart for you using a Melody board.

Maybe you can get a small amount made if you can afford it.

 

As for getting it selling in the store, AtariAge decides how to use the Melody boards it has and what completed games get into the store next.

 

I'm just guessing here as I haven't talked about getting my bB DPC+ Kernel game in the store yet, although it can be called 99.8% finished since November 2014. December 2011 to November 2014. Three years on and off.

 

Also the weirdness with player1 I've encountered also. Both in regular bB Multisprite and DPC+ Kernel.

To specify the virtual one, you use _player1 (underscore player1), and you've seen just plain player1 will register every virtual player.

We used both in DK Arcade 2600. Sometimes collisions with any virtual player is needed so we use player1. Sometimes we check for just a collision with virtual player and we use: _player1

 

I still don't understand collisions enough to help. I just keep trying things until I get the desired outcome.

In my FLAPPY, I had trouble with the bird (player3 & player4) hitting the pipe (player0), so I hid a missile inside the bird, which has the happy accident of allowing grazing the pipe above or below and not death (or "not pixel perfect" collisions). The missile floating inside the bird has to collide with player0 for "death".

[Mountain King]

I don't know if you guys have seen this thread.

 

http://atariage.com/forums/topic/236921-dpc-collision-example-program/

 

But I've implemented this routine in my game and it works quite well.

Basically what it does is compares the x and y value of player0 and compares it to the x and y value of the other objects. Whichever is closest jumps.

 

I also did the same thing as iesposta where I used the ball and superimposed a player sprite.

Edited April 23, 2015 by Mountain King

[killad517]

What a great game, my top score is 8400.

[winkdot]

What a great game, my top score is 8400.

Thanks Killad517. You are likely the The Universal champ! A true Deep Head

[winkdot]

I don't know if you guys have seen this thread.

 

http://atariage.com/forums/topic/236921-dpc-collision-example-program/

 

But I've implemented this routine in my game and it works quite well.

Basically what it does is compares the x and y value of player0 and compares it to the x and y value of the other objects. Whichever is closest jumps.

 

I also did the same thing as iesposta where I used the ball and superimposed a player sprite.

 

Thanks Mountain King. I need to give this a closer look.

[graywest]

I think I am my own worst enemy in this game. I am always trying to take too many risks and shoot all the enemies and I just end up getting myself killed. :-) I'm enjoying this a lot though!

[winkdot]

I think I am my own worst enemy in this game. I am always trying to take too many risks and shoot all the enemies and I just end up getting myself killed. :-) I'm enjoying this a lot though!

I do the same thing Graywest Super glad you are enjoying it.

[winkdot]

Hey folks I got a review of The Deep. I had no idea this was out there as I guess they don't notify the anyone.

Anyway, nice little review.

 

http://www.8-bitcentral.com/reviews/2600theDeep.html

[Mountain King]

Sweet! Nice review.

[winkdot]

Let's play video of The Deep on youtube.

 

[+SpiceWare]

FYI - The Deep has the same DPC+ jitter problem you had with Doom Patrol. Need to add the inits for DFxFRACINC.

 

Scanline count is also wrong when playing, it's 269 instead of 262:

 

The title screen has 262:

 

Speaking of which - here's a couple of changes that need to be done to both games.

• SELECT GAME - should abort current game and take you back to the title screen
• GAME RESET - should start a new game, even if you're already playing a game

It's OK to leave the support in for fire to start a new game from the title screen.

 

[winkdot]

FYI - The Deep has the same DPC+ jitter problem you had with Doom Patrol. Need to add the inits for DFxFRACINC.

 

Scanline count is also wrong when playing, it's 269 instead of 262:

Screen Shot 2015-08-14 at 12.34.47 PM.png

 

The title screen has 262:

Screen Shot 2015-08-14 at 12.34.38 PM.png

 

Speaking of which - here's a couple of changes that need to be done to both games.

• SELECT GAME - should abort current game and take you back to the title screen
• GAME RESET - should start a new game, even if you're already playing a game

It's OK to leave the support in for fire to start a new game from the title screen.

 

Thanks. Already realized this. Working on them one at a time

[winkdot]

Second Lets Play video on The Deep. He gets to the boat this time

 

[winkdot]

The Deep 0.3 released (see first post).

 

This is a code optimization release. If you are using a harmony cart, this might be the one for you.

 

As always, let me know if you see problems.

[+SpiceWare]

DPC+ jitter is gone.

 

Jitter during screen transitions.

 

Jitter when shooting when there's 4 enemy on screen. Once you've shot one (so there's 3 or fewer remaining) the jitter when shooting problem clears up.

[winkdot]

Thanks for trying it and the feedback SpiceWare.

 

On the screen transitions I've tried lots of stuff, none make much of a difference. My hope is the jitter there is just not very distracting.

 

The 4 enemy issue I have optimized a bunch, but apparently not quite enough. I pulled out some sprite animation also. My other choice would be to pull out a bad guy which I really hate to do.

 

Guess I'm going to have to purchase a Harmony cart at some point or wait until your code changes are in Stella. On the plus side, it plays wonderful on a Nvidia Shield TV

[RevEng]

[...]On the screen transitions I've tried lots of stuff, none make much of a difference. My hope is the jitter there is just not very distracting.

Have you tried throwing in some extra "drawscreen" commands, to break up the screen transition logic between frames? The player won't really notice if the transition takes 2 or 3 frames instead of 1, but they may notice jitter.

 

Just be sure to set the DFxFRACINC values prior to calling drawscreen.

 

[edit]

 

Also on the 4 enemy jitter... if you aren't already, try running the logic for 2 enemies on even frames, and the other 2 enemies on odd frames. Similarly, you can split other game logic this way too.

[winkdot]

Have you tried throwing in some extra "drawscreen" commands, to break up the screen transition logic between frames? The player won't really notice if the transition takes 2 or 3 frames instead of 1, but they may notice jitter.

 

Just be sure to set the DFxFRACINC values prior to calling drawscreen.

 

[edit]

 

Also on the 4 enemy jitter... if you aren't already, try running the logic for 2 enemies on even frames, and the other 2 enemies on odd frames. Similarly, you can split other game logic this way too.

Nope I haven't tried that. I've been trying to eliminate cycles instead, but will give it a shot. Thanks!

[+SpiceWare]

Nope I haven't tried that. I've been trying to eliminate cycles instead, but will give it a shot. Thanks!

Don't forget - the best way to get help with things like optimization is to post your source. Doesn't matter if the code's not pretty.

[winkdot]

The Deep 0.4 release (see initial topic post).

 

Whew... I have tested, moved, squeezed, danced (no I didn't dance), but this one does not exceed 262 scan lines.

I did get to memorize the breakif command, and play the game no telling how many times. I also got to learn a couple of things and found a bug.

 

Is there a list of what statements cost in terms of cycles?

If you have a harmony, give it a spin. There should be zero jitter.

[RevEng]

Glad you stuck with the cycle battle, and won.

 

There's isn't a comprehensive list of cycles used by commands anywhere that I'm aware of. I reported some basic ones and provided a non-assembly way to measure cycles in this thread

 

[edit] also, if you search "cycles" at RT's bB commands page you'll find some commands have the cycle usage mentioned.

[iesposta]

Any PF commands take a lot of both rom space and cycles.

PFPIXEL

PFLINE

 

To cut rom space, if they are called different times have them in a subroutine.

To cut cycle space don't use a lot of them or have more calls to drawscreen

[+SpiceWare]

Nice to see the beginnings of SELECT/RESET support.

 

It will occasional jitter at the start of a round, when you hit FIRE to come off the "launcher" arm, though it looks like it's just the playfield not the screen. Saw this on both real hardware and my Jitter build of Stella. As such, I suspect missing DFxFRACINC inits somewhere.

Other than that, much better

[winkdot]

Any PF commands take a lot of both rom space and cycles.

PFPIXEL

PFLINE

 

To cut rom space, if they are called different times have them in a subroutine.

To cut cycle space don't use a lot of them or have more calls to drawscreen

Yes, I've noticed those commands are hogs. Don't understand why they consume so much space. They are not used in this game.

 

Also after reviewing RevEng cycle post above. I'm getting killed on banked gosubs, which I changed wherever I could in this game.