Yeah it does look like a massive project, but I was drooling as I read the list - Multiple windows? Rumble pad? Multiple mice? OpenGL acceleration? Heck yeah! If no one snaps it up, will pgreloaded convert to SDL 1.3?
On Wed, Apr 1, 2009 at 8:17 AM, Tyler Laing <[email protected]> wrote: > 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 > -- - pymike
