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

I'd say so, yeah.

I think it would be more accurate to say it's running on modified DC hardware, as to me, saying it's running on DC hardware implies it's running on a bone stock system.

But a bone stock system doesn't have an SSD, so it's technical capabilities (specifically in terms of streaming performance) are technically higher than what a bone stock system can achieve.
 
I think it would be more accurate to say it's running on modified DC hardware, as to me, saying it's running on DC hardware implies it's running on a bone stock system.

But a bone stock system doesn't have an SSD, so it's technical capabilities (specifically in terms of streaming performance) are technically higher than what a bone stock system can achieve.
I think the usage of an SSD is of convenience rather than necessity, copying over a disc image is much less of a hassle than burning a disc for every new build.
 
I think the usage of an SSD is of convenience rather than necessity, copying over a disc image is much less of a hassle than burning a disc for every new build.

That is a reason, but the guy dealing with the port has also said they've not tested to see if the optical drive will keep up with the streaming demands now the game is running faster.
 
I think the usage of an SSD is of convenience rather than necessity, copying over a disc image is much less of a hassle than burning a disc for every new build.
Absolutely, but it also has a performance impact. So for every update running off fast storage, we'd still need a confirmation optical disk build to test for a full, native DC version.
That is a reason, but the guy dealing with the port has also said they've not tested to see if the optical drive will keep up with the streaming demands now the game is running faster.
I asked this same question for the same reasons 5 days ago. The two responses told me that burned CDs have been tested (so in principle it works, with unknown performance impact) and also CDs are gimped versus GDRoms, which is true. So in truth, SSD will be inaccurate as it's too fast, and CD will be inaccurate as it's too slow. We're not going to get anyone burning GDRoms so you'd need someone to create a virtual ODD that limited IO based on DC stats.

I hope that happens, but it'll be a low priority. What we're getting at the moment is a look at DC's rendering and processing capabilities with the whole IO considerations being left on the back burner.
 
Absolutely, but it also has a performance impact. So for every update running off fast storage, we'd still need a confirmation optical disk build to test for a full, native DC version.

I asked this same question for the same reasons 5 days ago. The two responses told me that burned CDs have been tested (so in principle it works, with unknown performance impact) and also CDs are gimped versus GDRoms, which is true. So in truth, SSD will be inaccurate as it's too fast, and CD will be inaccurate as it's too slow. We're not going to get anyone burning GDRoms so you'd need someone to create a virtual ODD that limited IO based on DC stats.

I hope that happens, but it'll be a low priority. What we're getting at the moment is a look at DC's rendering and processing capabilities with the whole IO considerations being left on the back burner.

I believe there a few devkits out there in the hands of collectors with the ability to burn GD-ROM spec disks. If there's someone with such a devkit, and they know how to use it, and they have some blanks left ....?

Bit of a long shot, but then again I never thought we'd see GTA 3 on the DC. ¯\_(ツ)_/¯
 
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.



Sonic R has a draw distance of 30 meter compared to CRT 1 kilometer/infinite.
Seriously, if you walk with sonic, you can never see more than 25 footsteps ahead in any given situation

Maybe you played the pc version?
 
so you'd need someone to create a virtual ODD that limited IO based on DC stats.
There's no reason someone couldn't modify KallistiOS's CD driver to add artificial delays to mimic the speed/seek times of a GD or CD.

The KallistiOS CD driver is a bit weak and is might contribute somewhat to the framerate problems of the GTA3 port. It works, but it reads data off the disk manually using the CPU (PIO), instead of DMA. It's also incapable of having two threads read at the same time (so you can't load game data in one thread while another reads and decodes compressed audio). If you try, both threads will freeze.

I was in the process of writing a new CD driver earlier this year, but after starting on HarleQuest I put it on the backburner. I had it mostly working, with disc swapping untested and error handling needed some double checking to make sure it was right. I should probably upload what I had working so someone else can try working on it, huh?

Something I noticed is that KOS's usage of PIO seems to limit the thoughput of my GDEMU clone a lot. With my DMA driver, I could get about 5.7 MB/s, but KOS would only get something like 1.9 MB/s. It's faster than a CD or GD, but much less than it could be.
 
I'm randomly thinking using a computer to serve into the hardware's IO. However data is being served currently from SSD, stick a processor between it and the DC and have add delay and limit rate. Like, I dunno, a Raspberry Pi functioning as a virtual CD drive. I guess you are presently streaming from Windows and that's where a driver would come in?

Edit: Actually as a Retro tech, such a device would be quite useful if you could plug it into the optical/IO connectors of any hardware. You could upload builds and test real-world performance. There's a real-world case of this, BTW. Champions of Norrath released with a 'bug' where tiles wouldn't stream in time. This didn't happen in development and caught the devs off guard, who found it was because of the dual-layer DVD and access on the second layer being slower. Having a virtual drive who's parameters can be tweaked will allow all scenarios to be tested against including varying performance of optical drives. With SSDs (even SD cards!) offering 'unlimited' performance, we can simply regulate them via software. Well, in a lot cases for retro consoles, the entire games could easily fit in RAM these days!
 
Last edited:
I'm randomly thinking using a computer to serve into the hardware's IO. However data is being served currently from SSD, stick a processor between it and the DC and have add delay and limit rate. Like, I dunno, a Raspberry Pi functioning as a virtual CD drive. I guess you are presently streaming from Windows and that's where a driver would come in?

