I guess this is the right time to get to some in-depth look at Mesa OpenGL.

As I see, the Mesa is pretty powerfull, but it has some major questions regarding the way in wich it is built.

First, look at QuakeGL. The MesaGL is showing some 256-color like textures and effects in some places, and the textures for the life meeter, ammo and text in general are having some strange "interlacing-like" effect on 640x480 resolutions.

Mesa is using 3DNow!/MMX, still I see no increase in performance on QuakeGL on 640x480x16. I expected to see at least a 2fps increase.

DDraw is among the libraries used for Mesa, if configured when building the project, what release of ddraw is Mesa basing upon? The one on Dx7,8 or 9 SDK?
With a normal build, there is an error appeareing when initializing OpenGL. What kind of performance increase is to be expected?

There are also some warnings that state that conversions between variable types are used. This is not a good sign.
----------------------------------------------------------------------
I invite anyone that participated to Mesa design to offer more informations on Mesa 60 in here.
----------------------------------------------------------------------

I am replying this, taking the paragraphs in a specific order! Boy, the first one is so moronic/idiotic... I can't help myself!  :o


Quote:

DDraw is among the libraries used for Mesa, if configured when building the project, what release of ddraw is Mesa basing upon? The one on Dx7,8 or 9 SDK? With a normal build, there is an error appeareing when initializing OpenGL. What kind of performance increase is to be expected?

AFAIK, Mesa does not use _ANY_ DDraw whatsoever. Geez, that's the whole point of a OpenGL implementation. There is only one lib required (gdi32), and that's for interfacing with the windoze crap.


Quote:

As I see, the Mesa is pretty powerfull, but it has some major questions regarding the way in wich it is built.

I guess you know a lot about the way it is built, just looking above! And, besides, what do you care? Man, this is a paradox: Mesa is opensource. Yes only few people can make use of that openness.


Quote:

There are also some warnings that state that conversions between variable types are used. This is not a good sign.

I guess you tried to compile it! Or saw the warning log on TV? Judging from what's above, I doubt it...


Quote:

First, look at QuakeGL. The MesaGL is showing some 256-color like textures and effects in some places, and the textures for the life meeter, ammo and text in general are having some strange "interlacing-like" effect on 640x480 resolutions.

Yep, that might be a bug! I haven't focused on GLQuake so far. Except I managed to compile old DOSQuake1 in OpenGL mode with DOS Glide3x.


Quote:

Mesa is using 3DNow!/MMX, still I see no increase in performance on QuakeGL on 640x480x16. I expected to see at least a 2fps increase.

Life sucks sometimes, eh?


Quote:

---------------------------------------------------------------------- I invite anyone that participated to Mesa design to offer more informations on Mesa 60 in here. ----------------------------------------------------------------------

Oops! That's another whole story! There is a big difference between 0.51 (everything I released so far) and 0.60 (the next 6.0-powered version). Mesa 6.0 features a new - cleaner - vertex code. It is around 10% slower than 5.1, but fixes a lot of bugs. There are a few ways to optimize it, mainly codegen! But without Keith's help, I won't stand a chance. I just hope I will be able to come with something in a few days / weeks.

Someone missed the point. It was the MesaGL used to create a software renderer OpenGL.

There is a mentioning inside the package that states that DDraw Acceleration could be used... And when using a Glide app with and without DDraw acceleration, there is a BIG performance difference. The same shall be with Mesa.

Next, in every app I know, if it used 3DNow!, you get 5fps more if having hardware acceleration available, so, given the complex math computed, 2fps more in software renderer should happend in all the OpenGL apps, as oposed to the old SGI-OpenGL.

Why that? As an example of speed boost, look at MS-OpenGL, and SGI. In every app, the SGI is faster by a serious margin, making beyond 5fps increases in 320x200 resolutions. So, it is possible.

There are lots of warnings regarding the variable types been switched, and to amaze you, it was on a real monitor when compiling, and not on a TV.

Serious problems still exists with the OpenGL compliance for Mesa, as of QuakeGL. The Tenebrae Quake mod, is working good until: "41 Meg of data.... vertices...". So let's face it: Mesa has lots of problems, but it is admirable that is the first ever attempt at implementing OpenGL features after SGI.

For sure, MesaGL was many, many ours of work, and it is a fantastic result. But problems here and there can get to 3dfx OpenGL support, and this is worse, because tracking down the problem on specific hardware is much more time consuming, than on a generic platform as the OpenGL software renderer is at this point.

wrote on 26.01.04 at 11:40:23:

Someone missed the point. It was the MesaGL used to create a software renderer OpenGL.

Then it's not MesaFX! And it's definitely not MesaGL! *FX is a pseudo-notation for Mesa with 3dfx driver. And *GL is a notation misunderstood by people! Mesa should suffice in your case. I would have understand better! It is admirable that someone tries to evaluate the foundation of Mesa, core-level bugs! But then again, it's Mesa we're talking about, not a specific driver.


Quote:

There is a mentioning inside the package that states that DDraw Acceleration could be used... And when using a Glide app with and without DDraw acceleration, there is a BIG performance difference. The same shall be with Mesa.

Mmmm! I doubt this states true for Glide! Even though I worked on HW issues inside Glide3x at SourceForge, I "missed" the win32-specific crap.


Quote:

Next, in every app I know, if it used 3DNow!, you get 5fps more if having hardware acceleration available, so, given the complex math computed, 2fps more in software renderer should happend in all the OpenGL apps, as oposed to the old SGI-OpenGL.

Then perhaps Mesa without 3DNow is even slower. That's life sucks. Have you done a comparative test?


Quote:

Why that? As an example of speed boost, look at MS-OpenGL, and SGI. In every app, the SGI is faster by a serious margin, making beyond 5fps increases in 320x200 resolutions. So, it is possible.

Yep! True! Read above!


Quote:

