Currently, I am basically going through SDL_x11video.c and adding GLX
calls wherever appropriat (surrounded by #ifdef USE_GLX). It ends up
that alot of the functions which are defined differently for normal and
DGA usage will be defined yet again for GLX. I am not very familiar
with DGA, so I am wondering, should DGA and GLX be enabled at the same
time? It would appear so if you want fullscreen support.
Documentation for some of the functions is lacking. Most of them I can
figure out from the API reference, but a few are not defined there.
X11_SetupWindow() is one of them. From the looks of it, this function
allocates the primary display surface, no?
Anyway, it looks like implementing 2D blits and stuff would work best
like this:
-blits from on-screen video memory to on-screen vidmem use
glCopyPixels()
-off-screen vidmem is stored in textures
-blits from off to on draws a textured rectangle, possibly with alpha.
-blits from on to off use glCopyTex[Sub]Image2D()
as for blitting from system memory:
- sysmem->screen = glDrawPixels() (slow
)
- sysmem->vidmem = glTexture2D()
Anyway, you get the idea.
Is there anything major that I am missing? Any more tips to give me? 
-Kenton Varda
Kenton Varda wrote:
-blits from on-screen video memory to on-screen vidmem use
glCopyPixels()
the last time I checked this was awfully slow.–
Daniel Vogel
666 @ http://grafzahl.de
Daniel Vogel wrote:
Kenton Varda wrote:
-blits from on-screen video memory to on-screen vidmem use
glCopyPixels()
the last time I checked this was awfully slow.
Depends on the implementation. Unfortunately, most 3D cards probably do
not do this very fast as it is not needed in any 3D games.
Just to offer a data point on this discussion, I can talk about an
uncompressed image sequence player I recently wrote with OpenGL (it loads
several hundred 720x480 24-bit frames into RAM and blows through them at 30+
fps; I use it for my 3D animation work)…
Don’t even try the 2D functions like glDrawPixels(). They’re rarely even
hardware-accelerated, and you’ll get about 1 fps.
glTexSubImage2D() works great. On a TNT under NT I easily get 50 fps
full-frame updates. I guess performance would suffer on cards with more
limited fillrates, but you could also get fancy and only update the dirty
rectangles like SDL does now…
A long time ago Sun offered an OpenGL extension that would guarantee
continued access to the texture map after calling glTexImage2D(), so you
could call it once and then scribble on the texture and have it updated
appropriately. Never saw it used myself though.
Dan
glTexSubImage2D() works great. On a TNT under NT I easily get 50 fps
full-frame updates. I guess performance would suffer on cards with more
limited fillrates, but you could also get fancy and only update the dirty
rectangles like SDL does now…
Hmm… does this support transparent (don’t blit color 0) drawing of textures?
Because if so, then we may as well scrap drawpixels…
Dan
Nicholas
glTexSubImage2D() works great. On a TNT under NT I easily get 50 fps
full-frame updates. I guess performance would suffer on cards with more
limited fillrates, but you could also get fancy and only update the dirty
rectangles like SDL does now…
Hmm… does this support transparent (don’t blit color 0) drawing of
textures?
Because if so, then we may as well scrap drawpixels…
Hmm, I don’t think so… TexSubImage2D is for replacing the pixels of an
existing texture with new pixels; the new pixel data is never examined in a
way that would allow transparency. Once could set up a few polygons on top
of each other and use OpenGL’s own alpha blending for transparency; this
would add some complexity of course.
I would consider glDrawPixels as a hack to get things working, and nothing
more. You won’t find it accelerated on anything except for outdated $1000+
cards and SGI workstations; not even nVidia’s legendary Windows drivers
accelerate it. (correct me if I’m wrong- anybody tried glDP() on recent 3dfx
hardware?)
Dan
Hmm, I don’t think so… TexSubImage2D is for replacing the pixels of an
existing texture with new pixels; the new pixel data is never examined in
a
way that would allow transparency. Once could set up a few polygons on top
of each other and use OpenGL’s own alpha blending for transparency; this
would add some complexity of course.
One more thought… I’m not familiar with SDL internals yet… When an
application says “blit this rectangle to the framebuffer,” how difficult
would it be to build a 32-bit RGBA image of it in memory? You could treat
each blit request as one polygon to be rendered, with an RGBA texture that
would handle both the color and transparency… Better yet, build the RGBA
images as sprites are loaded instead of at runtime…
Dan
I would consider glDrawPixels as a hack to get things working, and nothing
more. You won’t find it accelerated on anything except for outdated $1000+
cards and SGI workstations; not even nVidia’s legendary Windows drivers
accelerate it. (correct me if I’m wrong- anybody tried glDP() on recent 3dfx
hardware?)
Dan
IIRC, Rendition hardware (V1000, V2x00) accelerates glDrawPixels -
according to their developer docs, using glDrawPixels is significantly
faster than drawing a textured quad. I’ve never tried it on any recent
hardware, but there are quite a few hardware GL implementations out there
these days, so one of them might accelerate it. SDL could use an
environment variable (or something) to select whether or not to use
glDrawPixels (default - no).On Wed, 15 Dec 1999, Dan Maas wrote:
This signature has been infected by the signature virus.
Please help me spread and copy me to your .signature.
(('name “Andy Hefner”)
('email “vector7 at crosswinds.net”)
)
Hi everyone,
Can someone please point me to more information on the *.it format?
(The music.it file included with the SDL demo “aliens” plays
a continuous looping background riff, and I’m trying to
find out what is involved in creating such a control file
from scratch.)
Thanks for any pointers,
Steve Madsen
H2Eye Ltd
24-28 Hatton Wall
London EC1N 8JH
Tel: +44-171-404-9600
Fax: +44-171-404-9490
Email: @Steve_Madsen
Hmm, I don’t think so… TexSubImage2D is for replacing the pixels of an
existing texture with new pixels; the new pixel data is never examined in
a
way that would allow transparency. Once could set up a few polygons on top
of each other and use OpenGL’s own alpha blending for transparency; this
would add some complexity of course.
One more thought… I’m not familiar with SDL internals yet… When an
application says “blit this rectangle to the framebuffer,” how difficult
would it be to build a 32-bit RGBA image of it in memory? You could treat
each blit request as one polygon to be rendered, with an RGBA texture that
would handle both the color and transparency… Better yet, build the RGBA
images as sprites are loaded instead of at runtime…
That should work! I think you’ve hit on the best way of doing it - RGBA. That’d
be hardware accelerated on many machines, and since you could set the alpha bit
of areas that you want to avoid to 0, then you’re set. You could build a memory
image VERY quickly, too, if you use a bit of X86 asm code, then dump it. I was
going to do something like that, but setting the alpha bit to 0 is something
that I’d overlooked. Shoot me, I’m an idiot.
I’ll write that, no problem. I have 3 years of x86 asm under my belt, so
getting it suitably fast should take very little time. Other versions for other
chipsets will require other machine language instructions; somebody else can
write those. PPC asm ain’t my thing, and besides, I don’t have a compiler for
it. And don’t talk to me about LinuxPPC; I think it’s a nightmare 
Of course, first we need to iron out what format we need to actually send the
damn information as!>Dan
Hi everyone,
Can someone please point me to more information on the *.it format?
IT is short for Impulse Tracker, a free DOS based music editor created by
Jeffrey Lim for use in demos. Hunt around tracking sites and download it; it’s
well worth it and is definitely the best music-creation tool out there, even
though its old.
Steve Madsen
Nichol
.it comes from the program Impulse Tracker which is only available for
DOS and except for bug fixes will never be updated. Just do a search
for Impulse Tracker and you should be able to find the official page.
For other formats supported by the mixer lib (.s3m, .xm, .mod, etc)
try searching for tracking and the file extension.
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
Steve Madsen wrote:> Hi everyone,
Can someone please point me to more information on the *.it format?
(The music.it file included with the SDL demo “aliens” plays
a continuous looping background riff, and I’m trying to
find out what is involved in creating such a control file
from scratch.)
Thanks for any pointers,
Steve Madsen
H2Eye Ltd
24-28 Hatton Wall
London EC1N 8JH
Tel: +44-171-404-9600
Fax: +44-171-404-9490
Email: steve at h2eye.com
Umm…
That should be an Impulse Tracker mod…
If I understand You correctly You want to create mods?
This seems like a place to start browsing:
A good tracker for linux is:
http://www.soundtracker.org/
/DanielOn 1999-12-15 18:04:46, Steve Madsen wrote:
Hi everyone,
Can someone please point me to more information on the *.it format?
(The music.it file included with the SDL demo “aliens” plays
a continuous looping background riff, and I’m trying to
find out what is involved in creating such a control file
from scratch.)
Thanks for any pointers,
–
Now take a deep breath, smile and don’t take life so seriously…
Yeah… I was already planning to do that. One step ahead of you. I still
want to know the GL format and type flags for 16bit RGB and RGBA graphics, but
I’ll figure it out if no one knows.
Most optimizing compilers code better ASM than people these days, but you are free
to try it…
-Kenton Varda
vining at pacificcoast.net wrote:> That should work! I think you’ve hit on the best way of doing it - RGBA. That’d
be hardware accelerated on many machines, and since you could set the alpha bit
of areas that you want to avoid to 0, then you’re set. You could build a memory
image VERY quickly, too, if you use a bit of X86 asm code, then dump it. I was
going to do something like that, but setting the alpha bit to 0 is something
that I’d overlooked. Shoot me, I’m an idiot.
I’ll write that, no problem. I have 3 years of x86 asm under my belt, so
getting it suitably fast should take very little time. Other versions for other
chipsets will require other machine language instructions; somebody else can
write those. PPC asm ain’t my thing, and besides, I don’t have a compiler for
it. And don’t talk to me about LinuxPPC; I think it’s a nightmare
Of course, first we need to iron out what format we need to actually send the
damn information as!
Yeah… I was already planning to do that. One step ahead of you. I
still
want to know the GL format and type flags for 16bit RGB and RGBA graphics, but
I’ll figure it out if no one knows.
I haven’t had a chance to really look yet; this evening, I promise.
Most optimizing compilers code better ASM than people these days, but you are
free
to try it…
I usually beat the compiler by 10% - well, Watcom c++ anyways. I haven’t tried
fighting GCC…
-Kenton Varda
Nichol
Go to www.wotsit.org. If it ain’t there, it ain’t anywhere.
Steve Madsen wrote:>
Hi everyone,
Can someone please point me to more information on the *.it format?
(The music.it file included with the SDL demo “aliens” plays
a continuous looping background riff, and I’m trying to
find out what is involved in creating such a control file
from scratch.)
Thanks for any pointers,
Steve Madsen
H2Eye Ltd
24-28 Hatton Wall
London EC1N 8JH
Tel: +44-171-404-9600
Fax: +44-171-404-9490
Email: steve at h2eye.com