Scaling and DirectDraw

[Dave Gilbert]

Hi everyone!  I'm having a little issue regarding scaling in a hi-res game.  Normally this would be solved by choosing the "Direct3D" option in the settings file, but I learned when I released Blackwell Convergence that at least 10% of my users have computers that aren't compatible with Direct3D, so they were unable to run the game and had no clue how to fix it (which caused a lot of problems and lots of lost sales!).  So, I'm sticking with DirectDraw.  However, I am noticing a problem with scaling in that mode, even when the "smooth scaled sprites" option is enabled.

The following screenshot was taken with Direct3D enabled:



This was was taken with DirectDraw enabled:



This background required the characters be scaled down a bit, and as you can see, the quality gets downgraded significantly with DirectDraw.  In low-res games this was never an issue, but it's much more noticeable at higher resolutions (especially in full-screen mode!).  I am using AGS version 3.1.2.  I've resisted upgrading up till now, but I'd do it in a heartbeat if this was fixed in the most recent version of AGS.  Otherwise, is there a way around this?  Is there a way to detect if a computer is Direct3D compatible at runtime and change it on-the-fly?  

[AGD2]

I've ran into this hurdle too. It's often ideal to run hi-res games with the 2x filter in order to benefit from the improved scaling (especially at very small scaling sizes). However, due to the fact that the Direct3D driver doesn't work on all systems, this pretty much forces you to make the DirectDraw driver the default one, which results in the issues you've mentioned. The problem is that a lot of people are unaware that they can change the graphics options in winsetup.exe to make things look better.

The ideal solution would, indeed, be if AGS detected Direct3D capability at run-time. (In fact, I think it'd be great if all the current winsetup.exe options could be altered from an in-game "options" menu rather than having to access winsetup.exe -- it'd be more intuitive.) But since that's not possible at the moment, the only potential solutions I can think of are:

1) Ship your game with a launcher menu .exe file, but don't include the winsetup.exe file. Allow several different "pre-set" configurations to  be selected from your launcher menu, and include a corresponding acsetup.cfg file for each one.

2) Similar to the above, but program the various options into a GUI menu inside your AGS game. Then use WriteRawLine to write each setting as a new line into the acsetup.cfg file. The DirectDraw driver would be set by default (to ensure that the game loads). And if a player tries changing to the Direct3D driver, you could display an in-game message giving them instructions on how to reset the DirectDraw driver if the D3D one crashes the game on them. For this to work, the game would need to quit and be reloaded after the new .cfg file is written to ensure the new settings take effect. A bit sloppy.

3) I know next to nothing about this, but according to the Microsoft site there is a function (DrvGetDirectDrawInfo) that can be called to determine a computer system's capability to use the Direct3D driver.

"The DrvGetDirectDrawInfo function returns the capabilities of the graphics hardware."

http://msdn.microsoft.com/en-us/library/ms793204.aspx

This goes beyond the scope of my knowledge, but perhaps it's possible to write some kind of batch file or plugin that gets called before your game's .exe file is loaded and returns a value, regarding whether or not the system can utilize D3D capabilities. Perhaps someone with more knowledge is able to shed some light on whether this is possible...

Also useful, would be if AGS's System.HardwareAcceleration; function returned whether the user's system was capable of running the AGS game in D3D mode, rather than just reporting if the game is currently running in that mode.

[xenogia]

This would definitely be a great function actually, it would help with compatibility.

[Calin Leafshade]

I think a launcher with the ability to detect graphics capability would be best.. and pretty easy to code too.

[xenogia]

What would be really good is to actually game settings from within the game really easily.

[Dave Gilbert]

Being able to change the game's settings from with the game file - without making your savegame files obsolete! - would be the best thing ever.  You wouldn't believe the amount of confusing I get from users when I try to explain how to change the settings.  As strange as it seems, a lot of users don't even know how to navigate to a folder on their computer! 

[Kweepa]

