walaber

Yeah Ninjump is fun, and I think a fun 2600 port could be made. I still have a few elements to add to the game that will hopefully make it feel even more fun than it is right now, keeping the horizontal design. I'm working on cleaning up the code now, I got some tweaks in today to the width of the rooms and the collision detection and spike placement.

Got the technique mentioned above working and now I have a proof-of-concept multicolor logo screen I'll have to make the colors prettier, but it works! thanks for the help everyone!

Thanks for the feedback everyone! Today I've added in logic to detect when you collide with a spike, and have the player fall off the screen, resulting in a simple 'game over' state. Press the hardware reset button and the game will restart. Here is an initial build of the game, please give it a try and let me know what you think! wall_jump_ninja_20141129.bin Use player 1 FIRE button to start the game from the title screen, and the same button to jump (hold to jump higher). I haven't tested it on hardware yet, so play at your own risk. It seems to be a pretty solid 262 scanlines on Stella though (except for transitioning between the title screen and gameplay for a frame). Next I think I'll try to make the title screen more interesting, and then focus on tuning the gameplay a little more (I think the walls are too far apart right now). I also think adding more player frames would look nice, since the movement is pretty fluid, it would be cool if the player sprite animated more fluidly to match.

Sounds! I used Tone Toy to discover the different settings and it made implementing some basic sounds quite easy. updated vine video of the latest version: https://vine.co/v/OnvMxjErgXr

Thanks to everyone's help, I've got the 48-bit sprite kernel working, in order to add a title screen to the game. I really wish I could change the colors for each scanline, but I haven't found a way to squeeze the cycles needed into the kernel. Almost, but not quite: I can find enough time to change COLUP0 or COLUP1, but not both I have some free cycles because the logo is static so the LDX are only 4 cycles each instead of 5, and I'm happy that I was able to figure out how to compensate my kernel for this... my fallback will be to have "wall jump" be 1 color, and then in the blank line between that i can change the colors, and have "NINJA" be in another color. Here's the title screen, I've decided to call the game "Wall Jump Ninja" Also I think I'll try to use the playfield and background colors to make the title screen a little more exciting. but for now, back to game logic, and then onto sounds.

Thanks everyone for the replies and links! I had a feeling it must be related to VDEL, and now it makes sense! that code I posted actually did have more code, which included the additional write to GRP0. sorry for asking a question that it appears I could have figured out with a bit more exhaustive searching.

Hey everyone. I've been studying the "6-digit score" / 48-bit sprite technique of basically setting up P0 and P1 to be triple-repeating, and then changing out what's in GRP0 and GRP1 during the scanline to get the equivalent of 6 sprites worth of data drawn on the screen. I feel like I understand the basic idea, and going line-by-line through various examples in shipped games and those code examples I've seen around, I feel like I understand the code mostly. There is one part that's confusing me though... most of these prep some data in A, X, and Y, and do some rapid STA, STX, STY at the end to get the last pieces into the player graphics registers before the scanline passes. Most examples I've seen appear to re-use the contents of the A register twice without modifying it. To me that seems to imply that two of the sprites must be identical in this technique... here's an excerpt example: LDA (Ptr1),Y STA GRP1 <- first sprite contents LDA (Ptr2),Y STA GRP0 <- second sprite contents LDA (Ptr3),Y STA SomeTempLocation LDA (Ptr4),Y TAX LDA Address,Y TAY LDA SomeTempLocation STA GRP1 <- third sprite contents STX GRP0 <- fourth sprite contents STY GRP1 <- fifth sprite contents STA GRP0 <- sixth sprite contents I've hi-lighted the two instructions that seem to use the same contents of the A register. Am I missing something, or does that mean basically that the 3rd and 6th sprites must have the same bit pattern in this technique? that would seem impossible if you want 6-digit scores with different numbers in each digit.

Thanks for the encouraging notes everyone! I've now got a rudimentary 2-digit score display working on the bottom of the screen: my first attempt at an asymetrical playfield, and also figuring out how to turn a score into two digits lined up in PF1 (because that's the easy non-mirrored byte). I'm sure there are much fancier and more efficient methods of doing everything I'm doing, but I'm having a blast getting the game running! It's fun to sit down for an hour or two and make visible progress in the game, and also learn something new at the same time. obligatory screenshot: I still have some game logic to clean up, and then I think I'll detour into sounds a bit.

Hello everyone, this is my first post on this forum. I'm a game designer/programmer for my day job, working on mobile games. Lately I've been getting into 2600 programming, with the initial idea of porting a prototype I made for mobile over to the 2600. It's been a lot of fun getting back into assembly coding, I haven't really touched it since high school, when I learned some Z85 asm to make games for my graphing calculator The game is a simple one-button game: a ninja is sliding down a wall, tap the button to jump away and slide down the other wall. There is an opening on the right, make it through and you are in the next room (the opening closes behind you). It has roughly analog input, e.g. the longer you hold the button, the higher you will jump. As you progress the position of the door changes, and the size of the door opening gradually decreases. Spikes also appear that you have to avoid as well. I've been working on the 2600 version for about a week or so now, and I'm really pleased with the progress so far. here is a screenshot: And a short video I posted on Vine: https://vine.co/v/O1PTebm37er I'm currently working on getting a basic footer that will display what "room" you are in (this is essentially your score). After that I need to get collision detection between the player and spikes (this triggers a game over), and then work on fixing bugs and adjusting the feel of the timing, maybe adding some more animation frames for the player, adding some sound effects, etc. Any feedback is welcome!