There are lots of warnings regarding the variable types been switched, and to amaze you, it was on a real monitor when compiling, and not on a TV.

I am amzed, indeed!  :P Let me guess: you compiled with M$VC eh? Not that gcc is MUCH cleaner... anyhow, the last thing you need to worry, is the typecasting right now...


Quote:

Serious problems still exists with the OpenGL compliance for Mesa, as of QuakeGL. The Tenebrae Quake mod, is working good until: "41 Meg of data.... vertices...". So let's face it: Mesa has lots of problems, but it is admirable that is the first ever attempt at implementing OpenGL features after SGI.

Yeah, let's face it! 3dfx concentrated too much on Quake stuff. That's why their DLL fails on many new games. Yeah, Mesa has bugs, I admit! Feel free to contribute on Mesa mailing lists. In time, if you get really skilled and earn Mesa gods' respect, you may become a real developer with CVS access -- just like I did!


Quote:

For sure, MesaGL was many, many ours of work, and it is a fantastic result. But problems here and there can get to 3dfx OpenGL support, and this is worse, because tracking down the problem on specific hardware is much more time consuming, than on a generic platform as the OpenGL software renderer is at this point.

Yes, tis true. But, you see, to get to a specific bug, you (very often) need a complex application. It is a killer to run such a program using software renderer. Believe me, I tried it with GLExcess! Yes, I fixed a vertex generation bug, but i had to wait 5 minutes to get to buggy scene using SW renderer (the DOS SW renderer, actually -- which is actually faster than the current Win32 SW renderer).

A wonderfull thing to be implemented would be an app to enable disable specific functions and to set up a forced run (like the 3D Analyze succeds in many OpenGL and D3d apps), with, for a good speed example: 320x200x32 with bilinear filter 32bit Z-buffer, 256x256 size textures. Perhaps an "Onkey" event would make possible to change by pressing a key the res from 320 to 800. This will really get a fast understanding of what is happening, when you need it the most (as we know that high res and bilinear filtering are killing the CPU's performance mostly).

wrote on 26.01.04 at 12:14:03:

A wonderfull thing to be implemented would be an app to enable disable specific functions and to set up a forced run (like the 3D Analyze succeds in many OpenGL and D3d apps)

Well, you'll have to address other people for that  :(
Working in Mesa core, Mesa drivers, Glide core and such is pretty exhausting. And I had enough of emulators, since I wrote my own DOS extender, a few years ago.  :P

wrote on 26.01.04 at 11:40:23:

As an example of speed boost, look at MS-OpenGL, and SGI. In every app, the SGI is faster by a serious margin, making beyond 5fps increases in 320x200 resolutions. So, it is possible.

you really think you get the same speed boost in acceptable resolutions...let's say at least 800x600? i wouldn't say so..anyway, like daniel said, you should test mesafx with and without 3dnow! app, otherwise your comparison with ms/sgi-gl is useless, you know.


wrote on 26.01.04 at 12:00:00:

In time, if you get really skilled and earn Mesa gods' respect, you may become a real developer with CVS access -- just like I did!

like that one  ;D

wrote on 26.01.04 at 14:31:12:

you really think you get the same speed boost in acceptable resolutions...let's say at least 800x600? i wouldn't say so..anyway, like daniel said, you should test mesafx with and without 3dnow! app, otherwise your comparison with ms/sgi-gl is useless, you know. like that one  ;D

800x600 resoulutions wouldn't be more concludent when you are testing for speed than 300x200. In low resolutions, everything counts, and you see clearly a difference when either geometry/texturing is working faster. In high resolutions, texturing is costing more and more, and geometry impact is less and less, and there the difference is already noted at low resolutions. In fact, in high resolutions there is little to be done, elseway than a sort of generic hardware acceleration or high CPU processing power, translated into lots of operations/second. In windows, in fact you have to keep in mind the existence of that 100 ms timeslice, so actual processing power is waaaay lower than the desired, and theoretic ones. And that 100 ms timeslice counts a lot when stressing the system with lots of calculations, especially when going up in resolution, as in a Software GL.

wrote on 28.01.04 at 10:35:10:

In low resolutions, everything counts, and you see clearly a difference when either geometry/texturing is working faster.  [...] In windows, in fact you have to keep in mind the existence of that 100 ms timeslice, so actual processing power is waaaay lower than the desired, and theoretic ones.

do you know anybody who likes playing games in 320x200? therefore (and because of M$) we have those oversized cpu & gpu specs, you know that.

Okay, I'm no driver developer, nor have I really benchmarked MesaFX, but I will say that it's truly a work of art, Daniel is a blessing to the 3dfx community. Andei, have you tried checking out MesaFX vs. 3dfx/WickedGL OpenGL releases on games like Neverwinter Nights, or Call of Duty? If you don't already know that MesaFX is the only way (other then the exception of the horrid M$ drivers for NWN) to run these games, then you have no right to even think of reviewing this. So, Quake at 640*480 doesn't run any better. So what?? 3dfx worked their a**es off to get their cards running balls-out in Quake-based apps. This is why miracles like Daniel have to come along and build up compatability for newer games. I think that although your review might have some good points (actually, make that 1, as I see that Quake is the only real thing you looked at, and the fact that it runs about the same speed), you really ought to be getting into the compatability that MesaFX gives as well as speed. It is well-known that MesaFX is slower or worse in quality at times. It's not like you have to completely reformat your hard drive in order to use the 3dfx or WickedGL options, it's a relatively easy switch, when necessary.

To amp_man:

First of all, it is not just Quake1. The tests on OpenGL Extensions Viewer give the same proportions.

I am talking about Mesa, the foundation for the Software rasterizer, and for the 3dfx OpenGL. I am not talking about an implementation, such as the on on 3dfx OpenGL.

What you don't understand, is that in low resolution, everyhing that is code counts very much, and it is mostly visible. A difference of 0.2 frames in 1024 is telling you nothing when the average is 2fps. A difference of 5 fps when running at an average 50 makes more sense for testing, comparison, and tracking of bottlenecks. You have a lot to learn, and you shouldn't talk about the 320 resolution like that, when you don't have some neccessary basic knowledge on 3D graphics.

I've never said that Mesa isn't a great achievement, but I would say to be more realistic when judging things.


To micha:

Depends very much on the app itself, if is worth to see it in 320 or in 1024. You don't seem to know also that 16 bit can look just as well as 32 bit (unnoticeable difference), or that even a PAL8 texturing format is enough to bring the Memory usage waaaay down, and increase the texturing speed by tons. And the visual difference is not impaired more than when using DXT. In fact it is even better for 256x256 texture sizes.

Concluding, 320 resolutions is very handy in many cases. I've seen Quake in 320 and it is very playable. In fact, if you dont own a OpenGL accelerated card, and you are playing using a software rasterizer this is the only thing to do, in order to play at around 20fps.

And then again, do you need high res in order to see some visible glitches, and Z-buffer, or texturing problems? To some extent, the answer is clearly: NO.

wrote on 30.01.04 at 10:58:14:

To amp_man: First of all, it is not just Quake1. The tests on OpenGL Extensions Viewer give the same proportions.

What's your problem, man? What same proportions? Oh, sure I lied (minmax blending can't be done with Voodoo); so sue me!


