Topic: AGS4 cleanup branch

[Alan v.Drake]

Note: this topic is mainly targeted to AGS source developers.

As you probably know if you've followed the recent developments, I've started a branch named AGS4 whose purpose is to clean up the codebase from the old dead code and legacy features.
This is a requisite for future development, because others, like me, have faced the despair of trying to add new stuff while keeping the old stuff from breaking.

So we should diverge, AGS 3.4.1 "Classic" will be mantained separately since it's feature complete and able to play older games, while AGS4 will be the foundation for new features and refactoring.

This is the current battle plan.

I've already cut away some nasty stuff, but much more remains.
The branch is in a working state. Note that to open projects they must be first upgraded through the latest 3.4.1. As always, be sure to make a backup of the project.

Alone I won't be able to see it to the end FOR I HATE CODING but if we can coordinate and help each other identifying and cutting away the rotting parts, it won't be too long until we can finally make the code easier to deal with.

You can find me on AGS discord if you wish to discuss, share doubts or ask questions.


- Alan

[selmiak]

I am no source dev but this is great! Keep it up!

[Atavismus]

I am no source dev but this is great! Keep it up!

Same here.
Great initiative indeed.
I really hope several dev here could coordinate on a single project and make AGS a modern engine (but I know it's uneasy to make ppl agreed).
Good luck!

[Danvzare]

I am no source dev but this is great! Keep it up!

+1

[Snarky]

Yeah, sorry to not be any help on this, but I can at least add some suggestions for stuff to clean up:

The AGS general settings pane is littered with unnecessary switches, and even a lot of them that aren't explicitly identified as backwards-compatibility options should be rooted out. I'm thinking particularly of "Automatically move the player in Walk mode", "Automatically walk to hotspots in Look mode" and "Override built-in inventory window click handling": there's no reason to provide any built-in behavior here rather than just script it in the appropriate game templates. It's just one more complicating factor when a developer has to try to figure out how the engine behaves. Similarly, the GUI visibility setting "When mouse moves to top of screen" should be eliminated. All this stuff is legacy from when AGS was an engine squarely focused on making games in the  Sierra SCI style, and it is superseded by newer, more general functionality.

[Radiant]

From this old bug report: almost nobody uses MIDI any more, and as a result numerous Windows/Linux systems don't come with MIDI drivers by default. However, AGS insists on initializing a MIDI driver on startup (as well as a MOD and XM driver), and if this fails then depending on system AGS may abort, or refuse to play any music at all (including OGG/MP3 music).

Likewise, I have no idea why the Preload image must be in the long-obsolete PCX format (last updated in 1991).

On the other hand, I'm not sure if I see the point in removing aliases to functions (e.g. RawDrawLine to Room.GetDrawingSurfaceForBackground().Drawline) when all the alias does is call an existing and retained function with some default parameters. It seems to me that all this does is make your new version less accessible to existing coders.

[Alan v.Drake]

On the other hand, I'm not sure if I see the point in removing aliases to functions (e.g. RawDrawLine to Room.GetDrawingSurfaceForBackground().Drawline) when all the alias does is call an existing and retained function with some default parameters. It seems to me that all this does is make your new version less accessible to existing coders.

Perhaps it's so, but since the ultimate aim is to refactor and improve, the less is there to keep track of, the better. It'll be chance to redo some things differently, for example I'd like to have audioclip instances instead of being returned an enigmatic audiochannel that may or may not be what I had instanced it from, colors should be 32bit and not 16bit + hacks for the first slots, etc.
AGS Classic is not going anywhere and AGS4 is a long term project.

In the meanwhile I think it's not a bad thing to put a stop to the use of deprecated functions, they confuse new users.

- Alan

[Crimson Wizard]

From this old bug report: almost nobody uses MIDI any more, and as a result numerous Windows/Linux systems don't come with MIDI drivers by default. However, AGS insists on initializing a MIDI driver on startup (as well as a MOD and XM driver), and if this fails then depending on system AGS may abort, or refuse to play any music at all (including OGG/MP3 music).

I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.
Some strange logic in Allegro library, that I could not understand at the time, prevents DIGITAL sound initialzation in case if MIDI support, or something related to it, is missing.

Either Allegro should be investigated and fixed, or AGS needs to move to another library, even if using another library (-ies) for sound only.

[Radiant]

I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.

That's a good point, but it may be that the first function call (for MIDI+DIGI both, if I understand correctly) is causing problems in Allegro.

[Crimson Wizard]

I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.

That's a good point, but it may be that the first function call (for MIDI+DIGI both, if I understand correctly) is causing problems in Allegro.

Yes, it could be; I think this may be tested out by disabling MIDI in setup file ("midiid = 0"), then sound init will be called with DIGI/ no MIDI at the first try. If that works, unlike other attempts, then adding a MIDI-disabling switch will have an actual meaning.

[Snarky]

Another thing to get rid of in 4.0: The "Run the next loop after this" option in the view editor, which is unnecessary since we can have unlimited frames per loop, and only causes confusion.

[Radiant]

More legacy switches that could be deprecated:
* Anything related to 16-bit color depth
* Right-to-left operator precedence (the checkbox left-to-right defaults to ON, but AGS 2.6 and earlier assume right-to-left)
* Any alpha blending other than "proper"
* Non-anti-aliased TTF fonts
* Split resource files every X megabytes (a setting meant to distribute your game on floppy disks...)
* Being able to set for every individual sound and music file if it should be inside the EXE or not
* Integration with the Vista Game Explorer (which doesn't exist in newer windows versions), as well as the -registergame parameter
* Enhanced saved games should be on (the only reason not to is to save a bit of disk space)
* The low defaults for maximum sprite cache

[Alan v.Drake]

Operator precedence and alpha blendings other than "proper" have already been disposed.
Don't know about aliased ttf fonts, some might be designed to look good, assuming font hinting is in effect.
Splitting resource files might still have meaning, if the order of the resources is always the same. Could help when updating a game through steam, maybe.
Game Explorer is probably dead, so yeah we could get rid of it.
Enhanced save games is the option to double click on the save files to open them with the game, I don't think you were meaning that.

I also agree with Snarky about those old built-ins functionalities that would need a good look over

- Alan

[Crimson Wizard]

* Non-anti-aliased TTF fonts

Don't know about aliased ttf fonts, some might be designed to look good, assuming font hinting is in effect.

I am also not sure about this, I recall seeing certain troubles with TTF anti-aliasing. That may depend on font, the size it is scaled to, and on library used to AA them (latest FreeFont used on Linux versus older version currently used on Windows).
Perhaps making Anti-aliasing an individual font's property could be a better decision? By the way, if I remember correctly, it is even technically possible to toggle font's AA at runtime.

* The low defaults for maximum sprite cache

Current new default is 128 MB.

[Monsieur OUXX]

I agree with everything above, except (maybe) these:

* Non-anti-aliased TTF fonts

Don't know about aliased ttf fonts, some might be designed to look good, assuming font hinting is in effect.

I am also not sure about this

Me neither. Don't some people use this to generate multi-colored fonts? if there is an automated antialiasing it might mess uptheir carefully crafted font.

* Being able to set for every individual sound and music file if it should be inside the EXE or not

I don't this topic well enough : Couldn't that be helpful to upgrade just the EXE of a game without downloading the entire game again? I favor the principle of storing the resources outside of the EXE.

[Radiant]

I don't this topic well enough : Couldn't that be helpful to upgrade just the EXE of a game without downloading the entire game again? I favor the principle of storing the resources outside of the EXE.

I understand the point of not having certain resources inside the EXE.

I do not understand the point of setting for each individual sound file whether that particular sound file should be inside the EXE or not. In practice you either turn it on for ALL files, or off for ALL files.