All,
Is it possible to use Grabber files with Allegro 5? From what I'm reading, the answer is no. It looks like zip files and multiple commands for interfile locations etc. I was just hoping I was misunderstanding.
Thanks.
No grabber/datafile system. I'm working on my own that loads a void pointer array similar to allegro 4 datafile. It uses an text file index.
The tags with $name are variables accessed as $(name).
Specify path & file name. If it needs alpha mask fix. Supports wildcards. I am still tweaking it and only have bitmaps supported. It has option to save a header file as well with indexing. That is important if end result is a void* array.
The above index outputs this header file
Also, it's C++ not C.
Once it's all tweaked, I'm going to work it so that loads directly from a zip file. One convenient package.
That looks like a good way to deal with it. What are your internals like?
In my FileSystem I can load a manuscript with simple lines like this :
mouse = mysha.png cat = garfield.jpg meow = meow.ogg eek = eek.ogg music = backgroundmusic.ogg
and it will load them all and make them available under the shortcut names.
Simple enough for my needs and supports zip files transparently as if they were a folder :
archive = Data/data.7z music = Data/data.7z/music.ogg
Sadly it still involves a cast from a base* or a void* at some point. Can't be avoided completely.
Nice All. I wish I had your gray matter, I'd just write mine too. Meanwhile I'll just keep all the bitmaps, ttf, and WAV files in the folder with the executable. Works fine, just not as clean as I was hoping for.
Daniel, let me know when you have something to trial. I'd like to see how it works.
loading
destroying
//from kill/shutdown function if (m_data_file) { delete this->m_data_file; this->m_data_file = nullptr; std::cout << "Datafile Destroyed" << std::endl; }
using
// draw function ALLEGRO_BITMAP* logo = this->m_data_file->get<ALLEGRO_BITMAP*>(DATAFILE_BITMAP_LOGO); al_draw_scaled_bitmap(logo, 0.0f, 0.0f, (float*)al_get_bitmap_width(logo), (float*)al_get_bitmap_height(logo), 0.0f, 0.0f, (float*)al_get_bitmap_width(this->m_buffer), (float*)al_get_bitmap_height(this->m_buffer), 0); ALLEGRO_FONT* font = this->m_data_file->get<ALLEGRO_FONT*>(DATAFILE_FONT_MYSTICORA); string_t* text = this->m_data_file->get<string_t*>(DATAFILE_TEXT_TITLE); al_draw_text(font, color::map(0xffffff), 50, 200, 0, text->c_str());
If you're ambitious and realize I will probably update/modify the code in the future, you can check out my github repository.
EDIT: Modified what the code, so what I wrote here is not valid. You'll just have to check out the app that is in the repository that uses the library.
Daniel,
Forgive my ignorance. I get most of what is being done between the two post, but "datafile" is throwing me. It's not a struct or not a type I'm familiar with. It's not a function. Later you use it like a struct or class datafile::read etc. I'm just not understanding what is represents.
I understand the index (header file) and that is what indexs an array. I get that concept anyway.
In any case, is this the process you use or you creating as we speak? Thanks
Are you knowledgeable on STL? Or maybe namespaces?
My naming convention might be confusing:
"datafile" is the name of the namespace
"datafile_t" is a class that wraps an std::vector<void*>
// how to open file and create datafile_t object datafile_t* dfile = datafile::read(const string_t& filename); // how to access the objects (pointers) ALLEGRO_BITMAP* bitmap = (ALLEGRO_BITMAP*)(*dfile)[index]; ALLEGRO_BITMAP* bitmap = (ALLEGRO_BITMAP*)dfile->get(index);
Seems I didn't upload the latest also, I changed it so vector now wraps a std::shared_ptr<void>. However, it also removed ability to directly access the void* array. Object access is still the same.
// no longer valid void** array_data = datafile_t::data(); ALLEGRO_BITMAP*bitmap = (ALLEGRO_BITMAP*)array_data[index];
Can't do that now that they are shared pointers.
Daniel, Namespace I should have recognized it. Now it makes more sense to me. Still a little over my head but I get the gist of it. Thanks for the detail.
I am thinking about making a similar product, but much much simpler. Still uses the same text file processing, but the datafile itself is simple.
Header file will be something simple like this:
load_datafile will return an array of datafile_t;
Daniel, I'm just trying to learn somethings here. If you get bored with the questions, you can drop out. Don't feel obligated.
Will load_datafile return an array or a pointer to the first element in an array. Probably the same thing but the latter would imply the array size is known.
Will this create a data file or read from it. If create, how do you write to a file with multiple types? If it reads from one, does it look for a EOF to determine when a file with in the overall file is complete?
Thanks.
Will load_datafile return an array or a pointer to the first element in an array.
It would return an array. The last element's data pointing to null.
Will this create a data file or read from it
The datafile array is the end product of parsing a text file. Do not confuse the two.
This does not function the same was as Allegro4's datafile loading. That was a complete file with all objects stored in it. Mine only reads a single text file in a folder that has other files and folders where assets are stored.
I wrote individual functions that parse each type.
All I'm doing is writing some functions to simplify loading multiple files.
Thanks Daniel,
So if I'm understanding correctly. In short, you use a header to basically allow you to use easily understood names as an index for an array that holds various pictures and wav files. But the BMPs and WAV themselves are separate files in the programs folder or designated path?
My only concern (or preference) is the amount of files. Example, my last A4 game had 15+ BMPs between backgrounds, player pieces, game board pieces. Then couple that with 5 to 7 WAV files, not includeing 2-3 font files. Under A5 I would have 25+ files to be included with the game, where under A4 I have 2. Program file and grabber data file. Again, not a deal breaker where game function is concerned. It just increases the risk of a missing file or user manipulated file affecting game function.
Put it all in a zip file and use PhysFS.
Option one: Open files
{"name":"613356","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fbccfce10e1c37d0267b1afeaf350d4e.png","w":248,"h":278,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fbccfce10e1c37d0267b1afeaf350d4e"}
Option two: zip file
{"name":"613357","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/a\/4a35a423e83698b3918ef8ee86867f46.png","w":249,"h":295,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/a\/4a35a423e83698b3918ef8ee86867f46"}
I plan on implementing option two. Eventually.
Yesterday, I started working on a standalone app that just outputs the header file. I kept changing thing and the header file would get corrupt, which would lead to errors in my app.
I also implemented nested datafiles. Don't know if needed, but older Grabber/Datafile had nested datafiles.
/* */ /* */ /* Date: 7:12:01 a.m. 10/08/2023 */ /* Do not hand edit! */ constexpr auto DATAFILE_TEXT_TITLE = 0; /* TEXT */ constexpr auto DATAFILE_BITMAP_LOGO = 1; /* BITMAP */ constexpr auto DATAFILE_BITMAP_ICON = 2; /* BITMAP */ constexpr auto DATAFILE_BITMAP_ICON_SHEET = 3; /* BITMAP */ constexpr auto DATAFILE_FONT_MYSTICORA = 4; /* FONT */ constexpr auto DATAFILE_BUSTER = 5; /* DATAFILE */ constexpr auto DATAFILE_BUSTER_TEXT_TITLE2 = 0; /* TEXT */
Thanks Daniel. I browsed PhysFS. I think I get the skinny of it. I'd need to generate a test run program to understand exactly how it works.
I do too. I haven't used PhysFS either. Working on other issues first. I'll get around to it.
Eagle already uses Allegro 5 and PhysFS and works with archives as if they were folders.
All you need is PHYSFS_Init(argv) and then you mount the archive, read from it normally, close the archive, and you're done.
Simplified things a bit. I messed with it last night. Thought I was done, but realized it's broken. It works as is as long as you don't use nested datafiles. Will fix that in a bit. It's a fairly simple fix.
also think about just making it it's own repository.
Daniel,
Looks more concise though I'm not sure I know what I'm looking at entirely.
Edgar,
I jumped on your site. I checked out Eagle. I downloaded the binaries and the program ran, however, I'm not sure what it does. I tried to pull up a bmp but it wouldn't do anything. In short, what is the programs purpose?
If you don't care about adding custom types, then all you need is these two functions:
datafile_t* load(const string_t& filename); void destroy(datafile_t* datafile);
It will parse your text file, load the assets, create an datafile_t array. The size of the array 1 more than the number of objects. The data value of the last argument is NULL. That's how you know it's the end of the array.
In your game, you can use as such
ALLEGRO_BITMAP* bitmap = (ALLEGRO_BITMAP*)datafile[index].data;
I tried to make the final product similar to Allegro 4's datafile. It's just the loading is different as it's not one file.
If you want custom objects, then you can register your own type with custom parse and deleter. the other functions are used to access the data from the text file. I hid the actual data inside parse_data_t to make it cleaner.
Use the menu. Which program are you running? There are lots.
Sorry Edgar, I meant no disrespect. I wasn't implying the program didn't work as intended, only that i didn't know what it ws supposed to do. The included picture is what I ran. I clicked on file and tried to open a BMP file but nothing happened.
Nice Daniel. Thanks for the update.
Click "Formatting Help". However, there is an issue with attachments. You cannot use the link that is given right after it is attached. You have to submit/update post first and use the link from the post itself. A little annoying.
{"name":"613358","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/d\/0ddad389091e36509ce80cc844869e70.jpg","w":825,"h":658,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/d\/0ddad389091e36509ce80cc844869e70"}
Ace, that program is from Eagle 4 GUI. That's the old version of Eagle.
Thanks Guys,
I've gotten the A5 version, but still don't know what to do or the purpose of the program. Meaning, Like Word is a word processing program, Doom is a game program, Eagle 5 is a ..... program. Is it a compression program, or a cooler version of a grabber type program?
When I click on the Upper left Upper right etc, nothing happens. I figure it's my ignorance more than the program. Just curious.
Daniel, I've worked with the Formatting Help- for images for 20 mins. I just keep getting a hyperlink to this entry for edit. In any case the picture seems to be working. It's just a snapshot of the Eagle 5 program.
{"name":"613361","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45b12507f1c3329bae11a2dbbe1612b1.jpg","w":791,"h":620,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45b12507f1c3329bae11a2dbbe1612b1"}
{"name":"613362","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/8\/58a979be29f12e7989bec37a31556fb2.png","w":1030,"h":534,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/8\/58a979be29f12e7989bec37a31556fb2"}
Oops. I forgot the closing " at end of tag in picture
{"name":"613361","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45b12507f1c3329bae11a2dbbe1612b1.jpg","w":791,"h":620,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45b12507f1c3329bae11a2dbbe1612b1"}
As for Eagle, that is a GUI, and I'm sure Edgar can explain more.
Thanks, I got it to work. I was using the link to the forum post and not the picture.
Those are old example programs that don't DO anything. They're just examples of widgets and layouts. All the new examples are in the GIT repo and the latest build(s).