Allegro roadmap
From Allegro Wiki
Contents |
[edit] Roadmap for 5.0
[edit] Naming
Allegro 5.0 was too ambitious. We have decided to cut down on the things that need to change before we call it 5.0. [Actually, we knew it before and had decided on a transitioning path with the 4.4, 4.6, etc. leading up to the ultimate 5.0. It's partly a marketing/psychological thing to rename 4.4 to 5.0, but the jump from 4.2 to the next stable release would have been the biggest in terms of change, so a major version bump is also the right thing to do.]
What was formerly known as the 4.3 branch (before 2007-05-12) will now be known as the 4.9 branch. The stable branch arising from that will be 5.0. The two unstable releases 4.3.0 and 4.3.1 can be considered 4.9.0 and 4.9.1, so the first actual release of the 4.9 branch will be called 4.9.2.
[edit] Direction
What will be included in 5.0 are new interfaces for the following areas:
- inputs (done)
- events (done)
- display (almost spec'd)
- graphics
- initialisation
Optionally:
- fshooks (partially done)
- sound (implementation exists but not integrated)
For the display interface, our goals are to support:
- ability to use OpenGL commands
- multiple windows
- resizable windows
- abstract away display update details (double buffering, etc.)
[edit] Status of subsystems
The inputs and events interfaces are done and documented. The interfaces could be tweaked a little (e.g. renamings) or extended (e.g. user events) but otherwise it's there and has been for a long time.
The display interface has an incomplete spec: Display. We don't expect any big changes from here on in.
For the graphics interface we will start from Bob's original graphics API proposal. However, it was too ambitious and complex. We will divide it up into smaller subsections and discard some of the things that don't seem so useful.
For 3D graphics our assumption is that users will be using Allegro alongside OpenGL (or other library on top of OpenGL). For 2D graphics we may similarly defer to a graphics API such as cairo. In that case the Allegro graphics API can be much smaller and manageable for us.
For file system hooks (fshooks) the plan is to provide an interface in which users can plug in support for things like zip archives, etc. We will only provide basic stdio operations.
We have always intended to drop asm code. Asm code is an extra maintenance burden, becomes bit-rotted often and equivalent C code tends to perform roughly as fast if not faster than outdated asm code. Allegro is almost buildable on all platforms without asm at all (the last holdout was the Windows port and that will be rectified very soon). We've also had some nice work from people improving the C drawing routines to match the speed of the asm routines. Everything is going nicely on this front. This is now done.
See also New API.
[edit] Current tasks (5.0)
These are the immediate things that are currently being done (or should be done).
- finish the display API spec (this is pretty solid by now)
- start implementing display API on different platforms (done)
- write the gfx API spec
- write an initialisation API spec
- integrate and document fshooks framework
- write stdio fshook driver
Optionally:
- write sound API spec
- integrate sound API implementation
- write sound drivers
[edit] Roadmap for 4.2/4.4
We will incorporate AllegroGL into the 4.2 branch and the stable branch of this will be called 4.4. AllegroGL would still be built as a separate library with its own include files, etc. The difference is that users don't need to download a separate package and build it separately. Allegro 4.4 will still be buildable without AllegroGL, but it will make things easier for users who need both libraries.
We will reuse the "4.3" name for the unstable development branch for 4.4. The first release of the new 4.3 branch will be 4.3.10, to make it obvious there is a discontinuity between 4.3.1 and 4.3.9. This has been released.
Very popular addons like loadpng and jpgalleg may also be bundled for 4.4. These would continue to be built as separate libraries and only be built if the user asks specifically for them (or autodetected by the build system). We would not bundle libpng/zlib or other 3rd party libraries with Allegro unless they are extremely small. We do not want the responsibility of integrating their build systems into ours. Users must have installed any dependencies if they want those addons, as with AllegroGL support. This has been done.
The Nintendo DS and gp32 ports Allegro could and probably should be integrated into the main Allegro tree for 4.4 or later. The 4.6, 4.8, etc. branch names are available for any later generations who may wish to continue the 4.0/4.2 legacy.
- will be C-only by default (done)
- will include Amiga port (nothing heard from Amiga port author for ages so unlikely)
- will include Nintendo DS port (probably unlikely also)
