You might think so, but I started using something similar in my Editor project, and its really simplified finding resources (icons, settings, etc). This way, you don't have to try looking in multiple places yourself, its just handled for you.

Not sure I like that.. the one idea I came up with it something like: zip,file:/C:/path/to/a/file.zipin that, it'd create a zip object and hand it the file: uri.

The timer interface is more or less finalised already. There are implementations for Unix (including MacOS X in this case) and Windows. Both use threads, but I suppose someone could write higher performance versions.

/* Abstract data type */
typedef struct AL_TIMER AL_TIMER;

AL_FUNC(AL_TIMER*, al_install_timer, (long speed_msecs));
AL_FUNC(void, al_uninstall_timer, (AL_TIMER*));
AL_FUNC(void, al_start_timer, (AL_TIMER*));
AL_FUNC(void, al_stop_timer, (AL_TIMER*));
AL_FUNC(bool, al_timer_is_started, (AL_TIMER*));
AL_FUNC(long, al_timer_get_speed, (AL_TIMER*));
AL_FUNC(void, al_timer_set_speed, (AL_TIMER*, long speed_msecs));
AL_FUNC(long, al_timer_get_count, (AL_TIMER*));
AL_FUNC(void, al_timer_set_count, (AL_TIMER*, long count));

Note AL_TIMER objects can be used with the event system, but I don't want to explain that here. In addition, there are these time related functions:

AL_FUNC(unsigned long, al_current_time, (void));
AL_FUNC(void, al_rest, (long msecs));

I don't understand why this is an unacceptable design for a new timer API:

int al_get_tick_count();

If you really really want to patronise users, you could add:

void al_set_tick_frequency(int)

But I don't see a need for it. Obviously default frequency would be "1000 ticks/sec", although it would be fine to fall back on GetTickCount in win32 which in all the implementations I've actually tested gives around 997 ticks/sec.

In my opinion the ideal Allegro design would be a base library which can create windows and set graphics mode, accept keyboard/mouse/joystick/whatever input and do audio, probably including something like the current mixer code but, as I'm sure the Allegro developers will have already decided, without separate VOICE and AUDIOSTREAM concepts.

It would always set a GL graphics mode, so anyone wanting to use OpenGL immediately could, but would otherwise provide an AL_BITMAP system for blitting. Filetype support, although extensible, would be the bare minimum, so maybe WAV and BMP - because it's the most common of the simple bitmap file formats.

On top of that addons could provide a VFS if people really wanted it, more file format support, or anything else whatsoever. With respect to file systems, I think SDL has hit the nail on the head with SDL_RWops. To be honest, I'm not really sure why (apart from pride), Allegro should not be developed as an SDL based project.

The developers continue to prefer al_something_something_something, which is usually described as being because they want to do it that way and if anyone disagrees then tough. Thankfully the stupid non-orthogonal name space proliferation common to the current library does not look like it will be carried forwards so no al_draw_rotated_pivot_scaled_sprite will ever be implemented.

I'll quickly recap SDL_RWops as not everyone reading will be familiar with them.

