Pandora Porting An Old Dreamcast Game To The Pandora

[TheGoodDoktor]

Hi

I'm currently thinking of porting a Dreamcast game that I worked on many years ago to the Pandora.
My current plan is this:
1) Convert the game to SDL & OpenGL on my PC and get it working to a similar res to the Pandora.
2) Get a Pandora when they come out and port what I've done so far over to it.

From what I can tell by the specs, the Pandora seems to exceed the Dreamcast in term of performance so I think I should be able to get the game working on it eventually. I do however have some questions:
1) Does the Pandora currently have an implementation of the SDL library?
2) How does OpenGL ES differ from OpenGL ? I'm just doing basic stuff with vertex buffers (VBOs) and the standard gBegin/glEnd stuff, nothing particularly fancy. (no shaders or anything like that)
3) Does the SGX support texture compression (particularly DXT1) ?
4) What is the floating point performance like on the Pandora? I know it has an FPU but will standard float code compiled for it use it? I also noticed that it has a SIMD unit which presumably I could use for Matrix & Vector operations.
5) I'll need to put sound in at some point, I'll need to be able to stream a few channels of audio and play some positional sound effects.

That's it for now, I'll probably have more questions later on.

Cheers,
TheGoodDoktor

 

[zacaj]

1. It will defidently be ported soon if it doesn't, but Id assume it will include it
2. http://www.khronos.org/registry/gles/specs...spec_2.0.22.pdf <- thats for OpenGL ES 2.0 from the official site( http://www.khronos.org/opengles/2_X/ )

 

[Adventus]

2. There is no immediate mode in OpenGL ES, so glBegin/glEnd calls are not supported. VBOs are good.
3. The SGX supports offline compression in the 4 / 2 bit PVRTC format and the ETC format. I suggest you get the PowerVR SDK, it has many tools for this kind of stuff.
4. My understanding is that the floating point performance should significantly exceed the Dreamcast. Its has a Neon unit (SIMD, pipelined, single precision) and a VFP lite (non-pipelined, single/double precision), however they cannot work in parallel. Recent-ish versions of GCC have support for Neon operations.... but they may not be extremely optimised. GCC by default will produce VFP lite code (which i believe is a big reason why ARM included it, back compatibility).

Also note that its still up in the air whether we'll get an OpenGL ES 1.1 driver..... i believe ES 2.0 will definitely be available, which has no fixed function pipeline. However I'm sure the community will very quickly implement the ES 1.1 pipeline in ES 2.0.

Anyway, looking forward to your game.

 

[Svartalf]

From what I can tell by the specs, the Pandora seems to exceed the Dreamcast in term of performance so I think I should be able to get the game working on it eventually. I do however have some questions:
1) Does the Pandora currently have an implementation of the SDL library?
2) How does OpenGL ES differ from OpenGL ? I'm just doing basic stuff with vertex buffers (VBOs) and the standard gBegin/glEnd stuff, nothing particularly fancy. (no shaders or anything like that)
3) Does the SGX support texture compression (particularly DXT1) ?
4) What is the floating point performance like on the Pandora? I know it has an FPU but will standard float code compiled for it use it? I also noticed that it has a SIMD unit which presumably I could use for Matrix & Vector operations.
5) I'll need to put sound in at some point, I'll need to be able to stream a few channels of audio and play some positional sound effects.

1) The SDL code for the beagleboard should handle our board (Same SOC- at the userspace level, they should be nearly identical...).

2) Others have touched on this. However, I'd like to add that if we DON'T have ES 1.1, there's only a slightly higher learning curve involved with ES 2.0 (Getting rid of the glBegin/glEnd centric code would be the main piece....) and there will be tools in hand either at release or shortly afterwards that will aid in providing the desired fixed functionality shading as programmable shader functions. It's also worth noting that you can get started with ES 1.1/2.0 right now with a Windows, MacOS, or Linux machine with wrappers. If you're interested, we can point you in the right direction there as well.

3) It supports it's own compression format (also mentioned by others...) There's tools to help out there on the Imagination Technologies site (Though those are Windows-only right now...might need to see if TI can ask them nicely to make Linux/MacOS versions of the tools as well because of this little project and the Beagleboard one...).

