Direct3D scaling implementations

Started by Alan v.Drake, Fri 30/09/2016 01:21:52

Previous topic - Next topic

Danvzare

Quote from: StillInThe90s on Wed 05/10/2016 19:43:48
Calm down, Danvzare.
Quote from: Crimson Wizard on Wed 05/10/2016 20:19:56
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.

Quote from: Crimson Wizard on Fri 30/09/2016 15:17:15
(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

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

#22
Quote from: Snarky on Thu 06/10/2016 14:50:15
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...

Snarky

Quote from: Crimson Wizard on Thu 06/10/2016 15:20:56
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:

Quote from: Crimson Wizard on Fri 30/09/2016 15:17:15
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

#24
Quote from: Snarky on Thu 06/10/2016 21:31:07
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".

Quote from: Snarky on Thu 06/10/2016 21:31:07
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.

Crimson Wizard

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.

Alan v.Drake

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

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

Crimson Wizard

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

Danvzare

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

Are following variants correct in terms of English?

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

morganw

I think it would be "at screen resolution".

cat

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

#33
Quote from: cat on Mon 05/12/2016 16:01:58
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.

cat

Ok, thanks for the clarification. Looking forward to the new version :)

selmiak

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

Quote from: selmiak on Mon 05/12/2016 20:10:07
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

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

m0ds

#38
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... ;)

Crimson Wizard

Quote from: MJL on Sat 25/11/2017 11:39:29
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.

SMF spam blocked by CleanTalk