Messages

Thanks for all your feedback. It's always really useful to have this sort of feedback from people who are new to AGS and haven't just got used to it over time.

I do agree with the vast majority of your suggestions -- as always it's a matter of prioritisation. Once AGS 3.2 is out of the way with the new audio system, hopefully there will be an opportunity to implement some of these type of suggestions.

I can't believe how many times I said the word "time" in that interview ... it must have been a bad day when I answered it!

Interesting, I'll see if I can reproduce this.

Also, when I make a 16-color game and play it in a window, Windows 7 reverts to the basic graphics style (no transparency, or shadows, etc).  So now I will only make games in 32 color for that reason alone.

Vista and 7 do this with 16-bit colour DirectDraw games. If you use Direct3D or 32-bit colour, as you've noticed you won't get this.

Hmm that's strange. It might be worth trying to un-install AGS 3.1.2 SP1 and re-install it, but I'm not sure why this would be happening...

Can you try out the 3.2 RC 2 release from the beta thread and see if you get the problem with that too?

What problem are you seeing? Is it just that you're not getting any black borders, or are they going wrong in some way?

What I found with my monitor was that when I ran a 1024x768 game with widescreen borders, the monitor tried to be clever and automatically adjusted itself to remove the borders again. I don't know if this might be happening to you, too? Try manually adjusting the screen horizontal alignment to fix it, and then see if your monitor changes it back the next time you play the game.

Can you open the Event Log (under Administrative Tools in Control Panel) and see if any errors are generated there when this error happens?

Did you get any errors saving the game the last time before that? Are you saving it to your hard drive rather than a USB stick or anything like that?

I have retested this on my machine, and it is definitely working for me with 320x240 and 640x480 games.

However, it doesn't seem to be working with 800x600 games, and 1024x768 games create the sideborders but the game screen isn't properly centred -- I will look into these issues.

To those of you saying it's not working, what resolution is the game, and what is your Windows desktop resolution?

What had you just done when this happened? Had you just imported some new sprites?

I just noticed that the Scripting Tutorial still uses GetGlobalInt, which is probably what is confusing some people into thinking they need to use it. I've now changed the tutorial so it doesn't do that any more.

Hmm, that still shouldn't crash the engine though. I'll see if I can reproduce it.

Heh, yeah, but in this case I wont see the text I am going to proofread 
EDIT: oh, wait. Perhaps I can switch focus to some other window, but leave game not minimized.

Clicking on an empty bit of the Windows taskbar is the easiest thing to do -- since it's always there and activating it won't put any windows on top of the game window.

I've just discovered that the engine crashes if you try to call Character.PlaceOnWalkableArea from game_start. Makes sense seeing as no room is loaded yet, but the error message isn't very friendly

Heh, I'll take a look at it. There are various ways of crashing AGS by doing room-specific stuff in game_start, I'll continue to address them one by one as they come up 

Verified.  Upgraded to  latest RC and error no longer appears..  Thanks!

Glad to hear it!

If you've got one easily to hand, that would be useful, thanks!

[Neat fading]

I've been misled into thinking it was well implemented and supported because of one sentence in the introduction tutorial (http://www.adventuregamestudio.co.uk/acintro1.htm), coz that one says: "The advantage of a palette is that the game size will be smaller, and the game will run up to twice as fast as using hi-colour. Neat fading and colour cycling effects are also possible." If that is in fact not really the case (or at least not officially supported), shouldn't that part be edited out?

Hmm good point, that page was originally written a long time ago. I will re-word it to reflect the fact that 256-colour games are now not recommended.

I have this small suggestion - to completely pause the game when Pause/Break is pressed (and unpause by any other key).
Reason is quite uncommon: this will make it easier to do proofreading when testing a game, because you won't worry of speech text dissapear too early 

The easiest way to do this is to run the game in a window, and then simply press Alt+Tab or click outside the window when you want to pause the game -- that way the game window will still be visible but will be paused.

Thanks for testing it.

Interesting, I'll see if I can reproduce this.

There are various ways to script around this, though I do agree that it's not as simple as it should be. It's definitely something I'll consider for a future version.