Space Racing

[Andre Leao]

Released!





https://planetasinclair.blogspot.com/20 ... acing.html

[voxeltower]

Space Racing v1.2 update

https://voxeltower.itch.io/spaceracing

[StanVanman]

Quite amazed that nobody's had anything to say about someone CONVERTING F-ZERO TO TNE SPECTRUM!

[Andre Leao]

There is a new version for Spectrum Next

[Ralf]

Oh my, how to start...

This is a very ambitious attempt which is great in many ways but it lacks something
that I could just sit and enjoy it for hours.

It uses a very original approach. It uses a 3D engine which was probably really hard to create. It's fast (fast and furious )
It's smooth. It's big with lots of graphics and content. It's climatic.

But the static graphics seem often not created for Spectrum but autoconverted from some more powerful machine.
So they either have this nasty random dither or are a confusing mix of colours where it's hard to say what is what.

And the dynamic 3D graphics during the game are square and blocky (probably to make it fast) with lot of colour clash.
And the acual playing area is narrow, only 1/3 of the screen.

It all wouldn't matter if the gameplay was great. But because of everything mentioned above it was for me often hard to see
what's going on the screen so I got lost on the track or crashed into something.

It's like Wolfenstein or Doom on Zx Spectrum - great achievement if we consider Speccy limitations
but I would still choose Jetpac for a moment of fun.

Feel free to disagree with me, guys

[AndyC]

Quite amazed that nobody's had anything to say about someone CONVERTING F-ZERO TO TNE SPECTRUM!

Not embedding a YouTube link to footage of the game in action, or at least some in game screenshots is quite a big barrier to getting attention.

[p13z]

Not embedding a YouTube link to footage of the game in action, or at least some in game screenshots is quite a big barrier to getting attention.

I had the same thought - but there is actually a youtube vid shown on the link for the updated version, a couple of posts above this.

Yes, 3D floor plain looks awesome, and this is all seriously technically impressive, but the rest of the graphics / animation don't do it justice somehow.
I hope the guys who did this are motivated enough to milk this a bit more, maybe a sequel or something else using the 3D engine.

[Ralf]

Here's a Youtube video for you:
https://www.youtube.com/watch?v=T_MSKsBDJuE

By the way, I had problems with loading this game in Spectaculator. I had to turn fast loading off so it worked.

[Andre Leao]

Quite amazed that nobody's had anything to say about someone CONVERTING F-ZERO TO TNE SPECTRUM!

Not embedding a YouTube link to footage of the game in action, or at least some in game screenshots is quite a big barrier to getting attention.

My fault, I didn´t notice I posted twice the loading screen...

[patters]

It certainly is an amazing technical achievement. I do think it is a bit tricky to play though with such a limited draw distance. I think that could have been somewhat mitigated by displaying a track map overlay like the real SNES game with a blinking dot on it to show progress. Not sure how much of an impact that would have had on the CPU cycles the 3D engine needs though. Probably couldn't be done or it would have been

