AGS 2.72 Final 2 - World Cup Edition

[Pumaman]

Ok, beta 4a is now up, which should fix the dialog options corruption problem, as well as a few other things that were reported here.

[Kweepa]

As far as I know, the only options are off and on ... I think if the edge is 1 pixel wide it should filter it, but any wider and it won't pick it up. The Hq2x homepage is here: http://www.hiend3d.com/hq2x.html if that helps.

Yes, I looked at the source code there - that's where I got their edge determination code. Hmm, however looking at the "recommended" code (which includes some MMX assembly) I can see it's a bit more difficult than I first thought - the "treshold" const at the top of hq*x.cpp would need to be changed to

Code: ags

(Ythreshold << 16)|(Uthreshold << 8)|(Vthreshold)

[Fribbi AGDI joker]

Thanks for uploading -- found the problem, it happens if you use RemoveOverlay or SetTextOverlay in a rep_exec_always script while sierra-style speech is displayed -- in your case the OverHotspot module was doing so.

I'll get it fixed.

Thanks CJ. BTW I did not made that module so maybe it is too old for the new beta version. I can't even use "enable new script" because some of these modules I use for my game don't work with it. But I am not very good in scripting a module so I have be waiting for the new updated modules to fix that problem. I don't want to fiddle on that thing because I don't want to mess it up.

And your new update fixed my problem. Many thanks goes to you CJ.

[RickJ]

Manual Correction:

The game.previous_game_data  property is not  listed in the "Variables" section of the manual. 

[Snarky]

No, it is that simple. RGB is converted to YUV 888, and if (Ydiff > 0x30 || Udiff > 0x07 || Vdiff > 0x06) they are counted as different. So it's just a matter of exposing these threshold values to the game author.

OK. I freely admit that the source code for the algorithm is over my head. In the description, there is one paragraph that made me think something more complex is going on:

Creating a lookup table was the most difficult part - for each combination the most probable vector representation of the area has to be determined, with the idea of edges between the different colored areas of the image to be preserved, with the edge direction to be as close to a correct one as possible.

This seems to say that a lookup table is involved in determining if there are edges, but I guess it could just mean that the table tells you how to draw the edge once you've decided there is one.

It would also be good to be able to disable the hq filter option entirely, for games with painted or photographic artwork where it breaks down.

Isn't that up to the player? You can already fiddle with all sorts of settings (force alternate resolution, run in 640x400, smooth scaled sprites) that can make some games look wonky.

The x2 and x3 options are awesome too. Playing in a window while testing is now much more comfortable. Thanks CJ.

It is teh excellent. Since my LCD screen performs linear upscaling on lower-than-native resolutions, 320x2_0 always comes out blurry. I run all games in 640x4_0 (which is somewhat sharper), but it mucks up sprites when they are scaled down, and I have framerate problems on some games. These filters should solve all my problems.

[Kweepa]

I guess it could just mean that the table tells you how to draw the edge once you've decided there is one.

Yes, that's the idea.

[EDIT]
Here's my avatar with hq2x. The first image is with "treshold" 0x300706, the second with 0x200706.



The skin tones look much better IMO. The hair is debatable I suppose, but then it's more painted than outlined.

It would also be good to be able to disable the hq filter option entirely, for games with painted or photographic artwork where it breaks down.

Isn't that up to the player? You can already fiddle with all sorts of settings (force alternate resolution, run in 640x400, smooth scaled sprites) that can make some games look wonky.

Of course, as a player I'd rather have the option to turn it on. On the other hand, as a game designer I'd rather the player not see this when playing:
http://www.locustleaves.com/output.png [thanks Helm]
I think 90% of the designers around here are rather receptive to players' wishes, but I suppose there's the 10% who are obstinate and will want people to play it "as intended" no matter if it isn't possible on a particular machine.

[GarageGothic]

If only the generic AGS setup dialog could be customized, you could just remove options that you don't want to be available. I tried doing this using ResHacker - and it worked great until I tried starting the game and found out that AGS considered the .exe file corrupted