SDL_RWops is a struct containing function pointers for 'file' operations of reading/writing blocks of data and closing the stream. The base library provides separate functions for obtaining a suitable SDL_RWops struct for a file (not yet open), file pointer (i.e. an open file you've probably been doing stuff with) or a block of memory.

Besides SDL_LoadBMP and SDL_LoadWAV which operate much as load_bmp and load_wav in Allegro land, SDL_LoadBMP_RW and SDL_LoadWAV_RW will do the same from SDL_RWops.

They operate sufficient a background role that they are not even documented in the normal base API docs, and someone using vanilla SDL will probably never encounter them.

Where they come into their own is with the usual addon libraries such as SDL_mixer (for MIDI, MOD, MP3, OGG, etc support) and SDL_image (for PNG, JPEG, etc support). All of these can read from RWops instead of straight from files if the user wants.

Then there are completely non-SDL affiliated projects such as zziplib (which provides file system style access to ZIP files, think of it as like using a DATAFILE but with better compression and no proprietary weirdness), which often include examples of how to generate RWops from whatever data source they manage.

In this respect, SDL users get a base library that can access arbitrary data streams without paying for it with bloat. They are still, as Thomas Fjellstrom points out, working at a "low" level in that the initial opening of the file is not consistent across sources. In the case of Allegro, I would imagine this step would be handled by the VFS addon library, which could provide a vanilla open function able to decipher http://, file://, ftp:// or whatever at the start of the filename to determine a protocol or map different areas of its VFS to different devices ala Linux. And those of us who generally baulk at the Allegro paternal instinct remain free.

Of course, the aim would be for people using "Allegro on SDL" not to have to touch the SDL API if they don't want. I've no idea why you don't like it, but then it probably isn't any of my business anyway! And that's the point of view any such project should be written from.

Has the API design been frozen on the original 5 proposal + backwards compatibility?

Look, it would really help if you dropped this kind of language. We develop Allegro because we want to use it ourselves. If you think the timer API is too fanciful, fine, you're not forced to use it. But it is like that for a reason.

I basically agree with the RWOps, which is basically what the packfile vtables in 4.2 are. We even have equivalents of SDL_LoadBMP_RW, etc. (load_bmp_pf). This is what I meant about allowing you to use a VFS without having one built in.

Thomas you have valid points, but you often use negative language when talking about the development of Allegro, or the developers themselves.

This is ultimately not going to be productive and since you have indicated you are not interested in being a developer, then I wonder why you think it would help? The developers are not paid, nor under any obligations to us as users of Allegro, so being this critical is not helpful.

That is my personal opinion, but in no way should be seen as an attack upon yourself or your character.

Pax!

TH, your opinion is noted and your feedback appreciated. However, please realise that `If you really really want to patronise users, you could add:' isn't a particularly friendly way of expressing your opinion.

That's all well and good, but all the rude remarks and negativity just negates it all.

Noone has ever been "written out" of the CHANGES/AUTHORS file, And I don't see it ever happinging. Thats basically all the "thanks" anyone gets for working on allegro.

edit:

Uh, I'm not actually a Dev. I've submitted a couple patches, but thats about it.

Ok. We can discuss these issues now and at the end of it we can all agree to accept the outcome. We may like this or not, but we will have settled the debate.

Or, we can continually debate the same issues and new allegro structure repeatedly without ever accepting any outcome that does not agree with our own.

Which is more productive?

Peter Wang: The timer wrappers in allegro_new branch do not seem to follow the A5 proposal. If you will be so kind, could you specify what information an AL_TIMER struct holds? (I know this is off-topic to this thread, but it seems it's already been derailed so it doesn't matter that much). I'll try to make an experimental implementation of the A5 proposed api, but I need more information.

Thomas Harte: If I understand the new api correectly, it does what you are saying. However, what does a tick represent (1/sec)? What happens if the timer implementation can't keep up with the requested frequency? This is why I believe an api based on seconds will be easier to develop and use - the timers will always run at the highest possible frequency internally, and it's one thing less for the user to have in mind.

To developers: What parts of the current api depend on a thread-based timer implementation? Should the timer itself be thread-aware? Isn't it be possible to do all timer updating from a single thread?

Anyway, I'll try my hand at this.

That's the proposal I'm reading. Where is it implemented? A search for any of the proposed methods returns nothing! (in either the current or the the new allegro depository)

I wasn't meaning a thread per timer, either. It seems the current timers run on their own threads (though I may be wrong, I do not have much experience with threading), at least under windows.

What needs to be done? I have both Linux and Windows development machines.

I'm sorry, I have admittedly not really explained what background I was using for that statement which makes it look a little odd.

Your initial statement was "All I've seen from you (T Harte) in a good long while has been nothing but negative cryticism, and rude remarks.", a statement implying my input was strongly negative.

I countered with a non-exhaustive list of things I have done within "a long while" that I consider to be strongly positive.

You replied with "That's all well and good, but all the rude remarks and negativity just negates it all."

To negate is to nullify and make ineffective. So you have withdrawn your initial statement, which I considered offensive, that my input was purely negative and have instead said that I have merely a zero rating as concerns development of Allegro or to put it another way that I've spent exactly as much capital as I've earnt.

I also added that the average user is also at a zero rating, hence making me no worse than the average.

As I do not consider your second to be an offensive statement, I thought I would highlight how it revokes your first.

It also correlates to the way I feel about the criticisms that I make. In my opinion, while I continue to contribute positively to the Allegro community I earn the right to be strongly negative without overall creating a negative or destructive force.

Even in my comments I usually praise Allegro as much as destroy it, see the example above. However it is easy to ignore the positive and focus on the negative. I believe this is unfair and at worst appears simply to imply accepted weaknesses in the Allegro model.

Above all else, this is a bulletin board. Real time conversations are not possible so the posts are inevitably pushed towards speech making, which must always include a degree of rhetoric. There is no way to be sure that the meaning of a subtle post gets across as you have no measure whatsoever of reaction from most of the people that read your comments. So things must be stated strongly if they are to be effectively communicated, and this is the filter through which all bulletin boards have to be read.

It would be a shame if the Allegro community were to close its doors to dissent.

Read this thread. Especially when Stephen posts a long list of suggestions for API advancement and RP replies "Um.. Why don't you do it then Stephen?"

RP even adds in a later post "We've had discussions, we've had people giving their suggestions and others giving opposing suggestions. We've had lists and ideas and documentation, but unless you do something right now on the development I can't see anything changing."

So that I can fully understand the contrast of these two comments can I please ask whether you explicitly disagree with Richard Phipps? Or else do you discard the comment I've quoted and instead agree that anything less than actually wrestling with the codebase makes no difference and hence all such approaches are equally worthless?