Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro new style???

This thread is locked; no one can reply to it. rss feed Print
Allegro new style???
Carrus85
Member #2,633
August 2002
avatar

Quote:

- based on C++ (classes)
- hardware support

- full blown 3D engine

- etc

C++? Good idea, but I don't think the entire library should be C++ only... C programs have their merit. I do, however, think that C++ class interfaces should be defined and included in the base library.

Hardware Support? Most definately.

Full Blown 3D engine? Um... no. We don't have a full-blown 2d engine, so why would we need a full blown 3d engine? It would be nice to have openGL supported natively, though...

Some of my additions:

+ Basic Socket Wrappers
+ Virtual File System that supports various file types. (Initially supports .dat files, but can be extended via plugins to support .zip, .rar., .cab, .7z, etc. It would also be very cool if the pluginable file system could be created so that a FTP directory could be accessed as if it was a local file system as well. Maybe even a HTTP directory. But these are getting into the realm of plugins.)
+ Native support for PNG in the library.
- Remove GUI from base installation
- Remove software 3d routines
+ Support for multiple monitors
+ Resizeable Window Support
+ Multiple Window Support

khristina yer
Member #5,795
May 2005
avatar

Quote:

try allegro gl.
google is your friend to foundit.

its also listed in the addons section of this webpage. Its under graphics.
Right here

It allows you too use alleggl functions and you can use the opengl functions at the same time.

Fiddler
Member #5,385
January 2005

Quote:

+ Basic Socket Wrappers
+ Virtual File System that supports various file types. (Initially supports .dat files, but can be extended via plugins to support .zip, .rar., .cab, .7z, etc. It would also be very cool if the pluginable file system could be created so that a FTP directory could be accessed as if it was a local file system as well. Maybe even a HTTP directory. But these are getting into the realm of plugins.)
+ Native support for PNG in the library.
- Remove GUI from base installation
- Remove software 3d routines
+ Support for multiple monitors
+ Resizeable Window Support
+ Multiple Window Support

With the exception of the first (and possibly the second) item, I completely agree. Moreover:

+ Add a hook interface for all load_* functions, so you can provide your own loaders. The interface should externally be the same, regardless of the file in question.

- Remove all pointers to resources (eg. BITMAP*). Instead use handles (typedef BITMAP unsigned int). This should be mostly trivial to do in the new api, and will go a long way in ensuring that Allegro remains upgrade-able and api-consistent (ie. right now we have a font->width and a bitmap->w field... we cannot change that, too [1]).

- Remove every last macro in the code, and replace it with a normal function call. Macros kill the debug-ability of the code, while being excellent in obfuscating it (see blit.c for a nice example). Speed increase is negligible to none with modern compilers.

- Remove all globals.

- Remove all asm.

+ Add more accurate timer functions.

+ Simplify the video / system / memory bitmap api. Ensure a consistent way to use single / double / triple / multi buffering with either memory, system or video bitmaps (see DirectX swap chains and the like). OpenGL, may not support this however.

+ Update and simplify the driver api (especially the gfx one). Ideally one should be able to write and easily hook his own software / hardware implementation of the proposed new api.

+ Provide a virtual input device interface. This is something you have to implement for every single game. It gets tedious after a while.

+ Create a development system that will help draw more developers.

Most of these will be trivial to ensure, provided we keep the interface and implementation completely seperate in the new api. To do this, I propose we take as much time as needed (after the 4.2.0 release) to discuss and write down a complete, up-to-date interface proposal (with implementation notes), as well as a rough development roadmap. This will then be published along with a 'developers wanted' notice. I am 99% sure this will draw enough people's attention to provide a few more full and part time developers.

As for [1], I think there is a simple, non backwards-compatability breaking solution: Replace the FONT.width declaration with a nameless union (ie. union { int width, w }; ). This works 100% in C++ (tested in both MSVC2003 and Mingw) - it should work in C, too. This way, new apps can access the font width as font->w, while no old apps break.

EDIT: I sense many may find my tone somewhat offensive. I am not demanding anything of anyone. I just wanted to give some food for thought.

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Richard Phipps
Member #1,632
November 2001
avatar

