nmoog

Thanks for the encouragement - especially the kind works of r_type2600 I forgot what nice people everyone were around here!

Hi guys, my last post here was many months ago, and I think this is my first outside of the "2600 newbie" forum too. I learned of the Atari homebrew scene in May and spent the next few months trying to learn what seemed (and still does seem) like the unlearnable. I got a bit of a "game" going thanks to everyone here's help. But work has all but killed my free time, and I don't think I'll get back to it in the near future. So I'm posting it as a way of saying "I asked you guys lots of stupid questions, but I WAS actually doing something with all your advice! Thank you!". It is just the beginning of a game, and there are more buggy bits than not-buggy bits. But on the other hand - I wrote a tune for it! My game is called "Plops". It is set on a Sunday afternoon. On a tranquil lake. You are a well-to-do, mis-behaved rapscallion - out to destroy the fun of others. The aim is to collect the stones that wash up on the shore (um, the small black dots) and toss them at the sailboats that drift across the lake. The longer you hold fire, the further you throw. But beware the dreaded purple thingo that for reasons unknown incessantly fly toward you. Use your mighty up arrow to defy it! (its a bit tricky - i just played it then for the first time in ages - I must have just got used to it). Thanks again for all your help - I hope I'll be back again when I get a less crappy job plops5.zipplops5.bin

Ive seen that same pic (probably same guy selling) go through maybe 10 times in the last few months. I reckon its legit. You only get 1 controller and the 32-in-1 game. And i suppose if they are making $50 on ebay then that's what they're worth

I was just wondering about the best way to draw "multiple screens" in your games (such as splash screens or different game screen that can not use the same kernel) For instance, a game might require the following game states: 1. Splash screen 2. Main game screen with 1/2 second "get ready" pause" 3. Running main game screen 4. Switch screen to game element #2 with 1/2 second "get ready" pause 5. Running game element #2 6. Game over with enemies still moving As I am adding more pieces to my game, such as end-of-levels etc, my code is getting more spaghetti like - In higher level languages I'd just have a "state" variable and do a switch statement like switch(GameState){ case STATE_SPLASH: drawSplash(); case STATE_RUNNING: drawLevel(CurrentLevel); ... } Kind of thing. How do you organise your game screens and levels nicely for the 2600? At the moment I am drawing a standalone kernel (with vblanks, and overscans) for the Splash screen and then another kernel (with vblanks and overscan) for the "main game". But as I go to add another screen, it's starting to get ugly - especially as I want it to draw one frame of the new screen, pause for 1/2 second, then continue. Any suggestions on handling these types of game elements?!

Also, make sure that you have "processor 6502" at the top of the file somewhere - with at least one space. That might explain your unknown mnemonics if it is dying on things like lda, sta etc... If you try and compile something and it has errors, you will still get a .bin file and stella will run it showing a black screen and making funny tickky noises. I dunno why!

If you are just looking for bits of code to compile to mess around with, I'd suggest checking Andrew's tutorials here (http://www.atariage.com/forums/index.php?showtopic=33233) From after around Session 8 on that list, each thread usually has code you can compile - either by Andrew, or other people who are learnin' along in the replies.

I had my "walk cycles" using an offset to the sprite data, but special other frames (like jumping, and ducking) will be much nicer using the lookup table approach I think. And no, I wasn't using a unified counter to control any of the animation - thats a good idea! Thanks for your help

That's a cool idea - could you give me an example of what the lookup table would look like? How do you do a table of addresses for dasm? I'm learning assembler, so I haven't had a look at batari basic - it kind of seems like cheating In regards to the actually "counters" for animation, is that how you do your timing for animation frames - Store a timer counter variable and decrement each loop, when it's zero increment the animation frame? I can see what you mean about there not being a "right" way. I've only got about 3/4 of game logic working in the vertical blank area and I've run out of cycles! That's why I'm looking for more efficient methods of doing things like timing. My first efforts are working, but aren't very elegant

That subpixel movement is awesome! I don't know if this is related, but is there a sneaky clever way to do animation timing? I am using two variables PlayerFrame and FrameCounter - I set FrameCounter to some value, decrement it each frame, and when it is zero increment the PlayerFrame and reset the counter. Then in a horribly complex and ugly looking "switch" statement I point the SpritePointer to the correct frame (depending if the player is walking or jumping etc) Is this the best way to handle animation timing? The 16 bit math cleaned up my movement code nicely, and now my animation code looks really ugly Any animation tips?! Thanks!

Yep! That's the answer alright! That's the elegant solution I was looking for to clean up my mess of counter variables. And "subpixel" sounds likes a good keyword to search the forums and stella archives on too. Thanks!

Some unfocused, wishy-washy questions for you! I want to have a "jumping" sprite, and I'm confused on the best way to do it. For other languages/machines I've always done gravity kind of like this: YVelocity = 10 ; Set initial jumping velocity UpdatePlayerPos: ; Called every frame PlayerY = PlayerY - YVelocity YVelocity = YVelocity - 1 So that for the first frame after jumping the player moves up 10 pixels, then 9,8,7,6,5,4,3,2,1,0 then -1,-2,-3,-4,-5,-6.... Giving a nice looking effect of gravity as a player jumps, then lands. Implementing this for the 2600 is harder then I imagined - I can't move a player 10 pixels a frame, that'd look crazy. The way I imagine would look correct would be that I move the player up one pixel after 1 frame, then up one pixel again after 2 frames, then 3,4,5,6,7,8,9,10 then 9,8,7,6,5,4,3,2,1 frames (maybe not 10 frames... that'd be quite a pause mid air) I've been trying to implement something like this, but it's looking verrry messy (codewise), and not very impressive. Its easy when everything on screen moves 1 pixel per frame, but I can't figure out how timing can be done nicely. Are there any "standard" ways to do timing for games? How would you do it if some sprites need to move quickly (say, 3 pixels per frame) and others need to move slowly (say, 1 pixel every 3 frames)? How do you handle these timing issues?!

I sent a PM to Albert (Hopefully the right one) asking to be put on the Krok Cart waiting list - but still, I just love the idea of making carts for a couple of Atari fans I know. So far my learning 6502 and '2600 has been kept under wraps from them... I'm set for birthday gift ideas this year! I was just wondering, I know you can re-use old carts with the AA boards - but can you re-use the old boards if you de-solder the roms? I've got 5 asteroid carts and it just feels wrong to go chucking everything in the bin!

I've decided to get one of these instead: http://www.futurlec.com/EPROMProg.shtml - Not much more than the Willems, and there is a distributor in Australia around the corner (kinda) from me too. Everyone who mentions it on the AA forums says it works well.

Hi Zach, I've just started programming the 2600 and I've been learning a lot by loading up games, disabling players, missiles, playfields etc and seeing how different tricks were acomplished. I was blown away when I ran your demo - and tried to figure out how you did it. But you dont seem to use any player/playfields etc. Is it all done with backgrounds?! I tried to step through it with the Stella debugger... but that just made things more confusing... why does it sit on JMP $0080 for most of the drawing? Any hints?!

Wow, thats a great demo - Nice idea! I like the pixel roaches. I think it struck a chord with me, 'cause roaches just killed my PS2! Maybe the roaches need to have a goal - like eating your food, so food supplies go down, and if you aint got no food then its game over. Or, like in my house now, the more roaches - the more depressed you get