Could Dreamcast et al handle this/that game/effect? *DC tech retrospective *spawn

[sheathx013]

I had already played Sonic R extensively by the time Crash Team Racing came along. It was, finally, a Mario Kart type game on another platform to be sure. But the level geometry, character models and effects didn't impress me. If anything, I thought the game was actually made up primarily of squares, not smaller triangles. I still own it today, and I definitely get the gameplay appeal, but not the performance appeal, especially in comparison to Parking Garage Rally Circuit.

 

[davis.anthony]

Is that the PSOne 'impossible port' footage?

It looks horrendous in terms of visual cutbacks/things missing and still appears to struggle with frame rate to me.

 

[Nesh]

Yeah still needs a lot of work

 

[Shifty Geezer]

From what I've recorded of the PS2 version, there are many between frame changes that would need to be accounted for and ruled out before arriving at a true framerate count of that version.

If we want to talk framerate, we need to define what we're counting. Same as resolution, you can have asynchronous updates. If the geometry updates 10 times per second but the particles update 30 times a second, is it a 10 fps game or a 30 fps game? Or a 40 fps game because the particle effects always happen after the geometry changes giving 40 unique frames per second?

I think the most sensible counting should focus on the geometry and camera updates - the moving bit that gives a sense of fluidity. If we want to then look at other aspects, we can evaluate them more directly rather than just clumping them in the 'framerate' metric. We used to do this 15 years ago when talking about a game's 'resolution' and ultimately settled on talking about the 'opaque geometry buffer resolution' that resulted in the majority pixels one could perceive on screen where other buffers would typically be lower.

It's worth noting that DF developed an automated system to gather the metrics on framerate, detecting every unique frame, so manual frame-counting is a step backwards from their frametime graphs and completely unnecessary if those are available. Of course their rolling averages could sample a different interval which may give slightly different results to manual framecounts, but the overall ball-park figures and averages can be taken as presented.

It's also worth noting that in B3D's technical discussions of yesteryear, we used to do frame counting and pixel counting and compare results. Richard Leadbetter was a part of those conversations and they led to the automated tools that DF uses. So discussions with the people who produce DF's content leads me to be very happy with their methods and whatever results they get. One's free to disagree with interpretations, but the data is good and trustworthy. I won't take a manual frame count over a DF automated frametime analysis unless there's clearly something sus in DF's figures.

 

[EsppiraK]

Is that the PSOne 'impossible port' footage?

It looks horrendous in terms of visual cutbacks/things missing and still appears to struggle with frame rate to me.

You should be more respectfull to others work, and by the way this is till work in progress, can't belive you haven't been call out by a moderator at this point.

This is the latest progress, it is improving, yes still a long way to go but calling a psone port is disrespectull to anyone involved and console warring.

https://twitter.com/x/status/1823949520624910825

Also the draw distance is, by default way higher than on ps2 since it is using the default PC configutaion, expect better performance when reduced to ps2 levels,
You'll see in the screenshot below that the lighst are absent on the ps2 version because the lod distance is lower, also the cranes are missing in the backgound, cars appear closer to the player on ps2 too and the road has shorter draw distance on ps2. as said expect a performance increase when the DC version matches the lower draw distance of the ps2.....

 

[Shifty Geezer]

That's a huge improvement. And I hope everyone can see the difference between actual 24 fps and the low framerate in the original footage that I counted. I see some people posted laughing responses to my claim that the '24 fps' footage wasn't anything like. After all that faff I went through to produce real counted evidence, I'm glad I needn't bother now if framerate counts are to be included.

 

[Nesh]

You should be more respectfull to others work, and by the way this is till work in progress, can't belive you haven't been call out by a moderator at this point.

This is the latest progress, it is improving, yes still a long way to go but calling a psone port is disrespectull to anyone involved and console warring.

https://twitter.com/x/status/1823949520624910825

Also the draw distance is, by default way higher than on ps2 since it is using the default PC configutaion, expect better performance when reduced to ps2 levels,
You'll see in the screenshot below that the lighst are absent on the ps2 version because the lod distance is lower, also the cranes are missing in the backgound, cars appear closer to the player on ps2 too and the road has shorter draw distance on ps2. as said expect a performance increase when the DC version matches the lower draw distance of the ps2.....

