emkay Posted March 6, 2017 Share Posted March 6, 2017 But this is on 1.79 MHz CPU that is 8-bit and you need to handle 16-bit values. You have to write two different rendering engines, sync them without glitches and on top of that write physics engine. Why would anyone need two different rendering engines? I'd really love to see the frame stats breakdown - e.g. how much % goes to physics, collision detection, world processing, Z-sorting and rendering. It is no breakdown of fps, it's some irregular presentation of the frame content, timewise. If you look at the Amstrad part, it runs at around 4 fps, but the projection is right. Quote Link to comment Share on other sites More sharing options...
VladR Posted March 6, 2017 Share Posted March 6, 2017 Why would anyone need two different rendering engines? It is no breakdown of fps, it's some irregular presentation of the frame content, timewise. If you look at the Amstrad part, it runs at around 4 fps, but the projection is right. I'm still not sure that the horizon is not at least a partially separate codepath. Initially, I incorrectly thought that horizon is rendered as regular pixels - e.g. Gr.7. But since it can rotate, you can't just switch to charset on lower scanlines. So, it's all charset, hence the horizon is charset too. So, it's now reasonable to presume it's all using same , single, technique for both horizon and terrain. As for the "breakdown of fps" - I meant benchmark profiling - e.g. something like : 32.7% (charset line drawing), 11.2% (projections), 17.3% (drawing the chars) - things like that... I was wondering , if this is 6 fps, what is the framerate of TestDrive on C64 then ? 3 fps ? Quote Link to comment Share on other sites More sharing options...
emkay Posted March 6, 2017 Share Posted March 6, 2017 I was wondering , if this is 6 fps, what is the framerate of TestDrive on C64 then ? 3 fps ? Up to 4 (Hill & Street) , as it seems. Moving objects move 3 steps in a second. Quote Link to comment Share on other sites More sharing options...
VladR Posted March 6, 2017 Share Posted March 6, 2017 Up to 4 (Hill & Street) , as it seems. Moving objects move 3 steps in a second. Well, then it's taking 15-20 vblanks per game frame. And there's no complex 3D vector-based physics (compared to, say, StuntCar), which must be taking a lot of CPU time. One has to wonder then, though. If we spent 20 vblanks on A800, just to compose one game frame, how much stuff could be drawn, pixel by pixel. How many cycles are available in Gr.7 in total ? I'm thinking just vanilla Gr.7 with 4 colors so that we have as much CPU time as possible. I saw a cycle table somewhere here, just can't remember which thread... Or, perhaps, have first half of screen in charset (for static things like sky) to leave more CPU time, and only have bottom 100 scanlines in Gr.7 - for 3D environment. I never really considered 3-4 fps as a release candidate, but apparently, it was happening, out there, just fine. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted March 6, 2017 Share Posted March 6, 2017 Well, then it's taking 15-20 vblanks per game frame. And there's no complex 3D vector-based physics (compared to, say, StuntCar), which must be taking a lot of CPU time. One has to wonder then, though. If we spent 20 vblanks on A800, just to compose one game frame, how much stuff could be drawn, pixel by pixel. How many cycles are available in Gr.7 in total ? I'm thinking just vanilla Gr.7 with 4 colors so that we have as much CPU time as possible. I saw a cycle table somewhere here, just can't remember which thread... Or, perhaps, have first half of screen in charset (for static things like sky) to leave more CPU time, and only have bottom 100 scanlines in Gr.7 - for 3D environment. I wouldn't worry about speed of drawing at all. If C64 can do it, A8 can do it even better. Maybe I'm repeating myself but check out some recent demos for Atari. For example here is voxel terrain that is much more complex than what Stunt car racer needs to draw and it runs in really good speed. https://youtu.be/g3u-hGxT9XE My guess what SCR does with drawing is only 20-30% of time spent. Rest is all about physics and how cars move.. Who knows, maybe we could even make racing game over voxel landscape 1 Quote Link to comment Share on other sites More sharing options...
VladR Posted March 6, 2017 Share Posted March 6, 2017 Voxels are great for flying games, not car driving ones. That voxel terrain would be great for star-wars-style flying / racing, for sure. I wouldn't want to drive a vehicle there and try to discern hill from flat area in that voxel terrain. Programmatically, voxel is way less complex to implement, obviously - so it would have a huge advantage in the whole implementation process. Where the voxel would be great for racing however, is if you had a scanline road rasterizer (say, like Electra Glide) and put the voxel terrain right by the road - like in Need For Speed. Now that would give you best of both worlds and look awesome Wonder why noone did that actually... Quote Link to comment Share on other sites More sharing options...
toddtmw Posted March 7, 2017 Share Posted March 7, 2017 What is project M? Quote Link to comment Share on other sites More sharing options...
Mark loves Stella Posted March 7, 2017 Share Posted March 7, 2017 What is project M? Here is a video demo of Project M 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted March 7, 2017 Share Posted March 7, 2017 Could be interesting to have some "racing game" that resembles the road, using voxels. Driving between hills, and so on. But, please, in Graphics 7 and without black scanlines. As that may result in an ego view game, the front of the car could be done, using PMg with overlay. Quote Link to comment Share on other sites More sharing options...
VladR Posted March 8, 2017 Share Posted March 8, 2017 I was rewatching the Let's compare YT video and then it hit me - we could actually use the Atari 8-bit techniques on the Atari 64-bit console In short: - separate screen into 2 parts : - blue sky (could be a texture, but that would not artistically match with the flatshading look) - brown "terrain background" - rotate them (clock-wise and counter clock-wise, as the car is following the track) using ObjectProcessor - create the 3D "polygons" only by drawing the lines, just like on the 8-bit console - fill only those few small polygons that occasionally cross the border between sky and terrain Now you're probably thinking "WTF would be the point of that ?" But hear me out. Since we do not have to fill 95% of the screen (pixel by pixel, as would be the case in classic polygon rasterizer), we've saved enormous amount of bandwidth (which is at quite a premium on jaguar). So, it follows, that this technique should run even at the highest resolution of jag, which is 1400x480, since we're basically just drawing lines (plus few small polygons above the horizon, occasionally) This should look sharp even on 60" TV Clearing framebuffer 1440x480 (656 KB for 256 colors, or 328 KB for 16 colors - which should be enough for this environment) would take 10 times longer than 320x200 (64 KB), so that's a problem, but still Blitter should be able to do that within 1 vblank. it would be certainly faster to just erase old frame lines and draw new ones. My last line-drawing benchmark shows that about 18,000 line pixels can be drawn on GPU within 1 vbl. There's definitely less than that in those scenes. Even if we halve that number (to account for erasing), there still should be some buffer left. Worst-case scenario - 2 vblanks and 30 fps. But 1400x480 3D game on Atari - it's so crazy it just might work These threads are so inspiring - thank you guys ! 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.