I for one would like to be able to remove the 320x240 option, since any text in my game will be displayed at double the size. Sure, I can detect the resolution in script, put in a "This isn't the resolution the game was made for" message, and prevent the game from starting. But the user would probably think "then why did you even give me the option, jackass?"

Edit: Actually it would be way easier just to write an external setup program, since all it does is write to the cfg file. However, the player could still run "gamename.exe --setup". So perhaps it would be nice with an option to include or not include the setup menu in the compiled exe? (um, of course then, the  player could edit the cfg in notepad... but maybe a great big "don't fuck with the settings" message on startup would be at place then ).

[Pumaman]

Manual Correction:

The game.previous_game_data  property is not  listed in the "Variables" section of the manual. 

This is an interesting one, because there are several game.* properties that are not documented in the main manual page ... ideally I want to phase them out since they're rather ugly, but we'll see.

Here's my avatar with hq2x. The first image is with "treshold" 0x300706, the second with 0x200706.

Does anyone else think that exposing these values for the HqX filter would be useful? What about if they were settings in the .cfg file that you could add manually, rather than having to actually code them into your game?

Of course, as a player I'd rather have the option to turn it on. On the other hand, as a game designer I'd rather the player not see this when playing:
http://www.locustleaves.com/output.png [thanks Helm]

If the filter has completely garbled the screen like that, then it's a bug and it needs to be reported and fixed. I don't think that a bug in the filter code is a reason to disable it.

However,

I think 90% of the designers around here are rather receptive to players' wishes, but I suppose there's the 10% who are obstinate and will want people to play it "as intended" no matter if it isn't possible on a particular machine.

If only the generic AGS setup dialog could be customized, you could just remove options that you don't want to be available

Perhaps allowing the Filters option to be disabled is a reasonable idea as a compromise.

Currently AGS allows you to add these to your acsetup.cfg file:

[disabled]
musicvox=1
speechvox=1
16bit=1

Those entries disable the "use digital music pack", "use speech pack" and "downgrade 32-bit graphics to 16-bit" options respectively. A new, similar option to disable the Filter box is something I'll look at.

Now obviously, a seasoned player could simply open the CFG file and remove these entries to re-enable the options, but if they wilfully do that then really it's their own fault if the game doesn't play as expected.

[Kweepa]

Of course, as a player I'd rather have the option to turn it on. On the other hand, as a game designer I'd rather the player not see this when playing:
http://www.locustleaves.com/output.png [thanks Helm]

If the filter has completely garbled the screen like that, then it's a bug and it needs to be reported and fixed. I don't think that a bug in the filter code is a reason to disable it.

This is a good point.
I just ran Helm's original image through the recommended hq2x and hq3x source code and it didn't garble the image, so I'm not sure what Helm did wrong when he ran his tests. It sure doesn't seem like the algorithm could go so badly wrong, given the local nature of its approach.
Perhaps it got corrupted when he uploaded the image!
So I think the point is moot.

[Adamski]

These hq2x/3x filters open up a whole new headache for developers, especially if you enable them to be as screwuppable as possible by the end user who delights in diddling with every setting then emailing the game creator because the graphics suck. The less options there are for people to mess up with the filters the better, you can't trust the general public these days

The plain nearest neighbour filters are going to be wonderful for a multitude of reasons, but I can't get over worrying about releasing my game with the beautiful artwork scotch is putting so much effort into only for folks to put on the 'make my game look better' gee-whiz option and blurring things up to hell (and then emailing me saying the game is broken).

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.

[scotch]

I don't think this is a significant problem, not many people are going to turn it on if it isn't on by default, and if they do... well, they can decide what looks better to them.  On the subject of graphical perfection, I think being able to adjust the brightness/contrast of the display somehow would be good, would allow for the developer to make one of those little calibration bars at the start maybe.  Because it seems however I draw backgrounds they look washed out or too dark on most other monitors, or even on the same monitor but in a different display mode...