I know the new loading screen is meant to represent SNES box art, but I rather liked the earlier proposed loading screen (from the ZXDev forum, and from Voxel Tower's Twitter).

[voxeltower]

New video with tips to play and walkthrough

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


I am reading your comments. Obviously the game is not perfect (any game is?). The biggest problem I've had in making the game is getting an acceptable speed for a racing game.

It takes a lot of calculations to render a mode 7 (even if it's fake). For this reason I have had to use a very low resolution (1/3 of the screen and rendering every 2 lines), which leaves me with a resolution of 32x32.

By having such a low resolution and such poor precision in the calculations (16 bits) I cannot draw very small elements on the screen since they would not be distinguished in any way (I did a thousand tests before deciding), that is why the camera renders little section of track, since if it does farther than that distance would not look good. It could do better visually but the game would go down to 1 fps or less and it would be 100% unplayable.

Remember that the snes graphics chip is a beast compared to a z80.
When rendering such a short section I have had to put aids on both the track (arrows) and the indicator above (curves and jumps).

The only solution to avoid the colour clash in this game is to make it monochrome, but with the low resolution I don't think it would have been better this way.

Thanks for the constructive criticism, it will help me to improve in the future.

[Ralf]

Hi Voxeltower, welcome to Spectrum Computing (or were you here before)!

If you ever wanted to improve this game a bit more, here are some hints that seem doable to me:

- improve static graphics, as I said they seem to be a result of some automatic converter. I've seen earlier
loading screens and as other people say, they seem better than what we have now.

- improve scrolling of background (city or mountains in the horizon). Currently it seems to move by 8 pixels which
is jerky. Maybe it would be possible to make it smoother? Check classic games like Chase H.Q or even Outrun

- I would like an option to disable colisions with other vehicles. You would just run through them. The game would be
easier but still a challenge.

[patters]

The TAP file seems to crash after displaying the loading screen on a real Toastrack with a DIVMMC Future card. I guess that's the point at which the code executes. It works fine on emulation, but it would be best to play this on the real hardware.

[AndyC]

Honestly it's a technical marvel. I have no idea how you managed to pull it off, but from a technical standpoint it really is quite a staggering achievement.

I can't say I'm much of a fan of the SNES original though, I always found it too floaty and a bit too reliant on memorising the track and I'm not sure the shorter draw distance here helps that.

Still blown away that anyone even tried to recreate Mode 7 on a Speccy, let alone actually pulled it off though.

[Pegaz]

Technically, very nicely done, the 3D animation is really good, but the visibility and field of view on the track isn't, which affects the gameplay.
However, I really like the game, there is potential for improvements and actually it reminds me a lot of Amiga's Virtual Karting.

[voxeltower]

The TAP file seems to crash after displaying the loading screen on a real Toastrack with a DIVMMC Future card. I guess that's the point at which the code executes. It works fine on emulation, but it would be best to play this on the real hardware.

I'm not sure, the game when starting up keeps loading from the cassette to insert more data in the rest of the memory pages. It may be because of this. I have tried Retro Virtual Machine, Fuse and ZEsarUX and it has worked in all of them. And use ROM1 for this load.

I am not an expert in spectrum, possibly I am doing something wrong. Any ideas?

[patters]

I'm not sure, the game when starting up keeps loading from the cassette to insert more data in the rest of the memory pages. It may be because of this.

Is it using any kind of custom loading routine, or the ROM one? DIVMMC won't work with custom load routines AFAIK.

[4thRock]

For this reason I have had to use a very low resolution (1/3 of the screen and rendering every 2 lines), which leaves me with a resolution of 32x32.
...
Thanks for the constructive criticism, it will help me to improve in the future.

Being constructive, I think that gameplay could be adapted to better suit the engine's strengths. For example:
- track with less sharp turns (more like a race track)
- slower speed, make driving more technical
- trade horizontal for vertical resolution (16x64) and/or reduce horizontal play area (might improve perceived resolution)
- less use of color (use it to distinguish some parts of the track, like beach, grass, rocks, but same color overall)
- less dither (improves "readability" of the play area)

The engine is a great achievement and has a lot of potential

[Alone Coder]

There was a similar engine for Russian clones (it's absent in zxdb, I don't know why):
https://youtu.be/al0DFlyvpuc?t=30
Sources: http://alonecoder.nedopc.com/zx/NEDODSRC.rar

[AndyC]

The 90° (or sharper) bends are pretty much what makes F-Zero and really the only reason to prefer a Mode 7 style renderer over a more traditional one. I can see how they're problematic with such a short view distance though. Trading horizontal for vertical resolution, if possible, might be a good compromise though.

[voxeltower]

Is it using any kind of custom loading routine, or the ROM one? DIVMMC won't work with custom load routines AFAIK.

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?

Code: Select all

void zxt_loadFile(u16 destino,u16 lenght)  __naked {
    __asm
		push iy
        	ld iy,#4
	        add iy,sp  //Bypass
        	ld l,0(iy)   
		ld h,1(iy)   
		push hl
		pop ix
		ld e,2(iy)   
		ld d,3(iy)   
		SCF
		LD A, #0xFF
		call #ROM_LD_BYTES		//macro 0x0556
		pop iy		
		ret
	__endasm;
}

I have written down the rest of the notes that you have commented to me, to see what I can do. Thank you all.

[XTM]

This looks very impressive. I'm sure it was very hard to implement this, so kudos for even trying such a crazy graphics engine (insert "thumbs up" smilie here, which we don't have). Sadly I'll have to agree with some posters that there are some issues, the main one being that it's sometimes hard to see where you're supposed to go, but I suppose there isn't much to be done about this.

Ralf mentioned the scrolling of the background (city or mountains in the horizon) being a bit jerky. And this is what directly leads me to the feeling of abruptness of steering. When you steer left or right, there is only 1 frame of animation of your vehicle pointing left or right. It would feel less abrupt and thus smoother if there was at least one intermediate animation frame of the vehicle (and maybe having the background moving only 4 pixels to the left or right) being displayed for a very short amount of time before the fully steered vehicle graphic and 8 pixel movement of the background kicks in. All this regardless of the actual steering/displacement of where you are on the "mode 7" field, I feel it would just give you the illusion of being smoother.

I'll assume the 8 pixel scrolling of the background is due to memory limitations as having pre-shifts of the background may be too costly to implement, additional frames for the vehicle would also cost memory as we're talking 4 different vehicles. I just feel the general impression could be better if it was this way, so please take it as the constructive criticism it is meant as

[patters]

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 - [mention]Alessandro[/mention] or [mention]Ast A. Moore[/mention]?

[voxeltower]

Ralf mentioned the scrolling of the background (city or mountains in the horizon) being a bit jerky. And this is what directly leads me to the feeling of abruptness of steering. When you steer left or right, there is only 1 frame of animation of your vehicle pointing left or right. It would feel less abrupt and thus smoother if there was at least one intermediate animation frame of the vehicle (and maybe having the background moving only 4 pixels to the left or right) being displayed for a very short amount of time before the fully steered vehicle graphic and 8 pixel movement of the background kicks in. All this regardless of the actual steering/displacement of where you are on the "mode 7" field, I feel it would just give you the illusion of being smoother.

No problem, seriously, any well-explained criticism is welcome for me ever. But anyway I would like to explain the movement of the background because I think we are all wrong (including me ).
Used to playing 2d racing games, we always see that the background moves smoothly, but this is not realistic at all, and I will show you very easily.

This game is 3d, so you have to think in a 3d camera.

In the current version, game moves the background to 16 pixels in each frame that you are rotating (not 8), I chose 16 simply because the code was faster, there is no other reason. Just don't calculate it.

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

(image attached to be more visual)

Maybe I was wrong in the calculations, but it seems to me that they are correct.

If the game had a higher framerate, everything would be smoothed out.

I mean, neither 16 as I thought, nor 8 as it seemed, nor 4 as you would like. It really should move 36 pixels per frame to be realistic.

Buuuuuuuut something that I have learned in the years that I have been making videogames is that "Feeling > Realism" therefore, if it feels better moving 4 or 8 pixels it is better to do it that way even if it is not realistic. Soooooo you're right, I'm going to smooth that move.

[Ast A. Moore]

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

Hmm. Don’t think I can think of anything off the top of my head. I have zero experience with the DIVMMC, I’m afraid. An interesting problem nevertheless.