From now on I ll pretend I am the biggest PS2 fanboy ever and troll the shit of whatever is graphically missing so they will fix it faster

 

[davis.anthony]

You should be more respectfull to others work, and by the way this is till work in progress, can't belive you haven't been call out by a moderator at this point.

And how would you like me to be respectful? That video has very obvious cut-backs.

This is the latest progress, it is improving, yes still a long way to go but calling a psone port is disrespectull to anyone involved and console warring.

Not just any PSOne port, but an impossible port. And there are several parts in that footage that could subjectively be confused with late generation PSOne game.

This screenshot was taken at 1minute in to the video, and looks more PSOne, than it does DC.

You can pause the video any any given time and this is the quality of the visuals.

If this is an accurate representation of what the port looks like, it needs a lot of work.

Also the draw distance is, by default way higher than on ps2 since it is using the default PC configutaion, expect better performance when reduced to ps2 levels,
You'll see in the screenshot below that the lighst are absent on the ps2 version because the lod distance is lower, also the cranes are missing in the backgound, cars appear closer to the player on ps2 too and the road has shorter draw distance on ps2. as said expect a performance increase when the DC version matches the lower draw distance of the ps2.....

That is indeed what he said in the Tweet, but he also said this:

"The PS2 version features a dynamic lighting system implementing the full phong shading model, which we haven't even looked in to yet... and to pull that off is going to take every Dreamcast optimization trick in the book"

It seems that there is still a lot of things missing in this port and countless things to address.

It still doesn't have sound, heck the one Tweet said the DC VMU isn't working due to memory constraints a they don't have the memory load the VMU driver.

 

[Shifty Geezer]

And how would you like me to be respectful? That video has very obvious cut-backs.

You're being overly confrontational. You can talk differences as an engineer without using belittling language.

Not just any PSOne port, but an impossible port. And there are several parts in that footage that could subjectively be confused with late generation PSOne game. This screenshot was taken at 1minute in to the video, and looks more PSOne, than it does DC.

This isn't useful. If you want to look at what's missing, don't liken to a theoretical PSOne game but grab a screenshot from the PS2 version and compare/contrast the differences.

If this is an accurate representation of what the port looks like, it needs a lot of work.

It does indeed. Each WIP progression shouldn't be dismissed bluntly though. The progress is pretty remarkable. One can challenge what the port shows about DC's potential without needing to charge the discussion with passive-aggressiveness.

That goes for both sides. Too many people wanting to draw conclusions from a WIP effort instead of just waiting for it to develop.

 

[TapamN]

https://twitter.com/x/status/1823949520624910825

That video seems to be encoded at 25 FPS, so there's going to be judder playing it back on a 60/120 FPS display. So it's still not the representation of how smooth it really is.

 

[Davros]

cars appear closer to the player on ps2 too

could that be because the DC and PS2 have different fov's

 

[function]

could that be because the DC and PS2 have different fov's

Possibly yes, depending on whether widescreen mode has been selected.

A wider FOV would normally include more world detail and come with additional CPU load and probably some more work for the GPU as it sorts and bins more triangles prior to rendering.

 

[function]

I agree with you that at 44s in the first video, it's 20 something fps. At the earlier parts I counted, the driving, it's never getting that high. The off-screen one has some terrible frame pacing/weirdness, resulting in two visible changes per 'frame'. However, these are completely absent from the direct-capture, so I'm guessing it's some display-capture artefacting.

Actually I'm not even sure it's 20 fps where you say. Are we seeing TV motion interpolation in effect? There's very odd movements and smearing. You have a fairly regular 10-12 fps pacing, and then suddenly these moments of multiple small frames between larger changes, in between frames when the scenery moves but the animation doesn't change.

eg. This composite of two frames. Check the ghosting on the notice board.

View attachment 11869

I feel this source is unreliable and we don't need it anyway as we have the direct feed.

Going just off that, counting various points I'd say the game (or most accurately that video of it) is presently averaging around 10-11 fps. Lowest I've counted is 9 fps. At 1:11 frame counting in the video editor, it hits about 20 fps turning right in front of the grass but you can notice that as visibly smoother playing the video, and such smoother moments are very rare placing the average as pretty consistent with little variation.

