Hmm... I don't think I have personally ever seen that syntax before, I'm dumb!. I'm just saying, we need to have a common programming scheme.

Personally, in my functions I pass them with an a_something or a p_something so I know that the value I am using is the one that was originally passed to the function, not a copy of it. Either that or start them with an underscore, capital letter, something to signify that this variable will be effected outside of this scope (I usually only use these when a pointer is being passed).

Hmm... Hungarian notation is evil, eh? I actually liked it to a certain extent. (At least at the function level, anyway).

Right. Which is why I propose that if we are going to have a datafile system of our own, dat will be included and the grabber be a separate package; something separate from the core Allegro routines, but officially sanctioned by the same people.

I for one would definitely like to see a good VFS; I'm not sure it should be a core allegro component, but I am definitely in favor of seeing an addon for this. It integrates especially nicely with .zip files as datafiles.

Indeed - that's the whole point in using Allegro to begin with - so we don't have to reinvent any wheels.

Call me a pessimist, but I believe that it could be quit a bit faster with a universal compression algorythm such as *.zip. Which would you prefer? A compression algorythm such as *.dat that is maintained by a few people, or *.zip which is accepted as an industry standard? At least with the industry standard library, it isn't yoru code to blame if the file isn't loading properly, it is theirs.

Well, I think the original idea of packfile is that it uses a very fast compression format which can work both globally and on a per-file basis. I personally gutted zlib a while back to see why gzseek was so fucking slow on pocket pc (ARM processor), and it turns out when gzseek is called for anything before the current location, it goes back to the beginning of the file and uncompresses everything until it gets to the point you want.

Hence I wrote up my own compression format (raz: random access zip) using lzo or whatever it's called (same one that allegro uses).

Granted, it's not really a problem on today's systems with loads of ram and fast processors, but zlib isn't the fastest pickel in the bunch. I think a packfile system could easily be offloaded to plugins (and come on, plugins can be included with the standard download, they just don't have to be compiled into your app). Another argument is that all of the file-related functions call the packfile routines just for general file IO access, but I believe someone started up a new io stream api for allegro 5 that would render that argument pointless.

Another vote for in favor of zlib: I think PNG should be setup as standard with the library. There is no reason to not push for more usage of PNG out there. A lot of people are still using BMP's in their test projects and whatnot because they don't want to bother setting up PNG support.

Definitely drop DOS support.

And on the programming style conventions, I think a convention for the public API is definitely required, but under the hood, I think it could be more general stuff like "indent your code!" and whatnot.

As for dictators, I vote again for myself (woo, 2 votes!), because if I were dictator, I'd implement strict style conventions and make everything C++. Maybe throw in some java. (j/k)

Marcello

I'm dumb! Marcello...

First of all, the internals should be C. No way around it. C is a bit easier to debug, not to mention a measure more easily ported than C++. Although I would have to say with the usage of C++ that is going on, it would be most definately nice to have a C++ wrapper class that you can use natively in C++ that COMES WITH THE LIBRARY. Such as a bitmap class, datafile (if they are kept) class, etc.

I would vote myself for dictator, but I'm a bit on the unexperienced end. I'm more than willing to help program the internals, but as for the fact that my formal programming education is near nonexistant.

One other thing that I had an idea for. Wouldn't it be nice to allow both high-level (current allegro) and low-level (sdl-like) actions? That way the newbs could use the high-level stuff, and those who prefer to optimize stuff could use the lower level APIs.

EDIT: Mr. Harte, since we are dumping support for dos, isn't that essentially dumping support for the 386 as well? I would be amazed to see a 386 run win98 semi-reasonably. If allegro is to survive, we need to make it look as attractive as possible to programmers. If programmers have to learn a completely new syntax for everything, such as our custom datafile syntax, restricting them to our custom 3d routines, etc. THey are going to be turned away because they don't want to waste time learning stuff. Productivity is the key to programming. Besides, by integrating Zlib, opengl, FMOD (maybe), etc., we give common functionality to new programmers; language experience that could be easily transfered from one library to another.

