Anyone want to help?

SDL Development
1

I’m going to release SDL 0.8 as a stable release.

From then on, SDL development will be similar to that of the Linux kernel:
SDL 0.8, 1.0, 1.2, etc. will be bugfix only releases, and SDL 0.9, 1.1, 1.3,
etc. will be “development” releases where we experiment and extend SDL.
In this way, those who need a stable release with bugfixes can use the
even numbered versions of SDL, and those who want to play with new ideas
can use the odd numbered developer releases.

Okay, that said, I have a big list of ideas for SDL that I need help with.
The projects are:
Joystick support
MIDI support
CD-ROM audio control
Port to MacOS

Each of these items is very useful and interesting, but if they are to
be done, it would be very helpful to get some help.

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.

So, I hereby ask anyone who wants to take on one or more of the above
projects to post to the list. I’d like to organize groups of people
who want to work on these individual projects so we get more done, and
faster. :slight_smile: If you work on one of these, you’ll get to use that feature
in your project! MIDI support! Joystick support! Run your game on
MacOS! :slight_smile: Just think of the possibilities… smile

I also would like to get volunteers for compiling binaries when a major
release of SDL comes up. We need compilers for all the games on the
download page on all the platforms:

   Crystal Space                 Linux x86 libC5
   Descent 1X                    Linux x86 GlibC
   DOOM               X          Linux SPARC
   HElliZER                      Linux PPC
   qrash                         Linux ALPHA
                                 Solaris SPARC
                                 Solaris X86
                                 IRIX
                                 OSF/1
                                 Win32
                                 BeOS PPC
                                 BeOS X86
                                 MacOS 68K
                                 MacOS PPC

IRIX, OSF/1, and MacOS are not fully supported.

Anyway, PLEASE consider this and post to the list. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

2

I also would like to get volunteers for compiling binaries when a major
release of SDL comes up. We need compilers for all the games on the
download page on all the platforms:

Ok, I can handle Linux x86 glibc and LinuxPPC, and Joshua (my brother) will
probably either give me a login accound on his Sun station to compile binaries
or do it himself.

   Descent 1X                    Linux x86 GlibC
   DOOM               X          Linux SPARC
   HElliZER                      Linux PPC

Also, with MIDI support, do you just want something like
SDL_PlayMidiFile(filename) or do you want support support for pausing,
stopping, playing backwards etc?On Wed, Sep 16, 1998 at 05:42:56PM -0700, Sam Lantinga wrote:

–
– Michael Samuel

3

I’m going to release SDL 0.8 as a stable release.
From then on, SDL development will be similar to that of the Linux
kernel:
SDL 0.8, 1.0, 1.2, etc. will be bugfix only releases, and SDL 0.9, 1.1,
1.3,
etc. will be “development” releases where we experiment and extend SDL.
In this way, those who need a stable release with bugfixes can use the
even numbered versions of SDL, and those who want to play with new
ideas
can use the odd numbered developer releases.

Cool.

Okay, that said, I have a big list of ideas for SDL that I need help
with.
The projects are:
Joystick support
MIDI support
CD-ROM audio control
Port to MacOS

Each of these items is very useful and interesting, but if they are to
be done, it would be very helpful to get some help.

Something that I’d be very happy to work on would be a fast way for
OpenGL/Mesa to render to an SDL display buffer…
I’d need some help tho, as my programming abilities suck :\

I also would like to get volunteers for compiling binaries when a major
release of SDL comes up. We need compilers for all the games on the
download page on all the platforms:

I wouldn’t mind doing Linux/x86/glibc and Win32/x86 binaries of stuff. I
won’t really be able to start until the 29th, but after that I’d have no
problems with it, tho I could see these being the easy ones to get
people for :slight_smile:

-Erik Reid______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

4

Okay, that said, I have a big list of ideas for SDL that I need help with.
The projects are:
Joystick support
Have only got a old arcade joystick (c64, amiga). With a little converter
to the gameport…
CD-ROM audio control

Network API, just joint the previous ann. list…

grt,

  • JasperOn Wed, 16 Sep 1998, Sam Lantinga wrote:

