iOQuake3 Dreamcast port?

[OVERRiDE_DC]

http://ioquake3.org/
Its an open-source 3d game engine, written in C and uses SDL.
It seems like a great candidate for a Dreamcast port, this engine would open up a lot of possibilities.

So, I am not experienced enough at programming, so I am curious what some of you current DC programmers think about the idea?

Screenshot of the engine in action:

[Ex-Cyber]

RAM issues would probably stop it from running most maps/mods. IIRC the assets for the commercial DC port of Quake III Arena (levels, models, textures) were modified to reduce RAM footprint.

[OVERRiDE_DC]

RAM issues would probably stop it from running most maps/mods. IIRC the assets for the commercial DC port of Quake III Arena (levels, models, textures) were modified to reduce RAM footprint.

Yes, being a member of CSDC Dev Team, I understand how to work with RAM limitations, specifically on the Dreamcast.

Heck, we got Paranoia http://paranoia.level-design.ru/ to run on DC, and look at its requirements:

Code: Select all

Minimal configuration:

Processor with 1 GHz
64 Mb Ram
3D accelerator video card (32 Mb) with OpenGL mode support
Soundcard, Mouse, Keyboard
Half-Life v 1.1.1.0 or higer

Recommended configuration:

Processor with 2 GHz
512 Mb Ram
3D accelerator video card (128 Mb) with OpenGL mode support
Soundcard, Mouse, Keyboard
Half-Life STEAM v 1.1.2.0

The thing to remember, is that every asset of a game like this can be heavily modified.

.BSP's can be split or simplified ( reduced polygons ), models can have textures compressed and polygons reduced, the engine is allready using .ogg audio format, so that will work perfectly. As long as the engine supports PVR texture compression, anything is possible.

With a good Dev Team, 26mb should be plenty of RAM to work with...

[Maturion]

Where can I get Paranoia-DC?

[OVERRiDE_DC]

Where can I get Paranoia-DC?

More info on ParanoiaDC here:
http://www.dcfan.net.ru/forum/showthread.php?t=1890

Video of ParanoiaDC public beta 1 running on Dreamcast:
http://www.youtube.com/watch?v=LEU0vBVs2X0

And, some more recent screens running on DC:




But not to get too off topic, back to iOQuake3...

[Ex-Cyber]

I don't think it would be worthless or impossible or anything; I just think expectations should be set appropriately. It would definitely be cool to see the engine running on DC. I briefly considered trying it, but I'm fairly inexperienced at both Dreamcast and GL programming and already have more project ideas than I can shake a stick at (working on some Verilog stuff now, as a matter of fact), so it would be unlikely to produce much.

[park]

Where can I get Paranoia-DC?

More info on ParanoiaDC here:
http://www.dcfan.net.ru/forum/showthread.php?t=1890

Video of ParanoiaDC public beta 1 running on Dreamcast:
http://www.youtube.com/watch?v=LEU0vBVs2X0

And, some more recent screens running on DC:




But not to get too off topic, back to iOQuake3...

Wow that looks great,saw the video and for some reason I find it better looking than the dc version of half-life.Too bad the dcfan link doesnt work for me.Makes me wonder if a more complex location like the streets of a city is possible on the dc.

[BlackAura]

While it's possible (Raster managed it for the commercial version of Quake 3), it's hardly simple.

No existing Quake 3 data set would be compatible with it, for a start. The data set that's least resource intensive is Quake 3 itself - everything else was developed much later, and has correspondingly higher requirements.

That's the easiest problem to solve. The far bigger problem is that the entire engine was designed for PCs, using OpenGL, virtual memory, and loads of other stuff that we don't have on a Dreamcast.

The first hurdle is memory - Quake 3 requires 64MB of it, and that's on a system that supports virtual memory / paging. The Dreamcast has 16MB to work with.

Probably the biggest hurdle is the renderer. We don't actually have an OpenGL implementation that's capable of handling everything that Quake 3 tries to do with it, and the OpenGL implementation we do have is kind of slow. You'd basically have to write a new renderer, using the PVR API directly. That's a huge undertaking, especially considering that there's no possible way to run the original game's data files anyway.

