If this is going to be the case, would it be possible to name the SDL
libraries with a consistant soname?
You mean like libSDL-0.8 and libSDLdevel-0.9 ?
I’m working on CD-ROM audio control (mostly by taking apart CDP).
Hopefully I’ll have something available soon. I can’t vouch for how
well it’ll look or how much work Sam’ll have to do to make it fit into
the library, but it should be fairly easy to understand.
Well, I’m looking forward to seeing it. If you get a chance, implement
it under Win32 too…
SDL is growing to the point where just to compile and cursorily test
the games and demos on all supported platforms takes almost a week.
No offense, but I’m glad it’s you and not me. I’ve not tried to
compile anything under Windows, but if it’s as much trouble as WRITING
something for Windows, I’m not sure I ever want to have to do it.
Actually, using the cross-compilers, its as simple as compiling for Linux.
I’ll do what I can on all the x86 GlibC projects. I may be able to
help with the libC5 as well, if I can get that machine runing again.
Okay, I may not need your help, but if I do, I’ll definitely let you know.
Another thing that would be nice (I don’t know how plausible it would
be) is if there were a software-wavetable option for those of us with
SB16’s or lower. I know they’re working on stuff like this (Timidity,
OpenCubicPlayer), so maybe we’d be able to integrate it into a
suplementary library.
There’s no reason why we couldn’t port timidity to SDL if we wanted.
Actually, at the moment it wouldn’t really help with voodoo cards or
anything, because they don’t use the 2d card when in 3d mode, and that’s
the only 3d hardware well supported in Mesa. But it would help if
someone were to be using software rendering, because we’d be able to set
up our programs to use just the SDL surface or whatever, and whenever
you implement new features(ie double buffering), we don’t have to change
any code, if done properly, and I believe the blitting code would
probably be quicker, etc.
Ahh, I see. And it would be trivial to use 3-D hardware acceleration if
it was available, right?
That would work. Something that could be used to differentiate the
two, so they could happily coexist and ld.so could tell which is which.
Well, I’m looking forward to seeing it. If you get a chance, implement
it under Win32 too…
I don’t think CD-devices are accessed the same way under Win32,
unfortunately. Under Linux, it’s a simple matter of strategic use
of IOCTL. I don’t think it’s that easy under Win32.
Actually, using the cross-compilers, its as simple as compiling for Linux.
That is, once you get past that pesky little problem of actually
GETTING the cross-compiler installed into GCC.
Okay, I may not need your help, but if I do, I’ll definitely let you know.
That would work. Something that could be used to differentiate the
two, so they could happily coexist and ld.so could tell which is which.
Okay.
I don’t think CD-devices are accessed the same way under Win32,
unfortunately. Under Linux, it’s a simple matter of strategic use
of IOCTL. I don’t think it’s that easy under Win32.
Nope, but it can be done…
That is, once you get past that pesky little problem of actually
GETTING the cross-compiler installed into GCC.
Ahh, I see. And it would be trivial to use 3-D hardware acceleration
if
it was available, right?
That would be Mesa/OpenGL’s job, but yeah, all you have to do is have
Mesa compiled for your hardware, and it’ll accelerate 3d. Or use the
correct opengl.dll in Windows… I have no idea about BeOS,
unfortunately.
I believe that Mesa supports BeOS, come to think of it.
-Erik Reid______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
That is, once you get past that pesky little problem of actually
GETTING the cross-compiler installed into GCC.
Sorry for the off-topicness of this, but.
I’m currently having troubles with this, can anyone help? Send me to a
good URL?
I’m trying to do the mingw32 method. binutils compiles fine. egcs
doesn’t. gcc2.8.1 doesn’t. I have the mingw32 and windows32api headers
and libs and stuff all installed…
-Erik Reid______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Ahh, I see. And it would be trivial to use 3-D hardware acceleration
if
it was available, right?
That would be Mesa/OpenGL’s job, but yeah, all you have to do is have
Mesa compiled for your hardware, and it’ll accelerate 3d. Or use the
correct opengl.dll in Windows… I have no idea about BeOS,
unfortunately.
I’m sorry, but I’m quite sure that the only 3d thing that might be possibly
integrated into SDL is software rendering. I’ve tried to port our little
jump
demo to Glide and I failed because it’s very different from "normal"
programming.
As said before, the Voodoo card (and 3d-built-in graphics cards such as
Riva128, too I think) doesn’t use the 2d card any more (that’s why 3dfx
doesnt
support window games) so all graphics output has to go thru the voodoo card.
The problem is that although voodoo(2) has got a frame buffer to write to
directly,
it’s slow and isn’t used at all by any programmer (again I think). So ALL
output has to be done using textures (event sprites, text, lines…). I
don’t see a
way that Mesa could take to solve the problem. And from what I’ve heard,
OpenGL
under Windows without 3d acceleration must be very slow. AND I don’t think
OpenGL
can render into a buffer but only to the screen so it would be impossible to
mix
SDL-based graphics and OpenGL-3d graphics…
tell if (you think) I’m wrong, that’s just what I’ve learned
— Paulus Esterhazy (@Paulus_Esterhazy)
That would be Mesa/OpenGL’s job, but yeah, all you have to do is have
Mesa compiled for your hardware, and it’ll accelerate 3d. Or use the
correct opengl.dll in Windows… I have no idea about BeOS,
unfortunately.
I’m sorry, but I’m quite sure that the only 3d thing that might be possibly
integrated into SDL is software rendering. I’ve tried to port our little
jump
demo to Glide and I failed because it’s very different from "normal"
programming.
Not exactly. Glide was written by Brian Hook of iD software for
3DFx, and it is very much modeled after OpenGL.
As said before, the Voodoo card (and 3d-built-in graphics cards such as
Riva128, too I think) doesn’t use the 2d card any more (that’s why 3dfx
doesnt
support window games) so all graphics output has to go thru the voodoo card.
The problem is that although voodoo(2) has got a frame buffer to write to
directly,
it’s slow and isn’t used at all by any programmer (again I think). So ALL
output has to be done using textures (event sprites, text, lines…). I
don’t see a
way that Mesa could take to solve the problem.
You can build Mesa with its libraries linked against glide.
(Note: I am running BeOS, now on my x86 laptop along with
Linux and W98) At the time, that was the only way to get
hardware accelerated OpenGL on a machine running BeOS.
Anyhow, That’s exactly how I did my final project for my graphics course
when I hauled my PPC machine in to show off my simple video game
engine.
There isn’t even an x86 glide build yet for BeOS; but alas
there is no easy way of getting a Voodoo anything on my laptop
unless there has been a PCMCIA Voodoo (x) card that I don’t
know of yet.
And from what I’ve heard,
OpenGL
under Windows without 3d acceleration must be very slow.
Depends exactly on what you are doing. The performance of
the OpenGL implementation on Windows blows the doors off
of the software (unoptimized at that) implementation of OpenGL
1.1 on BeOS.
AND I don’t think
OpenGL
can render into a buffer but only to the screen so it would be impossible to
mix
SDL-based graphics and OpenGL-3d graphics…
tell if (you think) I’m wrong, that’s just what I’ve learned
I’m not so sure how its implemented in Windows, but BeOS
OpenGL is rendered into a BView. So it can be windowed.
Best Regards,
David Sowsy> — Paulus Esterhazy (pesterhazy at gmx.net)
I’ve not tried to
