Hi CPC friends. I have been working on a new game for our beloved computers for some time. I think it's far enough along that I think I can finish it (I hope I'm not wrong).
CPC Formula 1 is going to use a similar (albeit improved) technique to the fake mode 7 that it uses in Spectrum's Space Racing game. I have spent a lot of time trying to improve the effect and make it go as fast as possible in our Amstrad, I hope you like it.
Luckily, in CPC we don't have colour clash and it looks a bit better.
I'm trying to get the game to run smoothly on 464, though I'll probably make a version with some improvements for 6128.
Now I am adjusting the graphics of the game before showing it. Soon I will show the progress of the game.
Looking forward to it!
Ooh, sounds interesting. Can't wait to see it.
Hello friends, after getting stuck with this project :doh: , I decided to take a temporary stop and later return to the project.
During the stop I made "Sugar City" and started some projects for other systems.
The stop has been good for me, I have come up with many ideas to optimize and improve this game.
I am working again, finally made the decision to do it for 6128, since, although it can work in 64kb, it would involve a lot of cuts and multi-loading from cassette :'( (the scenarios are very large), so I have decided that it is better to do it for disk.
Using 6128 I have been able to improve mode 7 visually and in terms of speed.
If all goes well, the game will put 16 cars on the track, 128x64 tile scenarios and will offer a different type of racing game.
I hope to be able to show something soon. Thank you so much.
Hello
I didn't understand good how the game is. Is it the typical where you place the camera behind the car?
Quote from: luckpro on 08:54, 11 March 24Hello friends, after getting stuck with this project :doh: , I decided to take a temporary stop and later return to the project.
During the stop I made "Sugar City" and started some projects for other systems.
The stop has been good for me, I have come up with many ideas to optimize and improve this game.
I am working again, finally made the decision to do it for 6128, since, although it can work in 64kb, it would involve a lot of cuts and multi-loading from cassette :'( (the scenarios are very large), so I have decided that it is better to do it for disk.
Using 6128 I have been able to improve mode 7 visually and in terms of speed.
If all goes well, the game will put 16 cars on the track, 128x64 tile scenarios and will offer a different type of racing game.
I hope to be able to show something soon. Thank you so much.
Sounds really good luckpro sure will be impresibe, sugar city was
Quote from: Fran123 on 19:24, 31 March 24Hello
I didn't understand good how the game is. Is it the typical where you place the camera behind the car?
If you look up Space Racing on the Spectrum it should be clear.
Sounds interesting, I look forward to seeing it.
Hi Fran, Jesus and Anthony,
As Anthony has commented, the idea is similar to that used in Space Racing. The camera is behind the car (to be more correct inside the car) and the track is drawn in 3D like f-zero or mario kart. In addition to the track, I also draw walls (Space Racing does not have this).
The good thing is that in CPC I don't have the graphical limitations of Spectrum and it looks better.
Thank you.
I invented a steering wheel for the cpc. It would be connected through the expansion port. I have not implemented it but the scheme is very simple. It could be turned with different degrees and the steering wheel and brake would also have different degrees.
https://Twitter.com/voxeltower/status/1782502770194464889?t=J3qQx3S7QhBw-qQmBVC2ow&s=35
Video upload here too : https://files.fm/u/swvbte6uj2#/view/a8zaq899jm
Looks great, are there any technical details how this fake mode 7 works in this game?
Line doubling? 32 char wide screen for optimal maths? Byte addressing, not nybble.
Mode 7, point & click adventures (https://www.cpcwiki.eu/forum/games/the-key-a-a-full-point-and-click-game-for-cpc/)...
At this rate, the Amstrad CPC will be receiving a Tomb Raider 3D port by 2050 and a Shadow of the Colssus one by 2075.
The bits of this machine are duplicating every few decades!
That is mighty impressive!
I would love to see the actual car you are driving to give it that FZero vibe.
I was also thinking how nice it would be to not make it an F1 game, but a PowerDrift type of game instead so that it would have hills, dips and jumps. I'm guessing that a lot more memory would need to be freed up, so it would probably need to be a mode 1 game?
Quote from: Fran123 on 15:51, 13 April 24I invented a steering wheel for the cpc. It would be connected through the expansion port. I have not implemented it but the scheme is very simple. It could be turned with different degrees and the steering wheel and brake would also have different degrees.
It might be interesting to add support for it. even for the mouse interface. Thank you.
Quote from: Sykobee (Briggsy) on 11:55, 23 April 24Looks great, are there any technical details how this fake mode 7 works in this game?
Line doubling? 32 char wide screen for optimal maths? Byte addressing, not nybble.
Fixed sky area (6 chars), double buffer game area (13 chars), fixed car view area (6 chars), 32 width chars to optimize memory space for double buffer (not strictly for the maths) <---- SyX programmed me the interrupt function to use this configuration. Thanks SyX I owe you a beer :laugh: .
The game area have 8 chars to draw mode 7 (calc 32 lines and i duplicate it to 64 lines) and 2 chars to background image.
Right now, the game runs at an average of 8/10 frames/sec (if you have to draw walls very close the framerate can drop quite a bit :'( ). But I still have a lot to implement and it may change a little.
To make fake mode 7 (Patent pending :laugh: ) i have a table with precalculated data of the view (xy displacement of each visible line at that angle) and the game moves the player's position and calculates what color is drawn at that position in a loop.
To make these calculations faster, the game uses a part of the tile map and transforms it into a little bitmap in runtime (1 track pixel, 1 byte) so as not to need to process the nibble or tile information in the loop.
Walls info is in the same tile pixel info. While the loop check the pixel of the floor it can detect the wall and save it to draw at the end. The wall drawing scale wall info pixels in runtime.
If you want more specific information, ask me whatever you want. Thank you.
Quote from: sigh on 15:41, 23 April 24That is mighty impressive!
I would love to see the actual car you are driving to give it that FZero vibe.
I was also thinking how nice it would be to not make it an F1 game, but a PowerDrift type of game instead so that it would have hills, dips and jumps. I'm guessing that a lot more memory would need to be freed up, so it would probably need to be a mode 1 game?
Thank you sigh, unfortunately the engine is designed so that the ground is flat. It is drawn horizontally to make it faster. To do what you mention i would have to draw vertically and do more calculations, i guess it couldn't be done that quickly (or at least I don't know how to do it).
The graphics mode doesn't matter too much in memory for this game.
As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?
EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.
Quote from: cwpab on 09:57, 24 April 24As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?
EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.
Like you, several people have told me that there is little ground to be seen.
I'll try to improve that part.
The video is recorded using the RVM emulator although the quality is not very good (twitter limits...).
Thank you for feedback.
Quote from: luckpro on 11:43, 25 April 24Quote from: cwpab on 09:57, 24 April 24As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?
EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.
Like you, several people have told me that there is little ground to be seen.
I'll try to improve that part.
The video is recorded using the RVM emulator although the quality is not very good (twitter limits...).
Thank you for feedback.
ground seems big enough to me, you can improve readability with some columns or traffic signs maybe? Keep the speed! 8)
Ok, i will take note, i will check what signs usually appear on F1 tracks and try to replicate them.
Thanks for the feedback.
Looking forward to this.
Space Racing on the Spectrum was basically F-Zero before F-Zero was F-Zero :)
" Thank you sigh, unfortunately the engine is designed so that the ground is flat. It is drawn horizontally to make it faster. To do what you mention i would have to draw vertically and do more calculations, i guess it couldn't be done that quickly (or at least I don't know how to do it).
The graphics mode doesn't matter too much in memory for this game. "
Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
Quote from: sigh on 15:36, 25 April 24Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space
You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).
Quote from: andycadley on 16:29, 25 April 24Quote from: sigh on 15:36, 25 April 24Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space
You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).
Then I have been completely wrong all this time!
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
Quote from: sigh on 17:08, 25 April 24Quote from: andycadley on 16:29, 25 April 24Quote from: sigh on 15:36, 25 April 24Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space
You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).
Then I have been completely wrong all this time!
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
160*200*16 = ~16K
320*200*4 = ~16K
You have to drop in colour depth or resolution to actually save memory.
Quote from: andycadley on 18:27, 25 April 24Quote from: sigh on 17:08, 25 April 24Quote from: andycadley on 16:29, 25 April 24Quote from: sigh on 15:36, 25 April 24Was thinking that with the mode 1 graphics, you would have more graphics space for sprites?
It doesn't really work like that, Mode 1 has twice the horizontal resolution and half the colours, so the end result is graphics take the same amount of memory to fill the same physical space
You could save memory by reducing the colour depth of stored graphics and converting them on the fly but that loses speed (and it doesn't really matter what the target Mode is at that point).
Then I have been completely wrong all this time!
I thought a mode 0 sprite sheet that is 160x200 was 8kb and a mode 1 sprite sheet that is 320x200 was also 8kb?
160*200*16 = ~16K
320*200*4 = ~16K
You have to drop in colour depth or resolution to actually save memory.
Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.
For instance - if I were to draw a sprite that is 16*16, I would be able to fit more on the mode 1 sheet.
Quote from: sigh on 18:35, 25 April 24Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.
For instance - if I were to draw a sprite that is 16*16, I would be able to fit more on the mode 1 sheet.
Well there are half as many pixels across in Mode 0, so you can fit less 16*16 Mode 0 sprites compared to 16*16 Mode 1 sprites. But 16 Mode 0 pixels cover the same physical area as 32 Mode 1 pixels so it's not really a like for like comparison.
Ultimately there is absolutely no advantage to using Mode 1 over Mode 0 in terms of the number of sprites you'll get in a game. The only reasons to choose it are because you need the higher resolution for aesthetic or functional reasons (f.e. you have a lot of text) or because you have art designed for another system with square pixels (typically the Speccy but not necessarily) and don't want to spend time/effort/money reworking it.