MinGRo game engine

[Ñuño Martínez]

Backing to topic.

I've just finished the new animation module. I took more time and effort than expected because initially I planned to add animations as part of the sprite engine as I did with the tile engine (any tile may be animated), but just when I started the implementation of the sprites part I saw it would be better to do not do so. As I've said the tile engine is different: the animation module is part of the tileset. After doing some testing with the tilemap example I think I took the correct decision.

But after that I see the current "definition file" I implemented hasn't a good design, so I'll remove the current procedures and implement a simple scripting system. The engine will not require to use it so a different scripting engine can be used instead.

Tello said I'm at 70% of the alpha version.

[Ñuño Martínez]

Last month I didn't work as much as I would like on MinGRo. Anyway I've added a complete command-line simulation so it is now quite simple to add an in-game console, even use the command interpreter to define a batch-like scripting language. It isn't fast and lacks any memory management though.

Also, I've done some internal improvements, bug fixing and documentation updates.

Next LudumDare is near so I decided to make a first alpha release so I can use it in the contest. You can test it too.

https://sourceforge.net/projects/mingro/files/1.alpha/

[Ñuño Martínez]

So I'm back, and I decided to go straight on to finish this engine, or at least a "beta" version.

The first I've done is to rewrite the animation manager and the sprite engine subsystem. In both cases I used classes for everything so each time the number of animations or sprites changed the engine has to destroy and/or create a lot of tiny objects. So I've replaced some classes by records (as discussed here): Less memory fragmentation and less spreading.

Also I've decided to use more ideas from Diana Gruber's "Action Arcade Aventure Kit" book in the sprite engine. As a side effect the change has reduced the code complexity: I think the code (both the engine and the examples) are cleaner and more easy to read and follow. I don't know if it is faster now, but I like it.

[Thyandyr]

Looking forward to the beta

[Ñuño Martínez]

Looking forward to the beta

Me too.

Right now I'm thinking in "data containers". I have an idea of a "packed file" container format similar to Ken Silverman's GRP files but using IFF I think it will work. I'm not sure if a "data container" component that keeps all things in memory is actually needed though.

[Chebmaster]

Why not pk3 aka zip ? You can open and operate them using any file manager. And the code is already there in standard Free Pascal package.
I made me a modified version that can use streams, not just open files directly. Want me to share? (LGPL)

[Ñuño Martínez]

Why not pk3 aka zip ? You can open and operate them using any file manager. And the code is already there in standard Free Pascal package.
I made me a modified version that can use streams, not just open files directly. Want me to share? (LGPL)

Thank-you. Of course, share it. I was thinking about this a lot but I'm still open to new ideas. I'm using zlib/libpng license though and AFAIK it has some issues with LGPL.

Package systems I know forces a sequential access for files. I mean, you have to go file by file until you find the one you want (For example, TTarArchive.FindNext). If the package is compressed then it is mandatory. I don't want to load all data at once but allow to load the data when it is needed, so direct access is desirable.

Also, I need to bind the package with the Allegro file system so I can use Allegro to load data. Of course I can load data in a memory stream then interface the memory stream with the Allegro file system then use Allegro to "actually load" data, but why do it that way if I can bind directly the package with Allegro?

Finally, I like simple things and I find modern programming unnecessarily complex. IFF is simple, flexible and easy to parse. I think an IFF-based package system would be great.