AGS Awards nominations close at 13:59 GMT on Saturday 10 February 2018. You haven't yet nominated, so you've got 18 days and 6 hours left to play the games and decide which to nominate!

Author Topic: Direct3D scaling implementations  (Read 5830 times)

Danvzare

  • The Man with No Name
    • I can help with AGS tutoring
    •  
    • I can help with play testing
    •  
    • I can help with proof reading
    •  
    • I can help with story design
    •  
    • I can help with voice acting
    •  
Re: Direct3D scaling implementations
« Reply #20 on: 06 Oct 2016, 10:50 »
Calm down, Danvzare.
Danvzare, in my opinion, your examples are completely off scale with the setting in question.
Ok, sorry for overreacting. :(

And yeah CW, you make some good points.

I guess I just feel as though I'm the only one who rather likes the mismatched pixels, and thus feel as though I have to defend them. Which sounds pretty stupid when I put it into words.
Sorry again everyone.

(I.e. option could have following values: On (strict)/Off (strict)/On (by default)/Off (by default), with last two allowing player to change it).
Personally, I like this suggestion. Although I suppose to make things easier for the engine developers, a strict on/off might be better.
While I'd prefer it in the WinSetup, I guess I can understand why the developer would prefer it if they had control over it.

Snarky

  • Local Moderator
  • Mittens Earl
  • Private Insultant
    • I can help with proof reading
    •  
    • I can help with translating
    •  
Re: Direct3D scaling implementations
« Reply #21 on: 06 Oct 2016, 14:50 »
I don't like telling people what they should spend their volunteer efforts on, but it all sounds like a whole lot of work and complexity just for optional backwards compatibility with a bug that should never have been there in the first place (and which behaves inconsistently between the two renderers). If ever there were a case for unceremoniously breaking backwards compatibility, I think this is it: Just fix it, and if people like the old, broken behavior they can use an old version of the engine.

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #22 on: 06 Oct 2016, 15:20 »
I don't like telling people what they should spend their volunteer efforts on, but it all sounds like a whole lot of work and complexity just for optional backwards compatibility with a bug that should never have been there in the first place (and which behaves inconsistently between the two renderers). If ever there were a case for unceremoniously breaking backwards compatibility, I think this is it: Just fix it, and if people like the old, broken behavior they can use an old version of the engine.

That was pointed out in this thread (and was said before) that while this behavior could have been introduced unintentionally, it may be valid feature if properly implemented (see Ron Gilbert's engine example).
So this is not simply about keeping backwards compatibility.

Now, from what I know, current problem Alan has is not in keeping the old behavior, but finding out a clean and optimal way to implement NEW one. Because so far we could not find what code specifically is making characters drawn that way. As far as I know, until now Alan was not able to actually remove the old behavior, so in his Draconian version he overrides it by adding extra operation. (He may correct me if I am wrong, but that was what I previously saw in his code).
E: to elaborate further, the problem here is not that it is objectively hard, but because neither of us have big knowledge in Direct3D. This also may be related to overall AGS's entangled code state...

Finally, most of the discussion here is about whether to have or not have an option in winsetup, which is a non-issue from the coder's point of view.
Don't mean to be rude, but really that's the case when there is more talk than work...
« Last Edit: 06 Oct 2016, 15:44 by Crimson Wizard »

Snarky

  • Local Moderator
  • Mittens Earl
  • Private Insultant
    • I can help with proof reading
    •  
    • I can help with translating
    •  
Re: Direct3D scaling implementations
« Reply #23 on: 06 Oct 2016, 21:31 »
That was pointed out in this thread (and was said before) that while this behavior could have been introduced unintentionally, it may be valid feature if properly implemented (see Ron Gilbert's engine example).
So this is not simply about keeping backwards compatibility.

Perhaps the effect might be of use if the whole engine was built around it (the Thimbleweed engine supports "sub-pixel" scrolling and things like that), but you already said:

We just don't! The support will only cover effect that was present in the past.

I simply don't think this "effect" (i.e. bug) by itself is worth preserving in any form, and certainly not with the limitations currently in place.

As for why it happens... isn't it simply that the screen is scaled and then the sprites are drawn, rather than the other way around? Drawing everything to a game-resolution texture and then scaling and rendering that to the screen (which I thought was what Alan was doing) seems like the proper approach to me.

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #24 on: 06 Oct 2016, 22:29 »
I simply don't think this "effect" (i.e. bug) by itself is worth preserving in any form, and certainly not with the limitations currently in place.
I've been asked by certain game developers in the past to keep it. How else is it decided whats worth and whats not?
The point is, whether this is needed to anyone as a part of game design, and if yes, whether it will be complex to keep it as an option. I am not the one to answer on the first question, because I do not make games with AGS. But answer on second question is: "probably not".

As for why it happens... isn't it simply that the screen is scaled and then the sprites are drawn, rather than the other way around? Drawing everything to a game-resolution texture and then scaling and rendering that to the screen (which I thought was what Alan was doing) seems like the proper approach to me.
He told me he tried doing that and something did not work well, so he is back to original code he used. And that code looked tad like a hack to me, doing some excessive operations. Then again, it was long ago when I checked it last time.
I did not have time to look into this myself now, so I do not know details.


EDIT: As I see this, also refering to your explanation above, the possible solution is in separating sprite rendering code into a function that accepts destination multipliers as parameters. Depending on setting, this function is called either before stretching whole scene with multipliers = 1.0, then streches the scene, or called with  correct multipliers enough to stretch all sprites without stretching the scene afterwards.
This may actually be what Alan did in Draconian too, but as I said, I do not quite remember this.
That may not be the most perfect way, but it should work for renderer which has accelerated scaling. Honestly, I do not think that really will work for software renderer, because it is slower, and doing two-pass rendering will be more complicated, because of how walk-behinds work. But that's a separate issue IMHO.
« Last Edit: 07 Oct 2016, 01:50 by Crimson Wizard »

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #25 on: 06 Oct 2016, 23:48 »
Well, I found old Alan's code I loaded to my pc couple of years ago, and frankly, since I now understand what is going on in the code much better, I believe it could be way to go, just with certain cleanup & optimization. Adding an option to turn it between two rendering modes also seem to be super-simple to do.

Re: Direct3D scaling implementations
« Reply #26 on: 07 Oct 2016, 20:17 »
Well, to be fair Thimbleweed's engine is not really a good example to justify our broken scaling. That engine seems to run at a high native resolution and the assets are streched up by design.
The pixel purist mode will surely just be a shader that scales down or pixelizes. That's the exactly opposite thing of what's happening on AGS. (laugh)

- Alan

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #27 on: 06 Nov 2016, 17:37 »
In case anyone curious, this switch was just added to master branch in official repository.
It allows to either set up exact fixed mode for the game, or let player toggle it in setup at will.
The switch currently works only for Direct3D mode.
« Last Edit: 06 Nov 2016, 17:43 by Crimson Wizard »

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #28 on: 07 Nov 2016, 18:31 »
Hrm, well, this is kinda silly, but Alan had issues making a convenient name to this option :D. At least I think that it is very confusing as it is now.

Currently this setting is called "Scale native resolution", with ON making old Direct3D result, and with OFF making correctly scaled pixels (as DirectDraw).

I honestly do not know how to understand "scale native resolution" (cannot draw connection between the name and what it does), and I fear that will be super puzzling to the users who had never heard of this problem before (and maybe even those who had).

Currently I am looking for a good way to rename this to. My latest variant is "Subpixel sprite scaling". Although I am aware that subpixel rendering is kind of different thing, they have something similar in what the renderer is trying to achieve.
EDIT: another variant: "Use high-res pixels for sprite scaling".

I also invented following explanation to this property to be shown in the editor (and possibly manual):

"When drawing zoomed character and object sprites, AGS will take advantage of higher runtime resolution to give scaled images more detail, than it would be possible if the game was displayed in its native resolution."

I need opinions on whether it is elaborate or not.
« Last Edit: 07 Nov 2016, 19:47 by Crimson Wizard »

Danvzare

  • The Man with No Name
    • I can help with AGS tutoring
    •  
    • I can help with play testing
    •  
    • I can help with proof reading
    •  
    • I can help with story design
    •  
    • I can help with voice acting
    •  
Re: Direct3D scaling implementations
« Reply #29 on: 07 Nov 2016, 20:11 »
Yeah, "Scale native resolution" is confusing.

Personally, I can't think of a good name for it, but I kinda like "Subpixel sprite scaling".
We'd have to hear other people's thoughts first.

That explanation to be shown in the editor though, is perfect! ;)

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #30 on: 08 Nov 2016, 18:37 »
Are following variants correct in terms of English?

- Scale sprites in screen resolution, or
- Render sprites in screen resolution

Re: Direct3D scaling implementations
« Reply #31 on: 08 Nov 2016, 18:47 »
I think it would be "at screen resolution".

cat

  • Mittens Baronet
  • AGS Baker
  • Learn to how write cat in Japanese!
    • cat worked on a game that was nominated for an AGS Award!
      cat worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #32 on: 05 Dec 2016, 16:01 »
Will there be a new setting in the setup program? I was glad when the setup was finally slimmed down, adding another option doesn't sound like a good idea. Especially when I can and definitely will prevent the player from changing the sprite scaling.

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #33 on: 05 Dec 2016, 16:26 »
Will there be a new setting in the setup program? I was glad when the setup was finally slimmed down, adding another option doesn't sound like a good idea. Especially when I can and definitely will prevent the player from changing the sprite scaling.
There will be an option on Advanced tab. Game developer can enforce particular selection for their game (set in General Settings), which would render the checkbox in setup program always greyed out. If they did not, player may toggle it on and off.
« Last Edit: 05 Dec 2016, 16:28 by Crimson Wizard »

cat

  • Mittens Baronet
  • AGS Baker
  • Learn to how write cat in Japanese!
    • cat worked on a game that was nominated for an AGS Award!
      cat worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #34 on: 05 Dec 2016, 16:36 »
Ok, thanks for the clarification. Looking forward to the new version :)

selmiak

  • ǝsıɔɹǝxǝ ʞɔǝu puɐ uıɐɹq
    • I can help with play testing
    •  
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with web design
    •  
    • selmiak worked on a game that was nominated for an AGS Award!
Re: Direct3D scaling implementations
« Reply #35 on: 05 Dec 2016, 20:10 »
just asking, why is it greyed out and not just completely gone? curious players will feel cheated and maybe even complain to the gameauthor, well, just because...

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #36 on: 05 Dec 2016, 22:10 »
just asking, why is it greyed out and not just completely gone? curious players will feel cheated and maybe even complain to the gameauthor, well, just because...
That complies with other options that also get greyed out when they are not applicable to particular game.
Also that is plain simplier to do, if option gets removed there will be noticable empty space on window between controls, and we do not have automatic layout in setup.

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #37 on: 06 Jan 2017, 20:39 »
I found that this option already existed in OpenGL renderer all this time but was only available for Android (and probably iOS) ports. It is called "Supersampling".

MJL

  • Global Moderator
  • Mittens Duke
  • Mittens Founder
    • Lifetime Achievement Award Winner
    •  
    • MJL worked on a game that was nominated for an AGS Award!
      MJL worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #38 on: 25 Nov 2017, 11:39 »
Hiya! Sorry to necro this, but what is the current method to achieve what's seen in the right hand image please?



If it's a particular version of the engine or what not that should be used, please let me know? So you can run it in directX mode and still retain the pixel feel of sprites. This thread seems to hint at things but I can't see a clear cut solution.

I need a solution that doesn't involve redrawing things... ;)
« Last Edit: 25 Nov 2017, 11:41 by MJL »

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Direct3D scaling implementations
« Reply #39 on: 25 Nov 2017, 12:03 »
Hiya! Sorry to necro this, but what is the current method to achieve what's seen in the right hand image please?

If it's a particular version of the engine or what not that should be used, please let me know? So you can run it in directX mode and still retain the pixel feel of sprites. This thread seems to hint at things but I can't see a clear cut solution.

You need AGS 3.4.1, that has this looks by default. Optionally you may change "Render sprites at screen resolution" option in General Settings to either enforce particular look for your game or let players choose preferred looks in winsetup.