Um.. Why don't you do it then Stephen? I'm sure we will all thank you and be very grateful for a better version of Allegro.

Fiddler
Member #5,385
January 2005

Quote:

Um.. Why don't you do it then Stephen? I'm sure we will all thank you and be very grateful for a better version of Allegro.

Quote:

To do this, I propose we take as much time as needed (after the 4.2.0 release) to discuss and write down a complete, up-to-date interface proposal (with implementation notes), as well as a rough development roadmap. This will then be published along with a 'developers wanted' notice. I am 99% sure this will draw enough people's attention to provide a few more full and part time developers.

Allegro 4.2 is a development dead end code-wise. I am waiting for a document that officially describes the new api, before doing any work there - and by document I mean even a confirmation that the old Allegro 5 proposal is the plan. Right now, I do not know what is being worked on in the strange, behind-the-scenes new-api fork. I bet not many do. That is why I propose an official discussion on the new api branch when the pending release is out. Until then, there is not much anyone can do.

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Richard Phipps
Member #1,632
November 2001
avatar

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.

Call me cynical if you will..

Evert
Member #794
November 2000
avatar

Quote:

+ Virtual File System that supports various file types. (Initially supports .dat files, but can be extended via plugins to support .zip, .rar., .cab, .7z, etc. It would also be very cool if the pluginable file system could be created so that a FTP directory could be accessed as if it was a local file system as well. Maybe even a HTTP directory. But these are getting into the realm of plugins.)

You can already do this with the current (4.2) packfile routines. It could be easier, but it's possible.

Quote:

+ Native support for PNG in the library.

Requires both zlib and libpng. May not be a problem for people who don't mind extra dependencies and it was discussed (can't remember right now what came of it).

Quote:

- Remove GUI from base installation
- Remove software 3d routines

We know. No need to bring this up again, both of those can go into (standard) addons.

Quote:

+ Support for multiple monitors
+ Resizeable Window Support
+ Multiple Window Support

Already planned in 4.3.

Quote:

+ Add a hook interface for all load_* functions, so you can provide your own loaders. The interface should externally be the same, regardless of the file in question.

Do you mean like register_bitmap_filetype and the like? Or do you mean custom file I/O routines that work on PACKFILE's? Either way, it's there already.

Quote:

- Remove all pointers to resources (eg. BITMAP*). Instead use handles (typedef BITMAP unsigned int).

Disagree. I frankly don't see the benefit and it would be more awkward to work with (for me at least). Pointers are fine if used properly.

Quote:

- Remove every last macro in the code, and replace it with a normal function call. Macros kill the debug-ability of the code, while being excellent in obfuscating it (see blit.c for a nice example). Speed increase is negligible to none with modern compilers.

In many cases, the reason is not speed but the C equivalent for templates in C++: you write code once that works on integer types and then have the compiler create instances of it for each integer type instead of doing that manually. The extra work you do when you write the code for the first time is negligible, but the benefit becomes clear when you want to change things in the code.
I agree you want to limit macro's as much as is reasonable, but macro's, like pointers, have their uses and are powerful language features that you can use (and should, where appropriate).

Quote:

- Remove all globals.

Yes.

Quote:

- Remove all asm.

Yes... we know. We discussed this. We agreed on this.

Quote:

+ Add more accurate timer functions.