This and the direct capture footage could well be from different builds of the game - they're coming pretty fast and some changes will be faster than others, and some things might even go backwards in some regards.

Direct capture is definitely preferable, but off screen capture is okay if the recording is good enough (ideally 120 fps for a 60 fps display).

When counting on this video I looked for definite changes in things like the position of street lights and of geometry - made easier by tris glitching out. If something was blurred or showing a double image I disregarded it and moved on to the next frame I thought it was clear that the world had finished moving from one position to another. I think sample periods for the camera covering overlapping frames on the tv is responsible for a lot of the video frames where there's movement, but it's not clearly one frame or another. I didn't count frames where I thought it was possible this was happening.

Response times of the screen - likely to be low for grey to grey-ish parts of the image on the tv and compression artifacts might not be helping either.

 

[Shifty Geezer]

This and the direct capture footage could well be from different builds of the game - they're coming pretty fast and some changes will be faster than others, and some things might even go backwards in some regards.

That's moot now as Esspirak posted an updated build with much better framerate.

Response times of the screen - likely to be low for grey to grey-ish parts of the image on the tv and compression artifacts might not be helping either.

Behaviour is still whack and I'm not comfortable with any frame counting off that screen. There are these 'frames between frames' that just aren't present in the later direct-capture smoother build. In the latest, greatest build, you have a regular frame pacing, faster or slower for framerate, without any sporadic second frames appearing between the ordinary pacing. There's no logic to the game rendering a frame in 100ms, say, and then suddenly managing to render two in 50ms each before going back to rendering frames in 100ms.

 

[function]

Behaviour is still whack and I'm not comfortable with any frame counting off that screen. There are these 'frames between frames' that just aren't present in the later direct-capture smoother build. In the latest, greatest build, you have a regular frame pacing, faster or slower for framerate, without any sporadic second frames appearing between the ordinary pacing. There's no logic to the game rendering a frame in 100ms, say, and then suddenly managing to render two in 50ms each before going back to rendering frames in 100ms.

I didn't count any 100ms frames, but I certainly didn't check the whole video. I did see a couple of points where the animation of the player character appeared to miss an update though, even as the camera had definitely moved.

I suppose that's what it's right to point out, as you did, about update rates of different parts of the game. You could certainly, for example, lose synchronisation of different systems and have the world geometry update but an animated character be resubmitted for drawing in the state it was last frame.

Edit: you could also, and often did, have 60 hz games that simply dropped frames to sync with a 50 hz display. Can't say if that's happening here though.

 

[sheathx013]

If we want to talk framerate, we need to define what we're counting. Same as resolution, you can have asynchronous updates. If the geometry updates 10 times per second but the particles update 30 times a second, is it a 10 fps game or a 30 fps game? Or a 40 fps game because the particle effects always happen after the geometry changes giving 40 unique frames per second?

I think the most sensible counting should focus on the geometry and camera updates - the moving bit that gives a sense of fluidity. If we want to then look at other aspects, we can evaluate them more directly rather than just clumping them in the 'framerate' metric. We used to do this 15 years ago when talking about a game's 'resolution' and ultimately settled on talking about the 'opaque geometry buffer resolution' that resulted in the majority pixels one could perceive on screen where other buffers would typically be lower.

It's worth noting that DF developed an automated system to gather the metrics on framerate, detecting every unique frame, so manual frame-counting is a step backwards from their frametime graphs and completely unnecessary if those are available. Of course their rolling averages could sample a different interval which may give slightly different results to manual framecounts, but the overall ball-park figures and averages can be taken as presented.

It's also worth noting that in B3D's technical discussions of yesteryear, we used to do frame counting and pixel counting and compare results. Richard Leadbetter was a part of those conversations and they led to the automated tools that DF uses. So discussions with the people who produce DF's content leads me to be very happy with their methods and whatever results they get. One's free to disagree with interpretations, but the data is good and trustworthy. I won't take a manual frame count over a DF automated frametime analysis unless there's clearly something sus in DF's figures.