Quote:

I am talking about Mesa, the foundation for the Software rasterizer, and for the 3dfx OpenGL. I am not talking about an implementation, such as the on on 3dfx OpenGL.

Darm, I still have that blur look!  ::)
If you're talking about core, software renderers meet the full spec (yet they might be buggy). So there are no "same proportions". If you're talking about the 3dfx driver, then your logic need a lot of help, 'coz you lost me.


Quote:

What you don't understand, is that in low resolution, everyhing that is code counts very much, and it is mostly visible. A difference of 0.2 frames in 1024 is telling you nothing when the average is 2fps. A difference of 5 fps when running at an average 50 makes more sense for testing, comparison, and tracking of bottlenecks. You have a lot to learn, and you shouldn't talk about the 320 resolution like that, when you don't have some neccessary basic knowledge on 3D graphics.

What you don't understand, is that you can't evaluate 3DNow using different engines. The only way is to compile Mesa WITH and WITHOUT 3DNow. I could almost bet you don't know how to compile both ways; that's why you are avoiding the issue.


Quote:

I've never said that Mesa isn't a great achievement, but I would say to be more realistic when judging things.

Well, as I said, everyone's invited. Brian is really a nice guy!


Quote:

Depends very much on the app itself, if is worth to see it in 320 or in 1024. You don't seem to know also that 16 bit can look just as well as 32 bit (unnoticeable difference), or that even a PAL8 texturing format is enough to bring the Memory usage waaaay down, and increase the texturing speed by tons. And the visual difference is not impaired more than when using DXT. In fact it is even better for 256x256 texture sizes Concluding, 320 resolutions is very handy in many cases. I've seen Quake in 320 and it is very playable. In fact, if you dont own a OpenGL accelerated card, and you are playing using a software rasterizer this is the only thing to do, in order to play at around 20fps.

Why, my boy, you think you're the hotshot only because you played Quake1 in SW? Heh...

wrote on 30.01.04 at 10:58:14:

To amp_man: I am talking about Mesa, the foundation for the Software rasterizer, and for the 3dfx OpenGL. I am not talking about an implementation, such as the on on 3dfx OpenGL.

Please, be clearer about your terms, as Daniel already stated. It seems like you are talking about Mesa itself, and God-knows-what version of that you would be checking. MesaFX is different, and is what you should probably be looking at, this is the small files named .51x that Daniel has been releasing.


Quote:

What you don't understand, is that in low resolution, everyhing that is code counts very much, and it is mostly visible. A difference of 0.2 frames in 1024 is telling you nothing when the average is 2fps. A difference of 5 fps when running at an average 50 makes more sense for testing, comparison, and tracking of bottlenecks. You have a lot to learn, and you shouldn't talk about the 320 resolution like that, when you don't have some neccessary basic knowledge on 3D graphics.

I will badmouth 320 resolution all I like, 320 looks like SH!T! Nobody plays jack in 320 res, so why should the performance in it matter? If you still use 320 and have anything better than a 486SX 33MHz, you have some problems. How many FPS do you get at 800*600 or higher, anyways? I seriously doubt it's anything near two, if you get 50 at 320.  What are your specs, 50FPS in QuakeGL at 320 res is pretty damn crappy.  


Quote:

First of all, it is not just Quake1. The tests on OpenGL Extensions Viewer give the same proportions.

Wait, so to defend your review, you tell us that you didn't just check a game, you checked a game and the OpenGL viewer  ::) Any bloke can do that, and as has already been stated, you probably will not be able to get better performance than 3dfx did on Quake-based games. Life sux. Check out other games. The wonderful part of Mesa: if it doesn't run better, you don't have to use it.

ANYWAYS, my point really is that speed should not be nearly as much of a factor in this review as COMPATABILITY should be.


Quote:

I've never said that Mesa isn't a great achievement, but I would say to be more realistic when judging things.

Finally, Mesa is a great achievement, but Daniel is not God, he can only do just so much. You be more realistic, quit dreaming so much.

EDIT: Daniel, I guess you beat me  :P

wrote on 30.01.04 at 13:34:34:

Finally, Mesa is a great achievement, but Daniel is not God, he can only do just so much. You be more realistic, quit dreaming so much. EDIT: Daniel, I guess you beat me  :P

Nah... I'll just cast some lightning unto you  ;D

hey andrei, you really don't have a card supporting opengl? sad..well, i bet you have one, so nobody (including you) should play quake1 in 320x200! good luck @ 640x480!   ;D

>>adding<<
3d apis make no sense at low resolutions.

