- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)Done...
Great, then I won't touch it until you're ready. No need to duplicate work...
but I don't know how to test it. Any game that is known to require it and work with 3.2? KQ3 has video intro, but it worked before... through apeg/Theora, I suppose.
So far I haven't noticed it missing anywhere either - and I couldn't test my quick-and-dirty one-liner approach (system("mplayer whatever");") either.
- redesign audio support to use gstreamer, so audio will work properly on all platformsWould be nice. But isn't audio working already?
It is -- it's using almp3/alogg/apeg/libcda, which is a bit of a mess (too many different bits), but it works everywhere. It's a bit less messy now that I've adapted it to use current mpg123 rather than the old internalized copy.
(And I'd argue anything using gstreamer would be a bit of a mess as well, while it works well, I think gstreamer's code is rather awful. But then I'm somewhat biased, I tend to think anything that uses glib is broken by design)
- create ags plugin support on linux & macI don't know how the ags plugin system works. But even if added for linux & mac, I suppose already existing plugins wouldn't work since they are compiled for Windows, aren't? They could depend on Windows only libraries... and IIRC the C++ ABI is just different there.
There could be a way to do it by stealing wine's PE loader and most of wine's libraries, but then there wouldn't be much of a point in having AGS natively in the first place because people could just use all of wine. (And of course any attempt to do that on non-x86 Linux (the rest of AGS should work on ARM...) would be doomed to fail.)
It's probably best to just provide an identical API so people can just recompile their plugins to any platform (preferrably releasing the source so people on *BSD, Solaris and whatever can build their own).