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

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

Quote:


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

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

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.

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

No comments about this discussion

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*