Space Racing

[Alessandro]

Well I think I use the firmware, as I said I am not an expert in spectrum, this is my load function. After starting the game, it changes pages and calls this function to continue loading data from the cassette. I assume that this way of loading is not compatible with DIVMMC, can it be?

This is beyond my expertise I'm afraid, perhaps one of the other helpful auteurs in these parts could take a look - @Alessandro or @Ast A. Moore?

DivIDE/DivMMC interfaces will load data from tape image files only by employing the ordinary ROM loading scheme. Normally you would call the LD-BYTES loading routine at 1366 for loading headerless code blocks with:

Code: Select all

  LD A,255 
  SCF      
  CALL 1366
  RET

I see the first two instructions are swapped in the code posted above, maybe that could be the issue? I didn't try the game on the DivMMC myself by the way, I only downloaded and had a quick go at it yesterday, under emulation.

So I tried swapping the two instructions at 42268 and testing the modified file by emulating the DivMMC with SpecEmu. The program crashed after loading the last block.

[RMartins]

...

Normally you might think "oh how fast the bottom moves, it's weird". But it really should move even faster. To be exact, 36 pixels in each frame. WHAT?...

The calculation is as follows:

The pre-calculated game data has been done using an 80 degrees FOV.

Consequently, what is seen on the screen represents an angle of 80 degrees (background included).

Screen is 256 pixels wide, we have to make a rule of three to calculate how many pixels the 360 ​​degrees would be.

360 / 80 = 4.5 complete screens, total 256 * 4.5 = 1152 pixels.

1152 pixels would be a full camera rotation, 360 degrees.

As the player rotates 11.25 degrees in each frame (32 precalculated angles). It means you must move:

x = 1152 * 11.25 / 360 or x = 1152 / 32
x = 36 pixels per frame

...

That is all fine and dandy, but you are forgetting a very specific trick you are using, that invalidates all this thinking.

You are using parallax bands, which only purpose is to give the illusion of depth, by having bands of screen moving horizontally at a different rate.

If it was a camera and assuming the image is a projection into a cylinder around you, all that would be somewhat correct (assuming everything was linear, which it is not).
But the idea here is to provide an illusion of speed and depth.

NOTE: If we wanted to be too technical about it, the pixels at the edges of the screen would be distorted and would be representing a larger area then pixels at the center.

[voxeltower]

That is all fine and dandy, but you are forgetting a very specific trick you are using, that invalidates all this thinking.

You are using parallax bands, which only purpose is to give the illusion of depth, by having bands of screen moving horizontally at a different rate.

If it was a camera and assuming the image is a projection into a cylinder around you, all that would be somewhat correct (assuming everything was linear, which it is not).
But the idea here is to provide an illusion of speed and depth.

NOTE: If we wanted to be too technical about it, the pixels at the edges of the screen would be distorted and would be representing a larger area then pixels at the center.

The game is not realistic. Although the idea was just the one you mentioned about being inside a cylinder / tube that moves with the camera.

But the game does not use parallax in any sense for mode 7 or other thing. Using parallax involves multiple layers of drawing at different speeds, but my game only uses one layer.

Mode 7 is not built by moving layers at different speeds, it doesn't work like that.

It is built by pre-calculating the horizontal and vertical displacement of each point with respect to the camera (this is in a big data table in memory 8kb), then that displacement is added to the current position of the camera to locate the exact place where it falls on the tilemap. And from there it is calculated what color and texture that byte (and the one below) should be drawn from.

It is a real mode 7 with very simplified calculations and precalculating as much as possible, but I call it fake mode 7 since super nes does it in a totally different way (changing hardware values that draw the background), and this could be said to be made by software.

As you can see, it is not parallax, it is something simpler or more complicated, depending on how you look at it.

[RMartins]

The game is not realistic. Although the idea was just the one you mentioned about being inside a cylinder / tube that moves with the camera.

But the game does not use parallax in any sense for mode 7 or other thing. Using parallax involves multiple layers of drawing at different speeds, but my game only uses one layer.

Mode 7 is not built by moving layers at different speeds, it doesn't work like that.

It is built by pre-calculating the horizontal and vertical displacement of each point with respect to the camera (this is in a big data table in memory 8kb), then that displacement is added to the current position of the camera to locate the exact place where it falls on the tilemap. And from there it is calculated what color and texture that byte (and the one below) should be drawn from.

It is a real mode 7 with very simplified calculations and precalculating as much as possible, but I call it fake mode 7 since super nes does it in a totally different way (changing hardware values that draw the background), and this could be said to be made by software.

As you can see, it is not parallax, it is something simpler or more complicated, depending on how you look at it.

I know what you mean.

But we were discussing that supposedly far background.
And by "far", I mean that is what the parallax hack comes from, to give the illusion of depth by having different scroll speeds from background and the road itself.

If you are drawing everything as simple cylinder, then you can't do that using the same rendering code.