Isn't Peter's new timer system an improvement already (probably not for Windows, but I don't know)?

Quote:

+ Simplify the video / system / memory bitmap api. Ensure a consistent way to use single / double / triple / multi buffering with either memory, system or video bitmaps (see DirectX swap chains and the like). OpenGL, may not support this however.

Yes. The new API can handle (and hide) the update method from the user. Just tell Allegro you want to use a tripplebuffer and it'll be set up for you.

Quote:

+ Update and simplify the driver api (especially the gfx one). Ideally one should be able to write and easily hook his own software / hardware implementation of the proposed new api.

Yes.

Quote:

This way, new apps can access the font width as font->w, while no old apps break.

The new API will provide accesor functions anyway, and I don't think we'll document the names of struct members in the public API. The BITMAP->w and BITMAP->h will live on in the compatibility layer though, as will the other documented fields.
Your FONT example is perhaps flawed in the sense that the FONT struct members are not documented in the public API (correct me if I'm wrong). If user code uses it, it relies on an internal part of Allegro that it should not be relying on. Add-on libraries are a different story, so we probably won't remove structure fields or rename them for that reason, but in this case there is no public API compatibility constraint on changing it, or even removing it.

EDIT

Quote:

and by document I mean even a confirmation that the old Allegro 5 proposal is the plan.

It is.

Quote:

Right now, I do not know what is being worked on in the strange, behind-the-scenes new-api fork.

Right now, we want to get 4.2 out before continuing on 4.3. No sense in letting 4.2 die a quiet death.

Quote:

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.

Geez, thanks.

Elias
Member #358
May 2000

Quote:

Allegro 4.2 is a development dead end code-wise. I am waiting for a document that officially describes the new api, before doing any work there - and by document I mean even a confirmation that the old Allegro 5 proposal is the plan. Right now, I do not know what is being worked on in the strange, behind-the-scenes new-api fork. I bet not many do. That is why I propose an official discussion on the new api branch when the pending release is out. Until then, there is not much anyone can do.

This is as much of an official document as you can get right now, I guess:

Roadmap

I just updated it a bit. If something is missing, add it if you know it (it should be somehow possible to subscribe, Tomasu doesn't seem to hear complaints to make it more obvious how to :P), or else ask and add it :) Many things are not decided yet, so it's good to discuss them. But it's more detail questions (we really know about the GUI and software 3D), the general roadmap is quite clear, and a lot of discussion and design work already was done on the A5 list (which is in no way binding, but we use it as base, there's a link to the results in the above URL if you are interested). And there's nothing going on behind-the-scenes in new-api (unfortunately), it just has some of the A5 documents implemented already, but that's it.

--
"Either help out or stop whining" - Evert

Fiddler
Member #5,385
January 2005

Quote:

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.

Call me cynical if you will...

No, what you say is true. However, since after all these discussions nothing has changed, well, something must be wrong, true? I'd say that there are people who would like to help, but don't (or can't). Why? Well, bug fixing a broken 15 year old system is not something very fun. And most people (myself included) don't like to work on something for free, when it isn't really fun. (Ever seen someone try enthousiastically try to jump on the development bandwagon, and shortly after disappear? That's the cause). I'd wager that there would be people writing code for the 4.3 branch (if it was open for wide-spread development), who wouldn't even touch the 4.2.

Quote:

Do you mean like register_bitmap_filetype and the like? Or do you mean custom file I/O routines that work on PACKFILE's? Either way, it's there already.

Oh, sorry. I just re-read the docs.

Quote:

Disagree. I frankly don't see the benefit and it would be more awkward to work with (for me at least). Pointers are fine if used properly.

Well, there 3 issues I can see with it:
a) if you can use bitmap->w, you'll probably never use al_get_bitmap_width() (or however the function will be called). This may seem a non-issue at first, but may be limiting in the long run (if you ever need to change the internal representation, or whatever).
b) It is crash prone (it is quite possible to dereference an invalid pointer - in fact in a large project, it is almost assured unless you wrap up the pointer yourself). The al_get_* methods can be architected to never crash.
c) A handle is much easier to interface with other languages. Think .net compatibility (which sdl already has).

Quote:

In many cases, the reason is not speed but the C equivalent for templates in C++: you write code once that works on integer types and then have the compiler create instances of it for each integer type instead of doing that manually. The extra work you do when you write the code for the first time is negligible, but the benefit becomes clear when you want to change things in the code.

