walaber

The game is done! v1.0 is now available in this post in the 2600 Programming forum. Here's a video of the final version: https://www.youtube.com/watch?v=NjpSyfKn6jM and a few screenshots for good measure

Thanks SpiceWare, I've already seen that, and I understand the basics of fixed-point math, but can't seem to find actual code for all the math I need. every example I can find shows the extremely simple examples and then says something like "of course remember with twos-complement you have to change this a bit..." etc. I'm really surprised there isn't a link anywhere with basic routines for signed fixed-point 8.8 math with subroutines for ADD, SUB, MUL, DIV, SQRT...

Has anyone tried using software floating-point routines on the 2600? For my motorcycle game I'm thinking about different ways to handle the physics. I can always do something simplified and custom using just integers / some 16-bit math, but if I could get some floating point routines working it would be possible to make the physics pretty realistic. I see there are some 6502 floating point routines here: http://codebase64.org/doku.php?id=base:floating_point_routines_for_the_6502 (along with some other interesting links at the parent page: http://codebase64.org/doku.php?id=base:6502_6510_maths ) Has anyone tried these routines on 2600? I assume they consume a lot of cycles... but if I'm only simulating a few point masses it might be acceptible. otherwise does anyone have any recommendations for doing either floating point or fixed point (signed) math on 6502 assembly? In order to do a "proper" physics simulation I'd need the ability to add, subtract, multiply, divide, and sqrt. Other than the link above I can't seem to find any ready-to-use code for this kind of math.

looks like you're making good progress!

Alright, I think I'm happy to call this version 1.0 of Wall Jump Ninja! Please let me know if you find any bugs, otherwise consider this game complete. Here's a video of the final version: https://www.youtube.com/watch?v=NjpSyfKn6jM And a few screenshots for good measure (I adjusted the BG colors a bit in this final version, and improved the PAL color conversions in several places) ...and of course, the binaries: All-in-1 ZIP: wall_jump_ninja_20150115_v1_0.zip NTSC: wall_jump_ninja_20150115_v1_0_NTSC.bin PAL60: wall_jump_ninja_20150115_v1_0_PAL60.bin PAL: wall_jump_ninja_20150115_v1_0_PAL.bin If all goes according to plan, the game will be available on cartridge in the AA store in the near-ish future

I've made a tiny bit of progress on this, so far just working on the rotation frames for the motorcycle. I'm going for 16 frames of rotation to make it pretty smooth. here's an animated GIF of the sprite rotation loop: 16x16 enlarged and with non-square pixels:

nice work! The graphics are really nice, and the journey is communicated well through the visuals. I think it'd be more fun though if you had to occasionally be defensive... maybe make all the enemies shoot projectiles that are either low to the ground (press UP to jump over them), or head-height (hold DOWN to duck under them)... and if they have a "tell" that lets you know when they are about to shoot, you can actually have some more drama to the combat right now you can just spam the FIRE button and run through the game pretty easily.

pretty cool... an interesting interpretation of the original game

I've matched them according to the conventions others have come up with... But maybe a little hand-adjusting wouldn't hurt. Also after playing on a TV I think I need to brighten up some of the backgrounds anyway, it's hard to see the ninja and the walls in front of some of the darker hues on the bottom of the screen.

Mef- thanks for the feedback and the time to draw some nice looking sprites! I'm not sure I want to change the sprites, although I do agree that yours look less "stick-figure-like". I've made a final build tonight, and already made the instruction manual as well, so I think I'll stick with my own art. Here is what I hope is the final release candidate: RC7. New Stuff: * AtariVox+ / SaveKey save and load is working! Hold FIRE on left controller when launching the game to reset the high scores (actually it just skips loading them). * A little bit of background music for the title screen. Please excuse this, but I think it sounds better than nothing. Since I have no ROM space left, I re-interpreted my background color table as music frequencies, and did a little fiddling with adjusting pace and volume, and it didn't seem too terrible so I put it in! Fixes: * sound no longer plays in attract mode * fixed a few scanline count errors All-in-1 ZIP: wall_jump_ninja_20150111_RC7.zip NTSC: wall_jump_ninja_20150111_RC7_NTSC.bin PAL60: wall_jump_ninja_20150111_RC7_PAL60.bin PAL50: wall_jump_ninja_20150111_RC7_PAL.bin

I think you could also use the SAX command, which ANDs A and X and then stores the result. That way you only load the mask once and reuse it multiple times LDA (maskPtr),Y TAX ... LDA (gfxPtr),Y SAX ENAM1 LDA (movePtr),Y SAX HMM1

I've a fair amount of experience writing physics, I created a game on PC / Mobile called "JellyCar" which had a custom soft-body physics engine that I wrote. I'm not worried about the math, I just need to balance what I can afford from a CPU cycle perspective, and also learn how to do basic signed fixed point math in 6502 asm ... and of course tune the model to what plays well.

This is looking awesome! I'm surprised how good the skater looks even at such low resolution.

I've thought a little about the physics, yeah. I'm assuming I'll definitely have to be using a lot of 16-bit "fixed point" math to make everything smooth. I'm not sure how realistic I want to simulate the physics just yet... probably some fairly realistic aspects like gravity and acceleration, but simplified physics for flipping/landing/doing wheelies, etc. we'll see how it goes!

Thanks, I'll definitely add in a description there. Hopefully it's pretty apparent on the title screen, but I think adding that to the manual is a good call.

That's a really cool method!

