Re: [AD] Feature-freeze?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Wed, Mar 24, 2010 at 4:20 PM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
So, April 1st is approaching (again) and A5 is still almost done.
Perhaps it's time to think about feature-freezing the branch sometime soon, so it's clear what we'll be releasing as 5.0? It'll hopefully convince more people who are "waiting for it to mature enough" to actually try it.

One feature I think we still need:

- Capabilities querying API. Among others it should report:

ALLEGRO_HAVE_SET_BITMAP_TARGET

If this is not available, al_set_target_bitmap cannot be (reasonably) used except for using our software rasterizer for drawing to memory bitmaps.

ALLEGRO_HAVE_SET_SEPARATE_ALPHA_BLENDER

If this is not available, al_set_separate_blender cannot be used (it will just ignore the alpha values passed in and work like al_set_blender otherwise).
 
The only feature I'd like that we don't have right now is the gestures that was discussed earlier, but it can wait for 5.2 (or 5.0.2+ if we allow new features in the 5.0 branch that don't break old code; there's no reason they should anyway).

New iphone OS (the one which also will be on IPad) has those gestures now. The problem is it will be messy for which version we are going to support. 3.2 will have gestures everything below not. Also new iphones and IPad have OpenGL 2.0 (so for example separate alpha blenders) while old devices only have OpenGL 1.0, independent of the OS version :P Anyway, it's not one of our main platforms so not relevant for the release.
 
The feature-freeze would lock the current division between core and addons and what addons we'll be including (should probably wait doing that until the current work on the transformations and primitives is done). If there are still API issues that need to be fixed, that's not a feature. :P

Features that are currently in but not implemented on all platforms are:
 * pressure field in mouse struct, works on OS X, but not anywhere else?
 * "fullscreen windows", work in X11 but not anywhere else. Personally I'm still not entirely enthusiastic about this (it still feels like you should just ask for a fullscreen mode the size of the desktop) but that's beside the point (it's there, so that's done). I do have a question about this that I'll come to below.


It works in Windows and is just as important there. I'm sure there's a few Windows games who actually let you choose between real and fake fullscreen (I only saw it in WinUAE running in Wine recently), or automatically create a fullscreen-window when you choose the desktop resolution. Fast Alt-Tab and additional monitors just can be a huge advantage, like for having a walkthrough or gmail or something open on the other monitor while playing fullscreen.
 
Things that people have volunteered to contribute but that are still pending (so someone may need to be chased up on these):
 * Shader addon

Dario (I think) seems to have hit a stumbling block with enabling texture stages or something. It would be really nice to have of course, but we could release 5.0 without it.
 
 * MAXIMISED_WINDOW flag?


Should be simple to do in X11. My use case is if I exit my level editor while maximized, I'd like it to start maximized again the next time - but didn't get to work on my editor for some time hence the feature was not added either :P
 
Things that are broken that need to be fixed:
 * Fullscreen X11 driver (?)

It's just hard to do because it depends so much on the driver. With the nvidia drivers on my setup at home FULLSCREEN_WINDOW is the only viable solution as non-native resolutions use crappy scaling built into the monitor and the gfx card can do much better scaling for free with native resolution.
 
 * TTF addon on iPhone (?)

*Should* be easy the problem will just be the few crucial details which make it not work right now...
 
 * Cmake build system for iPhone (?)

I was looking at this 2 more times, spent close to 20 hours on it in total I guess... it *is* possible but I just don't have the time. The issues are:
- one solution works only with makefiles (the one guide which comes up most often in google) but if cmake doesn't create the xcode project we need to maintain that one manually anyway so useless for us
- the Ogre solution creates an xcode projects, but requires post-processing with a python script, and make doesn't work from what I've seen

Also, both will require some amount of fiddling to get things like the examples and resources to properly install on the device/simulator.
 

Parts of the API that still need some work:
 * It's still wrong to me that the primitives addon has a separate colour struct. I know why it's there, but it should go. Maybe it can be merged with Allegro's regular colour struct (on Windows, is it even needed anywhere else?).

Anything I've missed?

The question I have about fullscreen windows has to do with what the fallback position should be if you can't make a "fullscreen window". Does al_create_display() fail? Does it create a normal window instead? Does it create a fullscreen display the size of the desktop? I can argue why I'd expect it to do any of those three things. Actually, what vtable function is called internally? I'm guessing it's the one that creates a windowed display?


Fullscreen windows can never fail in X11 (Allegro itself chooses the size after all) and I'd hope the same is true for Windows.
 
As for a time-line. How about feature-freezing after the next WIP release (in April, I guess)? That way anyone who still really wants feature X can rush it in for platform Y before then and we can fix it for all other platforms afterwards. Anything that doesn't get in by then gets pushed back to post 5.0, full stop, end of discussion. :)

Thoughts? Gut-reactions? Counter-arguments? Alternative timelines?


While I kinda don't like a feature freeze, I know that it's necessary if we ever want to get 5.0 out. Feature freeze after next WIP sounds good to me.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/