Direct3D scaling implementations

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

Previous topic - Next topic

Alan v.Drake

Hello,
as pointed out countless times, DirectDraw mode and Direct3D mode do not draw characters/objects with different zoom levels the same way:


Left D3D, Right DD

Obviously the right one is the right way, so I'll push for it to become the default.
But for those who have somehow built their game around the non-standard D3D scaler, I can give the option to keep using the old scaling mode.

The working name for the feature is "scale_native_resolution".

Now the big question, should I add a checkbox inside winsetup ? Only from acsetup.cfg ? As a game setting ?
I could even make it changeable at runtime, but I'm not sure I should.

Let me hear your thoughts!

- Alan

selmiak

is the right version generated inside AGS from the left version? damned, this is interesting for scaling things. Or is this another version of the sprite completely?

Crimson Wizard

#2
I believe more elaborate explanation is a must...
For instance, I do not even remember how to reproduce this. Does it happen all time in D3D mode when you have zooming walkable area, or you need more than that to get this effect?

Quote from: selmiak on Fri 30/09/2016 02:56:44
is the right version generated inside AGS from the left version? damned, this is interesting for scaling things. Or is this another version of the sprite completely?
It is the same sprite, left version is rendered in Direct3D, right version in DirectDraw5.


Quote from: Alan v.Drake on Fri 30/09/2016 01:21:52
Now the big question, should I add a checkbox inside winsetup ? Only from acsetup.cfg ? As a game setting ?
I could even make it changeable at runtime, but I'm not sure I should.

My personal opinion is that this mode belongs strictly to game design, because it can change the game looks too much. It is not like scaling filter too, which is applied over all the game image, keeping it consistent; it makes particular parts of the game look different from the rest of the image.
So I vote for game property, similar to Alpha Blend modes, which we already have to keep backwards compatible "incorrect" behavior.
Of course, nothing will prevent to add config option, or script command to change this at runtime later, but I honestly doubt that would be asked for. Maybe just for testing/debug purposes...

Scavenger

To reproduce this, you must have a game running with a scaler, such as 320x200 running at 2x nearest neighbour. Any characters standing on a scaled walkable area will be scaled down using the resolution the game is scaled to (with the example being 640x400), not the resolution the game was created at (320x200).

This wasn't so much of an issue back in the old days when people would simply scale 2x at most, or keep it at 1x, but this age of scaling to 4x or 5x the size, it is extremely noticable.

Danvzare

#4
Ah yes, I've noticed this.
And I also realize I'm in the minority when I say I'm more of a fan of the left one.

Although considering Thimbleweed Park is going to have scaling like the left one, then clearly I'm not in too much of a minority. ;)

Still, it would be awesome if you could put in the option to choose between them. Preferably in Winsetup.

Crimson Wizard

#5
Quote from: Danvzare on Fri 30/09/2016 10:57:40
Still, it would be awesome if you could put in the option to choose between them. Preferably in Winsetup.
Welp, I was wrong :tongue:.


I am very interested to know WHY that happens like that in the first place, i.e. what code makes it stretch up before rendering properly, because that may point to the proper solution.
This really bugs me, and the reason I want to underline this is that logically thinking the fix should remove certain operation or alter one, rather than adding additional one, like I've seen in the old Draconian code.

Radiant

Quote from: Danvzare on Fri 30/09/2016 10:57:40Still, it would be awesome if you could put in the option to choose between them. Preferably in Winsetup.
I disagree. This affects the visual design of the game, and should be the choice of the game design team.

Danvzare

Quote from: Radiant on Fri 30/09/2016 13:25:34
Quote from: Danvzare on Fri 30/09/2016 10:57:40Still, it would be awesome if you could put in the option to choose between them. Preferably in Winsetup.
I disagree. This affects the visual design of the game, and should be the choice of the game design team.
The HQX filters affect the visual design of the game much more, and no one has ever complained about those being in Winsetup (to my knowledge).
And while it might not be comparable, choosing to use a voice pack or muting the music, would affect the audio design of the game, yet we still give the option.

People should be free to change it if they want to. If they want it exactly how the developers designed it, they won't change it. Who are we to judge how others play our games?

Radiant

Quote from: Danvzare on Fri 30/09/2016 14:52:24
The HQX filters affect the visual design of the game much more, and no one has ever complained about those being in Winsetup (to my knowledge).
You are incorrect. Most of the artists that I regularly work with have asked me if I could remove this option from winsetup.

Danvzare

Quote from: Radiant on Fri 30/09/2016 14:54:17
Quote from: Danvzare on Fri 30/09/2016 14:52:24
The HQX filters affect the visual design of the game much more, and no one has ever complained about those being in Winsetup (to my knowledge).
You are incorrect. Most of the artists that I regularly work with have asked me if I could remove this option from winsetup.
Oh, well that put me in my place.
I still prefer giving people more options, so they can play the games the way they want to play them.

