louisg

OK, so strobing at CPU cycles=20 isn't an anomaly then? Adding in the time the STA RESP0 takes, I get ((23*3)-68) + 5 = 6. Interesting! So the question isn't whether the pixel position is negative before RESP0, it's whether it's still negative *after* RESP0! But this doesn't hold up for hitting X=0: If I do RESP0 starting at cycle 18, that gives me ((21*3)-68) + 5 = 0, but I wind up with X=3, exactly as if I had triggered it any time it's still negative. I guess the +5-pixel lag for P0 has to happen when the pixel position is past the horizontal blanking period or it always places it at X=3. This would mean the earliest it'll place P0 is at X=5 (triggering RESP0 exactly as the horizontal blanking period ends), not counting triggering it inside of horizontal blanking. Is my understanding correct?

Hmm, it looks like sta RESP0 at cycle 23 gives me $F for the screen position. If I sta RESP0 exactly 20 cycles in, though, it gives me 6 for the position! I think this code is going to work. It's not as efficient as the one I found on the forum (I waste 5 cycles), but it's mine And now I can see why the author of this positioning code I was looking at wanted to hit 6-- it so happens that this is the left-most position in my fine-tuning table, and since fine-tune is only 16 values signed, it's slim pickings! I think the only alternative may be to have a special case for the left-most values, or to just offset everything (maybe by using sprite wrapping on the right-most side..?) I investigated the Air-Sea Battle code for a bit, and it looks like that one doesn't let sprites go all the way to the left (I think x=3 may have been the minimum..?). It's a fascinating system where getting full-range motion for sprites is considered a breakthrough! So is it documented somewhere what X position you can expect when strobing the RESP0 register at various times? I'm assuming it's a constant lag time once the beam moves onto the visible screen (from "pixel position" 0 onward), but it seems unpredictable as long as the pixel position is negative, giving 3 for the majority of the time. I wonder if Atari programmers were armed with this knowledge, or if they were just winging it? I'm guessing when you're coding Atari games 8+ hours a day, you have the luxury of being able to experiment BTW when I say pixel position, I'm thinking the counter in the Stella debugger. Thanks so much for your help!

I've been trying to get my own horizontal positioning code working, and have noticed something strange that I can't quite figure out. My demo program works when I pop in code by vdub bobby that I got from another thread. This code does STA RESP0 when the pixel position is -11, and the resulting coarse positioning of P0 is 6. My code, on the other hand, does STA RESP0 when the pixel position is 1 or -17 and I get the resulting coarse position of 3 in either case. What exactly is going on here? And if I want to position an object at X=0, do I absolutely need my routine to map that as coarse=6 and fine=6-to-the-left ?

Oh! I must've skimmed right over that somehow! Thanks

OK, cool. So the standard edition comes with a cart (not just a bare board) and everything. Thanks for the info!

I'm sure this has been asked before, but I couldn't find it via the search or on the Harmony page or manual: What exactly are all the differences between standard or deluxe Harmony carts? Is the deluxe one identical except that the firmware is pre-programmed and it includes an SD card?

Yeah the alternating lines is more "old school arcade" style, but I plan to make it so you can wrap any 1d texture on, add haze if I can (like you mentioned), and maybe try other shapes like cylinder. Lots of logo possibilities with that one Not to derail the topic at hand...

Hmm, I was hoping for something simpler that might not need as much mid-scanline instructions. That's why I was thinking maybe 4 sprites instead of 6. I'm actually pretty curious about Video Chess, but haven't looked at a disassembly yet. But is there something about the way they're doing it that makes it less tight timing-wise? Maybe just the wider spacing? Their technique needs a lot of CPU attention during the scanline too, right? Or maybe they're avoiding the use of vdel? I noticed that the Sega games have that logo in the middle of their title screen which is also a 4-sprite configuration. There must be some simpler-code advantage there...