I don't see your scaling problems getting fixed any time soon.
So, your options are:
* have the room redrawn so that the characters fit in without scaling
* have the characters redrawn (or just rescaled in photoshop) to fit the background for this room, and script it up to use the new graphics in this room
Whee!

[Dave Gilbert]

This isn't the only case where the characters need to be scaled, and the characters have lots of individual animations.   I could rescale all the animations for all of the characters in each instance that they need to be scaled, but that would be a ton of work and could conceivably double the size of the sprite file (which is already huge as it is!).  As for the backgrounds, they've all have been created (and paid for!) so redoing them now is an impossibility. 

So... what I'll probably do is sell the direct3D version off of my website (where the players are usually more tech-savvy), and sell the DirectDraw version on the distribution portals (where the players are usually, well, not).  Fortunately, the situations where this problem occurs are only in cutscenes, and they take place toward the middle/end of the game.  So hopefully any potential "fallout" will be minimal.  Aside from CJ fixing this problem in the next two months, there's not much else I can do.

I suppose this is what I get for not testing DirectDraw sooner!  For future games I'll definitely remember this problem and make sure to design everything so we won't require much scaling. 

[Ali]

I'm sure you all know, but it hasn't been mentioned in the thread: Selecting "Downgrade 32-bit graphics to 16-bit" will make smooth-scaling work correctly at the expense of alpha channels / anti-aliasing.

[subspark]

Unfortunately, your issue is native to DirectDraw5. It's an older engine and thats just how it shows its age. I doubt anything will or could be done to special-case fix it.
Your lower-spec customers are probably going to have to put up with the slight difference. I would however warn them of the differences and encourage them to play your titles on a DX9 capable computer.

What IS fixable though is DirectX9's up-scaling feature particuarily with low res games in that it doesnt scale pixel for pixel. It ununiformly interpolates the pixel grid, creating a mish-mash of different sized pixels-between-pixels.
Somewhere a fix is out there for this so that the upscaling algorithm forces a 1:1 match on the pixel grid.

Good luck with your new game Dave. I'm a proud customer of your Blackwell series. Keep it up.

Cheers,
Sparky.

[AGD2]

I think the issue isn't a matter of "fixing" the DirectDraw scaling per se, but rather to make AGS capable of detecting whether the user's system is capable of Direct3D, and if not, automatically making the game's display use the DirectDraw driver instead.

It's somewhat redundant, having to make two versions of a game and maintain them both when a (presumably) simple auto-detection of the system's graphics capabilities would eliminate this. This way, the game's optimal settings (Direct3D driver) can be set in the .cfg and released with the game, but if a particular user's system doesn't support these optimal settings, then rather than receiving a crash error, the game would simply run with the alternate DirectDraw driver without requiring any intervention from non tech-savvy players.

--EDIT--

An afterthought: What might actually be cool is the ability to set up a number of (completely optional) alternate "configurations" in the acsetup.cfg file. These would be listed in order of preference. When executed, the AGS game would try each "configuration" until it finds the first one that's compatible with the user's system. The benefit to this approach would be multiple attempts at getting the game to look as intended (or at least half decent) in the eyes of the designer.  It would only default to using "bare bones" settings (i.e. the DirectDraw driver) if no alternate "configurations" were found in the .cfg file or if none of them are compatible with the system.

This could be taken a step further by having certain configurations only applicable if the user's processor and/or GPU meets a certain speed - permitting filters to be enabled for hi-res games in the event that the user's CPU/GPU will be fast enough to handle the game without slowdown.

[subspark]

Automated 'benchmarking' combined with in-game configuration would be a radical improvement.
Sparky.

[GarageGothic]

Yeah, it would make a lot of sense if the engine would be able to autodetect Direct3D compatibility, just like it now tries different resolutions if the pre-set one doesn't work. The less need for the player to fiddle around with winsetup, the better.

[Dave Gilbert]

Oh yes.  Pretty please, Chris?  This would be a major major boon.

[Shane 'ProgZmax' Stevens]

