An Allegro Hack Day is tentatively scheduled for May 12th. (Otherwise it might be the 5th, but that is probably unlikely.)
If you plan on attending the IRC session, add your name, preferred time, and any topics you wish to discuss to the wiki (the above link). Note that these are only intended for the people who are serious about improving Allegro in some way.
Kinda OT, but what is the status on the new demo game? Did anything ever get done with the ones that were made?
The skater demo is in SVN in a separate dir, and does still work. Mimix also made it work with AllegroGL some time ago. I think we could use it for 4.3 as official demo instead of the current one.
It's a waste that such a good demo game is not yet made available to the public. And it uses 4.2 API, thus it doesn't really fit into 4.3, unless someone rewrites it. We should at least put it to Depot page or something.
True. Maybe add it to the depot, and then also link to its depot page from the alleg.sf.net download page (the one where you can get demo.dat and so on).
Hows it going to work exactly? Do we just code some random section of allegro or will there be some kind of facilitator telling us what we're going to be coding?
It's not literally a "hack day" in the sense that we sit around and program. It's really more of a developer's meeting to help keep people motivated to work. (Setting a monthly milestone is better than just waiting around for tomorrow man to do it.)
People discuss issues, improvements, status updates, etc. No one tells anyone what to do, but obviously if you are looking for something to do, I'm sure someone can come up with something useful for you to do. The development of Allegro is pretty much do what ever you feel like doing, and if you can persuade others that it belongs, it gets added... (Of course there is a new API that has been designed for 4.3. So it's not entirely chaotic. 
)
For example, I think the build system for MSVC is dumb. But attending the IRC session and just saying that is pointless. There's no task team that I can command to do my wishes. So if I want it done, I have to do it myself. (And I am.)
For now the "Hack Day"s are just meetings. Once we have some solid plans, the real Hackathons can start.
I think though that I'll attempt to finish my fshook stuff this next meeting. Theres really not much left to do in the main library, but I do need to make some tests and examples for the new api, as well as split out the old pack_ and datafile stuff into separate addon libs.
And before anyone asks and gets mad, no the pack and datafile stuff is not going away, it'll just be in its own library, distributed allong with allegro, and will use the new fshook stuff to do its thing. By default though, I'm probably just going to have the plain old stdio driver be the default one. A person can choose the old pack_ functions or something fancier like a PhysFS extension if one gets made (I don't doubt it will).
Since there still doesn't seem to be any proper roadmap, API plan, or, well, any kind of written documentation whatsoever, I'm out.
This is what these days are for. Did you read what was said? Right now we are fleshing out the plan and documenting it.
There's no task team that I can command to do my wishes.
Count me in. I have just hack/generated an asmlock.asm (attached) which was the sticking point when I tried to make an allegro .dsw. It isn't quite working yet, and I need to re-insert all the comments, but it is happening.
The key to this was gas2masm which is in the Quake1 GPL source. Unfortunately, I started with allegro 3.9.38 source (silly me didn't check) so if the BITMAP struct has changed since then this will need redoing.
We just committed patches to enable a C-only version of Allegro. I've got a MSVC 6 project file nearly done. I just have to add the examples and a few scripts to do things like generate plugins.h.
orz had mentioned that "a [c-only] dll would not be binary compatible with the existing dlls, due to the calling conventions used in the asm window locking code." So an ASM version may still be handy. Although, I haven't noticed any incompatibilities yet.
I know Kris Asick has been working on his own keyboard and mouse input code for Windows to fix some Allegro issues. Since there don't seem to be any other active Windows devs, could this be looked at as a possible replacement?
Since there still doesn't seem to be any proper roadmap, API plan, or, well, any kind of written documentation whatsoever, I'm out.
API and documentation is on the wiki. For example: http://wiki.allegro.cc/Display
It's still disorganized, but it's getting better.
I know Kris Asick has been working on his own keyboard and mouse input code for Windows to fix some Allegro issues. Since there don't seem to be any other active Windows devs, could this be looked at as a possible replacement?
One problem is that issues are reported but without any solid test cases. If something is happening to him, but it cannot be duplicated, the devs will be less likely to just accept a re-write as-is. It may fix his problems while breaking others.
I'm just talking about the general case because I don't know the details of his problems and solutions. If he can show that there is a problem and that he has a solution, while being willing to work as an Allegro developer, no one will stop him.
Although, I haven't noticed any incompatibilities yet.
What about that test you did the other day? The person who tested it said the screen wasn't updating correctly with the C-only version. I can't find the thread now 
http://www.allegro.cc/forums/thread/591252
I've seen that problem on the ASM version too. Also, the msvc+msvc combination failed to update, which couldn't be attributed to a compatibility issue.
Well I've made an asmlock.asm complete with symbols and comments (attached) but then when I tried to build I discovered that VC6 by itself does not recognise asm as a normal source file. you need to D/L and install masm seperately which kind of defeats the object of a VC-native build. EDIT: vc6 does have masm installed by default, it's just the IDE which doesn't treat asm as a default source file. A custom build rule for the file will fix 
The only nice solution I can see to this is to wrap all the asm funcs in asm{} in C files. This will simplify things considerably in other ways too so I'll go this way (e.g. the asm will have easy access to the C struct offsets that are currently hacked into obj/*/asmdef.inc by the build process)
Of course there is a new API that has been designed for 4.3.
Since there still doesn't seem to be any proper roadmap, API plan, or, well, any kind of written documentation whatsoever, I'm out.
This is what these days are for. Did you read what was said? Right now we are fleshing out the plan and documenting it.
I still say there is no API plan.
API and documentation is on the wiki. For example: http://wiki.allegro.cc/Display
It's still disorganized, but it's getting better.
Earlier, I chose an entry at random and found... nothing. I've now checked out all of them, and discovered that the rest don't seem to be any better. As far as I can tell, the "Display" link is actually the only page there I would call worthy of an API plan - the rest... well, they either consist of nothing at all or completely arbitrary function lists.
Thi is not nothing. Sound API proposal is there, you can download two (more or less) working implementation of the API, with an example app. It just doesn't have a nice web page. So ther is an API plan for most of the parts of allegro, but it's still in developer's heads and has to be put on the paper. That is what these days are for.
completely arbitrary function lists.
That's what an API is Sorry for being flippant, but it's basically true.
It's what an API is. It's not not what a fucking API plan is.
Either help out or stop whining.
Ah. I'll take that as "No, we won't write any proper plans in the future either". Good to know.
Quit your bitching. Help is needed (with the thing your bitching aobut!). Either help, or shut up.
Don't worry. I've taken the hint that criticism isn't welcome (at all) and hit the magic "Unsubscribe" button already.
Hey, keep it civil! I think gnolam has a valid complaint, although we're hopefully in the middle of addressing it now. Let's see what happens in the next couple of weeks.
I would like to hear what his idea of an API plan is. Maybe at a higher level than most of us are thinking?
Maybe at a higher level than most of us are thinking?
Doubtful... Oh, you mean in a technical sense. Never mind then.
If he had anything valid to say, he'd have said it instead of complaining about everyone else not doing anything.
I think gnolam has a valid complaint
Never said he doesn't. Just said that doing no more than complain about it isn't constructive. Ok, so I may have said it a bit harshly.
This is an open source project, not some commercial thing. If someone wants to make a road map more power to them. If no one wants to then who cares.
You have to enjoy developing it or why are you even doing it?
From my perspective as someone who's not really "in the loop," I'd say the two most lacking areas are:
AllegroRoadmap - That page is probably sorely out of date. A useful road map would list all components in a single table. It could be a very high level with general milestones. It's not about setting a due date, but just keeping an eye on what is done.
A high level description of each module that explains the fundamental differences between it and the 4.2 way. Some of the pages are better than others. For example, the "Display API proposal" looks promising.
I personally don't even know everything that is going into 4.3/4.4. From what I've seen it's basically 5.0... (And from a "marketing" standpoint, I think it should be called 5.0.)
Regarding this Saturday, is it safe to say 12:00 UTC is the official begin time? TF was the only one that mentioned a preferred time (avoiding afternoons). As it is now, it will be 5AM for Dustin and 10PM for Peter (if they live in the timezones I think they do).
from a "marketing" standpoint, I think it should be called 5.0
Eventually it will be. For now, there will be no complete 5.0 release as its being done piece by piece instead of all at once, like was planned before.
TF was the only one that mentioned a preferred time (avoiding afternoons)
Yeah, I have a thing from about 5pm MST/MDT onwards (probably till 12-2am), and 12 UTC is about 5-6am.. so getting up for the meeting will leave me quite drained for the other appointment. Don't bother scheduling around me though. At this point, I really don't have much to add. Besides getting input on my update to the File Systems page. I'll eventually flesh out the api and docs on there as well.
Eventually it will be. For now, there will be no complete 5.0 release as its being done piece by piece instead of all at once, like was planned before.
I just meant that there doesn't seem to be any need for a 4.4 series. There are enough changes in the works already to warrant a 5 number. If there are any major things that don't make it in the next stable release, we always have version 6.
Think of the 4.3+ series as the WIP version numbers, like 3.9.x was. Thats all it is really.
On the documentation front, I placed the modules listed on the New API page all under the NewAPI folder and created stubs for the modules that have an API.
I also wrote up a page on the Events module. It's meant to give an overview on how to use the events and to answer any common questions. It is not a complete API reference, as that already exists via the source generated comments.
Hello, you may remember I did some work on Allegro's OS X port a while ago. Unfortunately I haven't got any time for Allegro or programming stuff anymore, but I have got a partially complete OpenGL driver for 4.3. I alluded to this on the Wiki.
I'll attach it here, hopefully it will be useful to Juvinous or even lillo if he comes back.
Cheers and good luck,
Peter
go on then, attach it :p
Wow, welcome back PH. 
Uhh I forgot the 'Substandard Web Browser' option. It's been too long...
http://www.allegro.cc/files/attachment/592130
Pete