True. I once tried to debug a crash that lead somewhere into the EXPAND_BLIT macro - that was an experience I do not wish to repeat... I agree, this macro is a pretty smart piece of work, and saves quite a lot of typing. It is also completely obfuscated and undocumented. While one may understand what it tries to do, it is very difficult to find all the little places it might break under extreme circumstances. Writing the expanded functions would be a lot more work initially, but they also would be more maintainable (and wouldn't break the debugger).

Quote:

Yes... we know. We discussed this. We agreed on this.

I know. Just (one more) small reminder :P

Quote:

Quote:

This way, new apps can access the font width as font->w, while no old apps break.

The new API will provide accesor functions anyway, and I don't think we'll document the names of struct members in the public API.

I was referring to the current api. But, I don't think this change is something very useful, anyway.

Quote:

Your FONT example is perhaps flawed in the sense that the FONT struct members are not documented in the public API (correct me if I'm wrong). If user code uses it, it relies on an internal part of Allegro that it should not be relying on.

No, you are correct. However, I recall seeing it in user code - the point is that if one can use it he will even if he shouldn't.

Quote:

It is.

OK.

Quote:

Right now, we want to get 4.2 out before continuing on 4.3. No sense in letting 4.2 die a quiet death

All right, we agree (though I'd say all these small bugs that keep creeping out, are a valid indication that the 4.2 branch is a dying breed).

So after all this talk, would it be possible for me to start on the new branch (is it available somewhere)? Or should I wait for the release?

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

+ Add more accurate timer functions.

Feel free to write an HPET timer driver. :)

Quote:

a) if you can use bitmap->w, you'll probably never use al_get_bitmap_width() (or however the function will be called). This may seem a non-issue at first, but may be limiting in the long run (if you ever need to change the internal representation, or whatever).

The new bitmap type is probably going to be called AL_BITMAP, while the current bitmap type, for compatibility, will remain BITMAP. The two will not be interchangeable (though I'd expect some sort of conversion function). And if you handle typedef's like this:

Public/lib header:
typedef struct AL_BITMAP AL_BITMAP;
Private/only-included-by-Allegro's-source header:

struct AL_BITMAP {
   int w;
   int h;
   etc...
};

User code will not be able to dereference an AL_BITMAP pointer at all (effectively making it only a handle), but you'll still have the advantage of type checking. The internal library, however, will be able to dereference them as needed.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Elias
Member #358
May 2000

Quote:

No, what you say is true. However, since after all these discussions nothing has changed, well, something must be wrong, true? I'd say that there are people who would like to help, but don't (or can't). Why? Well, bug fixing a broken 15 year old system is not something very fun. And most people (myself included) don't like to work on something for free, when it isn't really fun. (Ever seen someone try enthousiastically try to jump on the development bandwagon, and shortly after disappear? That's the cause). I'd wager that there would be people writing code for the 4.3 branch (if it was open for wide-spread development), who wouldn't even touch the 4.2.

That's all true. And even the Allegro developers thought that way with A5. Also Korval thought like that. The ones still hacking on the core Allegro now want to try a different approach, doing sort of evolutionary development. Don't do a completely new project, but gradually upgrade an outdated API, and even developing a caompatibility layer along with it. Unfortunately, this is often not only not fun, but quite frustrating. I guess none of the current devs really know why they are putting all the work into it, at least I couldn't say for myself :)

Quote:

So after all this talk, would it be possible for me to start on the new branch (is it available somewhere)? Or should I wait for the release?

If you have a high enough level of C programming, nothing stops you from working directly on the code. But most tasks aren't fun I guess.. after 4.2.0 is out, we'll probably simply start working on new_api_branch. Updating examples to use the new API where available, and implement the new API. For designing new API parts, a lot of discussion will be necessary - unless you can come up with a completely implemented perfect API for something, where nobody can complain about anything :)

Other tasks will be writing/adapting drivers to work with the new API. And also some drivers might need to be completely updated.

Hm, I think I wanted to say something else, but it's quite late and I'm very tired..

--
"Either help out or stop whining" - Evert

Fiddler
Member #5,385
January 2005

Quote:

Feel free to write an HPET timer driver. :)

I take HPET stands for High PErformance Timer? I woudln't mind writing one for windows (indeed, I just finished a C# implemntation based on QPF), provided the current interrupt / thread based timer api is sent to the where dead apis go. A simple, high performance, platform-dependent timer (that, well, actually times things) I could do. Just don't make me go near the current implementation! :)

As for the struct 'magic', well this is nice, but I can't see how it could work. The public header would have to include a definition of the AL_BITMAP struct, which means you have full access to the internals (I just tried it, though I may have done sth wrong.)

EDIT:

Quote:

