-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi jason,
Great work, and its good to know we are making progress. I spend most of my time working on small tutorials and demos which highlight a specific problem, and havent yet had the 'pleasure' of spending much time playing the games I have got working!! A list like this is really good (as is the fact you have been creating patches!! - I'm not sure about the device.c one though, as I think copyrects is hacked to allow back buffer updating which would otherwise fail as you are copying to a render target). All patches, help and assistance welcome
I think we can easily fix the two cases unsupported on CopyRect
- I spend far too many nights up to about 1am trying to get things working.
As me :)
Personally I would love to have someone maintain a list of things which work and which fail, and test them periodically, seperated into the d3d level. One huge problem I have is regressions - I can code something to fix a particular feature but its very easy to break something else, and similarly its nice to know that a particular change actually fixes some other games!!
:)
Finally some info, I am currently spending my time trying to get some features of d3d8 working. I have put on hold render to texture and am concentrating on some other areas, although I want to get that one working. I then need to make a choice - I can either concentrate on performance, on adding hardware vertex shader support or on adding d3d9 support, and I havent decided which.
For hardware vertex shader, i'll send my proto when glx cards drivers will really support it with usable performances (it's unusable on my gf4 card and the support of pixels shaders have to wait for a glx driver that support it for testing)
I think d3d9 would make sense to wait until last otherwise any performance work will need doing in one place. I have an idea on some ways of speeding things up and have a glcore type setup which has been discussed before.
I think beginning with moving drawing code and texture code from d3d8 to wined3d should be easy.
One other thought. At some point in time we will have to address copy protection. I dont want to get into legal discussions and I dont intend looking into it (yet), BUT would I be correct in saying that if someone worked out the first point at which copy protection fails, and codes a basic application which emulates this behaviour. Since this simple app works on windows, then someone else could then work on getting the basic program working under wine without being contaminated by knowledge of the internals of the copy protection itself? If this is the case, it would be a useful thing to put on the projects page. If the legality of this is dodgy, forget it - there are always hacks around, its just frustrating.
For what i remember, copy protection is almost specific how cdrom windows driver work. We "only" have to completely emulate this behavior
Anyway, back to my next problem. Jason
And me to my dmusic code for unreal2 Regards, Raphael
PS: when i'll get this dmusic code working, i'll return to d3d8-9 :)