VOGONS


First post, by Stiletto

User metadata
Rank l33t++
Rank
l33t++

BTW, Paul, Fabio - check this out:
showthread.php?s=&threadid=279

Here's my complete email from him:

>Hi Zeckensack, >Are you still working on your Radeon Glide wrapper? Would you like to >help work on >OpenGlide instead? > >See […]
Show full quote

>Hi Zeckensack,
>Are you still working on your Radeon Glide wrapper? Would you like to
>help work on
>OpenGlide instead?
>
>See here:
>http://sourceforge.net/projects/openglide/
>
>The latest release on CVS contains the source code to the latest version of
>OpenGlide merged with the changes made by the author of GliDOS
>(http://www.glidos.net) - it's not compiled for a binary release (yet).
> But if you'd like to submit
>patches to OpenGlide, you're more than welcome.
>

I'll maybe take a look at it and post my findings. But don't expect me to start something thorough. Actually I'm trying to finish up and get rid of that project of mine pretty soon. I think I'm almost there, I've broken some LFB code with the last release that needs
to be fixed and completed, then I'm out of town more or less.
Oh yeah, then my source code will be published and I'll likely GPL it 😀

Then I'll start something new. I'm a bit tired of this glide wrapping business 😁

>A question I've wanted to ask: what makes your Glide wrapper
>Radeon-only?

It uses ATI-specific OGL extensions for the combiner emulation.
ATIX_texture_env_combine3 for Radeon1/Radeon7500
ATI_fragment_shader for Radeon8500/9000 and up

plus some goodies the NV drivers don't support (or didn't when I started), like ARB_window_pos.

Just the usual thing you have to do once you want to do something serious in OpenGL.

But ...
I have changed to sort of a plugin architecture for the pixel path 'backends', and work in progress NV_register_combiners support, which I can't complete/test for lack of NV hardware but it should be
pretty easy to find my bugs and drop the rest right in.

*gone looking at sourceforge*

That's a rather interesting idea to work with vendor-specific OpenGL extensions, don't you think? It might be worth carrying over to OpenGlide. 😀

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 1 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t
Stiletto wrote:

BTW, Paul, Fabio - check this out:
That's a rather interesting idea to work with vendor-specific OpenGL extensions, don't you think? It might be worth carrying over to OpenGlide. 😀

Useful to know about all these things, but really vendor specific extensions are something to be avoided if at all possible. In fact, much better to avoid any use of extensions if possible. You just open yourself up to the wrapper failing on certain cards. Already we have fog not working on voodoo cards because it uses an extension. Might be forced to do so for the sake of speed, though.

Reply 2 of 17, by Snover

User metadata
Rank l33t++
Rank
l33t++

Curiously, what's the easiest way to detect a card type? Through the Windows registry and/or the card's drivers? Or is there some ID that you can get from the ROM on the card?

Don't know why I'm asking, probably a really easy answer to a really dumb question, but oh, well.

Yes, it’s my fault.

Reply 3 of 17, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
Glidos wrote:

Useful to know about all these things, but really vendor specific extensions are something to be avoided if at all possible. In fact, much better to avoid any use of extensions if possible. You just open yourself up to the wrapper failing on certain cards. Already we have fog not working on voodoo cards because it uses an extension. Might be forced to do so for the sake of speed, though.

Aha. Okay. So something to look into later during the optimization phase of development, perhaps, but not so much right now - and best to be avoided, if possible.

I'd still like to see his source, though!

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 4 of 17, by GoldFinger

User metadata
Rank Member
Rank
Member

I don't know about you Paul, but my idea for OpenGLide was for People with newer hardware to use Glide.... 😀
I don't think we should be chained to OpenGL 1.1 or else I can assure you we cannot go much further because of speed limit.
And the only cards that only support OpenGL 1.1 are old ones that will not run Glide in an acceptable way.
Since OpenGL 1.2 most of the extensions were included in the OpenGL specifications.
We have a problem here, a good one I must say, because Voodoo boards (1,2,3,4) were discontinued, there are no newer drivers for them and there will be not.
now the great question... :p
Are we targetting OpenGLide for Voodoo boards? The same ones that have native Glide? That is funny.
Well, anyway I think that we need to support a wide range of boards, but I do not think that we should support all, at least for the our sake and the development of both OpenGLide and Glidos.
I agree that we "should" avoid vendor specific extensions but not extensions at all. I really want to move to OpenGL 1.3 and it features but we can postpone that.
I am open to discussion.... 😀))

Reply 5 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t

Yes I agree completely. With the extensions, other than vendor specific ones, I just meant we should always look for another way first, maybe only as a fallback so that not so well supported cards have a chance. But even in that maybe I'm wrong. If the vast majority of cards support all these features, we should probably use them freely, with perhaps a mind to providing the fall back for cards like the voodoos at a later date.

You can take it for granted that I am happy for you to lead on these issues. You have far more knowledge of OpenGL. I came to this project with no knowledge of OpenGL.

In fact I came to the Glidos project with no knowledge of OpenGL, Glide, VxDs, VDDs, DOS programming, Intel Architecture, Intel assembler, VESA. I'm really not a good choice for the job. 😁

Reply 6 of 17, by GoldFinger

User metadata
Rank Member
Rank
Member

Hahahaha,
But in fact you did a great job, sometimes (most of them) just the will to do something worths more than knowledge on how to do it.
I think we should try to direct (at least for now) the voodoo board owners to the OpenSource Glide pointed by Stiletto. That Glide is intended exclusively for voodoo owners, maybe that is better than OpenGlide.
I will do some research and we can talk more later on how to solve some problems, including the vertex snapping.

