Author Topic: Direct3D scaling implementations  (Read 7874 times)

Direct3D scaling implementations
« on: 30 Sep 2016, 01:21 »
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

  • ǝ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 #1 on: 30 Sep 2016, 02:56 »
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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #2 on: 30 Sep 2016, 03:05 »
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?

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.


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...
« Last Edit: 30 Sep 2016, 12:52 by Crimson Wizard »

Scavenger

  • Cavefish
  • In Four Glorious Colours!
    • I can help with animation
    •  
    • I can help with backgrounds
    •  
    • I can help with characters
    •  
    • I can help with scripting
    •  
    • Scavenger worked on a game that was nominated for an AGS Award!
      Scavenger worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #3 on: 30 Sep 2016, 03:39 »
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

  • 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 #4 on: 30 Sep 2016, 10:57 »
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.
« Last Edit: 30 Sep 2016, 11:10 by Danvzare »

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
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #5 on: 30 Sep 2016, 12:58 »
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.
« Last Edit: 30 Sep 2016, 13:06 by Crimson Wizard »

Radiant

  • AGS Baker
  • Mittens Knight
  • Return once more to the Two Kingdoms!
    • I can help with publishing
    •  
    • I can help with story design
    •  
    • Radiant worked on a game that was nominated for an AGS Award!
      Radiant worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #6 on: 30 Sep 2016, 13:25 »
Still, 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

  • 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 #7 on: 30 Sep 2016, 14:52 »
Still, 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

  • AGS Baker
  • Mittens Knight
  • Return once more to the Two Kingdoms!
    • I can help with publishing
    •  
    • I can help with story design
    •  
    • Radiant worked on a game that was nominated for an AGS Award!
      Radiant worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #8 on: 30 Sep 2016, 14:54 »
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

  • 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 #9 on: 30 Sep 2016, 14:58 »
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.

Re: Direct3D scaling implementations
« Reply #10 on: 30 Sep 2016, 15:06 »
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



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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #11 on: 30 Sep 2016, 15:17 »
EDITed original post.

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.

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.
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.
« Last Edit: 30 Sep 2016, 16:33 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 #12 on: 30 Sep 2016, 15:45 »
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.

Re: Direct3D scaling implementations
« Reply #13 on: 30 Sep 2016, 16:46 »
Also it needs to be supported for compatibility reasons, like CW said.

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

- Alan


Re: Direct3D scaling implementations
« Reply #14 on: 30 Sep 2016, 23:29 »
I'd probably see it as a game setting, and should be available in all modes (software, direct3d, opengl, future sdl etc)

Re: Direct3D scaling implementations
« Reply #15 on: 04 Oct 2016, 21:09 »
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:
Add spoiler tag for Hidden:
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:
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:
(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).
//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)
« Last Edit: 04 Oct 2016, 21:26 by StillInThe90s »

Re: Direct3D scaling implementations
« Reply #16 on: 04 Oct 2016, 23:27 »
(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

  • 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 #17 on: 05 Oct 2016, 10:49 »
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).

Re: Direct3D scaling implementations
« Reply #18 on: 05 Oct 2016, 19:43 »
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.

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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: Direct3D scaling implementations
« Reply #19 on: 05 Oct 2016, 20: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?


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.

« Last Edit: 05 Oct 2016, 23:09 by Crimson Wizard »