pouët.net

I think the information sort of got to my brain now, thanks for sharing spike. In any way, before i have to take care of such issues, I'd have to write an application that is worth being ported at first!

In the era of shaders it is no longer relevant.
D3D10+ and new versions of OpenGL (ES) have removed any fixed-function matrix functionality anyway, so it is entirely up to you what type of matrices you use.
In the end you just pass arrays of floats to the shaders, and the shader languages are capable of handling matrices either way.

So even if you want to do an engine that is cross-API, you don't necessarily have to have two separate codepaths for matrix math.

so in the era of javascript it is no longer relevant to understand how a CPU works? great :)

now it's just getting sad

1. scali: there's more to life than gpu based rendering (but you're right, though)
2. spike: stop being dumb

You can tell glm if you're using a row major order or column major order system. I never used it though, as I'm only OpenGL.
Anyway, using glm (or anything else, glm is only an example) for everything and fixing only the perspective matrix (which is kind of a hack, by the way) should do the trick quite easily.

There's more difference between D3D and GL (and other hardware/APIs) projection matrices than a simple transpose; eg. the range and even the direction of post-projection Z, the exact screen pixel offset, etc. That's the one part that needs to be platform dependent. Best to just have per-platform setup routines for orthographic and projective matrices that do the right thing.

There is? Like what? Amigas? 286s? C64?... :P

Better idea than what I used to do. But OK, that was porting ;)

Yes, the pixel:texel mapping was also changed from D3D9 to D3D10.
Iirc D3D10+ uses the same mapping as OpenGL now (1:1, rather than shifted by half a unit).

that's the first thing that struck me too, kb still in d3d9-land? :)

oh look at this "i know i know" thread derailment.