vdub_bobby Posted May 13, 2009 Share Posted May 13, 2009 (edited) More RAM Madness!! RAM Racer - an endless race, dodging moving...roadblocks? squares?...along an endless highway! This has been tested on a 7800 with a CC2 and it works fine. Emulators are a little wonky but still work fine. Incidentally, I discovered, whilst doing this, that neither z26 nor Stella correctly detect offscreen collisions. Anyway, L/R to steer, trigger to put on the gas. Sorry, no sound nor score. RAMRacer.bin Zero free bytes. RAMRacer.zip Edited May 13, 2009 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 13, 2009 Share Posted May 13, 2009 Very nice. And very tough too! Have you thought about paddle controls? Quote Link to comment Share on other sites More sharing options...
roland p Posted May 13, 2009 Share Posted May 13, 2009 It looks promising. If you memorise the places where you can pass the cars it's doable but very hard. Quote Link to comment Share on other sites More sharing options...
ibogost Posted May 13, 2009 Share Posted May 13, 2009 Wow, it is really hard! I haven't passed the third set of blocks yet Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2009 Share Posted May 13, 2009 More RAM Madness!! This has been tested on a 7800 with a CC2 and it works fine. Emulators are a little wonky but still work fine. Incidentally, I discovered, whilst doing this, that neither z26 nor Stella correctly detect offscreen collisions. I thought I read somewhere that collision detection isn't done in the VBLANK area. Because from looking at the Stella code, I see it was an intentional design decision to not process collisions during vblank. Technically, there's no reason the code couldn't be expanded to do so, but I just thought it wasn't necessary. More feedback on this issue would be great, as I could tie it into the TIA rework that's currently being done in Stella. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 More RAM Madness!! This has been tested on a 7800 with a CC2 and it works fine. Emulators are a little wonky but still work fine. Incidentally, I discovered, whilst doing this, that neither z26 nor Stella correctly detect offscreen collisions. I thought I read somewhere that collision detection isn't done in the VBLANK area. Because from looking at the Stella code, I see it was an intentional design decision to not process collisions during vblank. Technically, there's no reason the code couldn't be expanded to do so, but I just thought it wasn't necessary. More feedback on this issue would be great, as I could tie it into the TIA rework that's currently being done in Stella. Here's how it should work: collisions should be detected whenever VBLANK is turned off. (I tested this on a 7800.) z26 and Stella both do NOT detect collisions, whether VBLANK is off or on, that happen outside of the rendered area. I.e., if a collision happens at scanline 10, Stella/z26 won't detect it - unless you set the emulator to display that scanline; in that case both emulators will detect a collision that high. This comes up because this program has a 256-line kernel; and only turns VBLANK on for 3 scanlines (only during VSYNC!) so collisions can (and do!) happen anywhere from about scanline 4 to scanline 262. Since the behavior of the program depends on detecting collisions outside of the normally-visible range, you can definitely see this effect: On real hardware the blue squares stay between the white lines at all times - in emulation, collisions that are not displayed are not detected so the blue squares move right through the white lines. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 (edited) Very nice. And very tough too! Have you thought about paddle controls? The difficulty is pretty easily adjusted (I can change the width of the road and change the NUSIZxx value of the roadblocks); I have yet to really fine-tune the gameplay; I just, last night, got all the gameplay elements in. Freeing up those last few bytes to get the variable speed (with the trigger) took a while! Paddles... Never even occurred to me! I think I like it as is; I'd rather tweak the difficulty in the ways I mentioned above. Interesting idea, though. EDIT: Incidentally, I am using a few unorthodox tricks that all seem to work OK on my 7800 - but I'd appreciate feedback on whether it causes issues on other hardware. The main funky stuff are that I am depending on CXPPMM being of the form: %xx000xxx. Also, this is my VSYNC loop: VSYNCLoop sta VBLANK ;turn on and off VBLANK. seems to work fine, on CC2 in 7800 sta VSYNC ror sta WSYNC bcs VSYNCLoop I was worried that this would cause screen rolling, but it seems to be ok. Also, the picture isn't real stable; it varies between 262 and 263 scanlines while the game is running and is a (stable) 261 once your game is over. Again, this didn't cause any issues on my (NTSC) 7800. Edited May 13, 2009 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2009 Share Posted May 13, 2009 More RAM Madness!! This has been tested on a 7800 with a CC2 and it works fine. Emulators are a little wonky but still work fine. Incidentally, I discovered, whilst doing this, that neither z26 nor Stella correctly detect offscreen collisions. I thought I read somewhere that collision detection isn't done in the VBLANK area. Because from looking at the Stella code, I see it was an intentional design decision to not process collisions during vblank. Technically, there's no reason the code couldn't be expanded to do so, but I just thought it wasn't necessary. More feedback on this issue would be great, as I could tie it into the TIA rework that's currently being done in Stella. Here's how it should work: collisions should be detected whenever VBLANK is turned off. (I tested this on a 7800.) z26 and Stella both do NOT detect collisions, whether VBLANK is off or on, that happen outside of the rendered area. I.e., if a collision happens at scanline 10, Stella/z26 won't detect it - unless you set the emulator to display that scanline; in that case both emulators will detect a collision that high. This comes up because this program has a 256-line kernel; and only turns VBLANK on for 3 scanlines (only during VSYNC!) so collisions can (and do!) happen anywhere from about scanline 4 to scanline 262. Since the behavior of the program depends on detecting collisions outside of the normally-visible range, you can definitely see this effect: On real hardware the blue squares stay between the white lines at all times - in emulation, collisions that are not displayed are not detected so the blue squares move right through the white lines. Sorry, everywhere I said 'VBLANK' I meant to say 'HBLANK'. From my understanding of the current Stella code, it seems to only do collision detection in the visible area, as you say. That means no detection during HBLANK, and none for scanlines not shown. I believe the latter is an incorrect optimization thing (don't process lines that you won't see anyway), but the former is how I thought it would work. In any event, I can definitely see why it's not doing that in Stella; it was specifically designed not to. Changing it probably won't be too hard, but I just want to make sure that's the actual behaviour (particularly WRT the HBLANK area). Just to expand on that last point, to make sure we're on the same page. On each line there are 228 positions. Rendering is only done for positions 68 to 228. Would collision detection be enabled for position 0 to 67?? Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 How would it matter if you detected collisions during HBLANK or not? Nothing is there to collide. There are no PF pixels in HBLANK. Moving objects left past color clock 68 makes them wrap to color clock 228; they don't move into the HBLANK area. Or am I missing something? My rough understanding is that the TIA detects collisions only when it tries to draw pixels of overlapping, active objects. So when VBLANK is on, no collisions are detected (I assume!). But that does bring up an interesting question - are collisions detected under the blank HMOVE bars? I would assume that they aren't, but has anyone done any testing? Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted May 13, 2009 Share Posted May 13, 2009 Sorry, everywhere I said 'VBLANK' I meant to say 'HBLANK'. From my understanding of the current Stella code, it seems to only do collision detection in the visible area, as you say. That means no detection during HBLANK, and none for scanlines not shown. I believe the latter is an incorrect optimization thing (don't process lines that you won't see anyway), but the former is how I thought it would work. In any event, I can definitely see why it's not doing that in Stella; it was specifically designed not to. Changing it probably won't be too hard, but I just want to make sure that's the actual behaviour (particularly WRT the HBLANK area). Just to expand on that last point, to make sure we're on the same page. On each line there are 228 positions. Rendering is only done for positions 68 to 228. Would collision detection be enabled for position 0 to 67?? Collisions can only happen when the moving objects are processed. This doesn't happen during HBLANK, so no collisions here. However, the HMOVE puslses are transmitted over the same lines that handle the pulses to process a pixel during the visible part of the screen. So, if you position two moveable objects over the horizontal border and then trigger an HMOVE, their pixels would get processed and therefore you need to check for collisions here. IIRC Pole Position and Fatal Run are affectec by this, as both sides of the curbs might collide in the HMOVE. Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2009 Share Posted May 13, 2009 I.e., if a collision happens at scanline 10, Stella/z26 won't detect it - unless you set the emulator to display that scanline; in that case both emulators will detect a collision that high. This comes up because this program has a 256-line kernel; and only turns VBLANK on for 3 scanlines (only during VSYNC!) so collisions can (and do!) happen anywhere from about scanline 4 to scanline 262. Since the behavior of the program depends on detecting collisions outside of the normally-visible range, you can definitely see this effect: On real hardware the blue squares stay between the white lines at all times - in emulation, collisions that are not displayed are not detected so the blue squares move right through the white lines. What exactly did you do to trigger the bug as shown in the snapshot? I tried playing around with it, but can't get it to happen the way you've shown. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 I.e., if a collision happens at scanline 10, Stella/z26 won't detect it - unless you set the emulator to display that scanline; in that case both emulators will detect a collision that high. This comes up because this program has a 256-line kernel; and only turns VBLANK on for 3 scanlines (only during VSYNC!) so collisions can (and do!) happen anywhere from about scanline 4 to scanline 262. Since the behavior of the program depends on detecting collisions outside of the normally-visible range, you can definitely see this effect: On real hardware the blue squares stay between the white lines at all times - in emulation, collisions that are not displayed are not detected so the blue squares move right through the white lines. What exactly did you do to trigger the bug as shown in the snapshot? I tried playing around with it, but can't get it to happen the way you've shown. It was difficult. Stay alive for about 20 seconds and you'll see it - though it depends on how frequently and for how long you hold down the trigger. You need to dodge the faster roadblocks three times, I think. Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2009 Share Posted May 13, 2009 I.e., if a collision happens at scanline 10, Stella/z26 won't detect it - unless you set the emulator to display that scanline; in that case both emulators will detect a collision that high. This comes up because this program has a 256-line kernel; and only turns VBLANK on for 3 scanlines (only during VSYNC!) so collisions can (and do!) happen anywhere from about scanline 4 to scanline 262. Since the behavior of the program depends on detecting collisions outside of the normally-visible range, you can definitely see this effect: On real hardware the blue squares stay between the white lines at all times - in emulation, collisions that are not displayed are not detected so the blue squares move right through the white lines. What exactly did you do to trigger the bug as shown in the snapshot? I tried playing around with it, but can't get it to happen the way you've shown. It was difficult. Stay alive for about 20 seconds and you'll see it - though it depends on how frequently and for how long you hold down the trigger. You need to dodge the faster roadblocks three times, I think. OK, I got it. I just disabled P1 and M1 (ie, the red block) until it happened. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 OK, I got it. I just disabled P1 and M1 (ie, the red block) until it happened. Good idea. I should have thought of that. And I'll note again that if you set Stella (or z26) to display all 262 scanlines then the game behaves as expected, all collisions are detected. Quote Link to comment Share on other sites More sharing options...
+stephena Posted May 13, 2009 Share Posted May 13, 2009 OK, I got it. I just disabled P1 and M1 (ie, the red block) until it happened. Good idea. I should have thought of that. And I'll note again that if you set Stella (or z26) to display all 262 scanlines then the game behaves as expected, all collisions are detected. Yes, this will be fixed in the next major release of Stella with the TIA revamp. What's happening is exactly what you say; any scanlines below the start line are not processed at all. That means no drawing (which doesn't really matter) and no collision detection (which is obviously a bug). Basically, it's an optimization that's a little too agressive. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 13, 2009 Author Share Posted May 13, 2009 Yes, this will be fixed in the next major release of Stella with the TIA revamp. What's happening is exactly what you say; any scanlines below the start line are not processed at all. That means no drawing (which doesn't really matter) and no collision detection (which is obviously a bug). Basically, it's an optimization that's a little too agressive. Very cool; it was somewhat annoying trying to test this in emulation, as you can imagine. Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted May 13, 2009 Share Posted May 13, 2009 Very fun! Quote Link to comment Share on other sites More sharing options...
supercat Posted May 13, 2009 Share Posted May 13, 2009 (edited) collisions should be detected whenever VBLANK is turned off. (I tested this on a 7800.) According to page 2 of the schematic, the collision latching logic is gated with /VB, which is the inverse of the vblank register. The TIA, of course, has no way of knowing whether the electron beam is over a displayable part of the picture tube, but it gates using the VBLANK register. Interesting to know. As for horizontal, that might be worth some experimentation. The collision logic on page 2 does not seem to take into account the /HB signal (horizontal blank), and the signals it samples (pp. 3-4) are synchronized to CLKP (a clock that runs 228x/line) rather than MOTCK (which runs for the 160 visible pixels). By my read of the schematic, if a Player 0 is positioned so that GRP0 bits 0-3 are visible at the right edge of the screen, and 4-7 are visible at the left, and horizontal motion were not activated, then its sprite generator will output bit 3 of GRP0 continuously during the horizontal blank. If Player 1 were similarly positioned, its sprite generator would output bit 3 of GRP1. If going into horizontal blank, GRP0.3 was clear and GRP1.3 was set, and during blanking software set GRP0.3 and cleared GRP1.3 (in that order), I would expect it to cause a collision. If it doesn't, I'd be curious to know why. If things work as I described, the HMOVE behavior would be a bit tricky to describe. Before I bother, it would be helpful to know whether collisions like I described can occur. PS--On real hardware, VBLANK should start at least a line before VSYNC, and continue on for a dozen or so lines afterward. I suspect most newer televisions probably won't care, but a 1950's model might. Edited May 13, 2009 by supercat Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 14, 2009 Author Share Posted May 14, 2009 New version; only change is that I widened the road. Hopefully it will be a little easier. But not too easy! RAMRacer.bin Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 14, 2009 Author Share Posted May 14, 2009 (edited) As for horizontal, that might be worth some experimentation. The collision logic on page 2 does not seem to take into account the /HB signal (horizontal blank), and the signals it samples (pp. 3-4) are synchronized to CLKP (a clock that runs 228x/line) rather than MOTCK (which runs for the 160 visible pixels). By my read of the schematic, if a Player 0 is positioned so that GRP0 bits 0-3 are visible at the right edge of the screen, and 4-7 are visible at the left, and horizontal motion were not activated, then its sprite generator will output bit 3 of GRP0 continuously during the horizontal blank. If Player 1 were similarly positioned, its sprite generator would output bit 3 of GRP1. If going into horizontal blank, GRP0.3 was clear and GRP1.3 was set, and during blanking software set GRP0.3 and cleared GRP1.3 (in that order), I would expect it to cause a collision. If it doesn't, I'd be curious to know why. If things work as I described, the HMOVE behavior would be a bit tricky to describe. Before I bother, it would be helpful to know whether collisions like I described can occur. I tested this, I think, on a 7800 - and no collision was detected. I think I did this right; take a look at the binary and let me know if I'm doing what you said. The relevant part of the kernel: lda #$E0 ldx #0 sta GRP0 stx GRP1 sta WSYNC sta GRP1 stx GRP0 Where the 3rd pixel of both P0 and P1 is hard against the right-hand edge of the screen. If a collision is detected the screen should turn gray (from black). It doesn't on my 7800. Colldtct.bin colldtct.zip Edited May 14, 2009 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
+batari Posted May 14, 2009 Share Posted May 14, 2009 I think I did this right; take a look at the binary and let me know if I'm doing what you said.The relevant part of the kernel: lda #$E0 ldx #0 sta GRP0 stx GRP1 sta WSYNC sta GRP1 stx GRP0 Where the 3rd pixel of both P0 and P1 is hard against the right-hand edge of the screen. I think you are a pixel off. Wouldn't pixel 3 be the 4th pixel? Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted May 14, 2009 Author Share Posted May 14, 2009 I think I did this right; take a look at the binary and let me know if I'm doing what you said.The relevant part of the kernel: lda #$E0 ldx #0 sta GRP0 stx GRP1 sta WSYNC sta GRP1 stx GRP0 Where the 3rd pixel of both P0 and P1 is hard against the right-hand edge of the screen. I think you are a pixel off. Wouldn't pixel 3 be the 4th pixel? Well, yeah, but I figured that which pixel it was didn't matter. Is that wrong? Quote Link to comment Share on other sites More sharing options...
+batari Posted May 14, 2009 Share Posted May 14, 2009 I think I did this right; take a look at the binary and let me know if I'm doing what you said.The relevant part of the kernel: lda #$E0 ldx #0 sta GRP0 stx GRP1 sta WSYNC sta GRP1 stx GRP0 Where the 3rd pixel of both P0 and P1 is hard against the right-hand edge of the screen. I think you are a pixel off. Wouldn't pixel 3 be the 4th pixel? Well, yeah, but I figured that which pixel it was didn't matter. Is that wrong? That's possible. I could have taken Supercat's description too literally. Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 15, 2009 Share Posted July 15, 2009 This has been tested on a 7800 with a CC2 and it works fine. Emulators are a little wonky but still work fine. Incidentally, I discovered, whilst doing this, that neither z26 nor Stella correctly detect offscreen collisions. This problem has been fixed in the internal build of Stella, which will be available as a series of alpha/betas releases over the coming weeks. See here for more information. Quote Link to comment Share on other sites More sharing options...
keilbaca Posted July 15, 2009 Share Posted July 15, 2009 I agree completely in adding in paddle controllers. This would be a very fun Atari HSC game! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.