Edit: Actually as a Retro tech, such a device would be quite useful if you could plug it into the optical/IO connectors of any hardware. You could upload builds and test real-world performance. There's a real-world case of this, BTW. Champions of Norrath released with a 'bug' where tiles wouldn't stream in time. This didn't happen in development and caught the devs off guard, who found it was because of the dual-layer DVD and access on the second layer being slower. Having a virtual drive who's parameters can be tweaked will allow all scenarios to be tested against including varying performance of optical drives. With SSDs (even SD cards!) offering 'unlimited' performance, we can simply regulate them via software. Well, in a lot cases for retro consoles, the entire games could easily fit in RAM these days!

Someone saved you the trouble. Half assed padded not sorted cdr burn. Other than the initial load time being longer , the game runs the same off a unoptimized cdr compared to a SSD drive. Despite everything being streamed in ( models , textures) it copes with the data just fine. I dunno why they were having hard time on the PS2 for streaming especially considering this version isn't even meant to be run off a disc.( Reversed pc port).

 
I guess at this point we need to revisit what exactly was the quote about PS2 DVD's being limited. We have no source on that and maybe people are misremembering? The first google came up with this


The issue described here isn't PS2'd DVD drive being too slow overall, but too slow versus reading everything from RAM. That is, the problem faced was fitting a city into the game bigger than could be fit in RAM, necessitating streaming which was the new challenge.

If there's any particular reference to GTA maxing PS2's DVD capabilities, we'd need to see it, and then challenge it if DC can stream just fine off a CD (that said, the CD still isn't streaming audio concurrently which would some head movement and latency?)

Edit: Also
 
A few pauses on loading, but that's not half bad from a CD-R!

EDIT: The link @Shifty Geezer provided, this sticks out to me.

As the texture streaming on PS2 wasn't fast enough to load everything the GTA dev explained

That would be one area where the extra VRAM on DC could slightly alleviate the strain on the streaming requirements.
 
I guess at this point we need to revisit what exactly was the quote about PS2 DVD's being limited. We have no source on that and maybe people are misremembering? The first google came up with this


The issue described here isn't PS2'd DVD drive being too slow overall, but too slow versus reading everything from RAM. That is, the problem faced was fitting a city into the game bigger than could be fit in RAM, necessitating streaming which was the new challenge.

If there's any particular reference to GTA maxing PS2's DVD capabilities, we'd need to see it, and then challenge it if DC can stream just fine off a CD (that said, the CD still isn't streaming audio concurrently which would some head movement and latency?)

Edit: Also

I dunno I just took people at their word here about the whole DVD drive. They seem to collectively remember it. I guess maybe misremembering or maybe someone made up some crap.

For the audio not yet. It seems they settled on an open source version of Adx library. For it's low cpu impact and good file size. Work already started on that so it will be interesting to see how this plays out. So far though data throughput doesn't seem to be an issue .
 
I guess at this point we need to revisit what exactly was the quote about PS2 DVD's being limited. We have no source on that and maybe people are misremembering? The first google came up with this


The issue described here isn't PS2'd DVD drive being too slow overall, but too slow versus reading everything from RAM. That is, the problem faced was fitting a city into the game bigger than could be fit in RAM, necessitating streaming which was the new challenge.

If there's any particular reference to GTA maxing PS2's DVD capabilities, we'd need to see it, and then challenge it if DC can stream just fine off a CD (that said, the CD still isn't streaming audio concurrently which would some head movement and latency?)

Edit: Also

Sounds like the underlying work done to make the PS2 version possible should carry across pretty universally to other systems as the same problems and solutions would apply.

I found this bit was interesting:

"This is because the DVD needs to accelerate/decelerate as the head moves to a different track."

It seems they were using CLV mode for the PS2. Here's a quote from an old B3D post:

The PS2 drive can operate in either CAV or CLV mode. CAV is faster, but less stable, and only works on one layer of a dual layer disc.

We ran the drive in CLV mode, and I don't want to revisit the amount of time I spent laying out the 8GB of data we crammed onto the disc.

CLV mode on a 4x DVD drive should be at most ~2.2 MB/s (5.28 MB/s / 2.4), or possibly lower, and worse access times than CAV due to accelerating / decelerating the disk. @TapamN do you happen to know the CLV read rate of the PS2 DVD drive?

GD-ROM is 1.8 ~ 0.9 MB/s and CAV so no cost to access times from accelerating / decelerating the disk as you relocate the head.

Suddenly streaming GTA3 from GD-Rom isn't looking like such an insurmountable problem. (Obviously, this project will only have access to slower CDRs.)
 
That would be one area where the extra VRAM on DC could slightly alleviate the strain on the streaming requirements.
Compressed textures should help immensely too - far less data demands and likely closer physical proximity and more textures per square centimetre of plastic (a metric that needs its own IEEE unit). They mention for VC R* used better compression on texture and models. Although curiously that game runs so much worse! I guess IO was not the bottleneck for that game.
 
Compressed textures should help immensely too - far less data demands and likely closer physical proximity and more textures per square centimetre of plastic (a metric that needs its own IEEE unit). They mention for VC R* used better compression on texture and models. Although curiously that game runs so much worse! I guess IO was not the bottleneck for that game.

I/O was only really the bottleneck on the initial load.

I had a PS2 running games from an HDD 5-6 years ago, and I can say that loads times went from ~1 minute loading from the DVD drive, to ~30 seconds loading from the HDD on GTA:VC.

Although re-reviewing the DF PS2 footage of GTA3, the frame times look like compression/decompression related as it loads/unloads City blocks from RAM.
 
The transfer rate of a GD rom is 1.8 MB/s so you should try and get hold of a 12x cd-rom
edit: just remembered if your testing with an emulator I think nero had a utility to limit cd rom speed

ps: you could run GTA:VC from a 1gb ram drive here's a free one from AMD
 
Last edited:
Back
Top