walaber

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.

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.

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?

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

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.

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.

Just played this on Stella, it's awesome, nice work! the colorful sprites are really well done.

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.

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.

Now that Wall Jump Ninja is basically finished, I've started working on an idea I've been thinking about for a couple weeks now... a motor-cross / excitebike / trials type game. the "port" of tubin' I started earlier isn't nearly as exciting to me as this, so I think this'll be my next project. So far I've just worked out how I think the main kernel should work, and got a proof-of-concept up and running in Stella. For this I want smooth horizontal scrolling, and also for the jumps and terrain to be as smooth as possible. I've accomplished it by using an asymmetric playfield for the rough details, and then the ball and both missiles (set to 8 clocks wide) translated every few scanlines to describe the actual details of the jumps. this means I have to share colors between most objects, so this will likely be another "silhouette character against a colorful background" just like ninja was. I'm also limiting the vertical space that the course can occupy in order to get this all to fit in RAM. I'm also cropping horizontally so I can completely ignore the 4 bits of PF0 on each edge of the screen. I'm pretty happy I got the kernel to work! the other good thing about this kernel is that it should be quite efficient to store level data, as the actual playfield and jumps can be computed from just a few pieces of information (basically a list of jumps from a pre-determined set, and how far they are apart from each other). I'm expecting to keep the game quite simple, since I want to spend the rest of the ROM space on rotation frames for the player so that you can do flips My goal is another 4K game this time. here's a WIP screenshot, and one with Stella's debug colors turned on, so you can see technically how it's done.

Alrighty, here's Release Candidate 4, in NTSC + PAL60 + PAL flavors. I've adjusted the title screen one last time, simplifying it a little (and saving some ROM space in the process), which allowed me to add a best score counter on the title screen. It only lasts as long as the game has been running, as I don't have any room left in the code to squeeze in the VOX+ read/write routines Or I should say that all the low-hanging fruit for reducing ROM size is basically gone, and it's getting harder and harder to find extra bytes. I know I could make it work if I had to, but for my first game I think this is passing the return-on-investment threshold for me... I'd rather start on a new game! Here's two updated screenshots, one of the "Ninja Dash" (since I'd never posted a screen of that), and also the new title screen. BTW that score is legit (from Stella)... but don't compare it with previous versions, because the layout of the rooms has changed as a result of changing the code (the position of the walls is based on interpreting the code itself as a string of numbers that drive the placement logic). Screens: And build(s): All-in-1 ZIP wall_jump_ninja_20141231_RC4.zip NTSC: wall_jump_ninja_20141231_RC4_NTSC.bin PAL: wall_jump_ninja_20141231_RC4_PAL.bin PAL60: wall_jump_ninja_20141231_RC4_PAL60.bin Unless anyone reports and bugs or issues, I think these might be the final builds! [EDIT] looking at the "Ninja Dash" screen now there's an incomplete scanline at the bottom, I'll try to patch that up for the final build

Good points on reusing the rail object for the bottom pole. Now you've got another object free for drawing some skid sparks

Good points on reusing the rail object for the bottom pole. Now you've got another object free for drawing some skid sparks

Good call, I'll remove the dash from the title screen while I take yet another pass at the logo. I'm also going to try to squeeze in a high score display.

This looks cool and your approach makes sense to me. If you know that the rails will always be long enough that the vertical pieces don't overlap horizontally you could probably just use 1 missile for both sides, although that will require repositioning the missile mid-kernel.

Here's a modified version... easier to read?

I took a stab at a new logo for the title screen with a slightly more "Ninja" style font for the game, and also added the word "Ninja" in Japanese (忍者) into the logo. thoughts?

Tonight I took on the challenge of making the code support compiling to NTSC, PAL60, and regular PAL. This involved mostly providing alternate color data, and also allowing for different scanline counts. rather than stretch the game to fill the PAL screen I opted to center the content in the middle by adding blank scanlines above and below the game content. this required more code of course, which pushed me over 4K, so I had to look around in the code for ways to optimize. I found several I also fixed that there was 1 frame that wasn't the proper number of scanlines when transitioning between title screen <--> gameplay. Also required more code Here is a Release Candidate 3 set of builds, in all formats. can anyone with a PAL or PAL60 system please try this out on hardware and let me know if it runs/looks OK? All-in-1 zip file: wall_jump_ninja_20141229_RC3.zip NTSC: wall_jump_ninja_20141229_RC3_NTSC.bin PAL: wall_jump_ninja_20141229_RC3_PAL.bin PAL60: wall_jump_ninja_20141229_RC3_PAL60.bin

This is awesome! Nice work! Seems like a fun project and would be useful for developers who usually test on Stella to get an accurate feel of how it will play with an authentic controller. It makes me think it would be fun to make one of these as an external box that you can plug any controller into and turn it into Bluetooth.

Looking awesome!!! I better get working on the PAL version so we can get this thing on a cart!

This is looking awesome! Since the game graphics are all silhouette, what would you think about giving the ninjas some rim lighting to indicate they are being lit from behind? And maybe the wall most in the foreground could be darker and have a wall texture/pattern on it? Overall this is looking fantastic!!! Maybe we should change the title screen letters to match better the final font on the label? In particular the "NINJA" part.

OK I've addressed the "power up appears early and wraps around the screen" issue. unfortunately because of the way the code it set up, it now means that spikes will disappear a bit earlier than they should when you leave them behind. Here's a "Release Candidate 2" build, if anyone has time to play test and give any additional feedback I'd really appreciate it! wall_jump_ninja_20141228_RC2.bin

Death Beam in the background would be awesome, good idea! Can't wait to see the image in color. There has been some feedback that the colors of the death beam are kinda weird, anyone else have any thoughts on it?

Thanks for the great,detailed feedback everyone! Here's the changes I made this morning, basically I still have to fix the "early powerup" issue and then I'll make another release candidate. - fixed footer incomplete scanline - stopping death beam mid-screen so it doesn't turn black again when it nears the right-edge of the screen after you die - adjusted "wall slide" sprite graphics - fixed blue color at top of screen in NO-LAVA mode - reversed difficulty switches to match convention better - fixed player orientation when falling across door openings - fixed death wall "jumping backward" for a frame near the left-edge of the screen Nice! did it feel good to get the crazy "dash" powerup?

This looks awesome! Do you think there will be opportunity somewhere for the "sunset" background from the game? The only other feedback I have is that it looks a bit like the spikes are coming out of the Ninja's head, maybe that could be spaced out a bit, or perhaps it will be clearer in color.