±----
| Beheer Commisaris | Homepage: http://www.il.fontys.nl/~jasper
| IGV Interlink | PGP-key: finger @Jasper_Berlijn |
| E-mail: @Jasper_Berlijn |
----+

5

Hi there…
Sam Lantinga wrote:

I’m going to release SDL 0.8 as a stable release.

From then on, SDL development will be similar to that of the Linux kernel:
SDL 0.8, 1.0, 1.2, etc. will be bugfix only releases, and SDL 0.9, 1.1, 1.3,
etc. will be “development” releases where we experiment and extend SDL.
In this way, those who need a stable release with bugfixes can use the
even numbered versions of SDL, and those who want to play with new ideas
can use the odd numbered developer releases.

Okay, that said, I have a big list of ideas for SDL that I need help with.
The projects are:
Joystick support
MIDI support
CD-ROM audio control
Port to MacOS

Each of these items is very useful and interesting, but if they are to
be done, it would be very helpful to get some help.

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.

So, I hereby ask anyone who wants to take on one or more of the above
projects to post to the list. I’d like to organize groups of people
who want to work on these individual projects so we get more done, and
faster. :slight_smile: If you work on one of these, you’ll get to use that feature
in your project! MIDI support! Joystick support! Run your game on
MacOS! :slight_smile: Just think of the possibilities… smile

I also would like to get volunteers for compiling binaries when a major
release of SDL comes up. We need compilers for all the games on the
download page on all the platforms:

   Crystal Space                 Linux x86 libC5
   Descent 1X                    Linux x86 GlibC
   DOOM               X          Linux SPARC
   HElliZER                      Linux PPC
   qrash                         Linux ALPHA
                                 Solaris SPARC
                                 Solaris X86
                                 IRIX
                                 OSF/1
                                 Win32

I must confess that I was having huge problems compiling D1X on windows. I
eventually got it to the state where I could crash it after selecting new game
under the DIB driver. A lot of changes had to be made about structure packing
and so on in Descent itself (Is it true that MSVC doesn’t have an equivalent
for the __attribute(pack) directive, instead you have to surround stuff with
#pragma pack(1) #pragma pack()?).The win32 cross compiler just page-faulted
somewhere in the SDL library (when I tried running the result)… and the
native build kit you provide had huge problems under win95.
Have you got any plans to release those SDL MSVC project files? That would
really rock and make my life easier.

Alternatively I could do a proper port of the SDL to the native mingw32
compiler (avoiding the cygwin build tools if at all possible as they are very
unstable on win 9x).

:slight_smile:
Peter> BeOS PPC

                                 BeOS X86
                                 MacOS 68K
                                 MacOS PPC

IRIX, OSF/1, and MacOS are not fully supported.

Anyway, PLEASE consider this and post to the list. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)

–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

6

(Is it true that MSVC doesn’t have an equivalent
for the __attribute(pack) directive, instead you have to surround stuff with
#pragma pack(1) #pragma pack()?).

You can specify the alignment in the command line. I think using /Zp1,
/Zp4, etc… I don’t think this is well documented. But just throw
whatever alignment you need in the makefile and you should be all set.

-Chuck

7

Sam Lantinga wrote:

Okay, that said, I have a big list of ideas for SDL that I need help with.
The projects are:
Joystick support
MIDI support
CD-ROM audio control
Port to MacOS

Each of these items is very useful and interesting, but if they are to
be done, it would be very helpful to get some help.

I would be willing to help with the MIDI part, since that is what I am currently struggling with anyway. :) I do not have the time to really "head" a development effort, but I would like to offer my services as programmer. My experience is with Free Unices and a little win32/directx.

M.Watson

8

Michael Samuel wrote:

Ok, I can handle Linux x86 glibc and LinuxPPC, and Joshua (my brother) will
probably either give me a login accound on his Sun station to compile binaries
or do it himself.

Okay, I put you down for Linux x86-glibc, Linux PPC, and Solaris 2.6 (sparc)

Thanks!

Also, with MIDI support, do you just want something like
SDL_PlayMidiFile(filename) or do you want support support for pausing,
stopping, playing backwards etc?

We need at least “play”, “stop”, “pause” … anything else anyone?
(I’m not that familiar with MIDI)

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

9

