Saturn Emulation...

There is quite a bit of hoopla recently over the fake Saturn emulators for Dreamcast...and the problem with getting them off the ground, even for PC is the complex arcitecure. The other problem I would see is the Saturn security code which means that the Iso would have to be included on the disc with game...unlike bleem.

I've been thinking recently, wouldn't it make more sense to reprogram, or in essence PORT old saturn games to the Dreamcast. Just like porting any game from PS to dreamcast is it no possible with enough time and experience and ...well...talent to port older games such as Panzer Saga and Shining Force 3 to the DC enhancing the graphics and sound in the process. I'm sega could port these games if they wanted to....so if it's possible, and I'm sure it is...why don't some of us attempt it?
 
Because we do not have the source code....

And what we are trying to do as a community is help develop SOMETHINg.. so far the most advanced proyects are Stardust and the Phoenix emulator
 
Yes, it's entirely possible to port games, even without the source code. The kind of reverse engineering that needs to take place, however, has the potential to be a tremendous pain in the ass. Consider that this work has to be repeated for *every game*, and the allure of an emulator becomes clear.

Also, I don't see why the ISO would need to be included on the emulator disc - remember, the emu is in control of code execution once it is booted; it can completely ignore the region codes, patch the Saturn BIOS, temporarily pretend that the main Saturn CPU is a Z80, or whatever else is necessary to make things run.
 
You can rip all the graphics, create a program that mimics the behaviour of the original. How successfull you'll be, that's another question.

I don't get the ISO format question. If you are asking if the protection ring would be read on a DC, a Saturn CD is as possible to be read as a PSX one on a DC, and as the PSX one the only thing you _can't_ legally do, is to replicate the pantented protection protocol on the emulator. There are lots more other troubles than that simple matter to prevent succesfull Saturn emulation.
 
true...i just wasn't familiar enough with the protection ring to come to a educated conclusion about it...i wasn't sure if any laser was capable of reading the protection ring..but now i know...thatz what these message boards are for after all...right?

anyways...if there is a pressing need to get these games up and running from a Saturn to a DC...which way would you all see as being the faster or more efficeient way of going about it?

And what would you learn more from...porting or writing an emulator?

Forgive me if my questions sound lame...but I'm a self-confessed newbie so have mercy....
 
Both mean alot of work. I doubt there is a pressing "need" to have any of sutch games running on a DC. But that's my oppinion. Anyway, only porting would give a satisfying result given the small processing power of the DC processor. That means the whole code would have to be recriated from scratch, and and that's more trouble them most people are ready to assume :)
 
i just want to clarify my question about the protection ring...the Dreamcast would be able to read the protection ring on a original saturn game...but what about burnt versions...saturn games are so rare and hard to find that most people would have to play the burnt versions. Would you have to confiue the emulator NOT to check for a ring?
 
Exactly. The ring has pretty much *nothing* to do with the actual game, so you write the emulator in such a way that it doesn't matter whether or not it's there; it's somewhat similar to the situation with the Gameboy BIOS - there are plenty of GB emus even though the BIOS hasn't been dumped (AFAIK), because the BIOS exists only to make sure that Nintendo gets paid their royalties.
 
Plus, you gotta remember that you really couldnt enhance the graphics of the saturn games by any way other than raising the resolution, unless you spent lots of time on game specific hacks. The saturn doesnt have a 3d processor, so everything you see on the saturn is 2d essentially and all the 3d is "faked" or brute-force rendered, which is really slow, and i doubt it would be very feasable to implement graphic enhancements on it.
 
So in essence, to get any sort of graphic enhancement out any Saturn games would be to port them over and write a good portion of the code over again optimized for the DC hardware. Another reason to port the games rather then emulate them. However, would the DC's anti-aliasing do anything to the Saturn jaggies?
 
Good portion of coding? all of it. The best you can do actually to a Saturn game is to retrieve the texture, sprites and BG images to a PC. Studing the code would be quite difficult, since we lack proper porting tools, like an efficient debugger. But you can allways try ^^;

Getting the original 3D would be quite out of your range... Most SGL based games use a structure of quads, instead of triangules for the model (err... basicly, the models are made out of distorted sprites). So, the format, if you could retrieve them someway (something I have yet to see), are unable to be replicated on any other machine efficiently. So you need a 3D artist to replicate the original models.

As for the jaggies, the amout of coding for the DC would be so mutch, that you might as well add extra resolution. But I'm no DC expert.
 
besides you would end up with a completely different game... Why? because it would be a port... and two people don't think the same manner... in such a figurative sense.. It would be like trying to replicate a human being solely by his/hers looks... (A Snatcher? =P just joking)

Not that it is not worth it (in some cases) but, who would take such a job?
 
Hey, I recently have been trying to research a way to rip textures, models, etc.... Anyone know a good place to start. I haven't found anything, allt this time I just been designing a model of the rider and dragoon from panzer dragoon saga....
 