But nothing stops you from using a different scrolling code, or even the same code but configured or set differently to handle just that background band. for example to scroll slower (probably means you need a few extra vars to keep state of view vector, direction or angle (whatever is necessary to be able to render with the current code).

It's up to you, but you would probably get a better "fake" 3D illusion, if you split the rendering of the background and the road into different sections, even if using the same rendering code (configured differently).

[presh]

This is a great technical achievement, very nicely done

I've enjoyed playing it a quite a few times, I know the first course almost inside-out and got as far as the 3rd race so far.

My only gripe is with the red bumper things on the 1st stage - I keep getting stuck bouncing between them and the track edge, with no escape, until I blow up. It's rather annoying when you're on the last lap, full shields, 1st place and you run into one of these "insta-kill" traps Perhaps they can be a little less aggressive with a chance to escape?

Anyway I've just bunged you a few € for it (though you deserve a lot more, hopefully people are being generous!) and notice the version number is different, so maybe it's been tweaked since the I downloaded the "competition" version.

I'm super curious as to how you implemented this, though I imagine it's waaaay complicated and difficult to summarise, and would probably go over my head anyway!

[voxeltower]

My only gripe is with the red bumper things on the 1st stage - I keep getting stuck bouncing between them and the track edge, with no escape, until I blow up. It's rather annoying when you're on the last lap, full shields, 1st place and you run into one of these "insta-kill" traps Perhaps they can be a little less aggressive with a chance to escape?

I'm super curious as to how you implemented this, though I imagine it's waaaay complicated and difficult to summarise, and would probably go over my head anyway!

Thank you very much friend, theoretically the ships should not be blocked in those traps since they bounce diagonally and the edge of the circuit horizontally / vertically, therefore the trap should push you out.

But many players have commented to me so it should not be fine at all.

Do not think that it is so difficult. It is simply pre-calculated data stored in a large array to do the "hard" work for the z80, and in this way, the cpu only do a few 16-bit sums and little else. Although it is very striking, it really is not something very complex.

[patters]

DivIDE/DivMMC interfaces will load data from tape image files only by employing the ordinary ROM loading scheme. Normally you would call the LD-BYTES loading routine at 1366 for loading headerless code blocks with:

Code: Select all

  LD A,255 
  SCF      
  CALL 1366
  RET

I see the first two instructions are swapped in the code posted above, maybe that could be the issue? I didn't try the game on the DivMMC myself by the way, I only downloaded and had a quick go at it yesterday, under emulation.

So I tried swapping the two instructions at 42268 and testing the modified file by emulating the DivMMC with SpecEmu. The program crashed after loading the last block.

[mention]voxeltower[/mention] - are you perhaps able to debug the DIVMMC issue using SpecEmu? People playing the game on real Spectrum hardware are quite likely to use these devices, rather than waiting 10+mins with a TZXduino player.

[voxeltower]

Hello friends, I have uploaded a new version with feedback that you have told me here.

New version 1.3 (new improvements: fov/distance, monochrome mode, scene and difficulty check, and more...)

https://voxeltower.itch.io/spaceracing

@voxeltower - are you perhaps able to debug the DIVMMC issue using SpecEmu? People playing the game on real Spectrum hardware are quite likely to use these devices, rather than waiting 10+mins with a TZXduino player.

Sorry patters, but today I have tried with RetroVirtualMachine adding a DIVMMC device to spectrum 128kb creating a virtual sd and adding the game. I have tested it and it worked without any problems.
I'm not sure but it could be because of the firmware of your divmmc?, it's strange that it works in all versions of spectrum and error in your divmmc.
In any case, if someone knows how to patch it so that it works, tell me to let me know and we'll do it. Thank you.

[flatduckrecords]

[mention]voxeltower[/mention] a very cool game, I love the style and the sense of speed is great!

[mention]patters[/mention] are you using a Toastrack? I've just tested on mine and it crashes about 75% of the time. It seems to load normally on my Harlequin (even when using Toastrack ROM, or +2A ROM) and it loads fine on a real +2A.

I'm using esxDOS 0.8.9 on a DivMMC Future, and I tried it with both the standard NMI menu, as well as [mention]bob_fossil[/mention]'s LFN browser. There doesn't seem to be any pattern though, sometimes it works from a cold-start, but often it crashes. It seems a bit more reliable in the LFN browser though (as long as you load after a warm reset, it seems? I'm not sure). I also tried just using esxDOS commands without invoking the browser, but that didn't seem to particularly help. The only thing in common was loading via DivMMC on a Toastrack often crashes after the loading screen. DivMMC on the other Spectrums seems to load fine.

I hope that's helpful!

[patters]

Yes, I am using a Toastrack. And I am also using esxDOS 0.89 with Bob Fossil's LFN browser, on DIVMMC Future, for what it's worth.

[presh]

Hello friends, I have uploaded a new version with feedback that you have told me here.

New version 1.3 (new improvements: fov/distance, monochrome mode, scene and difficulty check, and more...)

Awesome!

I seem to be doing much better at it now... I'm onto the 6th race and in 2nd position on the leader board, only lost a couple of lives so far!

Think I found some sneaky short-cuts in the first couple of races which have no doubt helped!

(I did try one on the Jupiter Mine track but I think that's a figure of 8 and you've foreseen that... so no such luck there, ha!)

[presh]

Ah bugger, seems I spoke too soon... found a bug (hardlock), so can't progress and have been bouncing up & down for quite a few minutes now, with no sign of the race ever ending, so I can't even restart on a new life

This happened when I approached the yellow "jump" bit slowly after crashing into a wall... I landed halfway into the "wall" and it bounced me back into the yellow bit, and now I'm just bouncing up & down and none of the keys are doing anything.

A "quick fix" could be that the yellow bits only make you jump if you're going over a certain speed? As that would allow me to escape at least.

https://www.youtube.com/watch?v=POIa_U7BwJg

(By the way, the video is set to "Unlisted" so doesn't appear on my channel or in searches etc)