It'd actually be easier to write a stand-alone Quake 3 renderer, and bolt a game engine onto it. This guy actually implemented a Quake 3 renderer in Direct 3D, and used the publicly released mod source code to make it able to actually play Quake 3. Pretty impressive, considering that this was before the Quake 3 engine source code was even released. It lacked bots, and used a different network protocol, but it worked.

[OVERRiDE_DC]

OneThirty8 has recently implemented a PVR renderer into a simpler 3d engine, maybe he has some input on this subject...

I heard Chui stated that he has managed to utilize the SD card to effectively double system RAM, without slowdowns.

Couldnt the DC's 8mb of video memory be used for all of the (VQ) textures data? Im curious how much of the 64mb of RAM required is texture data?

But, then again, maybe its time I stopped Dreaming...

[OneThirty8]

OneThirty8 has recently implemented a PVR renderer into a simpler 3d engine, maybe he has some input on this subject...

Yeti3D was originally designed to run on a GBA and writing the PVR renderer was really simple after BlackAura posted information on how to use paletted textures. I wouldn't know where to begin with something like Quake 3.

[Quzar]

I heard Chui stated that he has managed to utilize the SD card to effectively double system RAM, without slowdowns.

Couldnt the DC's 8mb of video memory be used for all of the (VQ) textures data? Im curious how much of the 64mb of RAM required is texture data?

1) From who? Even the best rumours about DCiberia's magical SD card put it at way slower than any ram.
2) Nowhere near the full 8mb is availible if you want to have any video output at all. After all the standard buffers and whatnot you're left with something between 4 and 6mb.

As for something like csdc, you really can't compare the required minimum memory of something on a windows pc to a DC. At least one or two of the things I've ported have said 64mb or higher required. These sorts of numbers don't mean that the program itself needs 64mb, just that your machine will to run it. Hell, 16mb is required just to run Windows 95.

[OneThirty8]

1) From who? Even the best rumours about DCiberia's magical SD card put it at way slower than any ram.

Then there is the fact that releasing something that requires the SD card in order to work is going to severly limit the number of people who will be able to use your program. My opinion is that it would be something neat to support as an extra or a replacement for the VMU for storing gamesaves, but it's not something that any program I write is going to require.

[OVERRiDE_DC]

I heard Chui stated that he has managed to utilize the SD card to effectively double system RAM, without slowdowns.

Couldnt the DC's 8mb of video memory be used for all of the (VQ) textures data? Im curious how much of the 64mb of RAM required is texture data?

1) From who? Even the best rumours about DCiberia's magical SD card put it at way slower than any ram.

Everyone seems to think DCiberia created the SD adapter. They did NOT. JJ10DM designed the DC-SD wiring diagram. DCiberia just took his idea and ran with it.

And, lol, there is nothing mysterious or "magical" about it. Using JJ10DM's SDRip, a full 1.1gb GDI can be dumped in ~30min.
The wiring diagram is posted here:
http://f17.aaa.livedoor.jp/~takotako/dc ... php#sdcard

I have an extra serial adapter cable, from the system link adapter, if you want to build your own SD adapter, shoot me a PM.

About Chui using it for RAM, I heard it from Guaripolo in another forum:
http://www.dcemu.co.uk/vbulletin/showpo ... ostcount=5

2) Nowhere near the full 8mb is availible if you want to have any video output at all. After all the standard buffers and whatnot you're left with something between 4 and 6mb.

As for something like csdc, you really can't compare the required minimum memory of something on a windows pc to a DC. At least one or two of the things I've ported have said 64mb or higher required. These sorts of numbers don't mean that the program itself needs 64mb, just that your machine will to run it. Hell, 16mb is required just to run Windows 95.

So, your saying that also applies to iOQuake3, that its RAM requirements for PC will be greater than that of DC, because of PC O/S data also being considered a part of the 64mb required?

And, 4-6mb seems should still be enough room for VQ textures?

Then there is the fact that releasing something that requires the SD card in order to work is going to severly limit the number of people who will be able to use your program. My opinion is that it would be something neat to support as an extra or a replacement for the VMU for storing gamesaves, but it's not something that any program I write is going to require.

It would be a sacrifice for pushing the machine to its limits. And, it would encourage more ppl to buy an SD adapter, to further enhance the scene.

