Messages

The next version of AGS (3.2) supports this, you can try out the RC3 release which is available in another thread here.

You shouldn't get any freezes like that in DirectDraw mode -- however, AGS wasn't designed for working with backgrounds of that size; bear in mind that a 5000x5000 image at 32-bit takes up 100 MB of memory. This is something that AGS could be optimised to handle better, but it's quite a specialist requirement compared to what people usually do with AGS, which is why it's not something that I've really spent any time on improving.

If we end up going somewhere super-hot like Italy, maybe late June/early July might be a better bet to avoid us all melting into a hot tub of human remains?

Yes, I am planning to do so in a future version.

Rooms create at the resolution of whatever the default setting was, which I consider a bug.  I have the settings at 320x240 and it is consistently creating 320x200 rooms which I must then load a background into to adjust to the proper resolution.  Normally I wouldn't have noticed but I was testing a gui in the empty room and since 40 pixels were missing I couldn't see it and spent 20 minutes wondering why.

This is because the default room template is a 320x200 room. You're right that it's counter-intuitive but you can easily fix it by creating your own New Room Template at the right resolution, and then using that for your new rooms. I need to consider how to improve this.

Currently the plugin API doens't have methods to refresh the script list in the project tree. Generally the plugin API evolves by having methods added to it as and when people need them, so is this something you would like to see added?

This sort of problem is usually resolved by updating DirectX or your graphics card drivers, so it's strange that you're having it on multiple PC's. What is your desktop colour depth in Windows?

It's hard to know, because we'd have to know what percentage of players had a problem. That sort of data is hard to come by -- especially because most people who have a problem starting a game will just delete it and give up, rather than reporting the issue.

As we've discussed before, this is a feature that can be added, it's all a matter of priorities. There certainly won't be any new feautres like this until 3.2 Final is released

Ah yes, well spotted, in this case it looks like the Game.agf.user file was the file that was actually corrupt. This just stores some preferences and can be safely deleted without losing any game data.

Still, the file shouldn't become corrupted in the first place, please let me know if this happens again.

These are all good points, thanks.

However, the fact that so few 8-bit games are made nowadays means it's just never going to be a high priority to implement changes like this. Is anyone actually making an 8-bit game?

Direct3D doesn't support dynamically enabling/disabling vsync while the game is running, but it does support starting the game up with vsync enabled. This would need some sort of new Winsetup option since by the time your game_start function runs, with D3D it's too late to set the vsync.

Are you using Direct3D when you get this freeze? If so, it's because when you update any image (including the background), AGS re-uploads the image into video memory which can be quite a slow process.

If you try DirectDraw mode you probably won't get this slowdown.

This problem is usually caused by some sort of dodgy video codec, sometimes ffdshow. The AGDI FAQ has some tips for renaming the video files to get around this problem.

Let me rephrase the question ... with the original copy of the game that became corrupt, when it became corrupt was it on your hard drive, or were you editing it directly on a USB stick?

I ask because we have seen problems in the past where people have been editing a game on a USB stick and it hasn't saved the data properly, and has left them with corrupt files.

I don't know if this is a thing that can be asked for during RCs, but I'd like to have the 'exact colour import' option when importing a background back.

This option is already present, in the Preferences screen (not an ideal place for it, but 8-bit games are so rare now that it was just the easiest place to put the option).

Is the game on your hard drive, and not on a USB stick or anything like that?

PlayAmbientSound, PlayMusic, PlaySound are not marked as old style.

I set the general setting to 'Enforce new-style audio scripting' and those commands were still considered valid. (Even though the help says they're obsolete)

Are you sure about this? I just tried it and PlaySound/PlayMusic didn't work when New Stlye Audio Scripting was turned on.

Anyway, I solved the problem by overriding baseline for the object. It isn't a big trouble for me at all, I was just wondering if it is some kind of bug or not.

I don't think it's really a bug, since AGS doesn't claim to sort things in any particular order if they have the same baseline. Glad you sorted it out.


Anyway, RC 3 is finally up! This fixes various reported issues. Please try it out and let me know of any issues.

Do you get the problem if you run the games in a window? Next time you get the problem, can you try temporarily disabling any anti-virus app that you have running and see if that helps -- sometimes they decide to start a scan which can slow things down (though why this would only affect AGS games, I don't know).

The third error is self explanitory:

This game was saved by an old version of AGS. This version of the
editor can only import games saved with AGS 2.72.

AGS 3.x cannot open games that were made with versions before 2.72. You need to load the game into AGS 2.72 first and save it, then AGS 3.x will be able to load it.

Data at root level is invalid. Line 1, position 1.

This indicates that the game file is corrupt for some reason. If it is one particular game that is causing you this problem, try renaming the "Game.agf" file to something else, then rename "Game.agf.bak" to "Game.agf" and see if that resolves the problem.