Hm i actually have an old ATi Rage Mobility X-something lying in my drawr.. i don't think it has opengl nor d3d..
so 320*240 would make sense on it ^_^

wrote on 01.02.04 at 01:42:20:

Hm i actually have an old ATi Rage Mobility X-something lying in my drawr.. i don't think it has opengl nor d3d.. so 320*240 would make sense on it ^_^

This is from the original Rage Mobility:

Quote:

-Comprehensive support for DirectX (including DX6 texture compression) and Open GL API's

I'm thinking that 320 res would make more sense on something like a S3 Trio or an old Trident or something, lol

wrote on 26.01.04 at 10:07:37:

First, look at QuakeGL. The MesaGL is showing some 256-color like textures and effects in some places, and the textures for the life meeter, ammo and text in general are having some strange "interlacing-like" effect on 640x480 resolutions.

er, you know.. quake HAS 256 color textures :D

wrote on 30.01.04 at 13:29:16:

What's your problem, man? What same proportions? Oh, sure I lied (minmax blending can't be done with Voodoo); so sue me! Darm, I still have that blur look!  ::) If you're talking about core, software renderers meet the full spec (yet they might be buggy). So there are no "same proportions". If you're talking about the 3dfx driver, then your logic need a lot of help, 'coz you lost me. What you don't understand, is that you can't evaluate 3DNow using different engines. The only way is to compile Mesa WITH and WITHOUT 3DNow. I could almost bet you don't know how to compile both ways; that's why you are avoiding the issue. Well, as I said, everyone's invited. Brian is really a nice guy! Why, my boy, you think you're the hotshot only because you played Quake1 in SW? Heh...

Mesa is the base for the functions not supported in hardware, directly by the Voodoo, in OpenGL. Right? If so, then some of the functions and procedures might behave similar to some extent. So there is sense.

You would bet wrong.  I know very well how to compile by using, or not using 3DNow! instructions Mesa sources, but there is a great feeling of a lost time, since the results won't be those expected. Again, I am not avoiding it, I feel the lack of use of this action. In the past I compiled software using/not using 3DNow! instruction and the result varied, as the actual code, the one that is carried on by the FPU or ALU carried the big hit, sometimes it was 1% faster, sometimes 1% slower. It just depends primarily on the rest of the code.

However, I'll do the compilation of Mesa without 3DNow! instruction...

Every nice test is done on the following base for HW or SW OpenGL: Quake1+2+3, MDK2, GLClock, GLExcess...
But throught the testing experience, the results are quite scalar, and proportional between all these, at least for SW OpenGL.

By the way, GLClock is showing no coloring, no textures, no effects at all, just some black filled circles. FSAA is not computed (on SGI it was working, on MS it was working), DepthOfFieldBlur is. So it is very true the fact that if when running QuakeGl (which is the base for testing) you encounter problems, it is very likely that there are a lot more still to be discovered. QuakeGL proves the near 80% compatibility of the OpenGL base rasterizer with OpenGL 1.0 (3dfx minigl was not 100% OpenGL).

As i've said before, I've tested many OpenGL apps and games in SW, including 2001 released OpenGL games, as it is worth for performance analysis.

wrote on 01.02.04 at 13:23:23:

er, you know.. quake HAS 256 color textures :D

256 collors effects on the screen! This is what is strange, as QuakeGl computes effects (glares,flares) in 24bit color internally.

wrote on 30.01.04 at 13:34:34:

I will badmouth 320 resolution all I like, 320 looks like SH!T! Nobody plays jack in 320 res, so why should the performance in it matter? If you still use 320 and have anything better than a 486SX 33MHz, you have some problems. How many FPS do you get at 800*600 or higher, anyways? I seriously doubt it's anything near two, if you get 50 at 320.  What are your specs, 50FPS in QuakeGL at 320 res is pretty damn crappy.   ANYWAYS, my point really is that speed should not be nearly as much of a factor in this review as COMPATABILITY should be.

For the fun of it, I've seen some ATI technology demo's in 320x200 with 6xFSAA. It is not so bad actually. Again 320 res has sense if you can achieve 50+ fps in there.