Seriously though, when are you going to implement SD support for VC/DC? To browse SD and launch mpg / mp3 is a very cool idea.
After that, maybe you can add support for .3gp video files and .jpg images, and then it would be possible to plug your cell-phone sd card into your DC and view all media files on TV screen. Cool, huh?

[OneThirty8]

Seriously though, when are you going to implement SD support for VC/DC?

I don't have an SD card adapter, so I couldn't test it, and I'm working on other things at the moment so I don't have a release planned anytime soon. For the other media formats you mentioned, something like xine or ffmpeg would probably be better suited for that. The core of VC/DC is essentially libmpeg2 and mpglib glued together, and the VCD support that's in 0.2 is the result of months and months of trial and error and digging through the source code to vcdimager and libcdio.

[BlackAura]

Using JJ10DM's SDRip, a full 1.1gb GDI can be dumped in ~30min.

That's around 640kb/s - while that's not bad at all considering it's connected to the Dreamcast's serial port, it is really kind of slow. The GD-ROM drive is capable of around four times that, while the Dreamcast's RAM is capable of around 800Mb/s - that's megabytes, not kilobytes.

So, your saying that also applies to iOQuake3, that its RAM requirements for PC will be greater than that of DC, because of PC O/S data also being considered a part of the 64mb required?

Yeees... but for a game like Quake 3, there's not going to be much in it. If you're running on a system with limited RAM, Quake 3 basically forces the OS to page almost everything else out to disk. What you're left with is the non-pageable parts of the OS (the kernel, drivers, and the active parts of any other running programs - the inactive parts will be paged to disk).

For Windows 95, the minimum footprint was something like 6MB. For Windows 98, it's going to be more like 16MB. Even doubling that, Quake 3's minimum requirement is still twice as much as the Dreamcast has.

Besides, that doesn't take into account virtual memory. On a PC, even on crappy old operating systems like Windows 9x, the operating system will transfer less frequently used memory to the hard drive to make room.

Take Quake 2 as a good example of the effects this can have. Quake 2 has a minimum requirement of 16MB of RAM, running on Windows 95. It will run on a PC with only 16MB of RAM, despite having Windows loaded at the same time. However, it will not run on a Dreamcast.

The biggest problem is that it uses far more than 16MB of RAM while loading a level, and relies on the OS to swap out bits that aren't being used. It slows down loading times, but otherwise has no ill effects. A secondary problem is that Quake 2 levels can actually take up far more than 16MB of RAM while running. The game relies on the operating system to swap bits and pieces out to disc. Since PC hard drives, even back then, were pretty fast, this just meant you get the odd stutter when you go into a room you've not been in recently.

On a Dreamcast, there's a hard limit of 16MB of RAM. When you hit that, the game crashes.

There are basically four things you have to do to make a game like Quake 3 run on a Dreamcast without running out of memory.

1 - Significantly reduce the memory usage, both during loading, and gameplay. Ideally, the game should less memory while loading than it does during gameplay.
2 - Manage all memory directly, rather than relying on the OS. This allows you to manage the memory more effectively, and also helps prevent memory fragmentation. Between levels, you just dump all the resources, and reload them from the CD.
3 - Resource streaming. Basically, you treat the system's memory as a cache for the resources on the disc, and load them on demand. This reduces load times, and means that you can simply discard any resources that aren't being used at the moment. So, instead of 16MB to fit the entire level, you have 16MB to fit the current part of the level.
4 - Modify the game assets, to make them fit. This might mean compressing all the textures, compressing the sounds, rearranging the data so it can be streamed more efficiently, and so on.

Raster did 1, 2 and 4 for the Dreamcast port of Quake 3. I do not believe they did 3, since they were using the GD-ROM drive to play audio tracks during gameplay.

While this is quite doable, it's a hell of a lot of work. Far more than I'd be willing to do as a hobby.

[Quzar]

I'm well aware that JJ10DM created the adapter. I call it DCIberia's because they've made such a big deal about somehow mass producing it, and that they've got all sorts of magical drivers already written and what's holding them back is KOS' fault and other random stuff.

[Neoblast]

Erm, the library works flawlessly, the problem is when fox tried to add the sd support to the vfs of kos ( /sd ), then the speed slows down a lot.

Dciberia died years ago man.

The SD CAN be used as a memory expansion, in fact chui has been doing some tests on his emulators.