I squeezed in code to animate closed the wall openings after you pass through them, which I think is a nice little bit of polish that was well worth it. I may also have squeaked in a tiny easter egg as well, but that shall remain a secret Progress video Today I also put in the actual code to call the VOX routines, and of course I ran out of ROM space and had to optimize yet again. So I bit the bullet and optimized my movement tables to use much less data. I was worried that the additional code I'd need to unpack the data would offset the savings, but it was actually a new gain both on the data side and also on the code side. For those curious, I basically have a little counter variable that counts up and repeats every 4 frames (0,1,2,3,0,1,2,3,0,1,2,3,etc). I use this variable as a lookup into data tables to decide how much to move each frame for anything that animates, etc. Every few times the variable loops I increment another offset that moves me deeper into the table. Anyway, this means that I had movement tables that looked something like this: .byte #1, #0, #0, #0 .byte #1, #0, #1, #0 .byte #2, #1, #1, #1 .byte #2, #1, #1, #1 .byte #3, #1, #2, #1 As you can see I arranged it in 4-byte sections in order to understand visually how things will move. But looking at the data I realized I never move something more than 3 pixels in a given frame. This means I could combine all 4 values for a single row into just 1 byte, by using 2 bits per value: .byte #%01000000 ;#1, #0, #0, #0 .byte #%01000100 ;#1, #0, #1, #0 .byte #%10010101 ;#2, #1, #1, #1 .byte #%10010101 ;#2, #1, #1, #1 .byte #%11011001 ;#3, #1, #2, #1 In the above example this saves 15 bytes! Also the code to unpack this is actually pretty simple. In several places I have code that looks like this: LDY PlayerVelSection LDA (PlayerVelPtr),Y JSR GetMaskedMovementValue The first two lines load the specific byte from my table, and then I call my "GetMaskedMovementValue" subroutine, which will take the value in A, and based on the current frame counter, mask off the unnecessary data and shift it down into a regular integer that you can use in a math operation: ;------------------------------------------------------- ; INPUTS: A = unmasked movement value. ; OUTPUTS: A + TempVar = properly unmasked value. ;------------------------------------------------------- GetMaskedMovementValue SUBROUTINE LDX PlayerVelFrame AND FrameMask,X CalcLoop DEX BMI CalcDone LSR LSR JMP CalcLoop CalcDone STA TempVar RTS "PlayerVelFrame" is the 0-3 looping counter, and "FrameMask" is a sequence of 4 bytes: FrameMask .byte #%00000011, #%00001100, #%00110000, #%11000000 That loop at the end shifts the masked bits down to the right so they can be interpreted as a regular old number. Anyway I thought people might find that interesting. In total this saved me ~50 bytes, which was enough for the above improvements + VOX save/load code. Currently I have 2 bytes of ROM free, and 24 bytes of RAM free

Thanks for the explanation, I get it now!

I'm still a bit unclear on what constitutes crossing a page boundary, I assume it means accessing a new page since the last read, anyway could that mean that this line: lda (railTablePtr2),y ;5 is sometimes on the same page as the above read (tailTablePtr3), and sometimes not, making it inconsistent?

For reference, the root of my "pulsating" bug came from my misunderstanding of how the CMP operator works... Compare Instruction Results Compare Result N Z C A, X, or Y < Memory * 0 0 A, X, or Y = Memory 0 1 1 A, X, or Y > Memory * 0 1 * The N flag will be bit 7 of A, X, or Y - Memory Basically I didn't know about the "*" there, and I was using BMI to branch based on the comparison, which works for some numbers but not others. This makes me realize I probably have some other fragile areas in my code that are relying on the N flag when they really shouldn't be. in other news I implemented updated movement tables for PAL, so it plays at a comparable speed to NTSC now. It's a bit choppier, but pretty much plays the same.

yikes! Looping vertically on the screen is intended when LAVA is turned off (which is the default unless you flip a difficulty switch to Advanced), in previous builds LAVA was defaulting to ON. OK, the pulsating and audio issues should be fixed in this build: All-in-1 ZIP: wall_jump_ninja_20150105_RC6.zip NTSC: wall_jump_ninja_20150105_RC6_NTSC.bin PAL60: wall_jump_ninja_20150105_RC6_PAL60.bin PAL: wall_jump_ninja_20150105_RC6_PAL.bin

It's pulsating? That shouldn't be happening!

The latest build is available in this post. Here's a recent gameplay video: https://www.youtube.com/watch?v=3YaNwrS6qzg [EDIT] updated to latest build post link.

Thanks, I'll adjust that text. OK so here's RC5, this is the result of a TON of continued optimization and work on the game, hopefully I didn't break anything. New in this version: Attract mode! wait ~15 seconds on the title screen and the game will go into attract mode with a white ninja (and walls), who plays the game on his own. he won't overwrite your high score tho Background colors change every 30 rooms! I might adjust this number for the final release, but the logic is in and working. Tons of code optimization in order to include the VOX save routines (not actually being called yet), and the above features. Please let me know if you find any crazy bugs, on my to-do list to finish the game is: adjust movement tables for PAL50 version to match NTSC speed add VOX save/load logic and test it finish the instruction manual make a cartridge All-in-1 ZIP wall_jump_ninja_20150104_RC5.zip NTSC: wall_jump_ninja_20150104_RC5_NTSC.bin PAL60: wall_jump_ninja_20150104_RC5_PAL60.bin PAL50: wall_jump_ninja_20150104_RC5_PAL.bin Some kinda interesting stats on the latest build: RAM Free: 26 bytes Code size: 3,519 bytes(PAL), 3,514(NTSC) Data size: 545 bytes ROM Free: 28 bytes (PAL), 33 bytes (NTSC)

An Ice section sounds cool, I'll try to add that! I'm continuing to find bytes here and there to save, so attract mode + VOX saving are looking promising! In the meantime, here is the instruction sheet I'm planning, any feedback? FRONT COVER INSIDE BACK COVER