Pre-release binaries

At the directory
http://www.devolution.com/~slouken/SDL/new/release/

You can get the following files:
SDL-1.0.0-1.alpha.rpm
SDL-1.0.0-1.i386.rpm
SDL-1.0.0-1.ppc.rpm
SDL-1.0.0-1.sparc64.rpm
SDL-1.0.0-1.src.rpm
SDL-1.0.0-VC++.zip
SDL-1.0.0-beos.zip
SDL-1.0.0-mingw32.tar.gz
SDL-1.0.0.tar.gz
SDL-1.0.0.zip

Barring any serious errors, these are the final 1.0 archives.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Is the new version going to have joystick support? …nudgenudge… =)On Tue, 30 Nov 1999, you wrote:

At the directory
http://www.devolution.com/~slouken/SDL/new/release/

You can get the following files:
SDL-1.0.0-1.alpha.rpm
SDL-1.0.0-1.i386.rpm
SDL-1.0.0-1.ppc.rpm
SDL-1.0.0-1.sparc64.rpm
SDL-1.0.0-1.src.rpm
SDL-1.0.0-VC++.zip
SDL-1.0.0-beos.zip
SDL-1.0.0-mingw32.tar.gz
SDL-1.0.0.tar.gz
SDL-1.0.0.zip

Barring any serious errors, these are the final 1.0 archives.

-Garrett, WPI student majoring in Computer Science.

“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert Einstein

Is the new version going to have joystick support? …nudgenudge… =)

Nope, that’s post 1.0
It’ll get done faster if there is Win32 and BeOS support. … nudgenudge =)

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Ack, I vowed never to code in windows again after coding in linux for a
month. As for BeOS, I’ve never even used that. Looks interesting though,
although I have no hd space for it…

-Garrett, WPI student majoring in Computer Science.

“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert EinsteinOn Tue, 30 Nov 1999, you wrote:

Is the new version going to have joystick support? …nudgenudge… =)

Nope, that’s post 1.0
It’ll get done faster if there is Win32 and BeOS support. … nudgenudge =)

Nope, that’s post 1.0

Is there any, even vague, list of what is planned for upcoming releases?
Just curious how you see SDL developing.

NeilOn Tue, 30 Nov 1999, Sam Lantinga wrote:

Neil McGill mailto:Neil_McGill *8^) . .
Software Developer:ISDN, Cisco Systems Ltd ~~""~""~"~"|~"~
3rd Floor, 96 Commercial Street, Edinburgh, EH6 6LX, UK ||| |||
Tel: 0131 561 3622 Fax: 0131 561 3601 Mob: 07714 226 281 .:|||||:.:|||||:.

Nope, that’s post 1.0

Is there any, even vague, list of what is planned for upcoming releases?
Just curious how you see SDL developing.

Well, among other things, upcoming releases will have joystick support,
some form of OpenGL support, more assembly optimization, and better
framebuffer console support.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Tue, 30 Nov 1999, Sam Lantinga wrote:

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Is the new version going to have joystick support? …nudgenudge… =)

Ooh! :slight_smile: :slight_smile: :slight_smile:

And what about Paddles? (Ok, coming out of the pipe dream :slight_smile: )

-bill!

nudgenudge… =)

I was thinking, the way to get joystick information in windows is to call the
GetDeviceState() function which fills out a struct its passed with data every
time its called. So how would SDL do polling for something like this? I can’t
see it running in a tight thread in another loop, that would be a waste of CPU.
How often would SDL poll the joystick in windows?

-Garrett, WPI student majoring in Computer Science.

“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert EinsteinOn Tue, 30 Nov 1999, you wrote:

Is the new version going to have joystick support?

It would poll the joystick along with the other windows messages,
which is done whenever you call SDL_PollEvent() or SDL_WaitEvent()

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Tue, 30 Nov 1999, you wrote:

Is the new version going to have joystick support?
nudgenudge… =)

I was thinking, the way to get joystick information in windows is to call the
GetDeviceState() function which fills out a struct its passed with data every
time its called. So how would SDL do polling for something like this? I can’t
see it running in a tight thread in another loop, that would be a waste of CPU.
How often would SDL poll the joystick in windows?


“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

So it would call the joystick function everytime you call SDL_PollEvent()?
What happens if you do something like

while(SDL_PollEvent(&event))
{
/* proccess events */
}

where the program keeps calling PollEvent and proccessing events if PollEvent
returns 1? If PollEvent polled the joystick each time its called, it would
always get joystick info, and thus PollEvent would return 1 and you would be in
an infinite loop.

-Garrett, WPI student majoring in Computer Science.

“He who joyfully marches in rank and file has already earned
my contempt. He has been given a large brain by mistake, since
for him the spinal cord would suffice.” -Albert EinsteinOn Tue, 30 Nov 1999, you wrote:

On Tue, 30 Nov 1999, you wrote:

Is the new version going to have joystick support?
nudgenudge… =)

I was thinking, the way to get joystick information in windows is to call the
GetDeviceState() function which fills out a struct its passed with data every
time its called. So how would SDL do polling for something like this? I can’t
see it running in a tight thread in another loop, that would be a waste of CPU.
How often would SDL poll the joystick in windows?

It would poll the joystick along with the other windows messages,
which is done whenever you call SDL_PollEvent() or SDL_WaitEvent()

So it would call the joystick function everytime you call SDL_PollEvent()?
What happens if you do something like

while(SDL_PollEvent(&event))
{
/* proccess events */
}

where the program keeps calling PollEvent and proccessing events if PollEvent
returns 1? If PollEvent polled the joystick each time its called, it would
always get joystick info, and thus PollEvent would return 1 and you would be in
an infinite loop.

Details. Someone write it first. :slight_smile:
Seriously, you’d only signal a joystick event if the joystick state
had changed significantly.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Details. Someone write it first. :slight_smile:
Seriously, you’d only signal a joystick event if the joystick state
had changed significantly.

Would there be a way to tell SDL how “significant” something would have to
be?

-bill!

Details. Someone write it first. :slight_smile:
Seriously, you’d only signal a joystick event if the joystick state
had changed significantly.

Would there be a way to tell SDL how “significant” something would have to
be?

Of course. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Some thoughts on generalizing input devices. For input devices other
than the keyboard and mouse I can think of only two “types” of input,
the first being state based, the second being displacement. State based
input includes things like joystick buttons, mouse buttons, puck
buttons, toggle switches, or any other piece of input that takes a
finite (not necessarily 2) number of functionally distinct states. The
displacement based includes mouse movement, joystick movement, gamepad
movement, etc. This input consists of an n-dimensional vector, with
integer componenets. So based on these thoughs a general device
descriptor and data structure could be:

struct InputDevice {
int stateInputCount;
StateInput *stateInputs

int displacementInputCount;
DisplacementInput *displacementInputs;
};

struct StateInput {
int stateCount;
int currentState;
};

struct DisplacementInput {
int dimensions;
int *offsetVector;
};

The programmer could then set up some sort of dynamic binding (ala
quake) for whatever input device was attached. Additional functions
needed:

int CountInputDevices();
InputDevice GetInputDevice( int number );

Comments?

Stuart.