Jump to content
IGNORED

RAM Racer


vdub_bobby

Recommended Posts

More RAM Madness!!

 

RAM Racer - an endless race, dodging moving...roadblocks? squares?...along an endless highway!

 

:D

 

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.

post-6060-1242196653_thumb.png

RAMRacer.bin

Zero free bytes.

RAMRacer.zip

Edited by vdub_bobby
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

post-6060-1242229218_thumb.png

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.

Link to comment
Share on other sites

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! :D 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 by vdub_bobby
Link to comment
Share on other sites

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:

post-6060-1242229218_thumb.png

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??

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

post-6060-1242229218_thumb.png

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.

Link to comment
Share on other sites

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:

post-6060-1242229218_thumb.png

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. :ponder:

 

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.

Link to comment
Share on other sites

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:

post-6060-1242229218_thumb.png

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. :ponder:

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

:thumbsup:

 

Very cool; it was somewhat annoying trying to test this in emulation, as you can imagine.

Link to comment
Share on other sites

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 by supercat
Link to comment
Share on other sites

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 by vdub_bobby
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 months later...
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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...