| Home | Forums | What's new | Resources | |
| Saturn Emulation... |
| crystalmethod - Dec 10, 2001 |
| ExCyber | Aug 17, 2002 | |||||||||
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. 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. 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). | ||||||||||
| TakaIsSilly | Aug 18, 2002 | |||
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. | ||||
| ExCyber | Aug 19, 2002 | |||
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. | ||||