iGame v2 - A well known Amiga game launcher ( New Build! )

[walkero]

I just wanted to say that yesterday I pushed a fix of https://github.com/MrZammler/iGame/issues/162 at iGame repo. I made the necessary changes to be able to see the default image, in cases where there is no game screenshot and no Info datatype installed.

There is no beta version available yet. I hope that soon I will be able to release a new one, after a few more changes I'd like to test. How soon will be that? For sure less than "2 more weeks" (TM)

[Superman]

Nice work and I’m sure that would definitely fix all my issues.

[walkero]

I have a question guys for you. I am thinking to drop completely the tooltypes and use only the preferences as saved from the Settings window. By default iGame will be pretty light, with no screenshot and guigfx enabled. This way new users when they try to load iGame will not struggle with library issues.

What do you think? Any ideas on that?

[DisasterIncarna]

sounds good.

[coldacid]

Sounds reasonable to me. Might be worth improving the documentation alongside so that those who want these features enabled can easily set them up. Alternatively, add options for enabling or disabling screenshots and guigfx in the installer?

It looks like MUI 5 now ships with guigfx.library and render.library by the way.

[walkero]

Might be worth improving the documentation alongside so that those who want these features enabled can easily set them up.

I think the necessary information exists in the guide, but a fast start section might be a good idea.

Alternatively, add options for enabling or disabling screenshots and guigfx in the installer?

I'd prefer to avoid it. The goal will be iGame to start for everyone, as fast as possible, with the minimum of requirements. If someone wants to change the look, he can do it from the preferences menu. Tooltypes existed from a time were no Settings window existed.

It looks like MUI 5 now ships with guigfx.library and render.library by the way.

I know but I believe a lot of people still use MUI 3.8, unfortunately. That means that we can't use any new tricks that do not have backwards compatibility.

[walkero]

@amigasystem
Just wanted to share the following with you. It is not yet finished but when they are done I will release a new beta version for you to test.

[AMIGASYSTEM]

Perfect, the AROS 68k community will be very happy, thank you !

[OlafSch]

@walkero

Great

thank you very much

[coldacid]

Originally Posted by walkero

I think the necessary information exists in the guide, but a fast start section might be a good idea.

Definitely a good idea.

I'd prefer to avoid it. The goal will be iGame to start for everyone, as fast as possible, with the minimum of requirements. If someone wants to change the look, he can do it from the preferences menu. Tooltypes existed from a time were no Settings window existed.

I'm not talking about tooltypes here, but rather provide two different default prefs files and let the user choose which one to install. I'm very much on board with getting rid of the tooltypes config. But that's a different matter from giving users the option of the basic iGame experience for minimal systems, or the full experience for those who have things set up.

I'd have to improve my Installer knowledge, but as far as I know right now, it would be possible to detect in the install script of the user has guigfx and MCC_guigfx installed, and use that to provide the full experience out of box for people whose Amigas can support it, instead of requiring them to manually set it all up after installation.

I know but I believe a lot of people still use MUI 3.8, unfortunately. That means that we can't use any new tricks that do not have backwards compatibility.

Backwards compatibility might put a lid on removing guigfx in favour of picture.datatype. Image scaling was only added in picture.datatype V45 and honestly I'm not even sure if it supports maintaining the image's existing aspect ratio or if it just stretches the image to the object bounds.

By the way, I've made a PR for supporting non-WHDLoad game icon images.

[Radertified]

I think ideally everything could be definable with command line arguments. Fall back to saved settings for whatever command line arguments haven't been given.

This way anyone that wants to boot with/without screenshots, etc. can do so. Plus it opens up the possibilities for easy expansion and implementation of features, such as profiles (which I mentioned in this post).

[walkero]

I think you forget one think. The installer does not copy any prefs file, and the reason is to avoid to overwrite users' prefs. So, any user needs to setup his prefs only ones in a lifetime
To help new users understand the extra features of iGame, that might be hidden on start there are for sure other ways to do it.
Having right now the screeshots enabled by default, brings more confusion to new users than anything.

@Radertified
I am sorry to say but most people hate the terminal. Maybe you and me are the exceptions to this rule. People want to install something, double click on it and start it. They won't use the terminal and they won't read the manual on how to use it.
For example, iGame throws some error messages when a library is missing. Because the icon is set to run from workbench, those messages are not shown to the user, so he needs either to change the icon to shell, or run iGame from the shell. Unfortunately, there are not many that do that, so on the next release I will change the icon to run always from shell, without input of 'course.

[walkero]

Can someone inform me if iGame menu works as it should on ApolloOS or not? I wonder how the menu bug was not mentioned before. Or if it was, it seems I missed it.

[OlafSch]

Originally Posted by walkero

Can someone inform me if iGame menu works as it should on ApolloOS or not? I wonder how the menu bug was not mentioned before. Or if it was, it seems I missed it.

is there a new version to test?

[walkero]

@OlafSch
Not yet, but I hope that soon I will have one. If you would like to learn some details on what I am doing, you can have a read at my blog post at https://ko-fi.com/post/iGame-updates...AROS-A0A676RWS

[AMIGASYSTEM]

Thanks walkero, it would be nice to have also an AROS x86 version, but here things are more complicated

On AROS x86 there is a program similar to iGame, it is called WHD_MENU developed in AmiLua (script) that works very well and that uses as engine Janu-UAE, I attach a small video made with my AROS One x86:


[ Show youtube player ]

[coldacid]

Since iGame is completely written in C, it's theoretically possible to build it for x86, but libraries would likely be an issue.

[walkero]

I wanted to let you know that I just released a new beta version of iGame 2.1b3. It includes the fix for the AROS 68k menus

You can find it at https://github.com/MrZammler/iGame/releases/tag/v2.1b3

ATTENTION: In this beta version a lot of changes happened to the code. This is a highly experimental beta release. You better back up your iGame folder before testing this one.

In this version you will find the following changes:

### Added
- Added a check if the screenshot image is supported by the installed datatypes. If not, it is skipped. This fixes situations where the Info datatype is not installed and no image is shown instead of the default.

### Fixed
- Fixed the menus on Aros 68k. Menus should work on ApolloOS now.

### Changed
- The games list is not multiselect now. This speeds up a little bit the selection of games on slow machines.
- Moved the strings methods to a separate file. Also merged the strcasestr.c and strdup.c files.
- Moved the filesystem methods to a separate file.
- Set local methods as static in the funcs.c and cleaned up the iGameExtern.h from the shared methods
- Now all the libraries open on application start and close on application exit. No OpenLibrary() calls in the middle of the application.
- Moved the joystick methods from iGameMain.c to funcs.c
- A lot of global methods and variables removed
- A lot of refactoring happened, so to make funcs.c file smaller. This makes code more clear and readable.
- All the necessary libraries and interfaces are set to be loaded in the code. No "-lauto" is necessary any more.
- Changed the localization system to support the new menus. Now the strings header file is created based on catcomp

[wiz12]

Thanks for this update walkero, I always look forward to new iGame releases.

[OlafSch]

Thank you

I just test it on Aros Vision and up to now no problems