AGS 2.72 Final 2 - World Cup Edition

[Adamski]

Disabling Alt+X or running in a window is a lot different to disabling a gimmicky device that distorts the visuals (especially when they only work in 32 bit colour games where there'll more than likely be art used that resampling filters only mess up).

[Kweepa]

Too bad that not many 320x200 games are developed in 32 bit. Would it be enough to compile the game in 32 bit mode to make the filters work, or would the art have to be re-imported with the palette set to 32 bit?

It works for everything except rawdrawn graphics I think.
I don't know where you get your statistics on 32 bit use!
It should be relatively straightforward to convert 8bit or 16bit to 32bit for the filters (it wouldn't be necessary to convert back). Of course it would slow things down and consume a screen-worth of memory.

Jesus, now you want to disable the 2X and 3X filters?

Read his post more carefully.

32 bit colour games where there'll more than likely be art used that resampling filters only mess up

There's not necessarily a connection between 32 bit mode and painted artwork. I use 16 and 32 bit just to simplify colour selection.

[Snarky]

Disabling Alt+X or running in a window is a lot different to disabling a gimmicky device that distorts the visuals (especially when they only work in 32 bit colour games where there'll more than likely be art used that resampling filters only mess up).

Running in a window changes the experience just as much as smoothing out the graphics does. And in both cases there are valid reasons why a player might want to do so.

Besides, it's not technically true that these filters "distort" the visuals. If the original bitmap is a sampled representation of a continous image, the different resampling methods used to scale to another resolution (including pixel doubling or setting a high-resolution screen to a low-resolution setting) are all equally valid, they merely correspond to different assumptions about the image that was sampled.

Jesus, now you want to disable the 2X and 3X filters?

Read his post more carefully.

I understood the post just fine:

if a system variable is set to 2 all filters are disabled"

I know he made the suggestion because he wanted to allow people to not disable the 2x/3x filters, but this was the first time anyone had suggested there should be a way to disable them at all.

Since some people are so concerned about having filters applied to their game graphics, why not just add a message box to the setup when you pick a filter (other than 2x/3x), warning players that it makes the graphics look different? The same way you get a warning if you switch a 320x200 game to 640x400 resolution.

[monkey0506]

And yeah, if you give them the ability, developers will arbitrarily disable perfectly legitimate options. They may not be aware of the conditions under which the setting is useful, or they may just be obstinate. I seem to remember someone trying to disable Alt-X as a way to kill AGS.

Developers can be dumbasses just as much as players.

Shh...We've all put that behind us a long long long time ago.  Never speak of it again.

[Shane 'ProgZmax' Stevens]

Correct me if I'm wrong but AGS uses Allegro that works with DirectDraw, which is not hardware accelerated. Moving AGS to use Direct3D surfaces instead of DirectDraw would actualy provide a speed benefit, because 3D routines are fully supported by the hardware.

As far as I know it uses Allegro, but that doesn't mean it uses directdraw surfaces for rendering (and directdraw surfaces do support hardware acceleration), which is why I'm curious.  In my own engine I was able to implement 4 fully transparent interframe blended layers without virtually no speed hit (this was back on my 1ghz), and this is one of the reasons why I ask if ags is running completely under directx.  Direct 3d won't provide a bonus because it essentially treats sprites drawn on flat polys exactly like directdraw treats the surface.  The only real difference is you have far greater control over rotation- one major limitation of directdraw- and scaling looks nicer.  You can also place it in 3d space, obviously, but we're still talking 2d graphics here . 

Snarky- I'm not going to get into a discussion (read: pissing match) with you about how players deserve to have access to fancy bells and whistles regardless of their impact on the overall feel of the game.  I think those options should be up to the designer, you don't, the end.  It's that simple, really.

[Kweepa]

I think those options should be up to the designer

That's it. From now on I'm playing your games through a Fresnel lens and in a mirror. Oh, and I'm going to unplug the red cable from my monitor and feed the audio through a surround processor. Ha! Just try and stop me!

[Pumaman]

So yes, I second the notion to be able to disable the hq filters... if only in the cfg file, so those that are desperate to get eye-strain can enable them.

This seems to be a common viewpoint, so I will provide the ability to do so via the CFG file.

--
Edit by strazer:

AGS v2.72 Beta 5:
* Added cfg settings to disable graphic filter options in Setup. (see this KB article for more info).
--

Also, to address the AGS performance situation, it does seem to suffer when anything stressful is done- multiple transparencies

Transparencies are always slow when using a software renderer since AGS needs to manually read, manipulate then write each pixel in turn, which is a much slower operation than a standard "copy sprite to screen" type thing.

I'm not sure how thoroughly the speed loss was tested, but based on seeing a 16-bit game with a basic background and a few characters losing 15 fps immediately makes me wonder that the impact on a 32-bit game would be horrendousâ€"especially if one were to use transparencies or rawdraw or multiple onscreen animated objects/characters.

The advantage of the filters is that, for the standard 2x filter at least, it is actually faster running a 320x200 game with a 2x filter, than it is currently running a 320x200 game at 640x400 by selecting the "640x400" option.

Please see this post:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=25054.msg313812#msg313812
where I provide some examples of frame rates with various filters.

As far as Direct3D goes, I would say it will provide no benefit IF ags is currently fully directdraw functional; that is, if all the code is operating within directx handlers and such.

AGS currently uses DirectDraw, which is hardware accelerated to a point, but not to the same degree as Direct3D is. However, because of the way in which AGS does graphical rendering, most of the images are stored in system RAM rather than on DX surfaces -- it may be possible to change the rendering process to improve this, which is probably worth me experimenting with.

I'm curious what kind of framerates are people getting when using the Hq filters? Because from my own experiments I don't see any way to use them for games beyond 320x200 resolution?

Yes, as scotch says generally the filters are only useful for 320x200 games.

CJ - regarding the dialog problem, if you've edited your game on beta 4, will it still be broken when you upgrade to 4a? In other words, should I revert to my beta3 code when I start working with beta 4a? (and please, don't tell me I shouldn't really use betas for developing - the new features are worth the risk)

Beta 4 would only have corrupted your dialogs if you actually used the dialog editor pane, then saved the game. If you had only loaded your game, edited some sprites, then saved it, the corruption would not have occurred.

Easy way to check -- just have a run down all your dialogs and check that the options are ok.

Too bad that not many 320x200 games are developed in 32 bit. Would it be enough to compile the game in 32 bit mode to make the filters work, or would the art have to be re-imported with the palette set to 32 bit?

Adding 16-bit support for the Hqx filters is probably relatively easy, if it's a popular request I'm sure it could be done.

But if there's to be some way to disable the filters within the game, I'll recommend that you can disable them in levels

My current plan is to provide a per-filter option to disable filters, something like:

[disabled]
Hq2x=1
Hq3x=1
NearestNeighbour2x=1

etc

Moving AGS to use Direct3D surfaces instead of DirectDraw would actualy provide a speed benefit, because 3D routines are fully supported by the hardware. For example, a transparency calculation would not be done by the DirectDraw driver, it would be done by the video card. The same goes for scaling. This would provide a performance increase especially for 16-bit and 32-bit games.

This is true. The problem with moving to Direct3D is that it has various other difficulties to work around, such as textures being limited to sizes that are powers of 2, and other strange quirks that you have to code around just to get some sprites onto the screen.

[Shane 'ProgZmax' Stevens]

That's it. From now on I'm playing your games through a Fresnel lens and in a mirror. Oh, and I'm going to unplug the red cable from my monitor and feed the audio through a surround processor. Ha! Just try and stop me!

Nooooooooo!  Actually, I'd be curious to see the results ;P

AGS currently uses DirectDraw, which is hardware accelerated to a point, but not to the same degree as Direct3D is. However, because of the way in which AGS does graphical rendering, most of the images are stored in system RAM rather than on DX surfaces -- it may be possible to change the rendering process to improve this, which is probably worth me experimenting with.

Good to know, and yes, converting it to operating entirely on directdraw surfaces will improve performance considerably, especially for transparencies and the like.  I'd also recommend employing a triple-buffer flipping scheme if you haven't already, since I've seen substantial gains using it. 

[HeirOfNorton]

Out of curiousity, would switching to DirectDraw surfaces make the Linux or Mac ports more difficult to maintain, or would it make any difference?

(Not that either of them have been updated lately...)  :

HoN

[monkey0506]

* Fixed GUI Labels to not absorb mouse clicks.

I've only just noticed, but this seems to have prevented GUI Labels from being detected on screen at all?  Because I can't detect them with GUIControl.GetAtScreenXY any more.  I turn the Labels on, and I can see them, but using GUIControl.GetAtScreenXY always returns null for coordinates over the Labels.

And just as a matter of interest, does this mean that using on_event with eEventGUIMouseDown wouldn't be run for mouse clicks on Labels?  Because...I kind of needed that for the ScrollingDialog module.

Furthermore, it's time to quit all this foolish nonsense with updating the dialog system!   I've just about got all the bugs worked out (in mine), except every time I fix mine you implement new ones into the system! *

Spoiler

* I really love your work.  But I've been working on this dialog system for over a year now, and I've just about got it working.  No offense, but even if you do update the built-in system, I'd probably still use the module just so that I could say I programmed it, and, sentimental reasons of course....

[close]

[Besh]

When a new character is created, the Idle view comes put automatically to 1. It happens also in the previous versions.

I think that should be set to zero!!! 

I have been three days to understand why my plugin works on some games and not on others, simply I had not modified the idle view.

[SSH]

I just noticed that some old templates (.agt files) can't be seen (i.e. dont even appear in templates list when trying new game) by AGS 2.7 and later. e.g.  Junc's http://www.lucasstyle.com/media/ags/opensource/SPYvsSPY_source.zip

Now, I can get 2.56d to see this (most recent old AGS I could find) but it is older than that template.

So, is it possible to restore compatibility with these old templates, and if not does someone know where I can get AGS 2.62? AGAgames had it but the server crash must have killed that one.

[xenogia]

I have got the template bug also

[Traveler]

Out of curiousity, would switching to DirectDraw surfaces make the Linux or Mac ports more difficult to maintain, or would it make any difference?

I'm no DirectX expert, but I don't think CJ would have a difficult time with this, but he is the one who could tell for sure.

[monkey0506]

I just noticed that some old templates (.agt files) can't be seen (i.e. dont even appear in templates list when trying new game) by AGS 2.7 and later. e.g.  Junc's http://www.lucasstyle.com/media/ags/opensource/SPYvsSPY_source.zip

Now, I can get 2.56d to see this (most recent old AGS I could find) but it is older than that template.

So, is it possible to restore compatibility with these old templates, and if not does someone know where I can get AGS 2.62? AGAgames had it but the server crash must have killed that one.

http://www.sitesled.com/members/meleepta/ags_262.zip
[and...more because I needed to remember what the file structure was...]
http://www.americangirlscouts.org/agsuploads/files/ags_262.zip

[Pumaman]

Out of curiousity, would switching to DirectDraw surfaces make the Linux or Mac ports more difficult to maintain, or would it make any difference?

Well, any changes would have to be done whilst bearing in mind cross-platform compatibility, so this would of course have to be a consideration in the way it was coded.

I've only just noticed, but this seems to have prevented GUI Labels from being detected on screen at all?  Because I can't detect them with GUIControl.GetAtScreenXY any more.  I turn the Labels on, and I can see them, but using GUIControl.GetAtScreenXY always returns null for coordinates over the Labels.

This is a good point, GetAtScreenXY only detects controls that the mouse can click on -- this is not just limited to Labels. I guess the documentation doens't specify it one way or the other, so I'll see about changing this.

When a new character is created, the Idle view comes put automatically to 1. It happens also in the previous versions.

I just tried creating a new character and the idle view was "None".
You may be referring to this bug:
http://www.adventuregamestudio.co.uk/kbview.php?id=17
which is unfortunately not easily fixable.

I just noticed that some old templates (.agt files) can't be seen (i.e. dont even appear in templates list when trying new game) by AGS 2.7 and later.

I'll look into it.

Edit by strazer:

AGS v2.72 Beta 5:
* Fixed backwards compatibility issue with old templates.

[monkey0506]

I've only just noticed, but this seems to have prevented GUI Labels from being detected on screen at all?  Because I can't detect them with GUIControl.GetAtScreenXY any more.  I turn the Labels on, and I can see them, but using GUIControl.GetAtScreenXY always returns null for coordinates over the Labels.

This is a good point, GetAtScreenXY only detects controls that the mouse can click on -- this is not just limited to Labels. I guess the documentation doens't specify it one way or the other, so I'll see about changing this.

Thanks Chris.  It just seemed kind of odd to make Labels GUIControls (make the Label structure derived from the GUIControl structure) if GUIControl.GetAtScreenXY doesn't detect them.

And just curious...does the Label.Clickable property do anything?  I was going to say that it would be more sensical to let the user decide whether Labels would absorb mouse-clicks than the engine just saying yes or no, but there's already Label.Clickable and Label.Enabled properties.  The manual entries on these properties just redirects to the GUIControl property entries...so...

[Besh]

When a new character is created, the Idle view comes put automatically to 1. It happens also in the previous versions.

I just tried creating a new character and the idle view was "None".
You may be referring to this bug:
http://www.adventuregamestudio.co.uk/kbview.php?id=17
which is unfortunately not easily fixable.

Yes, the relative button in the character panel show "none" but if you click it the dialog show 1.

[SSH]

Whenever you obsolete old functions, CJ, can you provide a #define so that module-writers can make code work on the latest beta or the previous stable release, please?

Lots of my old modules that used GetGameParamter are broken, but I don't want to maintain two versions of them if I can avoid it.

[SSH]

Sorry for the double-post, but I wanted to make sure this wasn't missed.

If you have a function in a module (and probably global) script that took a "const string" and you change it to take a "String", then when this function is called in a room script with a string literal, it fails unless you add a blank line to the script or somesuch to make it become "dirty".