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.
----------------------------------------------------------------------

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.

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).

Quote:


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.

Quote:

like that one 

Quote:


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.

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.

Quote:


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:


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:


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:


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 

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!  

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