Ninja Wall Jump game - WIP

[+Philsan]

PAL50 and PAL60 versions work perfectly on real hardware.

[Thomas Jentzsch]

If you have ~150 bytes left, you could add SaveKey support for storing the highscores. But I suppose there is not enough free space, right?

 

BTW: Do you have compensated the PAL50 version for the slower speed?

[Brian O]

This game is great. Really happy you stuck with it.

[+Atarius Maximus]

Adding SaveKey support would be great, I tend to play games that support it much more than others. I know you mentioned that the "low hanging fruit" for space saving is gone, but if you could find the ~150 bytes that would be a really nice addition to the game. Simply having the high score on the title screen is a huge improvement either way, thanks for adding that!

[walaber]

If you have ~150 bytes left, you could add SaveKey support for storing the highscores. But I suppose there is not enough free space, right?

 

BTW: Do you have compensated the PAL50 version for the slower speed?

 

Another 150 bytes is going to be really tough. I'd probably have to rewrite several sections of the code.

 

I haven't compensated for the speed on PAL50 yet, although now that I think about it it should be pretty easy to adjust my movement tables to compensate. I'll make sure I put that in for the next build. It's surprising how different the game feels between 60fps and 50fps.

 

Thanks for the confirmation that the different versions are working properly on hardware! We're finishing up the label now, and I'm also working on an instruction sheet so we can get a cart put together soon.

[Thomas Jentzsch]

If you need help with optimizing your code for space, I am sure I can help you.

[ataridave]

Well I just played revision 4, and it's awesome! A LOT more fun then Flappy Bird, IMO! I would definitely buy this!

[DT Kofoed]

Nice addition with the "best" progress memory... can't wait to see what other fun you've got planned!

Edited January 2, 2015 by DT Kofoed

[walaber]

Alright, you all made it sound like 150 bytes must be hiding in there somewhere, so I've gone digging. I'm super close! After including the VOX read/write routines, here's where I'm at:

 

Also does anyone know a way to get DASM to print out the rom size even when you're NOT over the limit? the only way I've been able to gauge how I'm doing is to open the ROM in stella debugger and scroll to the bottom and count the zero bytes at the end.

 

A little more trimming and I should be able to add VOX scoring. I assume I need to email the address in the VOX documentation to get an official "slot" for storing my data? (4 bytes, 1 score per mode permutation is the plan)

 

for reference, a lot of the optimizations so far include removing redundant setting of variables, and switching code like this:

LDA INPT4 
AND #%10000000
BNE TitleButtonNotPressed

to this:

BIT INPT4
BMI TitleButtonNotPressed

Basically getting more familiar with the BIT command and changed all my input detection and collision detection routines. I also changed some redundant code into smaller loops, etc.

 

Next step is to look again and see if there are opportunities to scrunch the game data (sprites and colors) a bit more.

 

[walaber]

After adding proper support for different high scores per setting (total of 4), I'm down to only about ~128 bytes free... and I'm having trouble finding any more space to save. I have a feeling my sound routines are kinda wasteful and could be implemented more simply, but I'll have to think about how to do it.

 

If I ultimately can't fit the VOX+ routines in, I'll try to use the remaining space for some last flourish, like maybe an attract mode?!? not sure how I'd implement that in this game.

[Brian O]

After adding proper support for different high scores per setting (total of 4), I'm down to only about ~128 bytes free... and I'm having trouble finding any more space to save. I have a feeling my sound routines are kinda wasteful and could be implemented more simply, but I'll have to think about how to do it.

 

If I ultimately can't fit the VOX+ routines in, I'll try to use the remaining space for some last flourish, like maybe an attract mode?!? not sure how I'd implement that in this game.

 

Add an Easter egg

[Thomas Jentzsch]

Which i2c include file are you using? I have created one which is optimized for space. For counting free space, I suggest using macros e.g. for align and org.

 

Both can be found in my Three.s repository (see my blog).

Edited January 2, 2015 by Thomas Jentzsch

[Omegamatrix]

I'm sure you'll be able to find the space.

 

 

As for BIT it is often used just like you said (for testing bit6 and bit7). Another good use for BIT is to skip ahead 1 or 2 bytes in a spot where you would normally always branch or jump to. You can also use illegal NOP's that preserve all flags, but BIT is a good legal way to do it.

 

 

In some situations BIT absolute is also useful. Take a bit of code (not from your game):

    sbc    #9
    tax
    and    #$07
    bne    .goSomewhere
    txa
    lsr
    lsr
    ldx    #0

In the above code it looks like a good use of the X register, as it saves a couple of bytes over STA TEMP then LDA TEMP, or cycles over PHA then PLA.

 

However BIT absolute can be used and that will preserve the accumulator and save a byte. All you need to do is find a byte somewhere in your code that is equal to $07. Since it is absolute addressing it can be anywhere or anything (including instructions).

    sbc    #9
    BIT    BIT_TEST_07  ; this constant is the absolute address of some byte that is $07
    bne    .goSomewhere
    lsr
    lsr
    ldx    #0 

There, that's better because it preserves A, X, saves 1 byte, and takes few cycles.

 

 

 

Finally, looking forward to this game! I played it for a little while yesterday.

[Thomas Jentzsch]

I assume I need to email the address in the VOX documentation to get an official "slot" for storing my data? (4 bytes, 1 score per mode permutation is the plan)

Yes, that would be a good idea. I reused some free bytes from Boulder Dash for Three.s, but for your own game you better have your own slot.

 

