Re: [AD] Organizing an Allegro Hack Day |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] Organizing an Allegro Hack Day
- From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
- Date: Sat, 07 Apr 2007 12:39:44 +0200
In case I'm otherwise occupied atthe time of the meeting, here are some of
the main things I have to say.
* 4.2 branch (only bug fixes allowed?)
My position is yes, only bug fixes allowed. For a variety of reasons:
testing of new functionality, possibility of introducing new bugs,
backward compatibility in the compatibility layer of 4.3, time taken away
from 4.3 development. For some things (resizable windows, multiple
windows) patches/hacks existed during the 4.1 series and they were
rejected (either by consensus or by lack of genuine discussion) on the
ground that it would be better to do a more proper implementation of them
when overhauling the graphics drivers anyway. If we had wanted to
implement things liek this in 4.2, then that would have been the proper
time to do it. Let's be honest: if 4.3 were not a major overhaul, then
this wouldn't even be a topic for debate.
I do see how there is a problem that 4.3 as is is not directly usable. The
way around that, in my opinion, is to make sure that the 4.2 compatibility
layer is at all times functioning. That way, people can actually use 4.3
normally (good for testing) and experiment with new functionality if they
want (having been warned that the implementation is in a state of flux and
liable to change).
* OS X
Not sure what there is to discuss on this front. I know Thomas Harte is
vocal about Allegro mostly treating OS X as a generic UNIX system, which
it is not. I think he's right to do so and we should invest in making it
more OS X "native", but this could be tricky to organise. Getting a census
on who uses OS X might be useful.
I have an iBook G4, which I mostly don't use for Allegro-related stuff.
On a similar vein:
* Windows
This keeps popping up, and it's been discussed many times. There are some
standing issues (see the mostrecent threads on the dev forum on ACC) that
need resolution and developer intervention.
I personally do have Windows installed, but no developer tools - and quite
frankly, I don't have the time to look into Windows issues unless it's as
simple as compile&run.
* Display & Graphics (bitmap manipulation)
I think my position here is clear. :)
To me, a "display" is something like an application window, a "bitmap" is a
distinct object that might or might not be attached to a display. For a
display, things like buffering and vsyncing make sense, for a bitmap as a
seperate entity I think not. My experience with state based machines is
that they tend to make things more complicated in the long run. This is
not the case when dealing with single instances of a particluar type of
object, but when dealing with, say, different displays or off-screen
bitmap manipulation, I find them confusing and bug-attracting. I realise
that is a personal preference, and it may make an OpenGL implementation a
bit more awkward to implement (though it seems to me that should be fairly
easy to work around and should only affect internal anyway).
Other:
* Dictatorship/leadership and releases
I've brought this up before. I think the current system depends too much on
wether the Dictator has time to invest (or at least it seems that way to
me), which none of us seem to have in abundance. One of the things I
proposed earlier is to appoint Dictators for each branch instead of for
the project as a whole (in which case, following Roman nomenclature, the
term "consul" might be more appropriate). Another possibility is to
appoint a Dictator for a limited time only and then replace him (or,
technically, her). If someone reads into this that I'm very busy and the
time I have to spend on Allegro is limited, then that someone reads
correctly. I'm fine continuing to do releases for 4.2 and making
announcements, but I certainly can't promise more than that.
I think these are the main things I would want to bring to the discussion
and my position on them. I'll try to pop in on the IRC channel (provided I
even have an IRC client installed, I might not), but I may be a little bit
late. Discussion on input/events and the sound API I gladly leave to
people more knowledgeable on those.
Cheers,
Evert