And my point still stands when it comes down to voice packs and music.

Alan v.Drake

Quote from: Crimson Wizard on Fri 30/09/2016 03:05:40
So I vote for game property, similar to Alpha Blend modes, which we already have to keep backwards compatible "incorrect" behavior.

I don't think it should be a game property, unless we plan to actually support it. (And if we do, should we try to make the software renderer do the same ?)
Let's also keep in mind that this mode violates the game resolution property, which leads to some important side effects regarding DrawingSurface, DynamicSprite, and savegame screenshots.

To recap, the current D3D approach has the following quirks:

  • objects and characters can be scaled with a higher resolution than native, resulting in mismatched pixel sizes
  • objects merged into the background will become pixelated
  • savegame screenshots are affected by playing resolution and filters
  • DynamicSprite.CreateFromBackground() can give inconsistent results depending on resolution and scaling

There are multiple issues to consider here:

  • DrawingSurfaces and savegame screenshots shouldn't be getting the bitmap from the screen output: the result from these call should be predictable, the developer might be using the input for special effects (e.g: a flashbang effect simulating retina burn, etc). Savegame screenshots wouldn't increase in size with the resolution and would look the same, whatever filter the player is using.
  • if we want to actually support the "incorrect" behaviour how should we cope with all the side effects ?

I wouldn't officially extend support, mostly because AGS is ill equipped to handle this kind rendering the proper way. We'd need vector based movement and walk areas, a different approach to drawing surfaces



Quote from: Crimson Wizard on Fri 30/09/2016 12:58:45
Quote from: Danvzare on Fri 30/09/2016 10:57:40
Still, it would be awesome if you could put in the option to choose between them. Preferably in Winsetup.
I am very interested to know WHY that happens like that in the first place, i.e. what code makes it stretch up before rendering properly, because that may point to the proper solution.
This really bugs me, and the reason I want to underline this is that logically thinking the fix should remove certain operation or alter one, rather than adding additional one, like I've seen in the old Draconian code.

Because (laugh)
Quote from: Pumaman on Sun 14/03/2010 22:38:57
Quote from: Snarky on Thu 11/03/2010 16:25:29
This might be the flipside of Dave Gilbert's problem. Is it possible to fix the Direct3D scaling so it respects the game's original resolution when it's running with a 2x, 3x or 4x filter (at least the nearest-neighbor filter)?

The problem is that the scaling is done with hardware acceleration in D3D mode, and as far as I know it's not possible to tell D3D only to scale to a certain resolution.

The only way of fixing this would be to do the scaling in software mode instead, but then you lose the benefits of using D3D in the first place.


I think it all started because the old code was written assuming you couldn't do it the directdraw way, so the rendering was performed directly to the presentation surface, thus skipping the part where all is rendered on a surface of native resolution that is later stretched to screen. For that reason the _renderSprite() function calculates the relative drawing position of sprites, unlike software mode.



Anyway, browsing the source of the OpenGL driver, I just noticed a variable called "_render_to_texture", that might be doing the same thing I'm doing on D3D.
If that's the case we should bring that into the equation.



- Alan

p.s: it's like we are coding a damned psx emulator... native resolution... backbuffer effects...
p.p.s: I've been writing this damn post since early this morning, I'm just submitting and hoping I haven't left out anything vital



Crimson Wizard

#11
EDITed original post.

Quote from: Alan v.Drake on Fri 30/09/2016 15:06:04
I don't think it should be a game property, unless we plan to actually support it.
I guess I cared too much about keeping all backwards compatibilities all this time, but I honestly think we should support it.

Quote from: Alan v.Drake on Fri 30/09/2016 15:06:04
if we want to actually support the "incorrect" behaviour how should we cope with all the side effects ?
We just don't! The support will only cover effect that was present in the past.
If there would be ideas how to extend this support for other things you mentioned, then it will be implemented, if not, it is okay to keep it like this, with a warning in a manual.
E: This is also why I think that it should be game option, and winsetup should have it only if game developer enables it, because only game author can know if it can break the game or not.
(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).


All this obviously was an unintentional effect by mistake, but there were people who were using this incorrect behavior for their purposes for years. Some of the game developers have explicitly stated that they want this to be kept. I think we need to give them something in return of removing this unintentional engine mistake they were using.

I mean, there might be a way to implement this as a distinct feature, even though having issues with particular operations, in which case it also can be used to run old games which were intended using this effect as a part of game design.


PS.
Quote from: Alan v.Drake on Fri 30/09/2016 15:06:04
AGS is ill equipped to handle this kind rendering the proper way. We'd need vector based movement and walk areas, a different approach to drawing surfaces
AGS engine is bad for many kind of things... and the real, although harsh, question here is whether it is wise to expect big changes with it.
In the past we discussed that many times, and frankly I tend to think that if you want to have an engine with all of those issues fixed, then there should be two branches of the engine: the one that intentionally keeps all the backward compatibility, and another that is completely rewritten, having many old code throwed out, and not aiming to support backwards compatibility at all.