High res were really invented as there was a greater need for less jagged lines, and more space for colors, or for design (CAD 80's era). But in the later 90's, high res (1280x960 and more)were only forced into the markets because of the larger monitors where low res are not having the same dot dimensions as intended, and become less comfortable to the eye. For you, it is 50fps+ in QuakeGL on SW render on a 600Mhz CPU. Happy?

Compatibility was the thing I mostly attacked.

wrote on 02.02.04 at 10:27:13:

For the fun of it, I've seen some ATI technology demo's in 320x200 with 6xFSAA. It is not so bad actually. Again 320 res has sense if you can achieve 50+ fps in there. High res were really invented as there was a greater need for less jagged lines, and more space for colors, or for design (CAD 80's era). But in the later 90's, high res (1280x960 and more)were only forced into the markets because of the larger monitors where low res are not having the same dot dimensions as intended, and become less comfortable to the eye. For you, it is 50fps+ in QuakeGL on SW render on a 600Mhz CPU. Happy? Compatibility was the thing I mostly attacked.

why using 320x200 with 6xfsaa when i can switch to 800x600 or higher getting an equal or even better picture on my screen? there wouldn't be any compatibility problems, you know that, and i can achieve also 50+fps at those res. btw, games just look sharper, better and more "life-like" @ high resolutions. that's the aim of game graphics, isn't it? last point: larger monitors are better for the eyes, aren't they?
you see, everything you critizised has a simple cause, think it over!  ;)

The only thing you get with higher res (to some extent) gets you near to the CGI concept in computer graphics.

Larger monitors can confuse even more, as you can't catch with the eye all the screen, just parts of it. Look at the driver situation in a car. He sees in 1/100 of a sec one part of the road, or the lane next to his right or left. He gets more and more confused as the traffic becomes heavy. Similarly when on a big screen you are playing a game. You must stay at quite a distance to eliminate this effect. This is not so simple if you have a monitor, and you are keeping as usual at a 30-50cm in front of you.

I've seen games in low and high res. Most of them however are not more of a fun when in high res. It's the rest of the game that can make the res a plus in quality. Think textures: if they are jerky, or less polished, what difference does it makes? Most of the time, developers create a tree by using CGI techniques. This way you get nothing when on high res. The only real benefit would be if nearly everything was photographed from real life and then digitize it. But this requires a very big time to be available, and photographing lots of trees, taking 5 photo's from outside of a house costs too much to be economic. So there are very few cases in which a res increase would be 100% and trully obligatory.

CGI computer techniques stands for: Computer Generated Images. You basically draw something similar to a real thing, by equations. Then you translate the image created into a digital format. Finish.

wrote on 02.02.04 at 10:15:47:

Mesa is the base for the functions not supported in hardware, directly by the Voodoo, in OpenGL. Right?

Mesa is the base for everything. Even HW functions need vertices to work on.


Quote:

You would bet wrong.  I know very well how to compile by using, or not using 3DNow! instructions Mesa sources, but there is a great feeling of a lost time, since the results won't be those expected.

No sh!t, eh? My feeling grows stronger. If I "could almost bet" a few days ago, now I'm just one step to "taking a bet". Stop babbling and compile it already! If you take the time of all your posts here, in this thread, divide it by 3, then you still supercede the time taken to compile Mesa again.

Oh, andf FYI, I just committed a bugfix for GL_NEAREST texture sampler today. You might want to check again.

I still can't see your posts on Mesa-dev mailing list. We are looking forward to them; and I am sure it contains fixes / suggestions, also.

wrote on 02.02.04 at 10:27:13:

For the fun of it, I've seen some ATI technology demo's in 320x200 with 6xFSAA. It is not so bad actually. Again 320 res has sense if you can achieve 50+ fps in there.

Well, I'd like to kill that theory right off the bat. Running in Unreal Tournament on an Athlon XP 1800+/Radeon 9500 system, with everything at stock speeds, here are a few of my findings:

First off, frame rates:
320x240, NoAA: 146.2
320x240, 6x AA: 129.6
1024x768, NoAA: 130.9
1024x768, 6x AA: 120.5

I had planned on posting pics to show the image quality, but I thought that falconfly supported image uploads, he doesn't. Basically, even with the 6x AA, 1024x768 was much better than 320x240, and faster too. 320 has absolutely no sense what so ever.


Quote:

High res were really invented as there was a greater need for less jagged lines, and more space for colors, or for design (CAD 80's era). But in the later 90's, high res (1280x960 and more)were only forced into the markets because of the larger monitors where low res are not having the same dot dimensions as intended, and become less comfortable to the eye. For you, it is 50fps+ in QuakeGL on SW render on a 600Mhz CPU. Happy?

No actually I'm not. Higher res's, first off, weren't invented, they simply were be put into the hands of the average consumer in 3D applications. Simulation boxes were doing 1024x768 res long before the consumer got their hands on it, the technology simply wasn't fast enough for the hardware to reliably support it, so support wasn't provided or sought after. But even as far back as the old 1988 Trident ISA card I used to have supported 1024x768 in 2D. Also, where do you get the 600MHz CPU, is that yours? And if you're only getting 50FPS on that, with a game designed to run on a 486 50MHz, I think you need to check that vsync is off.


Quote:

Larger monitors can confuse even more, as you can't catch with the eye all the screen, just parts of it. Look at the driver situation in a car. He sees in 1/100 of a sec one part of the road, or the lane next to his right or left. He gets more and more confused as the traffic becomes heavy. Similarly when on a big screen you are playing a game. You must stay at quite a distance to eliminate this effect. This is not so simple if you have a monitor, and you are keeping as usual at a 30-50cm in front of you.

Yeah, great analogy ::). The thing that you fail to mention about that is that, like a car, the clearer an approaching image is, the easier it is to make out. If you see a sign at 320x240 resolution, you're going to have to squint like hell to make it out, because you will either have a really tiny screen or a really boxy image (unless you've got a V5 6k with 8x FSAA ;D), or some of both, whereas with higher resolutions, it can be destinguished easier, even on larger screens. I don't know how much sense that makes, but it makes about as much sense as your analogy does. Also, higher/lower resolutions are much more likely to hurt your eyes, other than doing a bunch of squinting, then low refresh rates are.


Quote:

I've seen games in low and high res. Most of them however are not more of a fun when in high res. It's the rest of the game that can make the res a plus in quality. Think textures: if they are jerky, or less polished, what difference does it makes?

I remeber games in low res too. Wing Commander used to be the bomb, at 320 res on my good old 486SX 33MHz, with one of those 3x multiplier things on it, so it worked like a 100MHz. The point is, hardware has evolved, or at least been raised in clock speed to the point where people think that it's evolved. You can't expect to run brand new games at high res and max details with a 600MHz P3?.

More to come...

...And here's the rest, for now at least


Quote:

Most of the time, developers create a tree by using CGI techniques. This way you get nothing when on high res.

Right. Lets go back to Wing Commander for a sec. The textures were designed to look good at 320x240 resolution. Anything higher than that would simply make the ailsing less obvious, but the textures would still be those same 320 textures, just smaller and more of them. On the other hand, something like Unreal Tournament's textures have been created for much higher resolutions, say 1024 (just becuase I like it). At 320, those 1024 textures are simply lowered in quality, and the screen shows less of the scene because the images are larger. But at 1024, you get much better scenery, because the engine can actually adjust for that, to bring more lifelike scenery into play, and make the whole effect worth it. And if that doesn't run well enough, you optimize driver settings, lower details, and as a last resort, lower the resolution. Did you notice the difference above when I went from 320 to 1024 res without AA? 16 FPS. That's barely a 10% loss in performance, between those two extremes. Well, this is drifting away from my original point, but then again, I'm still trying to figure out what yours was...


