Scaling and DirectDraw

[subspark]

Ive been raving about this scaling problem for ages. Im glad a few more of you are on the bandwagon. Nice examples, Snarky.

Cheers,
Sparky.

[Kweepa]

I rather like what D3D does to scaled characters. It works really well for 3xNN and characters scaled small amounts (90%, 110%).

[subspark]

Its really inconsistent. I suggest an option to support both, if both cases are strong enough.
Personally i view the current dx9 implementation as broken/incomplete but I'm sure there are others like you who have grown to appreciate the unusual side effects.

Cheers,
Sparky.

[Pumaman]

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.

[subspark]

Sigh. This not good.  :'(

[Snarky]

I was thinking maybe it would be possible to do the scaling in two steps. First do the sprite scaling by 65% or whatever to shrink the character, then take that temporary sprite and scale it up to 2x, 3x or 4x to match the game resolution. But admittedly I know nothing of how D3D works, so maybe that idea makes no sense whatsoever.

[Shane 'ProgZmax' Stevens]

To simulate a blockier scaling couldn't you just alter the D3DXVECTOR  scaling factor to some multiple of 2 rather than smoothly scale the texture as it moves along the walkable area?  This would make the resulting texture scale in 'blocky' units and may achieve a similar, if not visibly alike, result.  Obviously this method wouldn't be ideal at all for hi-res games so perhaps it could check to see what the default game resolution is before altering the scale step (320x240 and below: yes, 640x480 and above: no).

[Pumaman]

I was thinking maybe it would be possible to do the scaling in two steps. First do the sprite scaling by 65% or whatever to shrink the character, then take that temporary sprite and scale it up to 2x, 3x or 4x to match the game resolution.

That's basically what it does in software mode with the DX5 driver. But as far as I'm aware it's not possible to do something like that with D3D hardware acceleration, as there is no concept of a temporary sprite.

To simulate a blockier scaling couldn't you just alter the D3DXVECTOR  scaling factor to some multiple of 2 rather than smoothly scale the texture as it moves along the walkable area?  This would make the resulting texture scale in 'blocky' units and may achieve a similar, if not visibly alike, result.

Even if the target width/height was rounded to the nearest multiple of two, the way it scales would still look out of place due to the "half-size" pixels in the scaled graphics. It would be good if there was a solution to this...

[Shane 'ProgZmax' Stevens]

Would subtracting 1/2 from the screen coordinates keep the drawing rectangle so it only contains full pixels (no half-size pixels), or am I way off-base?

This is a problem I'm absolutely certain I've run into before (other people as well no doubt!) and I'm just as certain there's a fairly reasonable and pain-free solution.

[JJS]

That's basically what it does in software mode with the DX5 driver. But as far as I'm aware it's not possible to do something like that with D3D hardware acceleration, as there is no concept of a temporary sprite.

It should be possible to first render the whole scene to a texture in the games original size and then render a quad with that texture to the actual screen.

[Gilbert]

But then the purpose of using D3D will be lost.

[JJS]

I don't think so. The purpose of the D3D driver seems to be having hardware accelerated drawing to ease the load of complex drawing operations (e.g. particle system, transparency). Correct me if I am wrong here.

If the Direct3D way of rendering to a texture is anything like the OpenGl way, there is no real difference between it and drawing to the screen surface. All hardware acceleration is still being used.

The final rendering pass to the screen is also fairly lightweight with two triangles and one small(ish) texture that is already in the graphics cards memory.

[Snarky]

And you can do the final scaling using the selected graphics filter (nearest-neighbor or HQ)? It's not going to be some ugly bilinear or bicubic thing going on?

If so, it sounds perfect!

[subspark]

Yeah I actually agree here. This sounds like a sound solution to me in all cases. Like many of you, I assumed DirectX9 acceleration to be more than just DirectDraw5 with hardware scaling.
Coupling the performance benefit with the ability to scale the screen surface up at any desired resolution or aspect for that matter would be totally novel.

Thanks goes out to all you guys for putting your heads together on this one. I hope it turns out to be the solution everybody was looking for.

Big cheers,
Sparky.

[Pumaman]

I don't think so. The purpose of the D3D driver seems to be having hardware accelerated drawing to ease the load of complex drawing operations (e.g. particle system, transparency). Correct me if I am wrong here.

If the Direct3D way of rendering to a texture is anything like the OpenGl way, there is no real difference between it and drawing to the screen surface. All hardware acceleration is still being used.

The final rendering pass to the screen is also fairly lightweight with two triangles and one small(ish) texture that is already in the graphics cards memory.

The character sprite (at normal size) is already in a texture in Video RAM.
AGS tells D3D to render the texture at the scaled size.

It sounds like what you're suggesting is that AGS does a resize in memory and then renders the scaled sprite to a new texture at the scaled size; and then tells D3D to draw this texture to the screen at normal size.

If it did that, then effectively it's just doing software-based sprite resizing, which defeats the point of using D3D in the first place because the resize is no longer accelerated.

EDIT: ah ok, I see you're suggesting rendering the scaled sprite to a texture and then rendering this texture to the screen. Interesting idea, it might work, I'd need to look into it further.

[JJS]

Yes, I mean doing all rendering on a texture instead of the screen surface.

So the rendering would then consist of:
- Creating a texture in the games original resolution e.g 320x200
- Setting this texture as the render target
- Setup the viewport etc. as if you were drawing on a 320x200 screen
- Drawing everything
- Switching the render target to the screen and rendering a quad with the texture

Google turned up this: http://www.two-kings.de/tutorials/dxgraphics/dxgraphics16.html

I don't know how the high quality scaling filters are applied, but I guess they can operate on a single texture.

[Pumaman]

Ok thanks, it sounds like this could work. I'll look into it for the next version of AGS.

[subspark]

Yipeeee!!!!     

[RedTalon]

I'm specifically designing my game to work around this problem, as I would want those with older systems to enjoy the game fully. Each room will allow for only one uniform size of the character - but where scaling would normally be required, I'll be scripting in a separate view. To limit the number of sprites, I hope to keep these 'extra' views limited to transition screens (just walking, climbing etc.) where other animations aren't required.  

And, thanks to vectoring, I don't have to worry about my artist going insane from creating the extra scaled sprites.

Or should I say more insane.