AGS 3.0 Final - it's been a long road

[TheMagician]

Well, it's easy enough to just delete and re-type the closing bracket if you want to simulate a "match brace" type feature? Would pressing Ctrl+B actually be any faster?

Well but that only works for the closing bracket, whereas Ctrl+B also worked with the opening bracket.
But I agree, it's only a minor issue.

[Pumaman]

One of the greatest parts of the SCM file type was that it allowed portability not just between OSes, but also between versions of AGS. Has the way the SCM files are saved changed since AGS 2.72? If so, is there any way to restore the old behavior in saving these files?

Hmm, ah yes there does seem to be an issue there. I'll get it fixed.

Sure.  I mean compile warnings like ags 3.0 special 'normal view x has less than 4 loops and could crash the game', which pulls up a nice box to tell me about it and a loud beep every time I compile.  I'd just like an option to disable these warnings altogether (and I can't seem to find one) since I'm aware of what they are

The message box for both warnings and errors is controlled by the "Show message box when there are compile errors" option in Preferences. Or are you asking for an option that shows the message on errors, but not on warnings?

Oh, one thing I forgot to suggest was perhaps a more robust naming system for sound, music and voice files?  I can't begin to explain how many times I've had to go back and listen to sound or music files to remember what they were.

In a way, I think this is something that should have been part of AGS 3.0. However, it's also something that's ripe for a plugin to implement. With the editor plugin API in AGS 3 being much more usable than in 2.x, it should be possible to provide a music/sound manager through a plugin -- somebody's already working on one, I think. And if nothing is made in the end, it's always something I can add to a future version.

I can:  multi-tiered rooms!  I've recently been experimenting with this in Boyd Quest, making several playable rooms on one screen, each offset by enough pixels to not be visible and then popping the player to the new walkable zone.  This saves me a great deal of time, both in consolidating rooms in an area together and allowing me to bypass the often annoying look-up-destination-coords-and-flip-between-rooms-to-get-them-right phase since it's all in one area.  As a result, I tend to use more objects and certainly more hotspots.

However, doing this sort of thing leaves AGS with a huge background image to process and lots of objects to process too. It's not something I'd recommend doing for performance reasons, therefore I'd prefer not to encourage it by allowing unlimited objects.

[monkey0506]

One of the greatest parts of the SCM file type was that it allowed portability not just between OSes, but also between versions of AGS. Has the way the SCM files are saved changed since AGS 2.72? If so, is there any way to restore the old behavior in saving these files?

Hmm, ah yes there does seem to be an issue there. I'll get it fixed.

Thanks as always Chris.

Edit: Now this might be a silly question, but the DrawingSurface functions aren't really suited to (i.e., even feasible for a future version), say, creating an alpha channel are they? I was thinking that if I did:

Code: ags

DynamicSprite* sprite = DynamicSprite.Create(100, 100, true);
DrawingSurface* surface = sprite.GetDrawingSurface();
surface.DrawImage(0, 0, 82, 50);
surface.Release();
Overlay* ov = Overlay.CreateGraphical(sprite.Graphic);

I could create a semi-transparent Overlay. If that's simply not reasonable I could just set the sprite as the background of a GUI and use the GUI.Transparency instead.

[Shane 'ProgZmax' Stevens]

The message box for both warnings and errors is controlled by the "Show message box when there are compile errors" option in Preferences. Or are you asking for an option that shows the message on errors, but not on warnings?

Exactly.  I'm not so concerned about warnings but I definitely want to know about errors .

[DoorKnobHandle]

Bug, bug, bug...

And a pretty big one, if I'm not doing something wrong somewhere.

I'm trying to RawDraw a sprite/image to the screen. I have the game set to 16-bit, have the image saved as standard 24-bit bmp-file (same configuration worked perfectly fine in all older ags-versions), I call Surface.DrawImage ( x, y, sprite_slot ) with the slot and it comes out like this:



In the editor, it looks perfectly fine though (compare to my current avatar). Am I doing something wrong?

(AGS 3.0 Beta 15 - DirectDraw 5)

I can't believe no one would've picked this up until now, though, so I'm kinda sure I have done something wrong somewhere... I've tried it on multiple projects (including empty games), it's always the same.

[monkey0506]

Are you sure the room background is the same colour depth as the sprite? Because if it isn't (i.e., if you imported the room background before remembering to set the game's colour depth like I always do) then you'll get funky results like this.

Just as a test, does doing this yeild similar results?

Code: ags