The ability to switch realtime between modes would be very useful as well for the many people who see improvements in one mode or the other (visually, aesthetically).  Not only scaling is affected by d3d/dd5 afterall; I've noticed many small but noticeable differences in the modes that might be far more obvious to people with different video card and computer configurations!  I realize realtime changing of modes (including windowed/fullscreen) has been a subject of much discussion over the years but honestly I think working towards it (even if a little at a time) would bring a world of good to the engine and its users.  This would also allow a scripter (along with a function that returns the hardware capabilities of the system) to make their own mode toggle without having it hard coded, like so:

Code: ags

//place this in game_start to automatically generate the default mode

if(PollHardware.D3dSupport() == true)
{
   Game.RenderMode(eD3dmode);

}
else
{
  Game.RenderMode(eDdrawmode);
}

PollHardware would be the generic access point through which the scripter interfaces with the pc hardware, be it a check of render modes available, supported resolutions, and so on.  This could also be used to poll devices like gamepads, microphones, you name it, though that's certainly best left for another topic (and argument ).

[GarageGothic]

An overhaul of the way AGS initializes its viewport would also be an excellent occasion to implement better widescreen resolution support, as has been discussed elsewhere.

Just out of interest: Has the problem of savegame incompatibility between resolutions been resolved? I would think that could be a major obstacle to allowing in-game graphic mode toggle.

[Shane 'ProgZmax' Stevens]

Not as yet, but I think it would be possible to overcome if the game assumed you were using either mode and saved two split sections of data in each savegame (windowed/fullscreen).  It's messy and would make the save files larger but theoretically it should work.  Rewriting the way savegames work would be the only really 'proper' way of fixing the issue, I guess, but I don't remember ever having been told exactly what it is about the savegames that disallows transition between the modes (so this is all just conjecture on my part).

That said, switching render modes or between windowed and fullscreen *shouldn't have any significant impact on the save states since the room sizes and such all remain the same so the only place where I could logically see an issue appearing would be switching between unlike resolutions (room/sprite sizes are then altered which could be a problem).  This is the main reason why I'm confused about the windowed/fullscreen ddraw/d3d realtime issue since you shouldn't need to do anything to the savegames except maybe setting a render mode/display mode variable and restarting the engine with a command to reload the config and some autosave made just before the adjustment?  

*I'm not sure exactly what data is saved about render and display modes so this is a supposition.

**switched out the d3d/ddraw bits since I confused them with my previous post

[Pumaman]

Yeah, it would make a lot of sense if the engine would be able to autodetect Direct3D compatibility, just like it now tries different resolutions if the pre-set one doesn't work. The less need for the player to fiddle around with winsetup, the better.

Yes, this is probably a good idea. AGS already detects whether the system supports Direct3D, so this should be possible to do.
I'll look into it for a future version.

Just out of interest: Has the problem of savegame incompatibility between resolutions been resolved? I would think that could be a major obstacle to allowing in-game graphic mode toggle.

Yes, that is no longer an issue because it's no longer possible to change the resolution, only the graphics filter.

[Snarky]

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

This is from Aeronuts running with 3x nearest-neighbor in DirectDraw and Direct3D:



In DirectDraw, the character matches the resolution of the background, while in Direct3D it doesn't, and the scaling is uneven with different pixels several different sizes (1x1, 2x1, 2x2...). It seems clear to me that the first alternative is the desired behavior.

(Another weird difference is that the colors don't match; in D3D you can see much more noticeable banding across the sky.)

[Shane 'ProgZmax' Stevens]

I've wondered the same thing Snarky has, though my workaround has been to do everything in double-wide pixels which scale down beautifully.  Obviously this isn't meant to be suggested as a workaround for everyone, I just happen to like c-64 style and it's very scale-friendly.  I do think the D3D scale should take into account the resolution somehow, though.


Also, I notice the difference in sky hues between the ddraw and d3d pics above as well as the face of the foreground sign.  Interesting.