[Snarky]

These hq2x/3x filters open up a whole new headache for developers, especially if you enable them to be as screwuppable as possible by the end user who delights in diddling with every setting then emailing the game creator because the graphics suck. The less options there are for people to mess up with the filters the better, you can't trust the general public these days

The plain nearest neighbour filters are going to be wonderful for a multitude of reasons, but I can't get over worrying about releasing my game with the beautiful artwork scotch is putting so much effort into only for folks to put on the 'make my game look better' gee-whiz option and blurring things up to hell (and then emailing me saying the game is broken).

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.

In deciding whether to give the control to the developers or the players, I'd much rather let the player choose. After all, if a player selects the wrong settings, the only person affected is him. But if a developer decides to disable some function that is actually useful in some circumstances, that screws it up for everybody who might want to play the game.

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.

[Adamski]

I agree, but there are some cases where options are going to have a detremental effect on the visual experience and I feel this is true with the game I'm working on.
If they make the game look like someone's run riot with the smudge tool in photoshop and things look noticeably worse then surely it's not such a big deal to be able to disable the two hq filters, right? Especially if it's not a permanent disablement.

[Shane 'ProgZmax' Stevens]

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.

Completely disagree here.  What is and is not legitimate feature-wise is purely relative, and I think the power of all important decisions in any game engine need to rest with the creator rather than the players.  If the creator decides to do things a certain way, sobeit; viewing a nintendo-stylized game with filters would destroy the impact of the game and its nostalgia.  It is his/her game and decision, ultimately, as it should be.  Play another game or make a request to change it like everyone else does with commercial products.  Allow people to flick it on and off, sure, but put an option in ags to disable it from working if such a feature is entirely inappropriate to your game- and this is a decision the creator has the right to make.

Also, to address the AGS performance situation, it does seem to suffer when anything stressful is done- multiple transparencies, setting up a rawdraw loop in anything above 8-bit, and the filters effectively cut fps from a few tests I've run so far by up to half.  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.  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.  I only say this because I've coded many programs with directx support in the past and have read a great deal on the subject.  DirectX supporter, GET HIM!!!   If AGS draw routines and such are not handled through directx I will be happy to offer my knowledge in this regard- if you decide you want to update it.  Anyway, I think it's great that you put so much effort into adding all these features and I certainly applaud your dedication to a single program. 

I wish I'd been so dedicated to my own game engine.  Now I will go cry ;(.

-ProgZ

[GarageGothic]

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? Running my 640x480x32 game with the Hq2x filter in the 1280x960 windowed mode (can't run full screen due to laptop resolution issues), I get framerates of 12-13 fps even in rooms with nothing else going on, no animation, no rawdrawing, nada. This is on a 1.6GHz centrino laptop with 1024MB RAM and a 128MB ATI Radeon 9700 video card.

Edit: I also wanted to ask 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)

[scotch]

Yes they are extremely slow filters, they were designed for emulator games for older consoles and handhelds... so that's even lower than 320x200.  They aren't suitable for use on higher res graphics generally.

[GarageGothic]

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?

[Gilbert]

I'm a bit for the idea of being able to disable certain options in setup, just to prevent stuff from being screwed up.

Actually you can disable some of the setup options via script already, for example you can disable the "smooth scaled sprites" option (due to my previous request ) by putting this line in your script:
game.disable_antialiasing = 1;
Well, this won't remove the option from setup, however, it will in fact override the config file and force to disable it.

Some people might think it's not very important, however it's very import for me, as my games are in 256 colours and I use dynamic palette effects extensively, when this option's turned on it can mess up scaled sprites heavily when palette is being animated (I can expect the HQ filters can do even more harms for such a case, I don't know if they can be used in 8-bit modes or not, but if in case more filters that work under 8-bit may be added later...). I don't have a concrete example for hicolour+ cases, but maybe the filters should be disabled if you just don't want your good pixel art to be hurt, or in some evil pixel hunting puzzle that the original pixel arrangements must be perfect ?

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, for example, if a system variable is set to 2 all filters are disabled, if it's 1 all filters but the 2X and 3X ones are disabled. Since IMO 2X and 3X are AWESOME idea (in fact they're not "filters" at all, I think it can even help the MAC port to run games in "true" 320 graphics now).