DynamicSprite *sprite = DynamicSprite.Create(Game.SpriteWidth[SPRITE_SLOT], Game.SpriteHeight[SPRITE_SLOT]);
DrawingSurface *surface = sprite.GetDrawingSurface();
surface.DrawImage(X, Y, sprite.Graphic);
surface.Release();

DynamicSprite.Create (AFAIK) always creates a new sprite at the game's current colour depth. So if it properly draws the sprite to the DynamicSprite then it may just be a colour depth issue with your background.

[DoorKnobHandle]

Ah, I didn't even have a background imported. That used to be impossible to forgot due to an error in the older versions, now with 3.0 you can actually leave the room black and run your game (which is great), but it can cause these ugly errors. Hmm... Maybe a simple message-box could help here, CJ, warning the user when the background color-depth is wrong? Definitely leave it so that you don't need to import an image for a room though (I really love this as I hated how you had to have black-only images floating around on your hard-drive for creating simple test-games in the older versions).

Thanks monkey!

[monkey0506]

"if you imported the room background before remembering to set the game's colour depth like I always do"

Can't possibly imagine how I might have pin-pointed it so quickly.

Regarding the "black background", I think you're probably just using Rui's new Default Game template which does define a Room1.CRM file but it's just a blank, empty room with a black background, most likely imported at 8-bit colour depth (since that is the "default" colour depth for AGS).

[DoorKnobHandle]

Hmm... No, I'm sure I used the Empty Game Template. It comes with a room as well, though. Maybe the addition of rooms in 8-bit to any template should be over-thought again as it can cause problems, especially with people new to the editor or version?

[Pumaman]

Hmm yeah, the room background colour depth thing. The reason it works this way is because originally it was supposed to be a handy feature that you could have some rooms with different colour depths to do fancy effects. But nowadays I'm becoming more convinced that AGS should just convert all the room backgrounds to the game colour depth automatically...

[GarageGothic]

It would be nice if you could select different color depths on import for compression purposes (because who really can tell the difference between a 16- and 32-bit background?) and have it converted to the proper color depth on run-time. But perhaps it would cause too much of a slowdown.
I originally considered using 16-bit backgrounds and 32-bit characters to make the download smaller (my 640x480 game has around 35 rooms, and another few backgrounds used for cutscenes). But it created too many problems with RawDraw and DynamicSprites. Now that we can RawDraw directly to sprites, that is not really an issue anymore, so it could in fact be possible. But I would prefer it if it was in fact supported by the engine and wasn't just a hacky workaround where I have to remember to reset the color depth every time I re-import my art resources.

I think a lot of games could benefit from 32-bit sprites - think Nelly Cootalot with anti-aliased characters - but most of the time the extra file size of the backgrounds just doesn't seem worth it. So rather than forcing all art into the "correct" color depth of the game, I'd rather suggest making it easier and less problematic to mix color depths.

[Ghost]

...because who really can tell the difference between a 16- and 32-bit background?

I can. All you need is a small gradient, and you can easily see the difference.
Even simple gradients tend to look very grainy in 16bit but work perfecly in 32bit... might be me mesing up things again...

And something that has often puzzled me: If I save a room as a 16bit BMP and import it into AGS, set to 16bit too, all I get is a blank screen. Saving it as 24bit then works. Is that me misunderstanding something about colour depth?

[Dusk]

Hi, while working on SOTE with the latest beta (15), there was a total system freeze while compiling.
On reboot, the editor didn't open the game... not finding the xml root element in the Game.agf file. I (h)examined the file and it was just a pair of megabytes of NULL bytes... 

I restored the file from a backup (and I'm not sure of what could happen... please warn me if something can seriously break by using an old Game.agf with the newsest files - for example, there are new views/rooms/sprites that weren't present at the backup time... but I suppose that the Game.agf is primarily a collection of general settings/room index....)

By the way, my suggestion here is making AGS keep some sort of Game.bak updated to the latest non-potentially-distructive operation (before opening Game.agf for writing the XML serialization, I suppose).


Another v3 thing: I didn't read exactly ALL the recent threads, has the source versioning control been described somewhere? I setup a Perforce server and we'd like to work in concurrency but I'm not sure of what can be done without causing some breakage.
I saw that rooms and scripts are in separated files, and that's great, but what happens with global stuff such as the Game.agf and the sprites file?
I hope that in the final version documentation it will be fully described what can be done causing no harm and what can't

BTW, we SOTE guys love AGS 3

Bye!
D.

[Pumaman]

It would be nice if you could select different color depths on import for compression purposes (because who really can tell the difference between a 16- and 32-bit background?) and have it converted to the proper color depth on run-time. But perhaps it would cause too much of a slowdown.

As Ghost says, if you have any kind of smooth gradient (eg. the sky) then converting to 16-bit can make it look grainy.

