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:
(http://www.davelgil.com/PBdirect3D.png)
This was was taken with DirectDraw enabled:
(http://www.davelgil.com/PBdirectDraw.png)
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?
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.
This would definitely be a great function actually, it would help with compatibility.
I think a launcher with the ability to detect graphics capability would be best.. and pretty easy to code too.
What would be really good is to actually game settings from within the game really easily.
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!
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!
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.
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.
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.
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.
Automated 'benchmarking' combined with in-game configuration would be a radical improvement.
Sparky.
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.
Oh yes. Pretty please, Chris? This would be a major major boon.
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:
//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 :) ).
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 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=39521.0).
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.
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 :)
QuoteYeah, 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.
Quote from: GarageGothic on Sun 21/02/2010 05:24:03
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.
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:
(http://home.comcast.net/~snarkibartfast/images3/ddrawscale.png) (http://home.comcast.net/~snarkibartfast/images3/d3dscale.png)
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.)
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.
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.
I rather like what D3D does to scaled characters. It works really well for 3xNN and characters scaled small amounts (90%, 110%).
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.
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.
Sigh. This not good. :'(
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.
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).
Quote from: Snarky on Mon 15/03/2010 18:30:42
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.
QuoteTo 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...
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.
Quote from: Pumaman on Tue 16/03/2010 20:30:15
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.
But then the purpose of using D3D will be lost.
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.
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!
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.
Quote from: JJS on Thu 18/03/2010 07:32:05
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.
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.
Ok thanks, it sounds like this could work. I'll look into it for the next version of AGS.
Yipeeee!!!! ;D ;D ;D
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. ;D