Based on my two limited tests, the earlier cited DF video was very accurate, even on the turning sequences. Especially if it was counting unique frames that had zero change to the overall scene, the presentation of 28-30+ FPS appears to be accurate to me based on a tedious set of manual counts. At this particular point I'd say my recollection was off, or the full-scene chugging drops are very, very, hard to replicate. Kudos to the developer for that.

I realize DF's method has been accepted here. I recall it being developed for the PS3's HDMI output, and being dependent on Digital Output for at least five years afterward. I am sure for digital progressive output such a solution was very accurate, or at least relatively so. Since it has moved to analog sources, having not been privy to any of the technology, or the reasoning into what a "unique frame" is considered to be, I will continue to do my own counts when my experience differs with the graph. I like finding out I was wrong and finding new reasons to enjoy a game.

On the topic of "the impossible port" to Dreamcast. I also recall the other often repeated reasons being the Audio, specifically the variety in the radio, and the very specific to PS2 lighting. I am not expecting either to be a high priority in an indie source port from the PC version.

 

[TrekkiesUnite118]

I have no idea about the developers' true intent in the making of this game, but it is stated in this video that they "may" make a Saturn port if certain social funding goals are met.

Watching Parking Garage Rally Circuit, and thinking about the higher detail Saturn racers like Sega Touring Car Championship, I think they could make an adaptation of this game, but not what we are seeing in this hands on video. I don't think the Saturn or the Playstation or the N64 could handle *at 20-30FPS* the draw distance with the number of parked cars on screen for example. Maybe they could switch to 2D versions of cars in the back and it wouldn't be too obtrusive. The nearest equivalent to this I can think of is Formula Karts on the Saturn. At a glance they might look really similar actually.

I've seen 3D mesh transparencies in Saturn games, but not for debris and smoke in a Saturn Racer. I've seen these in Burning Rangers, and NiGHTs and Virtual On, but not a Racer. Maybe those would have to be reduced to period correct effects, or eliminated entirely.

Honestly I think for some of those tracks they're a bit over ambitious. While the SH2s might be able to do the math for that geometry fast enough, VDP1 is probably going to choke on it's own fill rate trying to draw some of those scenes, especially that last track where you can see the entire track below you through the road. If you need an example of the limit of VDP1's fill rate for a racing game look no further than Sega Touring Car Championship. That game's performance issues are entirely due to fill rate. If you tell the game to render everything as a wireframe it suddenly jumps to a solid 30fps. That means the CPUs are not what's holding up the rendering, it's entirely due to VDP1 not being able to keep up. Some clues looking at what the game is doing points to it using very high resolution textures even for very small polygons, which will kill VDP1's fill rate.

On top of that issue I'm not seeing a lot of places where even VDP2 planes could help out as even in the parking garage stages you'd have to do a lot of trickery with the coefficient tables and line windows to pull multiple levels off like that. And even then it might not really work. So there would probably need to be some harsh limits on draw distance and what not to keep the performance up. While an unstable framerate can be acceptable for a platformer or first person shooter, it's not really acceptable for a racing game. The transparencies and meshes are the least of concern.

Honeslty with the strides modern N64 homebrew has shown recently I wouldn't be surprised if they could pull that off. PS1 I'd imagine would be somewhere in between.

 

[Mittens0407]

Hardware footage of latest build:

 

[XboxKING]

You should be more respectfull to others work, and by the way this is till work in progress, can't belive you haven't been call out by a moderator at this point.

This is the latest progress, it is improving, yes still a long way to go but calling a psone port is disrespectull to anyone involved and console warring.

https://twitter.com/x/status/1823949520624910825

Also the draw distance is, by default way higher than on ps2 since it is using the default PC configutaion, expect better performance when reduced to ps2 levels,
You'll see in the screenshot below that the lighst are absent on the ps2 version because the lod distance is lower, also the cranes are missing in the backgound, cars appear closer to the player on ps2 too and the road has shorter draw distance on ps2. as said expect a performance increase when the DC version matches the lower draw distance of the ps2.....

OMG he even wrote a song! It is amazing and hilarious

I am really amazed at what they are able to accomplish especially because it seems like just one person.

Of course Dreamcast could have run GTA3, who are we kidding?

 

[davis.anthony]

Hardware footage of latest build:

Can I ask, if it's running from a super fast SSD, it is accurate to say it running on DC hardware?