4) It should be good. You can use either the FP or the matrix ops at any given time (Kind of like the x86 FPU and the MMX instruction sets of old...). Definitely better than what you'd see with the SH4 at any rate...

5) I'm not sure about software sound channel mixing or positionals yet. Right now we're in a bit of a bring-up state with the firmware. For software channel mixing, you'd need something like PulseAudio or OpenAL and you'd need OpenAL for the positional audio. Right now, nobody's done any acceleration work with the DSP edge for OpenAL and while I don't think Pulse would present a problem, it's very definitely NOT ported right at the moment any more than OpenAL (Either pure software or DSP enhanced) right at the moment. OpenAL's on the list of things to do (At least one of the titles I'm planning on porting needs it)- but I'm on the hook for helping with firmware before I can start dinking too much with the OpenAL middleware piece or my games.

 

[Adventus]

QUOTE
5) I'm not sure about software sound channel mixing or positionals yet. Right now we're in a bit of a bring-up state with the firmware. For software channel mixing, you'd need something like PulseAudio or OpenAL and you'd need OpenAL for the positional audio. Right now, nobody's done any acceleration work with the DSP edge for OpenAL and while I don't think Pulse would present a problem, it's very definitely NOT ported right at the moment any more than OpenAL (Either pure software or DSP enhanced) right at the moment. OpenAL's on the list of things to do (At least one of the titles I'm planning on porting needs it)- but I'm on the hook for helping with firmware before I can start dinking too much with the OpenAL middleware piece or my games.
Yea.

However, for simple stuff i suggest you use SDL_Mixer. It provides simple Positional audio (distance and angle of source) and multiple channels.

As far as i understand it works completely on top of SDL, so it wont require any porting.

 

[jakshep2]

what dreamcast game is it?

 

[Xmas]

3) It supports it's own compression format (also mentioned by others...) There's tools to help out there on the Imagination Technologies site (Though those are Windows-only right now...might need to see if TI can ask them nicely to make Linux/MacOS versions of the tools as well because of this little project and the Beagleboard one...).

The PowerVR PC Emulation SDK for Linux includes the necessary tools.
http://www.imgtec.com/powervr/insider/sdkd...index.asp#GLES2

 

[Svartalf]

The PowerVR PC Emulation SDK for Linux includes the necessary tools.
http://www.imgtec.com/powervr/insider/sdkd...index.asp#GLES2



Cool. I'd been under the impression that some of the texture and other management tools weren't available except under Windows for some odd reason. Thanks for the correction, Xmas. It's appreciated.

 

[TheGoodDoktor]

3) It supports it's own compression format (also mentioned by others...) There's tools to help out there on the Imagination Technologies site (Though those are Windows-only right now...might need to see if TI can ask them nicely to make Linux/MacOS versions of the tools as well because of this little project and the Beagleboard one...).

The PowerVR PC Emulation SDK for Linux includes the necessary tools.
http://www.imgtec.com/powervr/insider/sdkd...index.asp#GLES2


I've looked at the PowerVR docs. It's a shame that they don't support DXT compression as I'll have to convert the textures (from DXT if I can't find the originals).
This all looks pretty do-able, the OMAP certainly looks capable and the DSP can probably be used for audio. I just need to do the work and get it running on OpenGL first.
I don't want to say what game it is yet because I don't have loads of free time and I don't want to disappoint anyone if I don't have time to get it working. Also I might not legally be able to release it although the person who owns the rights is a good friend of mine and we've already chatted about open sourcing it. It is a good game though (it's green on metacritic) and I loved working on it originally and I'd love to bring it back to life again.
Thanks to everyone who's responded.

 

[Svartalf]

I don't want to say what game it is yet because I don't have loads of free time and I don't want to disappoint anyone if I don't have time to get it working. Also I might not legally be able to release it although the person who owns the rights is a good friend of mine and we've already chatted about open sourcing it. It is a good game though (it's green on metacritic) and I loved working on it originally and I'd love to bring it back to life again.

