MinGRo game engine

[Ñuño Martínez]

So why not use some different package/archive format instead of Tar which indeed does not support random read. You do know that Tar was initially developed to be used for storing data to magnetic tapes which by themselves also did not support random access.

(...)

There are numerous package systems that do allow you to read any of the contained file individually at any time. It isn't even so hard to make a custom one by yourself.

I like this.

Wasn't there an extension for Allegro game library which added support for working with various packages? Or do I perhaps just remember some game developers to make one for their own game?

Yes, there is: The PhysicsFS add-on but I have no idea how to use it. I suppose PhysicsFS is a library you install in your Windows/Linux system then it calls it or something.

I'm used to the "old" API (Allegro 4.x) and I'm still a bit confused with some parts of the new one (5.x), it is mostly designed as a state machine now but the file IO looks like a state machine mixed with other stuff. Not sure how to use it.

Well the problem of the IFF is that it still requires sequential reading since the file is divided into multiple chunks of various sizes. And in order to determine the size of first chunk you need to read its "header". In order to read the size of the second chunk you first need to know where it starts in order to read its "header" and that means the need to read the size of the first chink first.

Now what you would want is a package which has some sort of map (like file allocation table on disk drive) from which you can quickly read where certain file data begins and how big it is.

Yes, I know about that IFF limitation, but I have two solutions:

• Include a chunk at the begginning with the map of the file telling where each file is, in a similar way Ken Silverman's GRP files does.
• Scan the whole file when opening building the map in memory.

What is IFF ?

It is a standard container file format developed by Electronic Arts and Commodore/Amiga inspired by some old Apple MacOS API widely used by AmigaOS. It's still in use by a few formats like Apple's AIFF and Microsoft's WAV (this one using a modified version called RIFF though). PNG file format uses a similar approach too.

You can read the complete description in this paper.

Classes are *simpler* than procedural programming because they allow for *much* easier modifications.
I've never looked at Allegro, so I cannot tell how hard coupling them would be.

Ok, here is my conversion of the unzip.pp straight from Free Pascal RTL.

(...)

Thanks for sharing this.

Didn't know ZIP files allows random access to files. May be I'll rethink this.

[SilverWarior]

Didn't know ZIP files allows random access to files. May be I'll rethink this.

Yes they do. In fact I believe this is one of the main features why ZIP archives became so popular even thou they were other arhive types which offered better compression ratios like RAR archives for instance. That is also the reason why it was possible to extend Windows Explorer to allow working with ZIP files like they are just regular folders.

[Ñuño Martínez]

Before to work in the data containers I was working on the graphics subsystem.

The old way to initialize the graphics display was quite complex. There were a method to create it telling the size, depth and if we want a window or full screen. Then I added a method that implements a few pre-defined "legacy graphics modes".

I didn't liked it so I've finally rewrote the initialization code with a simpler one. Now there's only one method that receives a single parameter: an identifier that tells the kind of display we want (i.e. the bigger definition available, or simulate an old graphics mode as the PC-VGA or the C64-multicolor mode). Then the class decides the actual size and mode (windowed or full screen) of the display from the system information and the configuration. It is possible to drive the way the display will be created by using the configuration file. For example, we can force to create a window of a specific size.

It also defines most methods as virtual so the default behavior can be modified as needed. For example, current code creates the display using true color pixels allways. I'm planning to add to the engine a display class that initializes the code using a shader that simulates 8bpp palette modes (i.e. VGA/MCGA) so it will allow to use color animations and the actual color values of old computers. I just have to figure how to load the color palette information from image files as Allegro 5 doesn't do it.

[Ñuño Martínez]

Ok, I got it.

I've just finished the data package subsystem. There's an abstract base class that defines the interface and defines a few basic tasks. Then you can extend it to use any package you want. Right now I've included a simple custom IFF-based package system, format description has been included in documentation.

I had to add a binding between Object Pascal TStream and Allegro's file system too. I had a few problems with this (the way C and Pascal use pointers and parameters makes binding stuff a bit tricky) but now it works seamlessly and you can use Allegro's functions to load stuff (bitmaps, fonts, sounds...) from my package subsystem.

I think it's time to release a new alpha version of the engine. May be this week-end or sooner.

[Akira13]

One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

[SilverWarior]

make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

Wouldn't that mean that people would be forced to use Lazarus IDE while now you can compile the whole project by using Free Pascal alone. This in turn allows people to use any code editor they want.

[Akira13]

Well, I wasn't suggesting that he has to delete the makefiles from the repository. He could of course (and should) leave them there for anyone who wants to build it that way. I'm just saying it's far easier to make project-specific settings adjustments when you have actual project files to work with.

[Ñuño Martínez]

Just uploaded a new alpha release. Pretty happy with it. Look at it: https://sourceforge.net/projects/min...les/1.alpha.1/

I'll take a break now, until the next LudumDare. I'll still programming but will be stuff for my website because it is a big mess.

One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

May be useful, but that mean the examples directory will became a (small) mess with duplicated names. Anyway, I'll think about it and I'll do something with the next Allegro.pas release (no date though).

[Ñuño Martínez]

One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

As I've said in the Allegro's thread, I think I've found a way to do this in an ordered way.

[Ñuño Martínez]

Project is far to dead.

After releasing a new Allegro.pas version I'm working in MinGRo. I want to release a new alpha version this Friday, so I can use it in Ludum Dare and TINS.

There are many changes, most subsystems are now more robust and with better API (I think). Some of the latest changes where to fix data loading and configuration management. Previous version was confusing and a bit buggy. Also I've improved the sound subsystem.

So a lot of under-the-hood work fixing bugs and improving design, much with the GUI subsystem which was quite confusing even for me! Now it has a more coherent design, it is easier to use and the map editor have (finally!) a proper file selection dialog:
200413_202543.png
It is inspired in the file selector from 3D Construction Kit. I liked it because it is simple. On Windows it is a little bit different: Instead of the "CD", "media" and "mnt" buttons it has 5 buttons for drives.

And see how much has evolved graphically:
170318_1824.png