Quote:

The only real benefit would be if nearly everything was photographed from real life and then digitize it. But this requires a very big time to be available, and photographing lots of trees, taking 5 photo's from outside of a house costs too much to be economic. So there are very few cases in which a res increase would be 100% and trully obligatory.

Hmm, photographs...you don't honestly think that photographs are 3D do you? Oh, you want to digitalize them into 3D, is that what you're saying ??? Not only would that not be cost effective, but it would also be extremely stupid. After all that digitalization, you might have quality comparable to a decent 3D game, and then try running it, or even storing it. But how does that relate to res?

And then to finish:

Quote:

Compatibility was the thing I mostly attacked.

GLQuake tests compatability? Bull SH!T!! You need to get some common sense. GLQuake runs on nearly any PC with some sort of 3D accelerator. It only uses a small portion of the OpenGL, and being created in 1996, it uses a very early revision of OpenGL. So how exactly does that test compatability? You ran a measly test in insane (although this word normally implies the opposite extreme) resolutions, and expect us to even think of that as a valid review of all the capabilities of MesaFX? I don't think I even need to say any more >:(

I simply have GOT to get my other box back up and running so I can see what MesaFX can really do, this review doesn't tell anyone anything.

Andei, give it up. You are fighting with a master driver developer whose knowledge far surpases your own, and a forum of people dedicated to preserving 3dfx's legend. You can't come in here promoting a bunch of trash drivers (I have tried them, by the way, and they suck on NFS 3 and 5 :P), then start trash talking about the greatest thing to hit 3dfx owners in a long time. If you don't like MesaFX, then don't use it. But don't come here trying to talk like GLQuake at 320 res is an accurate benchmark to compare MesaFX to something that's been optimized like hell to run it, it's just stupid. You want to post some real benchmarks, like Half Life or UT 2003, in decent resolutions, 800*600 at the least, then be my guest, these would be fair comparisons, but don't bother going any further with this GLQuake crap, it's not worth anyone's time.

And *ugh* I shall add :

I operate Monitors from anywhere to 15" upto 21", and your "CGI theory" is honestly the most complete, utter nonsense I've heard in my life...

(anyone who sits 30-50cm from a 21 inch Monitor (!) needs professional help ASAP, but that's certainly not the Monitor's fault)

Somtimes, Boui, I think you're a Troll.

You write in great detail about things, that, after a short analysis, one can only assess you don't know alot (upto effectively nothing) about.
Yet, you still continue to elaborate and exhibit the old, known ignorance you seem so blessed with ::)

And looking at this entire Thread you labeled "Tech Review on MesaFX", I can only say :
"Reviews" should be limited to people who actually understand the technology :P

[quote]I guess this is the right time to get to some in-depth look at Mesa OpenGL. [/qoute]
Nothing wrong with that, but you are simply unable to create something like that. Period.

You go play the latest Games in 320x200 if you wish, but please : spare us of your unknowledgable talk !
Don't expect 'tech babysitters' to correct all your basic errors in realtime (which would be required), and the only real Problem I have with you writing all that nonsense, is that inexperienced Users might be tricked into believing you would actually know about what you're writing.

I'd hate such nonsense to spread from this Forum as a Source, because it pulls down the quality of it by a fair amount. Now that would be unacceptable in my quality terms. ::)

About godd@mn time somebody put Boiu Andrei in his place for all of this ferkin nonsense he's been posting all over the 3Dfx forum! ::)

I was gonna' give him a swift kick ages ago, but couldn't be bothered to waste my time! :P

NOW he's been given SEVERAL! ;D

Down, sit, STAY! >:(

Nuff said! 8)

i fully agree with falconfly & amp_man, but there's one thing left:


Quote:

The only real benefit would be if nearly everything was photographed from real life and then digitize it. But this requires a very big time to be available, and photographing lots of trees, taking 5 photo's from outside of a house costs too much to be economic.

actually this is made! e.g. the developers of stalker took photos of tschernobyl and tried to reproduce the settings very detailed in their game. (great dx9 game, expected spring/summer/fall 2004) anyway, this might not be the way andrei mentioned ('cause that's just stupid), but it's the only way so far to reproduce realism economically.
allright, let's stop this senseless discussion here: mesa rules, quake1 sucks  8)

wrote on 03.02.04 at 12:18:58:

allright, let's stop this senseless discussion here: mesa rules, quake1 sucks  8)

Well, not quite! As Mesa rulez, I serendipitously discovered that Quake1 rulez, too!
I compiled Quake1 (using DJGPP compiler) in OpenGL mode; as an OpenGL driver I used Mesa software. Worked okay. Then I tried MesaFX for DJGPP (same codebase as the released DLLs) on top of Glide3x DJGPP. Played the entire first episode without glitches.

I haven't bothered with Quake1 for windoze, because people did that over time. Porting GLQuake sources from QIP was done in 15 minutes using a Linux OpenGL template.

And I remember the software Quake1 (the original) was built using DJGPP compiler.

Anyhow, I still can't see how is Mesa incompatible with Quake series... as BA tried to prove.

I am sorry the discussion derailed already...

@BA: you know, democracy works two ways:
-> you are free to speak whatever you feel.
<- the minority obeys the majority.

I shall quote an old saying from memory: "more dangerous than stupidity is fake-knowledge"

I tried to put you in your place back in that Banshee thread. It seems to me that every godd@mn member of this forum has to do it before you calm down.
And if I would ever change my site's name, it will be "BeyondReality", Because I deliver real stuff, while you deliver zilch!

..er, maybe...quake1 rules...not quiet sure..yet.....maybe it ruled once...ok, i played it once! but not tried with mesa which -as we all know- rules, anyway.
;)

wrote on 03.02.04 at 13:48:35:

..er, maybe...quake1 rules...not quiet sure..yet.....maybe it ruled once...ok, i played it once! but not tried with mesa