Hi! I just started playing with Atari 2600 programming more seriously in the last week. I'd like to make a program that features a somewhat decent resolution logo bouncing around the screen. If I bounce it horizontally, the 48-pixel 6-digit-score-style routine seems very tricky to keep track of. I was wondering if there might be a routine that's maybe not as high quality but is easier to manage. I've even considered stooping to using only two quad-sized sprites, or maybe double-sizing but interlacing (venetian blinds style). But before I throw in the towel and do that: is there anything tricky I could do with maybe 3 or 4 sprites that'd be easier to manage? It seems like some games used 4-sprite routines and not 6-sprite routines (like Video Chess).. was that easier in some way? Any suggestions would help me a lot, as I'm pretty new to this. Oh, btw, here's my first 2600 effort. It's a 3d mapping routine: http://extentofthejam.com/road1.bin .. this is what I'm hoping to put the bouncing logo on.

To do the up/down hills, are you saying that it basically curves the Y axis instead of curving the X (like a left/right turn, but affecting the other axis)? And, do you recall if the dark/light grey pattern used on the ground is also a sprite in STUN Runner? To me, it seems like Roadblasters is somewhat different from STUN Runner in that STUN Runner's track is broken up into somewhat large sprite chunks (ala RadMobile) but Roadblasters works on a per-scanline basis (like Pole Position). Maybe I'm not fully understanding this though. I do get that the sprites in STUN Runner are tied to the road's position, but solving the hill problem always turns out to be a sort of chicken/egg deal! I do notice that STUN Runner doesn't seem to have hills at the same time as it's curving left/right, so that should simplify the problem somewhat. That's an interesting solution to the forking road. I did notice something a little funky about them, but couldn't put my finger on it! I'm glad STUN Runner was done using sprites-- speed is of course extremely important in a racing game, and it turned out great! In fact, it's the game that sold me on a Lynx in the early 90s.

Hi! Thanks for the reply! If there's one problem of pseudo 3d roads that I've found there are a multitude of ways to solve, it's hills. I was wondering, in Lynx S.T.U.N. Runner, how that was accomplished. I also wonder whether STUN Runner is a per-scaline slide engine (the way I imagine RoadBlasters is) or whether it's dealing in small 3d chunks of track projected onto the screen (not 3d in the sense that they can rotate, but 3d in the sense that the height on the screen for a given slice of track is found by solving something like y_screen = y_world/z). Would you be able to share the algorithm that S.T.U.N. Runner uses? And do you remember if overdraw was a concern on that platform? Right, I imagine given the density of scenery in S.T.U.N. Runner that the 1/depth relationship is important so that the pieces fit together without gaps or too much overshoot (not to mention the headaches that happen when the relationship is wrong ). Hmm I thought I saw Rampart source kicking around these forums, but maybe that's not official source. Is there anyone I might be able to write to and see if they might approve release of the S.T.U.N. Runner source? I'm surprised! So it's completely 3d to the point that, had the developers wanted to, they could have swiveled the camera to show the track from different angles. I do remember that one running a bit quicker in the arcade than Hard Drivin', but then again I suppose the physics are easier to calculate. Again, thanks for taking the time to comment -Louis

Hi, I saw the S.T.U.N. Runner topic over at http://www.atariage....-for-the-lynx/. Well, I run a page on how pseudo 3d road engines (like Outrun) work, and am always trying to add more case studies of actual games (http://www.gorenfeld.net/lou -- so far I just have a breakdown of Enduro and Road Rash). So, I was wondering if anyone knew whether S.T.U.N. Runner actually works more or less similarly to a game like Outrun (or Roadblasters, etc). I know the other thread had some source code from the game; does anyone know if the source code has been released in its entirety? Maybe a little off-topic for this forum, but I was also under the impression that the arcade S.T.U.N. Runner also was basically pseudo 3d in that the view of the road/tunnels is built from the front of the screen to the back, with curves simulated (as opposed to using 3d translations and rotations to move the camera as it goes around a curve the way a game like Hard Drivin' would).