Lumi

I did, but I fixed the problem before trying it out. Thanks for letting me know, though!

Thanks for the feedback, everyone! As you can tell, this is still a very early build. I haven't had time to balance the gameplay properly. I mainly wanted to see whether you guys liked the concept or not Difficulty ramp-up is a priority, as is making your speed count more towards your score. I'm also considering making the overall speed significantly slower so you can see two or three obstacles on-screen at a time. As Thomas Jentzsch pointed out, powerups would be a great addition, but I'm not sure how to pull it off. Between the asymmetric playfield and the player sprites, there isn't enough time in the kernel to place another object, unless I expand it to 3 or 4 lines. Would you guys mind too much if the gap between playfield lines was bigger? Also, I did consider making this utilize paddle controllers instead of the joystick, but I can't seem to get paddle games to work properly in Stella. If I can fix this, I'd definitely consider implementing paddles. It would be really great if I could let the player choose a control method via one of the console switches!

=== NOTICE: === This game has become a new game called "Drive!". See the new topic here. ============= Hello, everyone! This is the first real game I've ever made with any kind of assembly. It's a simple 4K game called "Jet!", where you take control of a guy with a fancy jetpack, dodging obstacles in his way. As you play, obstacles will drop down from the top of the screen. Use left and right on the joystick to move in between the gaps. You can push up to increase the speed, and down to decrease it. Increasing the speed will make it more difficult, but it'll get you more points! This game can be tough, and it takes a bit of practice to get good at it. Here are a few techniques I recommend using: - A good way to get points is to go at a high speed during easy parts (such as flying through obstacles), then decrease your speed as soon as you see an obstacle coming your way so you can get into position. It's a bit tricky to do this with arrow keys, so I recommend using a gamepad or joystick if you're playing in Stella. - The walls on the sides act a little bit like trampolines. If you're near a wall and you need to switch directions quickly, simply bounce off the wall. This will reverse your horizontal momentum, giving you an opportunity to switch your direction quickly. This is still a WIP, but I'm very interested to hear what you all think! What would you like to see in this game? Screenshots: Downloads: == NOTE == These are outdated, check the topic to get the latest version. Jet! v1 NTSC.bin Jet! v1 PAL60.bin

Wow... you're right, I made a major logical error! Thanks for pointing it out. The code you posted didn't work, but I was able to identify where it was failing. Here's a working routine, for anyone who needs help with this: checkhs: lda SCORE+2 ; start with most significant byte and work down cmp HIGHSCORE+2 beq checkMid ; if score byte = high score byte, the next digit needs to be examined bcc ret ; if score byte < high score byte, we know the player got a lower score bcs updateScore ; if neither branch was taken, we have a new high score checkMid: lda SCORE+1 cmp HIGHSCORE+1 beq checkLow ; same as above bcc ret bcs updateScore checkLow: lda SCORE cmp HIGHSCORE beq ret ; at this point, we know the player got the same score, so don't bother updating bcc ret ; if SCORE is less than HIGHSCORE, the player did not get a high score updateScore: lda SCORE ; all checks passed, set new high score and exit sta HIGHSCORE lda SCORE+1 sta HIGHSCORE+1 lda SCORE+2 sta HIGHSCORE+2 ret: rts

Hi, I'm pretty new to 6502 assembly and I need some help. Basically, I'm creating a game with a 5-digit score. The game keeps track of it using 3 bytes of RAM in BCD format. That works fine, but when the game is over I want to compare this score to a high score elsewhere in RAM. The code I've written starts by comparing the most significant bytes. If the score's MSB < the high score's MSB, it exits the subroutine. Otherwise it moves on, comparing the second and least significant bytes the same way. If it never exited the routine, it'll overwrite the high score with the current score. For some reason it doesn't work, and I can't figure out why. The first problem is, it doesn't seem to check the MSB at all. For example, I tried getting a score of 10050, with a high score of 1200. It thought 1200 was larger! If both digits are 9999 or less, it seems to work 90% of the time, but occasionally it'll just fail for no discernable reason at all. I feel like the answer is obvious, but I don't know what I'm overlooking. Below is the code I'm using. SCORE+2/HIGHSCORE+2 is the MSB, while SCORE/HIGHSCORE is the LSB. checkhs lda SCORE+2 ; compare most significant bytes cmp HIGHSCORE+2 bcc ret ; if score's MSB < high score's MSB, exit the subroutine lda SCORE+1 ; compare middle bytes cmp HIGHSCORE+1 bcc ret ; if score's middle byte < high score's middle byte, exit the subroutine lda SCORE ; compare least significant bytes cmp HIGHSCORE bcc ret ; if score's LSB < high score's LSB, exit the subroutine lda SCORE ; if all checks passed, set new high score and exit sta HIGHSCORE lda SCORE+1 sta HIGHSCORE+1 lda SCORE+2 sta HIGHSCORE+2 ret rts Thanks!

Thank you, that's exactly what I was looking for! I also just realized I could use CMD/ALT+L to display the number of scanlines. That's a useful feature, too.

Hi! I'm just getting into Atari 2600 programming, and I have a question about how certain behavior might differ between a real TV and Stella. I don't have a Harmony cartridge, so I can't test it for myself. Basically, I'm putting together a title screen, and after each major update I recompile the code to see whether or not it worked, working my way down the display. What I noticed is that in Stella, I don't have to draw all 262 scanlines of the frame - I can draw, say, the top half of the title screen, then go into vertical sync and Stella will immediately start the next frame, leaving the missing scanlines black. It's very useful for development, but I haven't seen any example code that does this, so I have to ask: what does a real TV do if you go into vertical sync before the frame is "complete"? Would it cause unwanted side effects, and if so, is there any way I can make Stella reflect this behavior so I'll know if I'm drawing the wrong number of scanlines? Thanks!