3d stuff

palpetine · October 26, 2001, 6:49am

heya.

is there any good extension for sdl that i.e. software draw textured
triangles ? i am not thinking about mesa or such stuff, but rather something
similar to fatmap32.

the second question is - when we use sdl^mesa how to determine if we are
using now hardware or software drawing method? what i am going to is that i
want to replace some of mesa software drawing functions with my own, which
are faster

and… when i run on x4.0^1024x768x16bpp^mdk with accel - when i run sdl app
which open 800x600 window - i can see stretching - fiting window to
fullscreen. on rh there is just 800x600 window. how to control this stuff?
is this determined by x servers or sdl ?

thanks a lot and dont blame for lame

firefox–

Zamow odbitki ze zdjec cyfrowych lub archiwum zdjec na CD!
[ http://lab.foto.onet.pl/laboratorium.html ]

David_Olofson · October 26, 2001, 7:50am

heya.

is there any good extension for sdl that i.e. software draw textured
triangles ? i am not thinking about mesa or such stuff, but rather
something similar to fatmap32.

How about TinyGL? (Not that I’ve used it myself yet…)

http://www.stud.enst.fr/~bellard/TinyGL.html

the second question is - when we use sdl^mesa how to determine if we
are using now hardware or software drawing method? what i am going to
is that i want to replace some of mesa software drawing functions with
my own, which are faster

There’s a problem there; you need to bypass SDL entirely to do that
rendering, or you’ll end up having SDL “download” an RGBA texture to
Mesa, which then has to blend that to the screen… heh

Or you could make software Mesa render into an SDL texture.

and… when i run on x4.0^1024x768x16bpp^mdk with accel - when i run
sdl app which open 800x600 window - i can see stretching - fiting
window to fullscreen. on rh there is just 800x600 window. how to
control this stuff? is this determined by x servers or sdl ?

Stretching…? As in “OpenGL pretends that the screen is 800x600, while
transparently scaling the transformation vectors”?

Would make sense in a way, but OTOH, life is just too easy for OpenGL
applications WRT screen resolutions. Why should the system confuse
matters by automatically “simulate” unsupported resolutions, potentially
breaking OpenGL applications that rely on pixel accurate rendering?
(There’s no way to scale graphics without visible artifacts! Besides,
texture filtering must be turned off for tiled map rendering and similar
2D stuff to work with scaling.)

Anyway, I’ve been using Mandrake and XFree86 4.0.x on machines with G400,
Rage128/Mach64 and Rage Pro 128 and never seen anything like that. Of
course, that might just be because of my huge collection of modelines.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 26 October 2001 15:40, firefox wrote:

palpetine · October 26, 2001, 8:12am

How about TinyGL? (Not that I’ve used it myself yet…)
http://www.stud.enst.fr/~bellard/TinyGL.html

i will check this out, but all stuff with GL in name seems to be… slow.

hmm… tommorow i start my weekend so my intuition tells me that i will have
to
write this by myself. thanks for help anyway.

There’s a problem there; you need to bypass SDL entirely to do that
rendering, or you’ll end up having SDL “download” an RGBA texture to
Mesa, which then has to blend that to the screen… heh

sounds shitty, but i’ll keep trying.

Or you could make software Mesa render into an SDL texture.

indeed. i am sco unix developer already, so i saw worse things

Stretching…? As in “OpenGL pretends that the screen is 800x600, while
transparently scaling the transformation vectors”?

something like that.

Would make sense in a way, but OTOH, life is just too easy for OpenGL
applications WRT screen resolutions. Why should the system confuse
matters by automatically “simulate” unsupported resolutions, potentially
breaking OpenGL applications that rely on pixel accurate rendering?

i was reading that indeed there is something like this already avaible.

(There’s no way to scale graphics without visible artifacts! Besides,
texture filtering must be turned off for tiled map rendering and similar
2D stuff to work with scaling.)

yeah, i know.

Anyway, I’ve been using Mandrake and XFree86 4.0.x on machines with G400,
Rage128/Mach64 and Rage Pro 128 and never seen anything like that. Of
course, that might just be because of my huge collection of modelines.

i have riva zx
that’s why software rendering on my pc runs faster then ogl
and i am going to move to G450 or some kind of gfrc.

firefox–

Zamow odbitki ze zdjec cyfrowych lub archiwum zdjec na CD!
[ http://lab.foto.onet.pl/laboratorium.html ]

David_Olofson · October 26, 2001, 9:02am

How about TinyGL? (Not that I’ve used it myself yet…)
http://www.stud.enst.fr/~bellard/TinyGL.html

i will check this out, but all stuff with GL in name seems to be…
slow.

Well, not if it’s h/w accelerated, of course, but other than that, you
seem to be quite right.

However, TinyGL seems to be optimized specifically for software
rendering. It even takes the liberty of not being 100% OpenGL compatible,
mainly for the sake of speed.

hmm… tommorow i start my weekend so my intuition tells me that i will
have to
write this by myself. thanks for help anyway.

That’s quite some work if you want it real fast… Even more work if it’s
supposed to look good AND be real fast.

You could probably rip the texturing code from some 3D game from the
early days of h/w acceleration, back when software rendering still had to
be playable. (Several of those engines are now GPLed.)

There might be some interesting code in Quake, Quake II, maybe also the
floor/ceiling texturing from Doom. (Although I think the ZDoom code is
faster - it’s probably the fastest source port around, and it’s optimized
for current CPUs.)

[…]

Anyway, I’ve been using Mandrake and XFree86 4.0.x on machines with
G400, Rage128/Mach64 and Rage Pro 128 and never seen anything like
that. Of course, that might just be because of my huge collection of
modelines.

i have riva zx
that’s why software rendering on my pc runs faster then ogl

It can’t be that bad, can it!?

and i am going to move to G450 or some kind of gfrc.

I’m very happy with the G400/Eizo F980 combo, but I would probably go for
a GeForce based card unless I really was going to use 1600x1200+
resolutions. GeForce 2 is much faster than the G400 and G450, and the
GF3 should be ever faster. (The G450 isn’t faster than the G400, but has
a better secondary output. In fact, the G450 is sometimes slightly slower
because of the half width, double speed bus.)

The major advantage or the Matrox cards (and ATI cards to some extent) is
that they happily generate high quality video signals at resolutions
beyond 1600x1200, which is not the case with any GF based cards.
(Integrated crap RAMDAC in the GF chips - silly nVidia…) I have a
machine with a GF2 card and a good 19" monitor, and in fact, the image
was sharper with the old Permedia-2 based card…

Oh, a G400 does run Quake III pretty well, so what’s the big deal?

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 26 October 2001 17:08, firefox wrote:

icculus · October 26, 2001, 9:31pm

the second question is - when we use sdl^mesa how to determine if we are
using now hardware or software drawing method? what i am going to is that i
want to replace some of mesa software drawing functions with my own, which
are faster

Time the routines at runtime.

Allegedly, Brian Paul swears that he won’t change the GL_RENDERER value of
glGetString(), so you can supposedly determine if you’re in software mesa
from that.

BUT.

Certain accelerated drivers will fall into software mesa just for
certain paths, which, depending on what your application does, might claim
to be hardware accelerated when in fact they are spending most of their
time on the CPU.
It takes a lot of faith to assume that that damned string will never
change again.
Other vendors could put out a non-mesa, software GL implementation, in
which case, any check you do on GL_RENDERER will be worthless.

And, if you’ve got faster software routines, PLEASE get them added to Mesa
itself if at all possible. ANYTHING to speed up software mesa is a good
thing in my book.

and… when i run on x4.0^1024x768x16bpp^mdk with accel - when i run sdl app
which open 800x600 window - i can see stretching - fiting window to
fullscreen. on rh there is just 800x600 window. how to control this stuff?
is this determined by x servers or sdl ?

Check /etc/X11/XF86Config or the equivalent on your platform; you need a
modeline to tell the monitor how to run at 800x600. Red Hat might supply
one, whereas Mandrake may not.

–ryan.