“Erik Reid” <lynx_c5 at hotmail.com> wrote:

Something that I’d be very happy to work on would be a fast way for
OpenGL/Mesa to render to an SDL display buffer…
I’d need some help tho, as my programming abilities suck :\

It shouldn’t be too hard to do with Mesa, as it can render to an X pixmap…
What would be the point?
I really want to know, because it keeps coming up, and I’d like to know
what advantages it would have.

I wouldn’t mind doing Linux/x86/glibc and Win32/x86 binaries of stuff. I
won’t really be able to start until the 29th, but after that I’d have no
problems with it, tho I could see these being the easy ones to get
people for :slight_smile:

I can do Win32/x86 binaries, and Linux/x86/libc5
I think Michael can do Linux/x86/glibc
I’ll definitely ask you if we need more help. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

10

(Is it true that MSVC doesn’t have an equivalent
for the __attribute(pack) directive, instead you have to surround stuff
with

#pragma pack(1) #pragma pack()?).

You can specify the alignment in the command line. I think using /Zp1,
/Zp4, etc… I don’t think this is well documented. But just throw
whatever alignment you need in the makefile and you should be all set.

Well I don’t think this is a good solution because not alligning the members
to dword borders
makes the code (much) slower. You’ll have to #pragma (8) … #pragma ()
around the SDL structures
anyway.

Paulus Esterhazy

11

Peter Hawkins wrote:

I must confess that I was having huge problems compiling D1X on windows. I
eventually got it to the state where I could crash it after selecting new
game
under the DIB driver. A lot of changes had to be made about structure
packing
and so on in Descent itself (Is it true that MSVC doesn’t have an
equivalent
for the __attribute(pack) directive, instead you have to surround stuff
with
#pragma pack(1) #pragma pack()?).The win32 cross compiler just page-faulted
somewhere in the SDL library (when I tried running the result)… and the
native build kit you provide had huge problems under win95.

I had the same problems with the member allignment - Sam should surround the
structure definitions with:
#ifdef VISUALC
#pragma pack (8)
#endif
or something like that because the dll and the program don’t have to use the
same
sturcture packing setting. I skipped the problem by compiling the dll myself
in visualc
and by sorrounding my own structures that are, for example, loaded from a
disk file by
#pragma pack (1)
…
#pragma pack ()
In my opinion, the Microsoft #pragma-solution is terrible, but I don’t think
there’s any other way!
BTW, /Zp# doesn’t really solve the problem.

Have you got any plans to release those SDL MSVC project files? That would
really rock and make my life easier.

Sam said there’ll be a seperate archive containing the project files to drop
in into the SDL sources .
I’ll send him the project files when I get the final sources for 0.8 because
it’s no use changing the
files every sub-sub-release (or is 0.8f already the final code?)
Is this Ok?

— Paulus Esterhazy

12

Also, with MIDI support, do you just want something like
SDL_PlayMidiFile(filename) or do you want support support for pausing,
stopping, playing backwards etc?

We need at least “play”, “stop”, “pause” … anything else anyone?
(I’m not that familiar with MIDI)

Hmm… what about choosing which synth to use? SDL_ListSynth() and
SDL_ChooseSynth(). SDL_DemangleSynth() which should be called after the pause
routine :wink:

Is anybody familiar with the MIDI interface on non-Linux systems? It is quite
basic on Linux.On Thu, Sep 17, 1998 at 09:31:05AM -0700, Sam Lantinga wrote:

–
– Michael Samuel

13

I’m going to release SDL 0.8 as a stable release.

From then on, SDL development will be similar to that of the Linux kernel:
SDL 0.8, 1.0, 1.2, etc. will be bugfix only releases, and SDL 0.9, 1.1, 1.3,
etc. will be “development” releases where we experiment and extend SDL.
In this way, those who need a stable release with bugfixes can use the
even numbered versions of SDL, and those who want to play with new ideas
can use the odd numbered developer releases.

If this is going to be the case, would it be possible to name the SDL
libraries with a consistant soname? By that I mean, could we make sure
that SDL is well-behaved enough to have both the “stable” and
"development" versions on the same machine? I know several libraries
(I won’t name any names) make no allowences for anyone wanting to run
both and therefore they don’t work well at all if you’ve EVER tried to
install both.

Okay, that said, I have a big list of ideas for SDL that I need help with.
The projects are:
Joystick support
MIDI support
CD-ROM audio control
Port to MacOS

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.

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. :slight_smile: 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. :stuck_out_tongue:

I also would like to get volunteers for compiling binaries when a major
release of SDL comes up. We need compilers for all the games on the
download page on all the platforms:

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.On 16 Sep, Sam Lantinga wrote:

–

| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

14

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.On 18 Sep, Michael Samuel wrote:

Hmm… what about choosing which synth to use? SDL_ListSynth() and
SDL_ChooseSynth(). SDL_DemangleSynth() which should be called after the pause
routine :wink:

–

| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

15

Software synth has a lot of overhead. The OSS kernel driver now has a software
synth in 2.1.x, and there are plenty of these for 'doze hanging around, so
it isn’t worth the effort, as those drivers should appear as another synth
device if the user has the spare CPU an RAM to handle it.On Thu, Sep 17, 1998 at 08:21:20PM -0600, kwalker at aros.net wrote:

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.

–
– Michael Samuel

16

It shouldn’t be too hard to do with Mesa, as it can render to an X
pixmap…
What would be the point?
I really want to know, because it keeps coming up, and I’d like to know
what advantages it would have.

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

I believe that Microsoft’s opengl32.dll uses DirectDrawSurface to render
to, so that it gets as much hardware acceleration as it can…
Am I making sense? :slight_smile:

I can do Win32/x86 binaries, and Linux/x86/libc5
I think Michael can do Linux/x86/glibc
I’ll definitely ask you if we need more help. :slight_smile:

Heh, thought so :slight_smile:

-Erik Reid______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

17

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.

DSP routines would be nice to have, I’m willing to work on them, but
again, my coding abilities aren’t great, and I’ve had a lot of trouble
finding good docs on doing any software DSP :frowning:

-Erik Reid______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

18

Hi there…
Chuck Homic wrote:

(Is it true that MSVC doesn’t have an equivalent
for the __attribute(pack) directive, instead you have to surround stuff with
#pragma pack(1) #pragma pack()?).

You can specify the alignment in the command line. I think using /Zp1,
/Zp4, etc… I don’t think this is well documented. But just throw
whatever alignment you need in the makefile and you should be all set.
-Chuck

Yeah, but that breaks about 17 other things (eg certain dlls).

PITA.

:slight_smile:
Peter

19

Not more than a couple of megs if done right. The only software
wavetable experience I have is CubicPlayer for DOS, Timidity for Linux,
and a program called WinGroove for Win3. The sound was actually really
nice, and Cubic played just fine on my 486/100, back before I really
used Linux.

But again, that’s all in the implementation.On 18 Sep, michael at surfnetcity.com.au wrote:

Software synth has a lot of overhead. The OSS kernel driver now has a software
synth in 2.1.x, and there are plenty of these for 'doze hanging around, so
it isn’t worth the effort, as those drivers should appear as another synth
device if the user has the spare CPU an RAM to handle it.

–

| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

20

kwalker at aros.net wrote:

Software synth has a lot of overhead. The OSS kernel driver now has a software
synth in 2.1.x, and there are plenty of these for 'doze hanging around, so
it isn’t worth the effort, as those drivers should appear as another synth
device if the user has the spare CPU an RAM to handle it.

Not more than a couple of megs if done right. The only software
wavetable experience I have is CubicPlayer for DOS, Timidity for Linux,
and a program called WinGroove for Win3. The sound was actually really
nice, and Cubic played just fine on my 486/100, back before I really
used Linux.

But again, that’s all in the implementation.

Yep, but that’s an OS service really… If the OS doesn’t support it (even Winblows
does, so what hope have we if it doesn’t?) If not, we should just plug one of those
implementations into the SDL (but not include it as a default option).

Hmmm… Wingroove. I remember cracking that. It had a lovely serial number
algorithm. That was before I discovered free software (I am a reformed character
now…) :slight_smile:

:slight_smile:
Peter> On 18 Sep, michael at surfnetcity.com.au wrote:

–

| |/ | | | _ | | | mailto:kwalker at aros.net |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/