Questions on SDL 2.0 API specification

SDL Development
1

I guess it’s not ready yet for comments, but I’m so excited I already
have questions about it :slight_smile:

millisecond accurate time querying
Why not more precise where possible? With functions to query max
precision and a default precision of 1 ms?

The memory module is a simple interface to the stdlib memory functions
Then why have it as a module?

Why does the Video module depend on input? I guess it’s to accomodate
for the input devices included in the module… But what kind of device
couldn’t be handled by the input module?

Shouldn’t Input & Audio modules depend on settings?

When the architecture will be fixed, will you implement it alone or will
you accept any help?

-Ga?tan.

2

When the architecture will be fixed, will you implement it alone or will
you accept any help?

I’ve been anticipating SDL 2.0 very much as well. I’m specially concerned
about the integration of Input+Threads+Multiple Displays.

I’m using SDL as the foundation of a framework that abstracts input/output
devices/systems for VR applications.

Multiple displays are a must-have for us, and we chose SDL because of the
its “promise” of supporting multiple displays in version 2.

The design of SDL 2.0 may promote our project or force us to choose another
solution for platform independent multimedia support.

I don’t know how the SDL 2.0 design process is taking place, or even if it
has begun, but we’d love to get involved in it. How?

Comments are most appreciated! :slight_smile:

Thanks,
Thiago Bastos

3

When the architecture will be fixed, will you implement it alone or will
you accept any help?

I’ve been anticipating SDL 2.0 very much as well. I’m specially concerned
about the integration of Input+Threads+Multiple Displays.

I’m using SDL as the foundation of a framework that abstracts input/output
devices/systems for VR applications.

Multiple displays are a must-have for us, and we chose SDL because of the
its “promise” of supporting multiple displays in version 2.

The design of SDL 2.0 may promote our project or force us to choose another
solution for platform independent multimedia support.

I don’t know how the SDL 2.0 design process is taking place, or even if it
has begun, but we’d love to get involved in it. How?

Comments are most appreciated! :slight_smile:

You know what worries me about this discussion? Everyone seems to have
favorite feature they want to see in SDL 2.0, but the current design of
SDL is concept driven, not feature driven. When a design becomes feature
oriented you wind up with something ugly. While adding, modifying,
extending, and generalizing concepts gives you a simple clean design.

I would like to see the SDL concept of a display/window be generalized
so that an SDL application can be written with more that one display and
with less than 1 display. I would like the SDL event system extended to
provide better support for user defined events. Of course, both of those
requests are really requests that SDL be more extensible than it already
is. I’ve identified two ways in which SDL could be made more extensible.
Please suggest other ways.

And of course, never forget that Sam has the final say in all of this.
In fact, this whole discussion could be considered to be completely off
topic.

	Bob PendletonOn Wed, 2003-03-12 at 15:42, Thiago Bastos wrote:

Thanks,
Thiago Bastos

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+

4

I was expecting more people would reply to this topic.

You know what worries me about this discussion? Everyone seems to have
favorite feature they want to see in SDL 2.0, but the current design of
SDL is concept driven, not feature driven. When a design becomes feature
oriented you wind up with something ugly. While adding, modifying,
extending, and generalizing concepts gives you a simple clean design.

Adding, modifying, extending… from seeing SDL’s CVS webpage that seems to me the way SDL has been being developed, mostly by contributions from the community. From my perspective, however, that methodology does not fit well when we need more serious redesigns (which I think is the case if SDL is to support multiple displays and the like).

I could add multiple displays support to SDL myself and then send my changes to Sam, but I’d be taking a high risk. My design/implementation could be a waste, or at least be something that could have been much better if more experienced SDL users had contributed to its design. That’s the reason for my interest on participating of a committee instead of contributing with patches.

I don’t even know if someone else has been working on multiple displays for SDL. No one mentioned how the SDL 2 (or 1.3) design process is taking place, yet. Would anyone care to tell a newcomer how things work here?

