Last night i watched this video on youtube.
I was thinking a vector library / RSX set could be a good thing for BASIC games if I were to code those. I did notice howeve the video seems to be isometric rather than perspective. Does anyone know if perspective has a more taxing load than isometric on a z80?
Also has anyone already got experience coding this stuff who would like to provide their code to me to bundle into an RSX library? I'm thinking fast rendering of 3d object lists with some collision detection options. Perhaps automatic rotations or animation like my JS sprite library - the same principles could work.
Likewise does anyone have any superfast line drawing routines for different modes?
List vector games on CPC:
- 3D Tennis
- Battle of the Planets (very fast and smooth)
- Cholo (a bit slow, I didnt really get the game)
- Elite (fantastic game with not bad vectors)
- Mercenary (I didn't really get the point of this game)
- Starglider (awesome game and vectors)
- Starion (not bad game but awesome vectors)
- 3d Star Strike (I really like this, and fast if not chunky)
- Star Wars (nicer looking than 3d Star Strike but not as fast/smooth)
- Empire Strikes back (slightly better than Star Wars vectors)
- Thrust (very smooth, a classic game)
- Top Gun (fast)
Filled in Vectors (not really wanting the initial library to cater for graphics like these):
- Freescape games
- Star Strike 2 (looks fantastic and fairly fast)
- Battle Command
- Carrier Command (both fantastic achievements)
- Sherman M4
https://www.youtube.com/watch?v=nUuxp0-KRJQ&t=25s (https://www.youtube.com/watch?v=nUuxp0-KRJQ&t=25s)
The Thrust games.
Bryce.
Does 3D Tennis help?
Out of the list you did, Starion is the most outstanding too me. It's so fast and smooth; I'm blown away at how this was achieved.
For full-3D, also add:
- Battle Command
- Carrier Command (both fantastic achievements)
- Sherman M4
So, these games have one thing in common: the faster it is, the more limited is the 3D display.
Complete freedom is slow, some "clever" limitations (like the limitation to convex bodies in Elite or Starion) is already pretty fast, and pseudo 3D then is even faster (3D Star Strike doesn't look like that are real 3D calculations at all, more like a clever drawing routine, that looks like it's 3D).
I doubt that it will be possible to create a library for Basic that will be fast enough for any action based game or simulation. The Basic overhead is just too big.
(One thing that came to my mind a few weeks ago was to use a PIC or other CPU as a coprocessor for the Amstrad. So a library would basically delegate calculations to the much faster external CPU. But that would kind of cheating and limit any software to owners of such an add-on.)
Quote from: eto on 13:50, 09 July 21So a library would basically delegate calculations to the much faster external CPU
No, this wouldn't really improve the framerate. It is not the calculation that really takes time, but the display. In that your additional CPU wouldn't help you.
Quote from: Targhan on 08:37, 10 July 21No, this wouldn't really improve the framerate. It is not the calculation that really takes time, but the display. In that your additional CPU wouldn't help you.
Oh, ok. Now I am curious. From my memory, the 3D calculation is a lot of multiplication. Or are there fast routines for that?
Quote from: eto on 09:51, 10 July 21Oh, ok. Now I am curious. From my memory, the 3D calculation is a lot of multiplication. Or are there fast routines for that?
Nothing of this is fast on the CPC (or Z80 in general).
3D Star Strike is not pseudo 3D, but takes a few short cuts (as does Starglider). Starion looks faster than the other games but does only implement parallel projection (which looks like shit) instead of perspective projection like in Starglider.
I might add that Starglider also uses hidden line removal for the main body of an object ("only" that is, so the battle tanks cannon is exempt, as is the Walker's legs).
Starglider was developed by Realtime Games Software which did all the Z80 8-bit ports and the IBM PC port (from the 68k originals by Argonaut games).
Many of their games have already been mentioned here:
Star Strike
Star Strike 2
Starglider
Battle Command
Carrier Command
So, if you'd like to program a mostly complete engine, take a deep dive into their games. But the viewports for most of these games are 128x64, and you're mostly in single digit framerate territory.
And that's about what you can expect of a feature rich Z80 3D engine. Any optimisation leads to a specialised 3D graphics engine that's not usable for a lot of other purposes. Demos with 3D graphics usually take such short cuts somewhere if they want to impress with speed.
An additional CPU wouldn't help much because communication with the co-processor will eat a sizeable bunch of Z80 cycles from the cycles you think you saved, and you'd still have to render every frame of the image with the Z80 in the CPC (something Targhan alluded to already in his post above).
Once you tread on that path, you could basically just use another faster computer altogether.
Top Gun is also a good one.
Quote from: Targhan on 08:37, 10 July 21
No, this wouldn't really improve the framerate. It is not the calculation that really takes time, but the display. In that your additional CPU wouldn't help you.
I was thinking that via BASIC we can program the scene with a couple of RSXs to manipulate the scene, as well as RSXs to update the display, and a collision detection RSX. The core game logic could be in BASIC still.
As for Matrix calculations, we are a community, maybe we can put the best Z80 calculations in there, with the best line-drawing routine in the renderer too.
Does anyone have any existing fast 3d vector calculations and line drawing routines for CPC?
What is the point of having fast code if Basic is used? It would simply completely slow down the whole stuff. If you want speed, use assembler all along, especially in 3D. Think about what would be the "bottleneck". It wouldn't be the display anymore... but the Basic.
Yeah, I suspect for fast 3D you need to eek every last ounce of performance out of the machine. Dropping back to BASIC for anything is going to undermine that to the point you might just as well keep all the 3D logic in BASIC anyway where it'll at least be readable to BASIC coders.
Quote from: zhulien on 02:12, 12 July 21I was thinking that via BASIC we can program the scene with a couple of RSXs to manipulate the scene, as well as RSXs to update the display, and a collision detection RSX. The core game logic could be in BASIC still.
Calling machine code from Basic has significant overhead. I just recently did some tests and for an RSX call, you "waste" between 1 and 2ms of CPU time, just for the pure RSX call. Plus almost. 0.5ms PER parameter that you send to your code. So easily 2.5ms for an RSX call with 2 parameters. If I am not mistaken, that would be the equivalent of 2500 NOPs that already have been wasted before anything relevant happens.
So an RSX library would probably not make a lot of sense for any action game. But maybe for something where frame rate is not relevant, like a text adventure with added 3D graphics.
Besides the games mentioned above, I remember my personal fave: Stunt Car Racer
Was fast and very playable!!
On the subject, back in the 20th century, I did some work with vector objects in Basic.
The fastest way is to have all your calculations done and stored ready in an array for all angles. And use results in integer only .
Quote from: Targhan on 08:29, 12 July 21
What is the point of having fast code if Basic is used? It would simply completely slow down the whole stuff. If you want speed, use assembler all along, especially in 3D. Think about what would be the "bottleneck". It wouldn't be the display anymore... but the Basic.
What is the point of a print command that can print strings in BASIC if you have a print command that can only print a character and a loop? Surely BASIC couldn't allow programmers with BASIC knowledge to print strings faster with a print command that can prints strings vs a print command that can print characters only?
The difference is that machine code is fast enough to do the printing and have lots of time left over to accomplish other work in BASIC.
There is barely enough grunt in an 8-bit machine to run a purely machine code 3D solution, you are almost certainly having to cheat slightly and squeezing every last cycle you possibly can for performance.
Handing any of the work at all over to the slow world of interpreted BASIC will entirely undo that and drop you straight back into a world of frames per minute rather than per second. And when you are that slow, the performance becomes irrelevant - the 3D aspect is going to only be useful for static content anyway, so you may as well let BASIC do all the work.