Next step is to look again and see if there are opportunities to scrunch the game data (sprites and colors) a bit more.

Often you can save ROM by overlapping data. I have written a programming which does this automatically for you (DOOD). Again, check my AA blog.

[walaber]

I don't actually have all that much data, so I'm not sure overlapping it will do a whole lot. However I decided to reduce the resolution of the bands of color in the background of the game, which has bought back a lot of space, and I'm happy with how it looks:

 

 

Originally I had a unique color for each 2 scanlines, this was actually to save cycles in the kernel, but I found time to add a LSR in there so now the colors are 1 byte for 4 scanlines. A better tradeoff of space to visual style I think.

 

With the extra space I think I'll be able to support VOX saves and an attract mode. I came up with a few ways to make an attract mode, and I think it will be fun to implement.

Edited January 2, 2015 by walaber

[walaber]

Also CoreyremarK has been doing some awesome work on the label, here's a near-final mockup of what the cartridge will look like:

[Thomas Jentzsch]

For the bands of color, you could simply use random data from the ROM. Just like Yar's Revenge did.

[KevinMos3]

Awesome work so far and a huge thank you for your continued efforts to add features. I'm really looking forward to AtariVox support and the attract mode will be really cool.

 

I don't actually have all that much data, so I'm not sure overlapping it will do a whole lot. However I decided to reduce the resolution of the bands of color in the background of the game, which has bought back a lot of space, and I'm happy with how it looks...

 

Your new method looks like it has ground or a floor in the the background which got me thinking. It might be cool, if you have the space, to use different background colors after each completion of the word "NINJA." That might enhance the feeling of completing a level and starting a new one. Here's an example with a blue sky, green ground, and water at the bottom:

 

 

 

That label is looking really good. How would it look with a little lava or fire at the bottom where the pointer is located?

 

[walaber]

I really like the idea of the colors evolving as you progress, and initially I thought it might be impossible... but I realized if I can free up some RAM maybe I can do it.

 

quick question... does anyone know a cycle-efficient way to "clamp" a value?

 

say I have a value in the accumulator that is in the range 0-45 and I basically want to clamp it to the range 0-31. I can AND #%00011111, but that will "roll" the values > 31 back to lower numbers instead of clamping it.

 

any way to do this without branching, or in as few cycles as possible?

[Albert]

I really like the idea of the colors evolving as you progress, and initially I thought it might be impossible... but I realized if I can free up some RAM maybe I can do it.

I like this idea as well--definitely adds some visual variety to the game and serves as a good indicator of progress.

 

..Al

[walaber]

I got it working, and didn't even need all the extra ram I thought I needed in the first place!

 

Check it out. basically I can add new patterns for the low, low cost of 8 bytes each, so once the game is done I'll fill up the remaining space with as many as I can. and I have a special idea for what to do if you get far enough that I run out of palettes... and it's pretty cool I think, but I'll save that for release

 

 

Brief video of testing this:

https://vine.co/v/OdJbuwM93Ql

 

That being said, I currently have... 12 free bytes of ROM space, and 30 bytes of RAM. That is with the optimized i2c libraries, but no code to actually call them yet. so I'm going to have to find some more space still if I want VOX scoring and attract mode.

[LS_Dracon]

I don't know how you're doing this, but there's a old trick to use shades of gray as background color, and add a variable to it, in this case, you need only 1 byte of RAM to change all the color.

Something like this :

 

Lda BKColorGray,y ; fixed gray background, $00 to $0F

adc ColorVar ;starts with $10 or $20 or $30 etc...

sta COLUBK

 

Outside of the kernel you can set the "ColorVar" as $10 up to $F0.

 

Naturally as you need 2 main colors, one for top and other for the bottom, so you need 2 variables.

[walaber]

I don't know how you're doing this, but there's a old trick to use shades of gray as background color, and add a variable to it, in this case, you need only 1 byte of RAM to change all the color.

That's pretty awesome, and a bit more efficient than what I was doing, I might make that change and save a bit more ROM space. I had a table of indexes (1,1,1,2,3,2,1,2,3,etc) and then a small lookup list of ( 8 ) colors, but this means I can keep the same table size, but my color list will just be 2 or 3 bytes, which is pretty cool. My only concern is whether or not I have the time in the kernel for the additional ADC.

Edited January 4, 2015 by walaber

[LS_Dracon]

As for free cycles, you can color the Beam just using the scanline counter, if is Y : STY COLUPF (assuming its a BALL)

And done! You have a rainbow effect.

 

Actually you can enable/disable it using Y too (STY ENABL)

 

Because in a counter, bit 1 always be on or off every 2 scanlines.

Edited January 4, 2015 by LS_Dracon

[Omegamatrix]

Because color registers on the 2600 ignore bit 0, you don't need to worry about the state of the carry while doing the addition.

 

You can of course also use ORA or EOR to do the same thing. That is a better alternative when the state of the carry can mess things up. EOR is especially useful if some bits are known beforehand. I have used EOR before in a NTSC to PAL conversion routine, where I masked the luminance and converted the color portion to its PAL equivilant. This took several cycles to do and would not be useful in your game.

 

Another alternative is if you have X register available then you can do SAX. The advantage here would be that you could perhaps pre-load the X register in a place where you have the cycles available.

 

 

 

ldx ColorVar ; bits 7-4 contain color value (bits 3-0 are filled)

 

routine continues...

lda LuminescenceTab,Y ; (bits 7-4 are filled) bits 3-0 contain luminescence value

sax COLUBK ; AND A with X, store the result in COLUBK.