I would like to see the SDL concept of a display/window be generalized
so that an SDL application can be written with more that one display and
with less than 1 display. I would like the SDL event system extended to
provide better support for user defined events. Of course, both of those
requests are really requests that SDL be more extensible than it already
is. I’ve identified two ways in which SDL could be made more extensible.
Please suggest other ways.

I don’t think this topic is the best place to start brainstorming concepts for SDL2, I’d rather start a new topic or even meet in IRC with some of you to discuss more interactively. But… grins

I think SDL should make better use of its multi-threading functions in version 2. SDL’s event structures could get an extra “displayId” field, and all events could be centralized in one event-handling thread. Each display could have its own separated rendering thread. On the other hand the design should allow one to continue developing with a single thread and a single display, maintaining compatibility with limited platforms.

SDL should continue to be simple and maintain compatibility with consoles and limited platforms, but it also should make good use of advanced functions available in modern computers. So I’d like to see SDL_WaitEvent using system-specific synchronization primitives instead of SDL_Delay, etc.

And of course, never forget that Sam has the final say in all of this.
In fact, this whole discussion could be considered to be completely off
topic.

I’m aware of that, in fact I’d love to hear some feedback from him regarding this discussion.

Best regards,
Thiago Bastos

5

I was expecting more people would reply to this topic.

You know what worries me about this discussion? Everyone seems to have
favorite feature they want to see in SDL 2.0, but the current design of
SDL is concept driven, not feature driven. When a design becomes feature
oriented you wind up with something ugly. While adding, modifying,
extending, and generalizing concepts gives you a simple clean design.

Adding, modifying, extending… from seeing SDL’s CVS webpage that seems to me the way SDL has been being developed, mostly by contributions from the community. From my perspective, however, that methodology does not fit well when we need more serious redesigns (which I think is the case if SDL is to support multiple displays and the like).

I could add multiple displays support to SDL myself and then send my changes to Sam, but I’d be taking a high risk. My design/implementation could be a waste, or at least be something that could have been much better if more experienced SDL users had contributed to its design. That’s the reason for my interest on participating of a committee instead of contributing with patches.

I don’t even know if someone else has been working on multiple displays for SDL. No one mentioned how the SDL 2 (or 1.3) design process is taking place, yet. Would anyone care to tell a newcomer how things work here?

I would like to see the SDL concept of a display/window be generalized
so that an SDL application can be written with more that one display and
with less than 1 display. I would like the SDL event system extended to
provide better support for user defined events. Of course, both of those
requests are really requests that SDL be more extensible than it already
is. I’ve identified two ways in which SDL could be made more extensible.
Please suggest other ways.

I don’t think this topic is the best place to start brainstorming concepts for SDL2, I’d rather start a new topic or even meet in IRC with some of you to discuss more interactively. But… grins

Why not? Where do you want to concentrate? So far you have concentrated
on specific features rather than general concepts. Concentrating on
features gets you a bowl of spaghetti.

I think SDL should make better use of its multi-threading functions in version 2. SDL’s event structures could get an extra “displayId” field, and all events could be centralized in one event-handling thread. Each display could have its own separated rendering thread. On the other hand the design should allow one to continue developing with a single thread and a single display, maintaining compatibility with limited platforms.

You contradict your self here. A centralized event handler implies a
single controlling thread. While having separate rendering threads for
each window implies distributed event processing.

On the other hand, I have already threaded event processing library to
solve the problem you mentioned with the current event processing model.
http://gameprogrammer.com/game.html

I would like to see the SDL event model generalized to include IO and
timers.

Seriously though, there is very little that I would change in SDL.

		Bob PendletonOn Fri, 2003-03-14 at 18:32, Thiago Bastos wrote:

SDL should continue to be simple and maintain compatibility with consoles and limited platforms, but it also should make good use of advanced functions available in modern computers. So I’d like to see SDL_WaitEvent using system-specific synchronization primitives instead of SDL_Delay, etc.

And of course, never forget that Sam has the final say in all of this.
In fact, this whole discussion could be considered to be completely off
topic.

I’m aware of that, in fact I’d love to hear some feedback from him regarding this discussion.

Best regards,
Thiago Bastos

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+