Messages

Could it be that the multiplier matches your screen resolution? IIRC allegro used to run borderless fullscreen if the windowed window is the same size.

- Alan

You could make a separate repo just for the compiled libs.
Probably simpler that way, and you don't have to gamble on the permanence of file sharing services.

- Alan

Name: Death
Age: Undisclosed
Status: Single
Hobbies: Collecting souls
Likes: People full of life, scythes
Dislikes: Skeleton jokes

"We'll have a date to die for"


- Alan

This all happened because the new resolution was recognized as "High Resolution" being > 320x240.
This behaviour was designed for switching from 320x200/240 to 640x400/480 and back. Custom resolutions came much later and do not play very well with that.
It must have asked you if you wanted to resize the guis, but I'm not sure if the resizing is proportional or not.
Your old sprite assets and system menus are still considered "low-res" so are now being doubled on the fly.

You can go back by setting the old resolution, or deal with the side effects.

- Alan

This is the quality of a $626k game, top notch beta testing and quality animations

- Alan

[really]

Forgive me for partially hijacking this thread, but since AGS source code is undergoing some significant changes, we could really use a feature demo game.

Might have one feature each room so it would help both us with testing, and AGS users by providing a reliable reference on how to use all the features.

God knows how it would have helped me back when I was learning AGS. It would help even know, I never remember how half the stuff is supposed to be used.

Since we're pretty busy enough with the source, it would be nice if the community could rise up and help compose this testing behemot. Many people could pick up a feature and prepare the room, which will later be compiled into one big demo game.

This is moderately urgent, if you want to discuss come to AGS discord. Thanks.


- Alan

I do not know if you realize, but I did more wrong to this project than good. Practically deviated development from the way it should have went.

The only wrong thing was keeping the compat.
You did reorganize the code better and made a player for older content. That's ok too I guess.

My memory is completely unreliable, but I think you got peer pressured by the community into keeping the backwards compat. You do have a weak spot when it comes to ags, probably because you've been in here forever, how many times did the agsers use that to exploit you?

As I see it there's no great damage, it's still better than the original code. To me the day the code was opensourced feels like just 2 years ago.



- Alan

There are already some attempts in the work: Scotch is working on a Javascript AGS version, Tzachs is working on a C# redesign and Calin has made an adventure engine with LUA.

On my part I'm planning to strip AGS from all the backwards stuff, doesn't matter which engine will end up winning the throne, this has been postponed far too long (I blame all the backwards evangelists from AGS forums) and will help make things clearer improving also manteinance a little.

And who knows... perhaps others will join if the code looks less aggravating, after all AGS already got all the features and IDE ready.


- Alan

You didn't change windows default theme colors, did you ?

- Alan

[before]

1. Most AGS games aren't updated after release in the first place.

You're forgetting game devs and their thousands tests before release!

2. Since most game makers won't need this, and may not even encounter the problem, it's not something they'll be looking for.

They won't... until they hear about it on the forums. "heelo freinds, I made game and found fix for bad savegame load crash - cheers :·))" - first result from google

3. Even if they do, why would they go to so much trouble to load old savegames unless their game is "professional-level"?

Well that's exactly the point, I would hope they didn't bother, unless the game is "professional-level".
Other cases may be not-adventure games where the savestate could be useful but not mandatory, AGS is flexible so you can never tell.

- Alan

If you are concerned about wasted work, I would say that around 90% of code I wrote for this task became useful for other purposes, such as creating cleaner save format  and big refactoring of saving/loading process for both game data and savegames (some of it is already in the current version).

If it make things cleaner, all the better.

This was also in plans - to support user data in saves.

Some will probably do this, for some games. But others won't. There are AGS users who do not have big experience with game making and working around saves.

Also, there are kinds of games and/or situations where user would hate if they will have to restore and find their character (and other objects) not in position they left them, simply because game developer fixed few bugs and released a patch.

Those who want to update commercial games must learn to handle these things, no other engine holds your hand in this regard, AGS is easy because it does all the work for you, but this comes at a price. There is no direct control on how everything is being saved or loaded, even with a callback it won't be possible to guarantee that the savestate is free from undefined behaviours. Undefined behaviours are the source of all evils and should be reason enough to prevent the loading of broken savestates.

Adding custom user data in saves can enable those who need it to prepare a fallback by storing the essential information, recognize that the save is for an older version and perhaps restart the game from chapter X instead of restoring the state.


I don't want to be a dick and this is just my opinion, but making mismatching savestates able to be loaded means that *absolutely everyone* will exploit this feature, even if they don't understand how to use it or simply don't care. Then they will come here, complaining that something doesn't work right.
Never ever underestimate fools.


- Alan

CW, is this really a sane feature or is it just going to complicate things? I remember being very skeptical about it when you mentioned this stuff.
A savegame is worth nothing, it so far below below recognition, what's with all the hardon about upgradeable saves? This is madness.
Breaking compatibility is the expected behaviour. You know you're all going to regret this.

Why cant game developers just make hardcoded checkpoints for players so they can recover from there without fear of mismatches?

You want to handle old saves? Add some metadata to the save file instead, make it readable without actually loading the savegame and there you have it.