1) A green rating on metacritic... Quite a few good titles in that potential list- coolness.
2) If your friend who owns the rights is interested in Open Sourcing the title, you might have at least one more person interested in making it come together- I'd think it'd be a cool thing to get a top rated AAA console, even if it's "old", out there and flying on Pandora and elsewhere.

QUOTE
Thanks to everyone who's responded.


You're very much welcome.

 

[icurafu]

It would be interesting to see how a popular Dreamcast game could be retrofitted to use OpenGL ES 2.0 and a much more beefy CPU.

When you say opensource, do you mean as in freeware? or releasing the source similar to Quake3?

Either way, you'll find many Dreamcast fanbois here.

EDIT: how did I manage to quote my own message without editing? o_0

 

[sindbad]

666 views. That's a sign that maybe I should contribute if contributions are welcome.

 

[Svartalf]

It would be interesting to see how a popular Dreamcast game could be retrofitted to use OpenGL ES 2.0 and a much more beefy CPU.

Wouldn't it, though? I'd love to see what he's got access to.

 

[mickb22]

From what I can tell by the specs, the Pandora seems to exceed the Dreamcast in term of performance

wait so if that line is true... then a dreamcast emulator shouldn't be too hard to make, right? im not too good in tech so tell me if i'm wrong...

 

[Chip]

then a dreamcast emulator shouldn't be too hard to make, right? im not too good in tech so tell me if i'm wrong...

You're wrong

To emulate a system, you need a system that is significantly more powerful. Just how much more depends on a lot of variables. I won't get into it here, as there are several threads that already cover the subject. Suffice it to say that playable DC emulation will be extremely difficult to achieve on the Pandora - if it's possible at all.

 

[mickb22]

THanks. i have had trouble understanding some of the real techy stuff.

 

[hotblack]

What we have here is someone with access to the original code of a game porting it to a new architecture (or thinking/trying to). This means the software will be running natively. This can generally be done between hardware that is of comparable power/solidification, for example the ports you see of games between the PS3 and 360.

Emulation on the other hand takes significantly more powerful resources than the original hardware, as you're actually translating on the fly.

I guess a reasonable comparison would be this. If you have a book written in English, there are two ways someone who speaks Spanish could read it. First, you get someone else to translate it into Spanish. This book can then be read by everyone who speak Spanish with no extras work needed by the reader, although it took a fair bit of extra work to perform the initial translation. This is somewhat like porting software.

Alternatively, the person that wants to read it could learn English. This is obviously hard work and means the person must think hard each time they're reading the book in English. It also means only they (or other people that can read English) could read the book... but it does mean they could read other books written in English with some success (unless they came across words they didn't understand). This is somewhat like emulation.

I hope I haven't confused matters further!

 

[bustaballs]

I thought I remembered someone mentioning that Dreamcast emulation was a theoretical possibility since some of the hardware in the DC was similar. I suppose I could be wrong. But even if it happens and at a very slow frame rate, I think it will open peoples eyes about what the near future looks like for handheld systems.

 

[mickb22]

What we have here is someone with access to the original code of a game porting it to a new architecture (or thinking/trying to). This means the software will be running natively. This can generally be done between hardware that is of comparable power/solidification, for example the ports you see of games between the PS3 and 360.

Emulation on the other hand takes significantly more powerful resources than the original hardware, as you're actually translating on the fly.

I guess a reasonable comparison would be this. If you have a book written in English, there are two ways someone who speaks Spanish could read it. First, you get someone else to translate it into Spanish. This book can then be read by everyone who speak Spanish with no extras work needed by the reader, although it took a fair bit of extra work to perform the initial translation. This is somewhat like porting software.

Alternatively, the person that wants to read it could learn English. This is obviously hard work and means the person must think hard each time they're reading the book in English. It also means only they (or other people that can read English) could read the book... but it does mean they could read other books written in English with some success (unless they came across words they didn't understand). This is somewhat like emulation.

I hope I haven't confused matters further!

thanks, now it's somewhat clear to me

 

[Prometheus]

@hotblack - That's one of the best non-technical analogies about emulation and porting that I've ever read. Kudos.