Danvzare

My last two cents on this subject: https://blog.thimbleweedpark.com/gdc2016
The first comment, and Ron Gilbert's response.

If the legend that is Ron Gilbert can give options to the pixel-purists, then why can't we give options to the pixel-unpurists. :-D

Also it needs to be supported for compatibility reasons, like CW said.

Alan v.Drake

Quote from: Danvzare on Fri 30/09/2016 15:45:46
Also it needs to be supported for compatibility reasons, like CW said.

It could be *tolerated* for compatibility reasons (laugh)

- Alan


sonneveld

I'd probably see it as a game setting, and should be available in all modes (software, direct3d, opengl, future sdl etc)

StillInThe90s

#15
I feel obliged to rant a bit, since that is what I usually do whenever this issue is brought up, every two years or so... So bear with me.

//Start of rant:
Spoiler
The D3D mismatched pixel issue is the main reason why I'm still using Alan's 3.2.1 build. I don't want to give players the choice of adding butt ugly mixed res scaling in my game, just like I don't want them to swap my purpose made font for Comic Sans, or add their favorite Lionel Richie tracks instead of the music I chose/wrote/recorded for it.
Apparently, people are designing games around the D3D scaling issue, so dumping it would be a bit harsh on them. However, adding more cluttering, non optional stuff to winsetup would be a bad idea imo. There used to be discussions about minimizing the setup because a lot of players had no idea what all the settings were for. So keeping winsetup clean is probably still relevant(?)
Also, the issue seems to be a potential game breaker as well, making non optional implementation a very bad idea:
Quote from: Crimson Wizard on Fri 30/09/2016 15:17:15
This is also why I think that it should be game option, and winsetup should have it only if game developer enables it, because only game author can know if it can break the game or not.
...which makes CW's suggestion sound pretty neat:
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).
Imo, HQX filters should also be optional if possible (I'm using an old build so maybe they already are).
[close]
//End of rant.

In short: Either in-editor option like CW suggested or if this is not possible, then good riddance.

EDIT: I'm sorry, is this thread about the main build or the new Draconian? (Rant applies to both I suppose... :-D)

Alan v.Drake

Quote from: StillInThe90s on Tue 04/10/2016 21:09:30
(Rant applies to both I suppose... :-D)

Yes.
Beware of switching to the last Draconian, it's based on 3.4.0 and is still missing a few things (my junk filters for DD), be sure to make a backup!

- Alan

Danvzare

Quote from: StillInThe90s on Tue 04/10/2016 21:09:30
or add their favorite Lionel Richie tracks instead of the music I chose/wrote/recorded for it.
If you put in the ability to change music volume (which you should), then people can simply mute your music and play their own background music.
I've actually done that with some games that have horrible soundtracks. Only about two I think.

Although I think that's besides the point. Why do you want people to experience your games in such a specific way?
Are you also going to force them to have a specific monitor, with a specific resolution, and with the brightness levels set to a specific value? Perhaps you're going to make sure they have a specific keyboard that makes a specific clicky noise when you press the keys?

What you're saying would the equivalent of a movie maker only wanting his film to be seen in a cinema, because a television wouldn't be able to give the full experience.
What your'e saying is like James Cameron's Avatar only having a 3D version, because that's what it was made to be watched in (screw those guys who prefer 2D).

When you release your game into the world, you've got let it go to some extent and understand people will want to play it their way. It's why mods are so popular on the PC!
You can't be so draconic in how it's played (and yes, pun completely intended).

StillInThe90s

Calm down, Danvzare.
If you want to make a extensively moddable game, that is fine. And If I don't want to include stuff that I think looks like crap in my game, then that should not be a huge issue. Sure people can ruin my game for all I care. I just do not want to ship it like that.

Quote from: Alan v.Drake on Tue 04/10/2016 23:27:45
Beware of switching to the last Draconian, it's based on 3.4.0 and is still missing a few things (my junk filters for DD), be sure to make a backup!
Was that a joke or should I wait for a later version? Is it unstable or just missing bits?

Crimson Wizard

#19
Danvzare, in my opinion, your examples are completely off scale with the setting in question. Everything you mention - brightness, etc - as well as previously mentioned gfx filters - they make an effect on all the game, in equal sense, and its core playability. While this option we were talking about makes an effect on particular objects' relative looks. It's like demanding that there were separate gamma setting or custom tinting slider for characters. Sure, thay could come handy in some cases, but forcing game developers to implement one regadless of what they want?


Quote from: Danvzare on Wed 05/10/2016 10:49:23
When you release your game into the world, you've got let it go to some extent.
But what defines this extent if not game designer? And why the method particular sprites in game are drawn should be an obligatory element in player settings?
When Ron Gilbert adds it to his game, he probably knows that his game will look fine with either variant. But that is not necessarily true for all games.


SMF spam blocked by CleanTalk