nVidias Dawn now works on R3x0

On the topic on whether the wrapper is legal ... I would assume it has the same status as for instance Wine or DosEmu or other emulators. Wine has been emulating Windows in Linux for quite a long time, never heard anything about any lawsuit, so I assume it's legal. I would assume the same thing about this wrapper, it's equivalent AFAICT.

On the topic of OpenGL. The strength, (and not the drawback as some implies) of the API is that it is extensible. There's absolutely no problem with the API as such or that it's extensible. The problem is that sometimes there's a lack of communication within the ARB. ATI and nVidia exposing their own shading extensions, nVidia silently developing Cg parallel with the GL2 shading language being developed basically undermining the ARB effort etc. Don't blame anything on Carmack, blame it on IHVs. That Carmack made IHV's adopt OpenGL has done loads of good for us. It made it possible to run pro apps on standard PCs. It made gaming in Linux possible strengthening the OS' position, it made graphics develop faster as new technology was immediately available in the API etc etc. Carmack did the right choice, even for gamers. He gives gamers the choice of using Linux.

 

the other great thing about opengl is it is free and it will stay free microsoft if it felt like it after it kills OGL could start charing developers who whish to use direct X.

 

The only thing that I've seen that may be slightly on the ilegal side with this is that you can now put the ATI badge on the demo. I'm pretty sure that rebadging prgrams as your own isn't quite within the law. And if nvidia wanted to get picky about it I'm sure they could say that the wrapper allowed others to plagarise their copyrighted material and advertise it as their own.

 

And Macs!
Yes, yes, I know, the mac is not a gamers choice of platform.
But even regular people (non-gamers) do appreciate having the option of fragging/RPGing/waging strategic 3D war every once in a while.

Besides, computer graphics has a much, MUCH wider application arena than "PC-gaming" which is the almost exclusive focus of these forums.
The open nature and portability of OpenGL is a great boon to people who do not necessarily want their work to be strictly tied to Microsoft Windows.

Entropy

 

Don't forget GL_EXT_texture_compression_s3tc, probably by far the most important proprietary GL extension (every game out there can use it, but it can't be implemented in the opensource DRI drivers).

edit: just wanted to clarify, this is not even a vendor specific extension (it's a standard extension), yet it is proprietary.

 

The problem is not with the wrapper, it's with Dawn itself. I started to 'hack' away at it removing the SSE code, but I would get rid of some, and there would be more code that needed removing. There is just 'so' much SSE code that getting rid of it isn't really feasible. In one case it looks like an entire function needs to be re-written, and once i saw that I pretty much just said no.

 

Good point, and I agree completely. In a game environment or with proof that PCs can do more than just one pretty girl, I would be very impressed.

And I should say that when you zoom in and recognize that the level of detail increases so that if her face fills the entire screen it is very detailed then it is pretty impressive.

 

You know you must start with something 'simple'...
Do the 'shaders' and/or geometry change ?
(cannot run the demo, I only have a 8500 in here)

 

If you're a developer who wants to do cross-platform--OpenGL is the only way to go, certainly. But I think blaming the IHV's for the natural consequence of making the API extensible is not a profitable way to view the situation. The very act of making it extensible would in itself create these conditions between IHVs who are competing with each other for market and mindshare in the wider market. Because D3d is not open to extensions this simply cannot happen. That's the point.

I am utterly apolitical when it comes to OS's, and so are a lot of people. Blaming sources of the problem won't solve the problem, is what I'm saying. It doesn't matter whether one blames Carmack, the IHVs, the ARB committe, or whom/whatever for the problem--the fact is that the allowance of vendor-specific proprietary extensions is fragmenting the API. Without them--problem goes away.

It's merely a matter of balancing pros & cons, I think, not a matter of perfection. I think the API needs to be robust enough itself so that the matter of proprietary vendor-specific extensions becomes moot. It looks to me that the same extensibility that people applauded for OpenGL (and some did not) is today what is actually slowing down the progress of the API's maturity.

 

Thanks for giving it a shot Colourless. One more reason for me to upgrade this cpu.

 

Don't thank me till you finish reading the post. Turns out, the 'entire' function that needed to be re-written was actually the last thing that needed to be done. And it was actually pretty straight forward in the end, and converted to 3DNow with no real effort at all.

So, what does all that mean?

Well it means I got rid of all the SSE code (I think), and Dawn runs pretty well for me on my Thunderbird

So, download this: http://www.users.on.net/triforce/dawn_thunderbird.zip

You will notice it contains a DLL, glu32.dll. Just copy the DLL to the dawn\bin dir and you should be ok to go.

I make no guarantees about if it will work. It is a really big hack. I make assumptions about the memory locations of SSE code in fairy.exe. This *shouldn't* be a problem unless fairy.exe is relocated. There is no reason relocation should occur though.

For those curious about what I've done. When the DLLMain function for my glu32.dll file is called by Windows, it goes through and replaces all the SSE code in the loaded fairy.exe with call opcodes to my replacement code. nops are then used to fill in the rest of the space (if any). The glu32.dll is simply a vehicle used so I can execute the patching code. All of the GLU calls are simply passed through to the normal windows glu32.dll.

 

Colourless, it works great! Thanks so much man. Have you sent a copy of this to MR.B at rage 3d so he can include it with the glwrapper?

 

No I haven't told anyone, but the people here. I might though.

 

And the Academy Award for "Best hack of a hack" goes to.....


....Colourless!

 

Nice work Colourless

Interesting to see if the 3Dnow would be faster than my SSE on my Athlon XP

 

It will probably be slower, but not because of the 3DNow being slower than the SSE. All the GLU funcs (and I have no idea how often they are even called) will be marginally slower. Also, all of the code that i replaced appears to be part of the loading sequence. Its hard to tell though. Why it was written in SSE then I don't think i'll ever know. Possibly just the Intel compiler being 'smart'.

Some of the code will be slower than the original SSE code. There were numerous instances where SSE code was used to do square roots, reciprocals and reciprocal square roots of only a single float. In these cases I replaced the code with x87 code rather than use 3DNow, which will be slower than the SSE code.

 

Fan f**king tastic - thank you so much - works perfectly now !!!!!

 

Hope you don't mind Colourless, I sent an e-mail to Mr. B telling him about this. I pointed him to this thread and asked him if he could host the file along with the glwrapper on his Dawn on ATI cards page. Haven't seen any update on his page yet though. Again, thanks for taking the time to get this working.

 

Hi Colourless do you have any idea how Nvidia managed to break compatability with 9x/me for the Dawn demo? Atleast I assume they did as as you may have heard the wrapped dawn demo does not work on 9x/me.
(nvidia only officially supports dawn on xp although it seems from feedback to run on 2k/xp)

 

Thanks Thanks Thanks Thanks Thanks Thanks Thanks
Thanks Thanks Thanks Thanks Thanks

To Colourless.