Ah this makes perfect sense and is exactly what I was looking for, thank you for your response! My limited understanding from the article was that 2.3 was simply cleanup and putting some extensions in the official API that have been in drivers for a while just not in the official API and then 3.0 is where the real change will be, BUT that it will only activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 cards). Please correct me if my understanding is incorrect and again I think we all realize this is all in the future and is just fun to talk about^_^
Thanks for all THE fish, -Matt
PS Yes I am an idiot some times =P
Stefan Dösinger wrote:
We are waiting for the final API before deciding if we like it or not. But from what I've read so far the changes make sense.
My concern is backwards compatiblity. For dx 1 to dx9 we will still need the old apis. For one part because the new api may not offer fixed function functionality, but more importantly because old cards will most likely not see any driver updates.
If the interface is vastly different we'll need 2 d3d implementations, one wrapping to old gl and one for the new version. An idea would be to just leave dx1 to 9 with gl 2.0 and write dx10 only for opengl 3.0.
If the new API allows it however, we want to keep the wine code unified. This could happen by simply duplicating very specific functions which are different, and then select them at creation time by choosing a different virtual function table. If we need an if condition for every opengl call we do it would be pointless to keep everything in one lib.
But we need to know the final opengl 3.0 API to decide what to do.
Hi guys,
I also read this short article recently. I agree with Stefan that we should wait until the API is finalized. I'm pretty sure that the 3.0 specification will be backwards compatible with 2.x in much the same way as 2.0 is backwards compatible with 1.1
By waiting a few weeks/months until we know for sure what the new extensions comprise (rather than diving in now with the NVidia specific ones), we'll be able to use the portable ones from the start.
Regards, Phil
Matthew Clark wrote:
Ah this makes perfect sense and is exactly what I was looking for, thank you for your response! My limited understanding from the article was that 2.3 was simply cleanup and putting some extensions in the official API that have been in drivers for a while just not in the official API and then 3.0 is where the real change will be, BUT that it will only activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 cards). Please correct me if my understanding is incorrect and again I think we all realize this is all in the future and is just fun to talk about^_^
Thanks for all THE fish, -Matt
PS Yes I am an idiot some times =P
Stefan Dösinger wrote:
We are waiting for the final API before deciding if we like it or not. But from what I've read so far the changes make sense.
My concern is backwards compatiblity. For dx 1 to dx9 we will still need the old apis. For one part because the new api may not offer fixed function functionality, but more importantly because old cards will most likely not see any driver updates.
If the interface is vastly different we'll need 2 d3d implementations, one wrapping to old gl and one for the new version. An idea would be to just leave dx1 to 9 with gl 2.0 and write dx10 only for opengl 3.0.
If the new API allows it however, we want to keep the wine code unified. This could happen by simply duplicating very specific functions which are different, and then select them at creation time by choosing a different virtual function table. If we need an if condition for every opengl call we do it would be pointless to keep everything in one lib.
But we need to know the final opengl 3.0 API to decide what to do.
-
Matthew Clark -
Phil Costin