And something that has often puzzled me: If I save a room as a 16bit BMP and import it into AGS, set to 16bit too, all I get is a blank screen. Saving it as 24bit then works. Is that me misunderstanding something about colour depth?

Not sure what you're saying here, can you clarify? Does AGS appear to import the image but actually just give you a black screen?

while working on SOTE with the latest beta (15), there was a total system freeze while compiling.
On reboot, the editor didn't open the game... not finding the xml root element in the Game.agf file. I (h)examined the file and it was just a pair of megabytes of NULL bytes...

Hmm, well AGS doesn't actually open the Game.agf file until it has constructed the XML to save, so if it has hung in the middle of the actual file write that seems to indicate a potentially serious problem.

However, I'll certainly look into adding some sort of backup of the file, like 2.72 used to do for the main data file.

Another v3 thing: I didn't read exactly ALL the recent threads, has the source versioning control been described somewhere? I setup a Perforce server and we'd like to work in concurrency but I'm not sure of what can be done without causing some breakage.

There is a "Source Control integration" page in the manual that briefly describes it. At the moment, AGS doesn't add the sprite file or the music/sound files to source control, because they are large binary files and therefore not really suited to source control systems. This does pose a bit of a problem for using the source control feature, because the scripts and rooms are the only things that you can sensibly check in/out on different PC's. With the current way the sprites are stored, I'm not sure what can be done to make this more usable.

[GarageGothic]

As Ghost says, if you have any kind of smooth gradient (eg. the sky) then converting to 16-bit can make it look grainy.

Well, that's really beside the point. A lot of games that don't even use gradients - pretty much anything with hi-res line-drawings - would benefit from anti-aliased characters while 32-bit backgrounds are not really necessary.  I would probably convert my whole game to 16-bit if it wasn't for anti-aliasing only being availble in 32-bit.
I'm just asking you to please not force me to use 32-bit backgrounds just because the final game will run in 32-bit mode. I appreciate that you might not consider it important enough to make a special checkbox for it when importing my art, but please don't force the editor to convert all my backgrounds to the game's color depth automatically (as you said in your reply to monkey and dkh), bloating the size of my distribution file for no good reason.

[LimpingFish]

I beg to differ.

32-bit backgrounds are essential to my work, and the day the function appeared in the editor was a godsend. Without the ability to display 32-bit backgrounds, I may as well bin AGS right now, because, to be honest, if we were still stuck with 16-bit highcolour, I'd have found an alternative program by now.

[GarageGothic]

Jesus H. Christ, why is it that I'm always misunderstood in these bloody forums. Are my communication skills really that poor?

I have never said that we shouldn't have 32-bit backgrounds. I merely responded to CJ's mention of forcing 32-bit color games to convert all background to 32-bit, asking him to please keep the current feature where it's possible to import backgrounds in 16-bit and then switch back to 32-bit before importing your sprites.

[Shane 'ProgZmax' Stevens]

I understood what you wrote perfectly, and I agree that keeping things as they are is the best way to handle it.  I'm also not sure why 32-bit is 'essential' to pre-rendered art but I'm one of those old guys that likes to preserve color count and filesize when possible!

[Dusk]

Hmm, well AGS doesn't actually open the Game.agf file until it has constructed the XML to save, so if it has hung in the middle of the actual file write that seems to indicate a potentially serious problem.

I just wanted to clarify that the system freeze didn't probably depend on AGS: it was a total Windows freeze (I don't know the details: it happened to my friend BobaFonts... maybe some hardware issue or... eeek... Vista issue ) that happened in the worst moment...

However, I'll certainly look into adding some sort of backup of the file, like 2.72 used to do for the main data file.

Perfect, thanks 

There is a "Source Control integration" page in the manual that briefly describes it. At the moment, AGS doesn't add the sprite file or the music/sound files to source control, because they are large binary files and therefore not really suited to source control systems. This does pose a bit of a problem for using the source control feature, because the scripts and rooms are the only things that you can sensibly check in/out on different PC's. With the current way the sprites are stored, I'm not sure what can be done to make this more usable.

Mmm yes, I can understand the problem here. Rooms and scripts are the most changed units, so I suppose that this is a "good enough" situation... and we just have to be careful to not add sprites without manually "keep in sync".
I'll let you know of problems/ideas as we have time to experiment with collaborative development

Thanks, bye!
D.

[Ubel]

As a small request, could you make the Sprite Manager window (the one that appears when you're selecting which sprite to use for GUI graphics, views and such) resizable, or at least a bit bigger? I find it too small to browse through lots of sprites right now.