That looks like an absolutely huge project, I have to admit. It would probably take a student like me a large part of the time just getting the basics to work, because they'd have to modify intensely the internals and the API of pygame. Then there's the issue of when the summer is over, such a port would work well if the student sticks around. But you guys have mentioned the issues with that already.
Just saying that from my perspective, that is a project, but I could very easily be wrong. -Tyler On Wed, Apr 1, 2009 at 2:12 AM, René Dudfield <[email protected]> wrote: > hello, > > An important project for gsoc could be to port pygame to SDL 1.3 > > If anyone wants to make a proposal for this, it would be important to > list the new features of SDL 1.3 that need to be wrapped, and tested. > > > Below are some of the planned features - many of which are implemented > already. The project should try and target the stable parts of the > API - since SDL 1.3 is still in development (but is getting closer to > being ready). > > A first step would be to get it working at all - then to start > wrapping new functionality. > > It's probably easier to start with the pygame 1.9x rather than > pgreloaded - since pgreloaded lacks tests... but to wrap new stuff for > pgreloaded (since it's cooler than new pants). > > > cu, > > > > - Multiple windows! You don't need to have a single video surface > anymore! > This is a new API (but SDL_SetVideoMode() still exists in the > compatibility layer). > - Multiple displays: SDL exposes details of what physical monitors are > hooked up to a machine and lets you control them individually. > - Formal API for positioning SDL windows: it sort of comes with the > multiple window/display support. No more setting environment variables > for this! > - Video device enumeration: you can get an idea of what APIs and > hardware > are available to you. > - 2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with > the 2D interfaces, so we can get acceleration on modern systems where > X11 or DirectDraw just aren't the fast paths anymore. The framebuffer- > oriented interfaces, like X11, are still there, though, for legacy > platforms and hardware. > - Texture support: the 2D interfaces now concern themselves with > "textures" > and not surfaces. The assumption is that, even in 2D graphics, you now > want to try to push all the effort to the hardware when you can, > falling back to software where you can't. On the most basic level, > this > just means you can't get at pixel-based framebuffers without locking > the "texture" and doing so may be much more expensive than in 1.2, but > in many common scenarios, a well-designed program can be significantly > more efficient in 1.3. There are some basic texture operations to > offload > common per-pixel operations to hardware so you may not have to lock > the > texture and do it yourself. This is meant to be a very simple API, > however: those needing more, even in 2D, should consider using OpenGL > directly. > - Multiple input devices: we'll be merging ManyMouse into SDL, which > will let us handle input from more than one connected mouse on at > least > Linux, Mac OS X, and Windows. If all you care about is the usual > generic > pointer input, that'll still work, too, but if you want to make a game > where all your friends plug in a USB mouse and compete, that'll now be > possible. This is also interesting for experimental work that has > nothing > to do with games, or Photoshop-style things that want mice AND pens, > etc. > - Pressure/tilt support: mouse-like input devices like tablets will be > able to report their pressure/tilt through SDL, for those that want to > write art programs. TuxPaint, I'm looking at you here. > - Horizontal mousewheel events: SDL 1.2 only responds to the oldschool > vertical mousewheel, but many mice you buy now can scroll > horizontally, > too, including the Mighty Mouse that ships with Apple desktops. > There's > a formal event for this in SDL 1.3. > - Mousewheel no longer looks like a button: SDL 1.2 treats wheelup as > button 4 and wheeldown as button 5. This was an accident of history, > since XFree86 mapped the wheel to these buttons back when Loki had an > interest in making this work Right Now, but it wasn't guaranteed to be > those buttons, and it never was on other platforms. These have been > moved to formal events in 1.3. > - Separation of text input and key events: Basically, we're fixing the > Unicode support. The keyboard can be treated as a 101-button gamepad > with the usual KEYUP/KEYDOWN events, but there will be separate > events for text input, so IME implementations can let users compose > characters as they'd expect to on their platform. This will replace > the > "unicode" field in 1.2 key events, which was universally unreliable > once you stepped outside of America and Europe. > - Formal API to permit screensaver: no more environment variable hack! > This is useful if you're writing a windowed application and not a > game. > > Audio: > - Audio capture support: You can record from a microphone, etc, and > recover > this data through SDL. > - Audio device enumeration: You can find and choose specific audio > devices. > - Multiple audio device support: You can open multiple devices and > playback > different audio from each at the same time. Take all these things and > you could, for example, have a game where the audio plays through a > set of speakers, but speech from your teammates comes to a USB headset > while you reply through a microphone...and probably other interesting > things we haven't thought of yet. > - Audio device disconnect notification: if someone accidentally kicks > out > their USB audio widget, the app can be notified, so they can pause and > let the user get reconfigured, etc. > - Support for PCM data in int32 format. > - Support for PCM data in float32 format. > - Non-power-of-two resampling. If you had to do something other than > double or halve your sample rate, SDL 1.2 would break (and probably > corrupt memory). This will be fixed in SDL 1.3. This is useful for > programs that worked fine with data at 22050Hz when everyone was using > audio cards at 11025Hz, 22050Hz, or 44100Hz, but now there are a lot > of > motherboard cards that only eat at 48000Hz and break badly in 1.2. > - 7.1 output support. > - Macros to parse audio format enumerations. > No more need to do things like this: > const int bitsize = MyAudioFormat & 0xFF; > Now you can do the more readable: > const int bitsize = SDL_AUDIO_BITSIZE(MyAudioFormat); > (...and others like this.) > - SDL_MixAudio() won't need an open audio device: In SDL 1.2, you could > only mix audio buffers based on the opened device format. This has > been > changed to a generic interface in SDL 1.3 that allows mixing data > without > dependency on a specific device, or a device at all. > - Better audio format converters: these should be faster and work > better, > since we generate all the possible cases in a perl script now instead > of > trying to tapdance at runtime. This means converting a buffer takes > one > pass regardless of format, instead of a pass to change bitsize, > another > to change the format, another to change the signedness, etc. This is > cleaner to maintain and extend, and doesn't thrash the CPU cache as > much, > etc. > > Joysticks: > - Connect notification: In 1.2, you needed to restart the > joystick subsystem to find new sticks. In 1.3, your friend can walk up > and plug in his controller, and your game will be able to announce "a > new challenger approaches!" > - Disconnect notification: ...and you'll also be able to deal with the > controller getting kicked out midgame, or your friend getting tired of > losing and leaving with his controller. > - Force feedback: sticks and platforms that support vibration, rumble, > etc, > will be controllable via SDL. > > SDL_main: > - No longer required on any platform. Now it does what it was intended > for: hiding differences in main/WinMain/etc. Initialization details > are being moved into SDL_Init() where they belong. This makes it > easier > to have SDL as a plugin, or use a non-SDL path without it hijacking > your > mainline just to function. This is really useful for scripting > languages, > since, say, a Python program might want to use SDL without linking > SDL > directly to python.exe and replacing its main() function. > > Misc: > - Atomic operations API: a way to deal with atomic operations like > test-and-set and compare-and-swap will be added. This is becoming > increasingly important in game development, and every processor and > platform handles this differently, so it'll be nice to abstract the > details into SDL. > - SDL_KillThread() is gone. It was never safe or portable. The function > will continue to exist for binary compatibility, but it will always > be a no-op that reports failure. If you need this, your program has > problems anyhow and needs minor reworking to cleanly handle thread > termination, even if KillThread was still available. > > Planned but not yet fully considered: > - Some minor cleanups and clarifications to the RWOPS api are planned > to fill some gaps, but this is still work in progress. > - A basic API to read/write from the system clipboard would be nice. > - A basic API to support drag'n'drop with the system would be nice. > - Probably other stuff! Let Ryan know what you want! > > > > cheers, > -- Visit my blog at http://oddco.ca/zeroth/zblog