The ones still hacking on the core Allegro now want to try a different approach, doing sort of evolutionary development. Don't do a completely new project, but gradually upgrade an outdated API, and even developing a caompatibility layer along with it. Unfortunately, this is often not only not fun, but quite frustrating. I guess none of the current devs really know why they are putting all the work into it, at least I couldn't say for myself :)

:) I know, I just think 4.3 should have been opened for public experimentation while the 4.2 development continued.

Quote:

If you have a high enough level of C programming, nothing stops you from working directly on the code. But most tasks aren't fun I guess.. after 4.2.0 is out, we'll probably simply start working on new_api_branch. Updating examples to use the new API where available, and implement the new API.

I'll start tinkering when I have enough time (about next week, that is.)

Quote:

For designing new API parts, a lot of discussion will be necessary - unless you can come up with a completely implemented perfect API for something, where nobody can complain about anything :)

Fat chance :)

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Peter Wang
Member #23
April 2000

Quote:

As for the struct 'magic', well this is nice, but I can't see how it could work.

It is a standard C practice, called opaque data types. The key to it working is that public interfaces only take pointers to things. And they are as easy to interface with other languages as handles are, except that the C compiler gives you type checking for pointers.

Quote:

:) I know, I just think 4.3 should have been opened for public experimentation while the 4.2 development continued.

Well, it's has been available in CVS for a long time. Have you tried to check it out?

Carrus85
Member #2,633
August 2002
avatar

Just for a clarification, the VFS thing I'm talking about would work something like this:

1al_vfs_mkdir ( "/datafiles" );
2al_vfs_mkdir ( "/ftp" );
3al_vfs_mount_datafile ("data1.dat", "/datafiles/data1");
4al_vfs_mount_ftp ("ftp://wherever.blah.balh", "/ftp/wherever.blah.blah");
5 
6// Load from ftp:
7AL_BITMAP* ftpBitmap = al_load_bitmap ("/ftp/wherever.blah.blah/ftpbitmap.bmp");
8 
9// Load from datafile
10AL_BITMAP* datafileBitmap = al_load_bitmap ("/datafiles/data1/datafileBitmap.bmp");
11 
12// Load from root directory of program
13AL_BITMAP* localBitmap = al_load_bitmap ("/root/localBitmap.bmp");
14 
15// Load from working directory
16AL_BITMAP* workingBitmap = al_load_bitmap ("/work/workingBitmap.bmp");
17 
18// Load from arbitrary file system location (C:\windows\temp\blah.bmp in this example)
19AL_BITMAP *fsBitmap = al_load_bitmap ("/system/c/temp/blah.bmp");
20 
21// Load from arbitrary file system location (linux )
22AL_BITMAP *fsBitmap = al_load_bitmap ("/system/usr/local/linux/linuxRocks.bmp");

Something like that. It isn't perfect syntax-wise ( it could be worked on... bigtime.) But that was the general idea I was having. Of course, /root, /work, /system, etc. could be defined as something else later on. And a string starting with letter: could be translated into system/c for windows users.

Peter Wang
Member #23
April 2000

IMHO Allegro should not have a VFS at all, but should be able to be connected up to one.

Felipe Maia
Member #6,190
September 2005
avatar

Allegro was developed to C, making it C++ is just doing the same thing twice, if you want it so much, just redirect function calls and so...

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

I take HPET stands for High PErformance Timer?

High Precision Event Timer. It's something in the Linux kenrel, but should be easilly detected using configure. It's something closer to how Allegro's timers operate, instead of the current method of emulation with a thread. Obviously you'd need to be careful, since some of the things Allegro installs as a timer expects to actually be a thread.. but luckilly on the Unix side, there's a bg_manager construct that can continue to use threads.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

+ Virtual File System that supports various file types. (Initially supports .dat files, but can be extended via plugins to support .zip, .rar., .cab, .7z, etc. It would also be very cool if the pluginable file system could be created so that a FTP directory could be accessed as if it was a local file system as well. Maybe even a HTTP directory. But these are getting into the realm of plugins.)

I am working on one. It will contain two user api's, one thats a little lower level, where you manage your own VFS handles ie: VFS *file = vfs_create_local("/foo/bar"); VFS_STREAM *fh = vfs_open(file, "baz.png"); /* do stuff with stream handle */