It is possible to convert Saturn 3D models to some standard format. Each face in the saturn model is made of 4 vertices, the converter could simply create 2 triangular faces for each quad face. Of course, in certain cases the result would look quite different... since the saturn's sprite rendered can deal with faces made of non co-planar vertices without trouble - after all, they'll be converted to 4 flat screen coordinates where the distorted sprite corners will be drawn - but when sliced into 2 triangular faces, the volume effect wouldn't be the same.

Also, hardware acceleration is possible. Just grab all the vertices on the scene (2D and 3D, doesn't matter), and use them to build textured polygons, that can be easily manipulated by any 3D hardware. I think the Satourne and the Giri Giri both do that, since they allow the use of HW bilinear filtering, and giri giri has texture perspective correction problems.
 
Originally posted by M3d10n@Aug. 14 2002, 10:21 am

It is possible to convert Saturn 3D models to some standard format. Each face in the saturn model is made of 4 vertices, the converter could simply create 2 triangular faces for each quad face. Of course, in certain cases the result would look quite different... since the saturn's sprite rendered can deal with faces made of non co-planar vertices without trouble - after all, they'll be converted to 4 flat screen coordinates where the distorted sprite corners will be drawn - but when sliced into 2 triangular faces, the volume effect wouldn't be the same.

Also, hardware acceleration is possible. Just grab all the vertices on the scene (2D and 3D, doesn't matter), and use them to build textured polygons, that can be easily manipulated by any 3D hardware. I think the Satourne and the Giri Giri both do that, since they allow the use of HW bilinear filtering, and giri giri has texture perspective correction problems.

Er, that's not that immediate. The main problem, actually, is the matrix deformations. Unlike the Dreamcast and N64 (and PSX?) there aren't the so called "display-lists", ie. a list of 3D models that is to be rendered. What are is a list of sprite deformations, in the form of lots of matrix data. That has no correlation with 3D space, but can be turned into 3D polys (like giri giri and satourne do). But, when we get that matrix data, the SH-2 processor has already done all the 3D world to 2D plane conversion, so the resulting acceleration is minimal.

We'd need to find out _when_ the SH-2 are making that conversion, and then use an PC/DC native code. It would be kinda like MDEC decoding por PSX. The problem is that the library (and can be hundreds of diferent solutions for all we know) is not always in the same place in memory, since it's linked at compile time...
 
It is possible to convert Saturn 3D models to some standard format. Each face in the saturn model is made of 4 vertices, the converter could simply create 2 triangular faces for each quad face.

The models can use any representation that the artists and/or programmers find convenient. It only needs to be in quad format for the final render by the VDP1, which most likely only gets fed parts of the models (any time spent drawing non-visible parts is wasted, after all). Like Takashi said, to really rip models you need to find the transformation code and reverse engineer the model format from that.

Of course, in certain cases the result would look quite different... since the saturn's sprite rendered can deal with faces made of non co-planar vertices without trouble - after all, they'll be converted to 4 flat screen coordinates where the distorted sprite corners will be drawn - but when sliced into 2 triangular faces, the volume effect wouldn't be the same.

Actually, VDP1 doesn't handle 3D at all. All it draws are scaled/distorted 2D quads. any coplanarity and perspective issues have to be dealt with in the transformation code that generates the VDP1 display list. Realistically, I doubt that non-coplanar polygons are used with any significant frequency, since it's a pain in the ass to deal with in any case.

The main problem, actually, is the matrix deformations. Unlike the Dreamcast and N64 (and PSX?) there aren't the so called "display-lists", ie. a list of 3D models that is to be rendered.

As far as I know, such things don't really exist on PSX, N64 or Dreamcast either, except to the extent that the console manufacturer will assassinate any project that doesn't use standard library code (which is why many N64 emus are so damn speedy at emulating the RCP).
 
As far as I know, such things don't really exist on PSX, N64 or Dreamcast either, except to the extent that the console manufacturer will assassinate any project that doesn't use standard library code (which is why many N64 emus are so damn speedy at emulating the RCP).

Well, but the concept that there is a "poll" of raw 3D data in a given fixed format that one could take advantage is there. Or something. I really not into next-gen emulation enough to know the terms they use.
smile.gif
 
Well, but the concept that there is a "poll" of raw 3D data in a given fixed format that one could take advantage is there.

I don't think it is, except when standard transformation libraries are used (which means it's essentially the same situation as on Saturn). AFAIK, pretty much no recent PSX emulator does "HLE" of the GPU because many games use custom list-building code. N64 emulators can get away with doing this with the RCP (consequently eliminating the need to emulate a ~60MHz MIPS MPU with a vector coprocessor) because Nintendo apparently required developers to use a standardized set of RSP microcodes based on OpenGL.
 
Back
Top