EDIT: Let me expand, with custom metadata handled by the game dev himself, there's no need to even load the savestate, he can check it's a older version and use the metadata to rebuild a consistent state (restart the chapter, whatever). No need to bother listing conflicts and mumbo jumbos. Also they could be useful for other reasons like showing how much gold the player had in that savegame, etc.

- Alan

What happens if there's a part of the screen where all three layers are present?

- Alan

And maybe an improved save system (to avoid corruption between version).

I don't agree with this.

Let's make one thing clear: AGS savegames are not savegames, they are *savestates*.
By design savestates can't help but corrupt when you change the game data. Making them pretend they work is bad, real bad (and also a waste of time).

Forcing a savestate not to fail will lead to all sort of mismatches which may lead to bugs and lots of headaches and despair.

If you need an upgradeable savegame system you'll have to code one yourself.
An upgradeable save system means you're storing the version of all the stuff you need to serialize along the data, so with each newer version you add the required transformations needed to upgrade the various subsets of the saved data.

That way older saves are able to execute all the required steps to correctly upgrade the data structure.

This cannot be done engine side, the engine has simply no clue what you're doing between versions, it cannot keep track of this stuff.


- Alan

Thanks! I remember that, and the considerable resistance against making the default template "too good", thereby either discouraging newbies with impossible standards or tempting them to use the defaults rather than make their own.

Too good?  Whew, when I tried AGS for the first time I was about to drop the ball for how ugly it looked,
Presentation is important, sadly.

As they say, you only get one chance to make a good first impression.

- Alan

SP3 had become the de facto standard, due to many drivers and programs requiring it specifically.
I'm surprised there are still people running xp sp2 and below... there's not even reason not to upgrade.

4.0 or 4.5 is a non issue for mono, as long as the features being used are supported by both, it should compile all the same.

- Alan

[utterly disregard retrocompatibility]

As discussed before, AGS is a pain in the ass to code for, there's much legacy stuff lying around that becomes a hindrance to refactoring attempts. It doesn't look like much at first, but trust me, there are so many little things and they all pile up. Which leads to discouragement.
IMHO that is the main reason there are so few active developers. Only people with a vested interest on AGS can have the proper motivation to try. Or madmen.

I was suggesting to split AGS into a legacy player branch (maybe AGS classic as Darth suggests) that only receives small fixes, and let the main development utterly disregard retrocompatibility, so new developers can actually develop instead of getting deadlocked into a code nightmare.

You don't need retrocompatibility when you make new games.
New source developers don't give a damn about retrocompatibility.
No one wants do deal with retrocompatibility.
Everybody but the users hate retrocompatibility.
New coders just want a good game engine that can be easily customized.

Last year I worked on a few new features, and I suffered way more than necessary, a dozen files just for a single feature, time lost because of gotchas and surprises. And I had prior experiences in messing with the sources.
Imagine what a new developer dabbling with AGS source code has to go through: he wants to change a function, so he changes the code where he would expect it to be changed, only to find out nothing changes, because that part of the code is actually legacy code and the actual one has a different name, he fixes it but something else breaks. No wonder he gives up and looks elsewhere!

Writing a new AGS from scratch is too big an undertaking, it will never happen. The only chance for things to get better is to start cutting away the dead weight.
8/16bit color support ? Rest in peace. Left-to right operator precedence ? Shouldn't even be a question. Old audio system ? Nope. And so on...

There's plenty of this stuff that makes it impossible to even imagine how to rewrite, because it's all intertwined. The knowledge required to change things without causing a nuclear meltdown is no laughing matter.

I had to refeer to CW's knowledge multiple times to properly wrap up most of my features, or I would have broken compatibility several times, I pretty much went forth blind with pure brute force, with little to no clue about what the heck I was doing.


As things stands, I feel too overwhelmed to touch the code, at least until I realize I really *really* need a new feature.

That said, I gotta thank you CW, you've improved the state of the code a lot, I probably wouldn't have even tried to code on AGS again if it weren't for that. But the legacy stuff has to go, only you know enough to make sense of it, I don't think anyone else can without going mad.

Others seem to create their own versions of AGS rather than contributing to the main engine(Draconian). Maybe I am wrong about that?

You're mistaken, the Draconian edition may be tailored for my purposes, but most of the feature branches have made their way to the main engine. Except few small things and the new blend modes feature which is kinda lost in limbo, I'm not too happy the way I coded it but I can't get myself to suffer more on it (it works good enough, but the code is not good enough. Stalemate).

- Alan

Heh, perhaps we should just rename MaxChannels to ReservedChannels, we always end up realizing that it reserves channels, but the next time it comes up no one remembers and everyone is in doubt again.
It's a vicious cycle.

- Alan

Exposing AudioChannel that way was a bad design decision. It would have been better scripting-wise if an audioclip instance was returned instead of the channel.
Then knowing if the clip is playing and manipulating its properties would have been a no brainer.

Could be something to implement in a future version, 3 years from now when I'll feel like doing more coding on AGS source. 

- Alan

You might be missing some DirectShow filter for decoding that format.


- Alan