On the other hand, however, since you can warn players in the game's documents about using some of the settings (who reads documents nowadays? ) this may not be that important anyway.


Enough ranting for me.

[Traveler]

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.

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. 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.

[Snarky]

Completely disagree here.Ã,  What is and is not legitimate feature-wise is purely relative, and I think the power of all important decisions in any game engine need to rest with the creator rather than the players.Ã,  If the creator decides to do things a certain way, sobeit; viewing a nintendo-stylized game with filters would destroy the impact of the game and its nostalgia.Ã,  It is his/her game and decision, ultimately, as it should be.Ã,  Play another game or make a request to change it like everyone else does with commercial products.Ã,  Allow people to flick it on and off, sure, but put an option in ags to disable it from working if such a feature is entirely inappropriate to your game- and this is a decision the creator has the right to make.

I don't want to get into a big argument about this, but I don't buy that argument at all. No, all important decisions in the game engine shouldn't rest with the game creators. The disabling Alt-X example I gave earlier demonstrates the fallacy of that.

Graphic filters shouldn't, in my opinion, be considered part of the game design. It is part of the settings for the environment the game exists in. I can turn on filters in DOSBox, ScummVM, MAME, or ZSNES, for any game. It works better for some games than others, but I as a player am perfectly able to make that judgment. The game design is not involved at all.

If you want to give the game creators this level of control, why not allow them to turn off the option to run the game in a window, too? After all, I'm sure a lot of creators prefer players to play their games in full screen. Or disable the ability to Tab out of AGS, to make sure people aren't "abusing" it to look up hints? You could make a much better case that these are game-design issues, but allowing creators to dictate and restrict players in this way would be a Bad Thing.

Besides, these days probably as many people play old Nintendo games on emulators as play them on the original consoles, and usually with filters, so a Nintendo-stylized game is exactly the kind that filters are appropriate for.

Even if you don't want certain settings turned on when people play your game, there are completely legitimate reasons why people might want to do so. One of the most obvious and probably most common is just to see what it looks like, or to test the effect. For instance, if I was making a game with lots of graphical effects, and wondered whether it would run under hq3x without stuttering, I might want to test it on Mind's Eye with the filter turned on, because I know that's a graphically demanding game. Earlier in this discussion, I mentioned how running a 320x2_0 game in 640x4_0 mode mucks up the sprites when they're scaled; I quickly verified that by running Cedric, which has extreme character scaling on one of the first screens. Another may be for performance; these particular filters reduce the frame rate, but it's conceivable that other settings might speed things up... or you may be in a situation where you need to slow it down. Or there may be unexpected factors coming into play, like my case where LCD screens produce a sharper image in higher resolutions.

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, for example, if a system variable is set to 2 all filters are disabled, if it's 1 all filters but the 2X and 3X ones are disabled. Since IMO 2X and 3X are AWESOME idea (in fact they're not "filters" at all, I think it can even help the MAC port to run games in "true" 320 graphics now).

Jesus, now you want to disable the 2X and 3X filters? Under what possible situation would a game creator have any reason to do that?

The amount of effort devoted to making things difficult for players astounds me. Almost everyone who plays your game will be familiar with the standard AGS setup, will know their system, and will be able to choose the settings that are right for them.

In order to add something vaguely constructive to the thread, it sounds like what CJ suggested would be a workable compromise: Adding flags to the cfg file will remove the options from the setup, but a dedicated player could always go in and edit the file manually to restore them. Adding Steve's edge threshold as another setting to the cfg file also makes sense, since again it's not really part of the game design itself, but precisely part of the configuration.