And another layerd ontop of that that more closely resembles a mix of the unix style "mounting" setup and a uri based scheme ie: vfs_mount("file:/foo/bar", "/"); VFS_STREAM *fh = vfs_open_uri("/baz.png"); /* stuff */

(api shown will not be the final design). Other modules that I may include are "zip", "tfs", "ftp", and "http" VFS modules, as well as a zlib filter module

Quote:

IMHO Allegro should not have a VFS at all, but should be able to be connected up to one.

I don't see HOW that could work without having its own vfs api in some form. I may be a little biased, but the vfs I've been putting together is rather simple and flexible. The base of the VFS code is a rather thin layer.

KittyCat said:

It's something in the Linux kenrel

Actually its a piece of hardware somewhere in any modern enough PC IIRC. I think even win32 has an api for it some where.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

I think a VFS is great for Allegro, if someone is willing to code it. While Allegro doesn't necessarily have to support any "streams" out of the box it would obviously have to support the concept.

I don't know that you really need much of an exposed API. Wherever a filename is expected, just use a special protocol syntax:

load_bitmap("ftp://...")  // FTP stream
load_bitmap("http://...") // web stream
load_bitmap("lfs://...") // local file system
load_bitmap("/foo")       // local stream (no protocol)

dir = al_open_dir("datafile://foo.dat");
// dir = al_open_dir("lfs://."); 
// dir = al_open_dir("ftp://foo");
while (file = al_read_dir(dir)) { /* */}
al_close_dir(dir);

I don't know that I'd make it any more complex than that. Out of the box, Allegro would only need to support the local file stream. I think also, the local file stream would force you to use forward slashes and it would know how to intelligently find a person's home directory, a writeable config directory, etc. Other than that, the local file stream would pretty much be nothing more than a straight copy of standard i/o functions.

Each stream could support as much or little of the functionality as makes sense. For example, a datafile stream might be read-only.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

I don't know that I'd make it any more complex than that.

That was the first plan I had, but several people talked me out of JUST giving a simple api like that. Not flecible enough. But yes, a simple uri based scheme will be available. You can use as much or as little of the feaures as you like.

Quote:

For example, a datafile stream might be read-only.

Sure, but I'll be providing a new "datafile" format what has read write capabilities. Its a Fileystem in a File. Beable to use a "TFS" datafile as just another directory/filesystem.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

What were the practical limitations? You could even implement filters like this: "scheme://location#internalname|filter1|filter2". I'd hate to be the person who coded all that, especially if you do it properly without blocking. But I'd like to be the person using such a system. ;)

You'd have to answer questions like, "Should the programmer be able to download a gzipped datafile from a remote ftp server and read an arbitrary bitmap from it all in one pass?" Because you could do something like:

al_load_bitmap("ftp://ftp.allegro.cc/junk.dat.gz#mybmp|gz|datafile");

But is that really even very practical? What type of scenarios were you thinking of covering with your VFS?

Richard Phipps
Member #1,632
November 2001
avatar

Quote:

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.

Soryr Evert, I wasn't criticising the developers. I was refering to people who want Allegro to be changed to be a certain way, but don't want to do any work to make it happen. However, I am glad to see that Stephen seems to be keen on working on Allegro. :)

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

But is that really even very practical?

Oh god no. I originally had thought of allowing chaining uris like so: al_open_file("http,gzip://server/path/file.foo.gz");
But thats just a little too complex for one command.

Quote:

What type of scenarios were you thinking of covering with your VFS?

Well, the lower level api lets you do stuff like this:

VFS *local = vfs_create(vfs_local, "/foo/bar/baz"); /* /foo/bar/baz is now the root of the "local" vfs */
VFS *archive = vfs_create_sub(local, vfs_zip, "lala/archive.zip", "/archive"); // links the contents of "lala/archive.zip" to "archive" in the "local" vfs.
VFS_STREAM *file = vfs_open(local, "archive/readme.txt"); // opens readme.txt in the archive.zip file

Again, api not final.

And the higherlevel api will go something like:

