Hello Marcos,
Thank you very much for your kind feedback.
My answers to your questions are below.
How complex can games built with MiniGUI become?
Pros:
* 2D games are feasible, especially simpler ones: sprite drawing (images), basic animation (via timers or loops), handling input (mouse, keyboard) are all possible. The sample set includes (for example) a Minesweeper game. ([Группы Google][2])
* You get existing UI widgets and windows, so overlay menus, dialogs, simple in-game UI is mostly “free” if used appropriately.
* Portability (on supported platforms), ease of building rapid prototypes if you are comfortable with Harbour/xBase.
Limitations / Bottlenecks:
* Performance: because it’s not built for fast graphics (like a game engine does), performance will likely degrade with:
1. Many sprites / many independent moving objects: redrawing large portions of the screen frequently (especially with transparency, or many overlapping bitmaps) will be slower.
2. High frame rates: getting 60 fps with many moving parts + collision detection etc. might be tough.
3. Hardware acceleration: I think MiniGUI and HMG Extended do not provide advanced GPU hardware acceleration out of the box for things like shaders, full-blown 3D, etc. It’s much more software / basic GDI/Win32 / basic graphics context based.
* Limited 3D: you’d be reinventing a lot or embedding another library if you wanted 3D or advanced effects.
* Memory / resource constraints: depending on platform, image sizes, sprites etc will eat into memory, and garbage / object overhead from using higher level abstractions (Harbour) may add overhead.
* Tooling / ecosystem: fewer game-oriented libraries, maybe fewer community resources for physics, audio, particle systems etc built for HMG. So you'd need to build those pieces yourself or integrate external libs.
Conclusion: you can build 2D games of moderate complexity; think of platformers, puzzle games, arcade style, or simple side-scrollers. Big open world, high FPS action, 3D, or very high-resolution sprite-rich games will be challenging, probably inefficient or awkward.
---
Would it be efficient to create a game engine using MiniGUI?
It depends what you mean by “game engine” and how performance critical a target you have. Here are considerations:
Efficiency trade-offs:
* If you build a lightweight 2D engine (sprite management, basic collision, tiled maps, simple sound) in HMG Extended, you *can* make it reasonably efficient, especially if you are careful about minimizing redraws, perhaps using dirty-rects (only redraw parts changed), optimizing image loading, caching, etc.
* If you need high performance, frequent redraws, many simultaneous moving objects, complex physics, etc., it might be more effective to use a graphics/game library built for speed (SDL, SFML, etc.), possibly embedding or calling those from Harbour. Or possibly combine HMG for the UI part but embed a faster engine for the game core.
* Another dimension is ease vs performance. HMG gives you many conveniences (windows, controls, menus, etc.), so for a game with lots of menus, dialogs, configuration screens, it’s nice. But when it comes to the rendering loop, updating, etc., you may hit limitations.
* Also consider cross-platform requirement: MiniGUI / HMG Extended is more suited to certain OS environments, so if you want mobile, consoles etc, it doesn’t fit as well.
So building a “game engine” in MiniGUI is possible, but you'd probably aim for something simpler / moderate, not AAA. Good for hobby, educational, or specific types of games.
---
Suggestions / Best Practices if You Build a Game Engine with HMG Extended
1. Layering: separate engine core (update, physics, sprite handling) from UI. Use HMG for UI (menus, dialogs), but core game loop perhaps more “bare metal” where possible.
2. Graphics optimizations: see if you can use off-screen buffers, caching bitmaps, etc.
3. Efficient input handling: rather than polling too often, use event hooks where possible.
4. Use timers carefully: many small timers might be less efficient than a single master loop.
5. Memory management: reuse sprites, images etc., avoid leaks.
6. Limiting resource size: image size, number of objects etc.
---
Existing Sample: Tetris in HMG Extended
One useful real sample is “Tetris game”, contributed by Claudio Soto, in the HMG Extended samples. It’s included in version 20.06 of HMG Extended, and now it's available in the PRO release.
This shows that simple arcade-style games are already being done. You can examine how it uses:
* Game loop / timers
* Drawing blocks (images or rectangles)
* Handling user input (keyboard)
* Simple collision / boundary logic
Examining how Tetris is implemented gives a working reference for structuring the game: dividing responsibilities, optimizing redraws, etc.
---
Thank you again for your attentiom.
Best regards,
Grigory