Want the EXE? ;D I am not talking bullsh!t!  8)

Quote:

which -as we all know- rules, anyway. ;)

Thx!  ;)

quake 1's sourcecode was given out by ID a -loooong- time ago.. anyone can take it and compile their own 'ub3r optimized Q1' :)

or better yet, change it's name+logos and make it look as if you created that game ^_^

wrote on 03.02.04 at 16:48:13:

quake 1's sourcecode was given out by ID a -loooong- time ago.. anyone can take it and compile their own 'ub3r optimized Q1' :)

I haven't tweaked Q1. I used the QIP sources. What I did is, only provide the GL interface.

wrote on 03.02.04 at 16:48:13:

or better yet, change it's name+logos and make it look as if you created that game ^_^

Why did you have to say that, now we all know what BeyondDream's next project is  ::)

Nah, that's something I don't think he would do...

For these kinds of things, we know better candidates ;)
(although I figure they'd be utterly unable to even compile a single line of code *g* )

I don't get it why everyone said I was only focusing on QuakeGL?! I said that there were problems on OpenGL extensions viewer (at least for another compilation of Mesa than the WinBinaries archive), GLClock (with WinBinaries), Quake TNBRAE (based on QuakeGL but uses OpenGL 1.4 extensions).

Secondly: OK. I maked a VERY BIG mistake. The title of the thread should've been: "Mesa Software Rasterizer". Everything I said was about the Mesa SW, not MesaFX. I can be blamed a lot for this one... I have changed the name for my message to be less confusing, but it might be too late. I was thinking at MesaFX probably by mistake, and created a thread with this wrong name.

Third: I don't try to make everyone believe more than it is. Yet I believe that you really don't understand what I am talking about. For example, the "CGI theory" has a lot of sense, since you either paint a tree texture by using your hand, or pen when drawing, and then save to a bitmap, or photo a real one. In most of the cases, the later option is much more realistic, but it could look less well when doing Mip-maps. Basically it was all about vector drawing as oposed to raster drawing.

Fourth: I don't sustain 320x200 games, I don't like that much this resolution, I am trying to point at only one thing: if you have no hardware acceleration, or very little one, going on a lower resolution might be the best thing to do, as it lowers the fillrate need (that kills the CPU in SW). Again, FSAA when using low resolutions is more of a demonstration that it can be done, and it looks resonably well, given the fact that such a low res is used. Then again, the low res gets you a clear view when analyzing various AA algorithms and methods (rotated grid for example). Most of the the little AA differences are not spotted so easily and so fast when in high res.

Fifth:


Quote:

I tried to put you in your place back in that Banshee thread. It seems to me that every godd@mn member of this forum has to do it before you calm down. And if I would ever change my site's name, it will be "BeyondReality", Because I deliver real stuff, while you deliver zilch!

I don't accept this idea, as you know nothing of what is happening behind the scene. This time I can say to you: be silent if you don't know anything about what you are saying. And again, I am not using publicity before a thing is fully ready as you do with your drivers, Dborca...


Finally:
I accept constructive suggestions, and agree when a thing is wrong in what I am saying. I don't do and noone else does perfect things. I don't say anything and say that is the only way to be like that. I give some arguments, and rest my case. I believe that most of you don't get this, and think that I am trying to pretend to know more than I know: wrong again. I am saying what I am saying, better or worse, closer or farer to your point of view, that is it. Take it as a personal point of view!

wrote on 04.02.04 at 09:55:38:

I don't accept this idea, as you know nothing of what is happening behind the scene.

Well, I don't know who was the first guy that stabbed Julius Caesar, either. I know there were more of them, tho...


Quote:

This time I can say to you: be silent if you don't know anything about what you are saying.

You're not in a position to tell me anything, I am afraid. You will be if/when you prove you can do better than me.


Quote:

And again, I am not using publicity before a thing is fully ready as you do with your drivers, Dborca...

I think you don't get one thing: the whole opensource community uses this kind of... "publicity". And it is good for both the developers and people. I am talking about feedback. I personally adopted the SourceForge dogma: Release early, release often.

Mesa is not a finished product for several years now. Imagine if it was not public. How many years the average Linux user should wait, until the product was 100% finished. Forever?

Anyhow, I wish you good luck with your secret projects. Voodoos have serious problems with AGP slots already. In the future, I bet they'll have problems with the PCI, too. I just pray you won't release by that time.

You really don't know about what you are talking. Never mind... I don't get the analogy with the Voodoos, but I wish you the same luck if you are so "nice" to wish that to me, perhaps I wish you even more: to get stuck like them, and then realize that time has run out, and everything that you can do is to reflect at you mistakes done in the past.

wrote on 04.02.04 at 10:34:50:

You really don't know about what you are talking. Never mind... I don't get the analogy with the Voodoos, but I wish you the same luck if you are so "nice" to wish that to me, perhaps I wish you even more: to get stuck like them, and then realize that time has run out, and everything that you can do is to reflect at you mistakes done in the past.

If you haven't noticed by now, this is a 3dfx forum... and I still don't get it: what are you doing here? All I tried to do is help people around here. Perhaps you took over Syed's business and plan to deliver the next "ueber" chip. Maybe, who knows... Anyhow, it seems your intelligence surpasses mine by a far margin, since you discovered hidden meanings of my phrases. I meant no analogy at all. And my mistakes, eh... actually, I try to cover 3dfx engineers' mistakes.

Second, your wish of "me getting stuck" is a personal attack, and what can I say... apart from my favorite quote (Lecram's saying).

You said: "I just pray you won't release by that time." As you stated over there it is clearly that you are wishing something that I participate onto, not be released, right? That is why I "returned the favor" if I can say so.

Anyway, getting back to the intended talking, the whole cause because of the existance of this thread is very simple: Mesa is the foundation for now and future OpenGL Voodoo's support, so it is very good to know how do we experiment, and what results do we get with each technique, before implementing it into a driver for a video card.

I won't belive the fact that you have never thinked that Mesa could become a standard one day, and that it could become a "home-user" chance of experimenting the latest technologies without the latest hardware been available. In that case, the interest (and mine to a certain degree) on Mesa is that it can become the real figure in the future for the "cross-platform" development environment, linking Windows, Linux and perhaps other platforms. Again, I won't believe that the idea of an unified Win/Linux Integrated Development Environment, comercially free wouldn't be one of your dreams, because one way or another, it is everyone's.

One of the things I already know is that Mesa would like to become in a certain future, an addition to video cards OpenGL drivers, to support for OpenGL functions not supported by hardware, but usefull, and that can rely on the CPU to make a balance between the loads on the GPU and CPU. This thing is just a step in the big idea mentioned above...

Thus said, in-depth Mesa compatibility analyse is very usefull. That is why I tried to show the problems on Mesa. I was thinking that someone would try the same situations, and think at what could've went wrong, but the whole discussion didn't lead until now to somewhere.

Dborca , why you haven't tested and why you will not test the WinBinaries (Software OpenGL Rasterizer compiled Mesa) that include the compiled Mesa (don't remind what exact version they are), and see if you get to the same results, and not flame eveything I say, is a mistery to me. The whole idea was that you would test the WinBinaries and give a description of the possible cause of the problems spotted, and then there was a chance of thinking at some sollution. But it is clear that you don't want that...

wrote on 04.02.04 at 11:53:47:

You said: "I just pray you won't release by that time." As you stated over there it is clearly that you are wishing something that I participate onto, not be released, right? That is why I "returned the favor" if I can say so.

What I meant is, "I just pray you will release earlier, and not by the time your release becomes really futile". Ohwell, I should've emphasized that.


Quote:

Dborca , why you haven't tested and why you will not test the WinBinaries (Software OpenGL Rasterizer compiled Mesa) that include the compiled Mesa (don't remind what exact version they are), and see if you get to the same results, and not flame eveything I say, is a mistery to me. The whole idea was that you would test the WinBinaries and give a description of the possible cause of the problems spotted, and then there was a chance of thinking at some sollution. But it is clear that you don't want that...

