On the one hand, it's unfortunate that we need to use wrappers to get old stuff working. On the other hand, it's good, because it means old stuff can't crash our systems. In any case, who said you all could communicate via email and not let everyone in on the juicy details? That's just not nice! 😉

I think implementing OpenGL or D3D on top of Glide might be the easier direction. OpenGL and D3D commands tend to be at the level of "what you want done", whereas Glide is closer to setting up the hardware in a way that gets the job done. An OpenGL to Glide wrapper would be a bit like an OpenGL driver for a real card, or that higher levels of such a driver. That's a bit of an over generalisation, but sort of true.

The difficulty with Glide to OpenGL is that the various functional units can be set up in some really weird ways that don't necessarily map onto sensible OpenGL commands.

I suppose all the modern OpenGL extensions would be hard to map onto Glide.

Thought: Maybe once OpenGlide is in a thoroughly debugged and beautiful state, we let the WineX guys have a go with it (WineX is by Transgaming Technologies http://www.transgaming.com/) It's a compatibility "layer" for Linux, permits Win32 and Win16 programs to run in Linux. You think that's Wine, eh? (http://www.winehq.com/) Well WineX additionally translates D3D to OpenGL and DirectX to whatever else corresponding Linux API. Perhaps they'd like this, who knows...

Anyhow, back to the original question.

I have a vision of an arbitrary API framework that could be used to recompile code from -one- API to another. I'm simply trying to determine if it's possible, if it's probable, estimated development man-hours or man-days, etc. Where problems would occur, thoughts about implementation. That's kinda why I asked this question.

Stiletto wrote:

I have a vision of an arbitrary API framework that could be used to recompile code from -one- API to another. I'm simply trying to determine if it's possible, if it's probable, estimated development man-hours or man-days, etc. Where problems would occur, thoughts about implementation. That's kinda why I asked this question.

Not quite sure what you mean. Are you suggesting you might take the source code of a game that uses Glide and apply a transformation to it to produce the same game but using OpenGL?
Something like that.

Yes.

I also have a vision of a Stiletto-API. Write in Stiletto-API, choose target API (OpenGL, Direct3D, Glide, RRedline, etc.) and compile. However, there's the problem of SDK licenses (grr...)

I think there must already be in-house Stiletto APIs, for any game that lets you select between D3D and OpenGL. Looking at the Descent II source, they also have a sort of Stiletto API that is implemented either in Glide or OpenGL.

I guess the main problem would be that you could efficiently support only the common capabilities.

Glidos wrote:

implemented either in Glide or OpenGL.

Oops! Meant Glide or software.

Snover wrote:

In any case, who said you all could communicate via email and not let everyone in on the juicy details? That's just not nice! 😉

The upshot is Vlad and SaPu (http://sapu.ngemu.com/index_e.html) may have this MSCDEX thing figured out. I'm hangin' on to the technical conversation by the skin of my teeth. 😀

Glidos wrote:

I guess the main problem would be that you could efficiently support only the common capabilities.

Still, depending on the API, that could be quite a lot of functions. I hope someone smarter than me takes a look into this at some point.