Dunno what you're going on about 386... what does that matter other than for optimizations that detect the cpu anyway?

As for C++, even bob has suggested this on the mailing list for the internals (instead of basically recreating vtables in c, to use c++'s for drivers), unless I'm incredibly mistaken.

It makes a lot of sense to me, I mean, name me a platform that doesn't have a c++ compiler that you actively are interested in having allegro compile on?

Marcello

Either that or supply a common API for the image loaders to follow, so it wouldn't be difficult to add them to the library.

We need to have some already supported with the download, for the newb-types. I would suggest these be the more commonly used, easier to edit file types (such as png, bmp). The rest could be implemented using add-on libs.

And, if we are going to implement addon libraries, which we have to in order to have a good library, it would also help if these libs followed a standardized setup plan. Aka... they all follow the fix.bat whatever, make, make install scheme.

Either that, or make a plugin directory under allegro that you can put all of your addins/plugins, and have some sort of orchastrating program to keep everything up to date..

Sorry, I'm kinda busy doing homework for other things right now, I'll hav eto put more thought into this later.

There is the question of how to handle the dll if we switch to a plugins based system. Should there be some type of multi-tier system:
1 - allegro raw dll, say allegro-raw50.dll
2 - allegro core "standard" plugins, allegro-core50.dll
Core standard plugins could be, for example, be the set of plugins most similar to the features allegro 4.0 has now that would be removed, such as packfile, png loader, DUMB, gui.
Then plugins could either be in dlls that work with both raw or core versions of the main DLL (for example, allegro-raw50.dll and allegro-dumb.dll; or allegro-core50.dll and allegro-software3d.dll), or compiled straight into your program (for example, allegro-raw50.dll with dumb compiled into application exe).

I can see the problem people have with tons of dlls in their system directory, but I see no problem if there is a standardized system. You can always include the dlls in the game directory instead of system. It is not uncommon to see applications/games with tons of dlls in their program directory. Likewise I think the plugin system should have a standard way to link statically and dynamically, so if you do not want any dll dependence (on any OS), you can compile it out.

If such a system is adopted, it would also be nice to have some kind of plugin repository with official DLL builds (done in upx, msvc++ or whatever gives you the smallest/most optimized dll) so conflict are minimized.

Any takes on that?

Marcello

If PNG is going to be included, PNG should be on top of BMP support. Not everyone needs, wants, or can, use PNGs. As open as it is.

Loading PNGs requires libpng, and that requires zlib. Allegro should build and run all by itself (without additional dependencies). We don't want people to have to download 4 or 5 packages just to get Allegro up an running.

Well, wether or not you use PNG or BMP, it is quite trivial. We could simply do some sort of program design like this...

It would be a pain to get anything like that to compile though... Most of the common stuff should be integrated into the library, and the plugins should be able to seamlessly integrate themselves with the existing functions.

For example, if you have the *.png loader and the *.bmp loader, you should be able to do a call like this:

load_bitmap("whatever.png")
load_bitmap("whatever.bmp")

and the library should be able to handle the various file types. The only problem with this would be that you would need to implement some rather, how should I put it, interesting(?) coding styles.

EDIT: Bob, welcome to the world of scripting. Just write a python script or something that downloads those additional libs for you so you don't have to find them yourself. (I'm dumb!... great idea, but we don't want to force people to install python. Maybe the makefile could make a c/c++ getfile tool or something, then use that to retrieve the needed libs from the net?)

EDIT:

As for dll naming conventions, I would prefer something like this...

As for DLL clutter, can you load DLL's from a subdirectory? So, for example, you could do something like this

PROGRAM_ROOT:
      -Executable
      +all5plugin folder (or something.  Heck, it might even be possible to use a zip file for this)
            -all50wav.dll
            -all50png.dll
            -etc.dll

EDITED Again for clarity