DirectX 10 start as a SoC project?
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: -> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan
Am Samstag 10 März 2007 19:39 schrieb Ivan Gyurdiev:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that would be another story.
Also, you have to have a well-defined project to set completion criteria. "starting the infrastructure" does not define when the project is complete. Yeah, Henri had the same concern. We need proper completion conditions. How about: "Have d3d10 headers, a d3d10.dll with creator functions, functions calling wined3d where applicable, at least a stub for each other function and routine tests for reference counting and things that can be checked on the implemented functions" ?
Stefan Dösinger wrote:
Am Samstag 10 März 2007 19:39 schrieb Ivan Gyurdiev:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that would be another story.
Also, you have to have a well-defined project to set completion criteria. "starting the infrastructure" does not define when the project is complete.
Yeah, Henri had the same concern. We need proper completion conditions. How about: "Have d3d10 headers, a d3d10.dll with creator functions, functions calling wined3d where applicable, at least a stub for each other function and routine tests for reference counting and things that can be checked on the implemented functions" ?
This is describing a well-understood approach to adding a new DLL. I think the SoC project needs to push the participant to be creative and solve a significant obstacle in wine development, which others find challenging. Yes, I am sure wine will benefit greatly from a d3d10 stub, mapping 1-to-1 to wined3d where possible, but is it really a project that requires a lot of creativity and the whole summer to do ? I think something that adds new functionality and can't mirror d3d8/d3d9 would be better. Ivan
On Sat, 2007-03-10 at 14:13 -0500, Ivan Gyurdiev wrote:
Stefan Dösinger wrote:
Am Samstag 10 März 2007 19:39 schrieb Ivan Gyurdiev:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that would be another story.
Also, you have to have a well-defined project to set completion criteria. "starting the infrastructure" does not define when the project is complete.
Yeah, Henri had the same concern. We need proper completion conditions. How about: "Have d3d10 headers, a d3d10.dll with creator functions, functions calling wined3d where applicable, at least a stub for each other function and routine tests for reference counting and things that can be checked on the implemented functions" ?
This is describing a well-understood approach to adding a new DLL. I think the SoC project needs to push the participant to be creative and solve a significant obstacle in wine development, which others find challenging.
Why do SOC challenges need to require creativity and be challenging? Seems to me like the BORING projects are the best way for people to learn. This is especially so when no one else wants to do them. Like, say, writing test cases for all the functions we already have. Thanks, Scott Ritchie
On 3/10/07, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that would be another story.
I am a computer science student in the 4th year. Stefan's project idea seems like something that I can actually try manage to accomplish in the SoC time range provided I get a decent amount of mentoring. I say this because I do not have much programming experience, especially with something as monstrous as Wine. I have never written my own compiler nor had to look at the internals of one. All I have is good knowledge of C, a strong desire contribute to Free Software, desire to learn, and a special interest in the Wine project. In other words, I don't think this would be "too easy" for me. It will be a good learning experience, however.
Also, you have to have a well-defined project to set completion criteria. "starting the infrastructure" does not define when the project is complete.
Stefan mentioned writing a number of functions which can easily be counted: - stubs for the functions to allow the app to create all the interfaces - methods that have already 1:1 equivalents in wined3d Will comparing that to the number of functions that actually get written not be a good measure of progress? -- Libre Software: http://www.gnu.org/philosophy/free-sw.html
Saturday March 10 2007 15:56、Stefan Dösinger さんは書きました:
Opinions? Suggestions?
I think that's good idea. This is because adding DirectX 10 support will take some time (that is, support complete enough to make most DirectX 10 applications to work), and if wait too long with start, lack of DirectX 10 will be more and more severe trouble (more DircectX 10 applications - more problems for users because of no support; this is especially true for users that don't have or don't use Windows at all, only Linux, like me or my brother for example).
"Have d3d10 headers, a d3d10.dll with creator functions, functions calling wined3d where applicable, at least a stub for each other function and routine tests for reference counting and things that can be checked on the implemented functions"
It seems to be clear enough to me.
I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Cheers, Stefan
-- Cheers, Bryan
Ack I also meant to mention that yes, if we do this, we would be a little ahead of the game when DX10 apps really start rolling out, but if we do, we might also have some DX 8 and 9 people stray to 10... just a worry. I'm sure it will work out. Everything will be done eventually! Thankfully SoC really gives people a push, eh? On 3/10/07, Bryan Haskins <kingofallhearts999(a)gmail.com> wrote:
I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there.
I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol.
On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Cheers, Stefan
-- Cheers, Bryan
-- Cheers, Bryan
Am Sonntag 11 März 2007 00:06 schrieb Bryan Haskins:
I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. The idea is that our main Direct3D engine, wined3d, is shared between all Direct3D versions, from Direct3D 1 to Direct3D10. Admitadely, the core functionality that is equal between d3d1 and d3d10 is comparably small, and the part that exists should work pretty well by now. But work on d3d10 games can definitly fix bugs in d3d9 apps accidentally, in the same way the d3d7 merge fixed bugs in wined3d that affected d3d9 apps.
Also consider that d3d10 may need some architectural changes to wined3d. I think it is better to make them now and when further optimizing it have things in the d3d10 style than to drive everything to d3d9 and see in a year that we have to turn a few core parts upside down. Of course having one SoC project on d3d10 does not exclude someone else who wants to do something do a SoC project on d3d9 :-) . Ideas would be Overlay support for movie players or the d3dx9_xy helper DLLs(Although those are maybe out of scope for wine). Or even a completely different area of DirectX. DirectSound, DirectPlay, ...
I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. One problem is nowadays that wined3d is pretty advanced already, and the learning curve is rather hard already. D3D10 is in my eyes an oportunity of an exciting project which allows a new developer to grow into wined3d. I personally won't start hacking on d3d10 immediately, I'll continue to work on d3d9 and below apps. The state of d3d9 does not justify that yet.
And I think that *Direct3D* isn't in a bad shape nowadays. We recently had a nice success when that new Command and Conquer game came out, and ran on the day it hit the shelves. Wine is getting the public opinion that it does better on games than Cedega. What we should not shout our loudly is the shape of other DirectX stuff. DirectSound is an issue, although I must say that Maarten Lankhorst is doing nice work on winealsa :-)
That pretty much what I meant, you just explained it in a clearer way... I only had a minute or so to type it in heh. The irony here is I was writing it while playing WoW via wine through opengl... The factor of irony is overwhelming =P. I basically agree. I figured (without actually looking at it) that d3d was a shared code-base of some kind with the individual dx dlls basically pointing here and there for the nuggety center. Now just throwing up a (pretty much) mock up of d3d10 or dx10 in general would be great, it would atleats give a little structure, and as you said ease the code to a new structure if need be. On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Am Sonntag 11 März 2007 00:06 schrieb Bryan Haskins:
I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. The idea is that our main Direct3D engine, wined3d, is shared between all Direct3D versions, from Direct3D 1 to Direct3D10. Admitadely, the core functionality that is equal between d3d1 and d3d10 is comparably small, and the part that exists should work pretty well by now. But work on d3d10 games can definitly fix bugs in d3d9 apps accidentally, in the same way the d3d7 merge fixed bugs in wined3d that affected d3d9 apps.
Also consider that d3d10 may need some architectural changes to wined3d. I think it is better to make them now and when further optimizing it have things in the d3d10 style than to drive everything to d3d9 and see in a year that we have to turn a few core parts upside down.
Of course having one SoC project on d3d10 does not exclude someone else who wants to do something do a SoC project on d3d9 :-) . Ideas would be Overlay support for movie players or the d3dx9_xy helper DLLs(Although those are maybe out of scope for wine). Or even a completely different area of DirectX. DirectSound, DirectPlay, ...
I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. One problem is nowadays that wined3d is pretty advanced already, and the learning curve is rather hard already. D3D10 is in my eyes an oportunity of an exciting project which allows a new developer to grow into wined3d. I personally won't start hacking on d3d10 immediately, I'll continue to work on d3d9 and below apps. The state of d3d9 does not justify that yet.
And I think that *Direct3D* isn't in a bad shape nowadays. We recently had a nice success when that new Command and Conquer game came out, and ran on the day it hit the shelves. Wine is getting the public opinion that it does better on games than Cedega. What we should not shout our loudly is the shape of other DirectX stuff. DirectSound is an issue, although I must say that Maarten Lankhorst is doing nice work on winealsa :-)
-- Cheers, Bryan
On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Wasn't there mention of making a Windows XP version of wine's DirectX 10, so people can use XP for gaming instead of Vista? If so, it would be nice if your code compiles and works on Windows too.
Cheers, Stefan
Cheers Damjan
Wasn't there mention of making a Windows XP version of wine's DirectX 10, so people can use XP for gaming instead of Vista?
If so, it would be nice if your code compiles and works on Windows too. Yes, that is the idea :-)
Just one note for clarity: I am a student, but I do not plan to work on D3D10 myself as a SoC project. I am rather suggesting it to other people interested :-) Oh, and just in case we run out of idea, there is still plenty work to do for DirectX. Other Ideas are dplay.dll, d3dxof.dll, dmusic.dll, d3dx9_xy.dll, dsound, ...
On Sunday 11 March 2007 13:53, Stefan Dösinger wrote:
Oh, and just in case we run out of idea, there is still plenty work to do for DirectX. Other Ideas are dplay.dll, d3dxof.dll, dmusic.dll, d3dx9_xy.dll, dsound, ...
After Stefan mentioned this a couple of times, I'd like to restate that I'd stongly suggest anyone considering to tackle dplay or related things to shoot me an email first. I'm not planning to do this myself for this year, but I'm planning to participate in GSoC as a student, so I can't mentor anyone there. Of course if anyone is really good at that sort of work, I'll be happy to offer help on what I already have and all. I just think we still don't know enough about the dplay protocol to make a SoC project out of this. My EUR 0.02 Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Cheers, Stefan
The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API. Jesse
Jesse Allen napsal(a):
On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Cheers, Stefan
The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API.
Jesse
Nvidia introduced Nvidia SDK for DirectX 10 http://developer.nvidia.com/page/home.html direct link: http://developer.nvidia.com/object/sdk_home.html Mirek Slugen
Am Sonntag 11 März 2007 19:40 schrieb Jesse Allen:
On 3/10/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late.
My idea is to start a d3d10 implementation up to the following point:
-> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-)
I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it.
Opinions? Suggestions?
Cheers, Stefan
The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API. Regarding applications, I have a few of them:
/opt/windows/dxsdk/dx9/Samples/C++/Direct3D10 $ ls BasicHLSL10 GPUSpectrogram PipesGS Bin HDRFormats10 ShadowVolume10 CubeMapGS HLSLWithoutFX10 SimpleSample10 DisplacementMapping10 Instancing10 Skinning10 DrawPredicated MotionBlur10 SoftParticles EmptyProject10 MultiStreamRendering SparseMorphTargets FixedFuncEMU ParticlesGS Tutorials 21 applications, so it is a widely used API. Oh ooops, those are just the sdk demos. And only 19 of them, bin/ and EmptyProject10/ do not really count... Jokes aside, there aren't any dx10 apps yet, except some demo apps. The first one to be expected is Halo 2 on April 24th afaik. The only thing is that MS has created some hype around dx10 recently. It would give us some nice publicity if the Halo 2 box states "Runs on Windows Vista and higher" and winehq.org says "Runs Halo 2 on Linux, MacOS, Windows XP and earlier" I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going. Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't purely for educational purposes. No idea of SoC can be considered an educational thing.
On 3/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Am Sonntag 11 März 2007 19:40 schrieb Jesse Allen:
The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API.
Regarding applications, I have a few of them:
/opt/windows/dxsdk/dx9/Samples/C++/Direct3D10 $ ls BasicHLSL10 GPUSpectrogram PipesGS Bin HDRFormats10 ShadowVolume10 CubeMapGS HLSLWithoutFX10 SimpleSample10 DisplacementMapping10 Instancing10 Skinning10 DrawPredicated MotionBlur10 SoftParticles EmptyProject10 MultiStreamRendering SparseMorphTargets FixedFuncEMU ParticlesGS Tutorials
21 applications, so it is a widely used API. Oh ooops, those are just the sdk demos. And only 19 of them, bin/ and EmptyProject10/ do not really count...
Jokes aside, there aren't any dx10 apps yet, except some demo apps. The first one to be expected is Halo 2 on April 24th afaik. The only thing is that MS has created some hype around dx10 recently. It would give us some nice publicity if the Halo 2 box states "Runs on Windows Vista and higher" and winehq.org says "Runs Halo 2 on Linux, MacOS, Windows XP and earlier"
I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going. Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't purely for educational purposes. No idea of SoC can be considered an educational thing.
Okay, the test apps you have are a decent start. On buying vista, it would have to depend on getting accepted for the project, because I can't do that right now. I have that kind of typical student budget. Now I'll hunt around for the ed version here. Maybe we got it at my bookstore. But I don't mind buying any upgrade version for my XP laptop. Even ultimate. Jesse
On 3/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going.
Well if I am able to use my laptop, it has the ATI XPress 200M. DX9 compatible chip. But I have been rather dissappointed with the ATI driver in linux. Maybe I should verify if it works now. Do you think this may be a good enough?
On 12/03/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 3/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going.
Well if I am able to use my laptop, it has the ATI XPress 200M. DX9 compatible chip. But I have been rather dissappointed with the ATI driver in linux. Maybe I should verify if it works now. Do you think this may be a good enough?
I think Stefan was referring to verifying d3d10 behaviour on Vista. For most of the basic stuff ATI should be fine, but they've got some nasty bugs/quirks in some of the more advanced GL features.
Am Montag 12 März 2007 17:38 schrieb Jesse Allen:
On 3/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going.
Well if I am able to use my laptop, it has the ATI XPress 200M. DX9 compatible chip. But I have been rather dissappointed with the ATI driver in linux. Maybe I should verify if it works now. Do you think this may be a good enough? It certainly won't work for rendering anything, unless mesa software is extended to support GL_EXT_geometry_shader. On windows you can render with Microsoft's reference rasterizer. Though you have to consider that it is a long way until any rendering is done. I think we will need at least the shader compiler for that.
On 3/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't purely for educational purposes. No idea of SoC can be considered an educational thing.
When I checked my bookstore, Vista Home out of stock. Vista Business was available, but that's not an education version. They have XP Pro student, and it clearly states on the front to not be used for commerical purposes. Despite the intended nature of the project I'd rather just buy a regular copy to keep myself out of trouble.
participants (11)
-
Bryan Haskins -
Damjan Jovanovic -
H. Verbeet -
Ivan Gyurdiev -
Jesse Allen -
Kai Blin -
L. Rahyen -
Michael [Plouj] Ploujnikov -
Mirek -
Scott Ritchie -
Stefan Dösinger