Reply 7 of 17, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

All Nvidia TNT+ cards support OGL 1.3.

Unsure about ATI's. The Radeon's most likely support 1.3. The pre-Radeon's mabye 1.2.....mabye.

The Matrox G400's are 1.2 and the Parhelia may be 1.3.

How To Ask Questions The Smart Way
Make your games work offline

Reply 8 of 17, by GoldFinger

User metadata
Rank Member
Rank
Member

Yeah,
I know about that, I wish to get a full picture I mean, let's do a Poll asking what are their video boards and ask them to send the OpenGLid.log file that detect the extensions/opengl version, so we can focus on the most common features.
What do you all think?

Reply 9 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t
GoldFinger wrote:

I think we should try to direct (at least for now) the voodoo board owners to the OpenSource Glide pointed by Stiletto. That Glide is intended exclusively for voodoo owners, maybe that is better than OpenGlide.

Yes quite agree. Afterall, the Voodoo owners should be the one group that don't need OpenGLide. Having said that though, some reports of experiences with RB, suggest that the Voodoo drivers are less Glide compliant than OpenGLide. 😀


I will do some research and we can talk more later on how to solve some problems, including the vertex snapping.


Yes, I'll look forward to it. AP88 via multitexturing would be good too. I also have some reinstated window-creation code, I could check in when you're ready, although only if we need it. So far for me it hasn't made nay new games work.

Also, did you do any tests? I'd love to know if, during the process of making new games work, many previously working games were lost.

Reply 10 of 17, by GoldFinger

User metadata
Rank Member
Rank
Member

I did not test any new (or old) game yet, did not have time to do it at home.
Can you explain to me the problem with vertex snapping?
What was happening and why, you said you do something with the vertex values before sending to OpenGLide, what is it?

Reply 11 of 17, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
GoldFinger wrote:

I think we should try to direct (at least for now) the voodoo board owners to the OpenSource Glide pointed by Stiletto. That Glide is intended exclusively for voodoo owners, maybe that is better than OpenGlide.

Hold up!

By all means, Voodoo users should be attempting to use Glide as it runs native on their card.....

... unless they want to run their Glide game in a window (See: WinGlide - http://www.google.com/search?q=WinGlide&num=100&filter=0)

... or there's some graphical problem which can be solved by piping Glide through a wrapper...

... or they just don't want to.

But the project I linked to, http://www.sourceforge.net/projects/glide
it does not include binaries, and is really only there for Linux users!

So Voodoo users, if they want to use Glide, should refer to their drivers. And you know places to get Voodoo drivers (http://www.google.com/search?num=100&q=Voodoo+drivers)

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 13 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t
GoldFinger wrote:

I did not test any new (or old) game yet, did not have time to do it at home.
Can you explain to me the problem with vertex snapping?
What was happening and why, you said you do something with the vertex values before sending to OpenGLide, what is it?

This is two difference things that got mixed up in my explanation.

The first thing. The problem with vertex snapping for RB, is that RB uses guDrawTriangleWithClip, and hence feels free to draw enormous triangles, only little bits of which cover the screen. OpenGlide doesn't do the clip processing, it just passes the triangle to OpenGL, which handles it. The trouble with vertex snapping is that it has a nasty effect on very large values, and the big triangles get their coordinates corrupted. This gave flashes of green and missing ground patches in RB.

The other thing I mentioned was that if RB had been a DOS game then it wouldn't work via Glidos, because Glidos also does something that damages large valued coordinates. It does this for the sake of Redguard. Redguard also produces enormous coordinates (up in the millions), but unlike RB, it doesn't really mean it. To get Redguard to work, I have to take the values of coordinates mod 2048, in effect ignoring bits above the eleventh in the integer representation of the values.

Perhaps there is some connection between your vertex snapping and my applying mod 2048. Sorry if this still isn't very clear. I'll have another go at it, if you like.

Reply 15 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t
GoldFinger wrote:

Ok,
First thing to do is to implement Clipping properly.

That's one way, but it seems a pity not to let OpenGL handle it if it can so easily. The fact that RB works shows that OpenGL really doesn't mind doing the clipping.

What about if we apply vertex snapping only to grDrawTriangle and not to guDrawTriangleWithClip. Presumably, Unreal doesn't call guDrawTriangleWithClip.

Not sure that makes sense because I don't yet understand what vertex clipping is. Can you explain it?

Doing our own clipping could be expensive because a triangle can easily clip to become a hexigon. Perhaps that wouldn't happen very often.

Reply 16 of 17, by GoldFinger

User metadata
Rank Member
Rank
Member

Well, doing the clipping does not necessary mean doing all the calculations, but maybe implementing it right, OpenGL can handle it, I just need to do it right.
Vertex snapping as far as I remember is to remove some precision and to snap vertex together, I think only a handful of games use that, but... 😀
I will do some more research because I did not remember, I did that in 1999 or 2000... :p

Reply 17 of 17, by Glidos

User metadata
Rank l33t
Rank
l33t
GoldFinger wrote:

Vertex snapping as far as I remember is to remove some precision and to snap vertex together, I think only a handful of games use that, but... 😀

Ah it is what I thought. I think you are supposed to add a very big number and then take it away again. Being floating point, low bits of the original value get shifted off the end by the addition of the big number.

But as you say, better to do some research and make sure it's right.