Well, it's not that I don't want to. But I could really appreciate a more accurate description about bugs and/or missing features. I believe the knowledge you claim (directly or indirectly) you possess in various matters can be put at work and give me something more than an "average Joe" opinion. I am doing Mesa for free, in my spare time. If you don't like my approach, feel free and take over.

::)
No comments about this discussion
:P

hehehe, we would have spared a lot of writing, reading and time if andrei had made his threat clearer at the very beginning.  ;D

WOW, everyone keep their cool! Andrei, if you are bothering to review mesasw...well, why are you bothering? Dan has said over and over again that Mesa is much slower because it hasn't been optimized. Perhaps it will be in later releases, if you don't piss him off to the point where he gives up altogether!

As for the whole pictures thing, that's entirely ridiculous, taking the time, effort, hard drive space, and getting the hardware to run such technology would be ridiculous and simply not feasible, and even then real pictures could only be as lifelike as the hardware that displayed them and the format they were saved as. As for the rest of the crap you're talking about, I really don't even care to read it, let alone try and figure out wtf you're trying to say, I'll let the master deal with it.

Do not insult Dan or you and the entire 3dfx community will pay the consequences! My god do I wish I could kick/ban your stupid, misunderstanding, and ungrateful a** into enternal voodoo damnation. He is doing this for free, and as such you cannot, should not, and have no right whatsoever to demand things like unending testing of bugs that you don't even describe. If you want to report a bug or make a suggestion about Mesa, how about making it to the entire Mesa (not MesaFX) team, Daniel is simply one branch who is currently dealing with a very different portion of Mesa then you are addressing!

*realizes he's lost his cool too, and with good reason*

Quote:

And if something needs to be clarified : We support totally the Team and MesaFx

That´s for sure 8)

First a bit about self-compiling in general. Compared with the PC's you can buy today at your local computerstore i  have an old system (K6-2 500) and often have to recompile programs (especially emulators like mame32) with the K6 switch and other speedup options and #defines to make them run a bit faster. It's always makes me wild when i see that you can only compile a program with a specific version of one compiler. I have downloaded 3 different mingw versions for 3 different emulators.  Because i came from dos and linux i have a little practice how to manipulate makefiles, setting variables and #defines but i think beginners, especially those who don't know what to do with a dosbox at all, are unable to compile a program themselves. Many programs, especially open source software, compiles on gcc-variants like mingw, emx (remember os/2) or cygwin (for unixers who don't want to port their programs to windows). But others rely on M$VC. I know there is a command-line freeware variant but especially dialup users dont want to download that big archive just to compile one single program!

@dborca
Back to mesafx. I just started to use it on my Voodoo³ and havn't checked many games yet. Q3A runs well. But GLMARK doesn't. That strange benchmark crashes on nearly every 3dfx ogl implementaion (wgl, minigl, koolsmoky's mesa, hawk's old mesa3dfx and altsoftwares mesa to d3d6 wrapper). If i check all my opengl stuff (latest stable 1.07 driver with latest glides and opengl from the 1.08b driver) is this the right place to write the result? And are you interested in such reports at all?

Regards,
Andreas

P.S.
I've found no direct link from the www.mesa3d.org site to your site or to any site containing binaries at all.

Okay, boyz and galz!

I am uploading SW Mesa right now. It uses CVS snapshot from 31-jan-2004, coz I didn't bothered with newer sources. Compiled with M$VC... Against my principles, but ohwell... (it's smaller than MinGW version, although not faster).

I really didn't tested anything but GLClock and GLViewer (as mentioned by Boiu). I could have tried GLQuake, but i was tired yesterday.

For anyone interested, here's the link:
http://www.geocities.com/dborca/mesa/mesasw.zip