vfs_mount("file:/foo/bar/baz", "/");
vfs_mount("zip:/archive.zip", "/archive");
VFS_STREAM *fh = vfs_open("archive/readme.txt"); // etc

Though one thing I've recently thought about is allowing "merging" of trees, so each concecutive mount overrides files in the previous ones, ie:

vfs_mount("file:/usr/share/foobandfriends", "/");
vfs_mount("file:/~/.foobandfriends", "/");
// any "uri" given without a protocol/scheme is assumed to be a "vfs" uri, that is, it sarches the vfs mounts.
AL_BITMAP *logo = al_load_bitmap("/images/logo.png"); // will first look into ~/.foobandfriends/images for logo.png, then /usr/share/foobandfriends
// blit for great justice!

Now, its not limited to that, I do intend on having all actions that could take a while, like copying, to be asyc, so the following won't block vfs_copy("http://server/path/updates.xml", "/"); while copying "updates.xml" to the vfs root dir (which was set previously).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Fiddler
Member #5,385
January 2005

Quote:

It is a standard C practice, called opaque data types. The key to it working is that public interfaces only take pointers to things. And they are as easy to interface with other languages as handles are, except that the C compiler gives you type checking for pointers.

I see. I was trying to create a struct not a pointer to it (which of course gave an error). I hadn't thought of this technique. Nice!

Quote:

Obviously you'd need to be careful, since some of the things Allegro installs as a timer expects to actually be a thread.. but luckilly on the Unix side, there's a bg_manager construct that can continue to use threads.

Except for the mouse and gui code, what else depends on the implementation of the timer?

Reading the http://alleg.sourceforge.net/future/timer.txt, I have some comments:
a) Multiple timer objects are not really useful. One is more than enough, provided you can register a callback (or event) to fire after a specified time period.
b) The code would be simpler if a timer always updates at maximum frequency, and all timing functions operate (ie. their arguments and return values are) in seconds (as a double)*. Right now, the proposed timer is more like a counter (which updates with a specified frequency).

  • This is what the GLFW library and the Managed DX Framework do, which is (arguably) more intuitive than Allegro's timers.

All in all, I'd propose the following timer interface (note: names are not final):

- AL_BOOL al_install_timer(void); // Initialises the platform-dependent timer driver. True on success. I'd say this is automatically installed on allegro initialisation.
- void al_start_timer(void);
- void al_stop_timer(void);
- AL_BOOL al_is_timer_running();  // True if timer is started.
- double al_get_timer_resolution(); // Returns the time between two subsequent timer 'ticks', in seconds.
- double al_get_time(void);    // Returns the time elapsed since al_start_timer() was called, in seconds.
- double al_get_time_delta(void); // Returns the time elapsed since the previous call of this function. Can be used to easily regulate movement (if a varying timestep is not a problem).
- double al_get_current_time(void); // Returns the time elapsed since the allegro was installed. In most cases this is close to the application start-up.
- AL_TIMER_CB_HANDLE al_register_timer_callback(double period, AL_BOOL one_shot, AL_CALLBACK function); // The 'function' will be called when 'secs' seconds have passed. If one_shot is true, then the function will be fired only once, and the callback will be removed. Otherwise the 'function' will be called ever 'secs' seconds. AL_TIMER_CB_HANDLE is used to uniquely identify each callback.
- void al_unregister_timer_callback(AL_TIMER_CB_HANDLE handle);
- AL_TIMER_EV_HANDLE al_register_timer_event(double period, AL_BOOL one_shot, AL_EVENT event_;
- void al_unregister_timer_event(AL_TIMER_EVENT_HANDLE);

Any thoughts? Either api is ok with me, and I'll try an experimental implementation as soon as I have some time.

PS: The vfs is looking nice. Keep up the good work!

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Kitty Cat
Member #2,815
October 2002
avatar

vfs_mount("file:/usr/share/foobandfriends", "/");
vfs_mount("file:/~/.foobandfriends", "/");

I think that could get very confusing very quickly if you allow multiple mounts on the same point like that.

As for multiple types in a single uri, I'd expect to do something like:
file://C:/some/path/to/a/zip://file.zip/with_objects.txt

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham



Go to: