Direct3D issues list

Started by Crimson Wizard, Sat 04/02/2017 19:28:18

Previous topic - Next topic

Crimson Wizard

What are the known Direct3D renderer issues at the moment?
Fixing them is very important, because most of them are probably not related to Direct3D as a system, but to how AGS uses it. In other words, 1) they may be not that difficult to fix, 2) they may affect other hardware accelerated renderers (OpenGL, for instance, which is currently used only by mobile ports, but may be used by desktop versions in the future).
Also, I believe that game should not depend on single renderer, that is dangerous in the sense that it may make it unplayable on certain systems.

KNOWN ISSUES:

1. Imperfect sprite scaling (also known as super-sampling). FIXED in 3.4.1 by introducing sprite scaling switch
Explained here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=53972.0
This is already fixed in the development version, and solution will be included to the new upcoming beta version.

2. Color distortion. FIXED in 3.4.1 by launching games in 32-bit display mode
Mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=40132.msg532501#msg532501 (but screenshots are no longer available).
What is that and how can I see that (under which conditions)?

3. Supports only up to 75 sprites (character and objects) displayed at the same time.FIXED in 3.4.1
Mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51823.msg636508899#msg636508899
This is a ridiculous problem that can be fixed in no time.

4. 8-bit games do not work with Direct3D.
This is a critical problem for 8-bit games (if the software renderer cannot work on a system for some reason). Not certain how difficult, but there may be ways to make it work though.

5. IgnoreWalkbehinds property does not work properly in Direct3D mode
This is because it makes objects arranged in a non-sensical z-order on screen. I think, in theory it may be possible to make it work with a certain hack, but I'd rather won't bother unless only in the sake of supporting old games which use it to run with D3D and OpenGL.

6. Another restriction of 200 displayed sprite entries. FIXED in 3.4.1
Similarly should be very easy to remove the limit, although that is unclear if AGS games ever may have that many separate objects on screen.

7. 8-bit sprites are not converted 100% accurately (in non-8bit games), compared to software renderer.
Cause is currently unknown.

8. BlitSprite* plugin API functions do not work with hardware-accelerated renderer. FIXED in 3.4.1
Details and possible solutions:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=25665.msg636554785#msg636554785



Do you know any other problems that prevent you to use Direct3D for your games?

Mehrdad

Do you mind if I mention an important plugin? Rain/snow plugin is so useful and doesn't work with D3D . I really need to it. Sorry if this post is out of thread. 
My official site: http://www.pershaland.com/

Crimson Wizard

#2
Quote from: Mehrdad on Sun 05/02/2017 16:04:03
Do you mind if I mention an important plugin? Rain/snow plugin is so useful and doesn't work with D3D . I really need to it. Sorry if this post is out of thread. 
Frankly, this is up to plugin authors, not engine developers, to make them work properly, this is the idea of plugins.

Snow/rain plugin in particular was rewritten by JJS to work on mobile ports, which probably means it should work with D3D too, but I am not certain. The code is located in our repository. Maybe someone could check if it works: https://github.com/adventuregamestudio/ags/tree/master/Plugins/ags_snowrain

Snarky

Here's a pair of screenshots that demonstrate the Direct3D color distortion. The game is Aeronuts, running in AGS 3.20.1099 (and I believe it's a 16-bit game, which may be relevant). To reach this screen, just start the game and walk one screen left ("to backside").

(Sorry for the size, I used a 4X filter to also demonstrate the sprite scaling.)


DirectDraw


Direct3D

Notice the banding in the clouds. I've verified this this is not some kind of screenshot artifact, but how the background actually appears when playing. It also looks the same way both when running in a window and full-screen.

Crimson Wizard

I had to open two screenshots in two tabs and switch between them to notice the difference, but yes, I see what is wrong now.

Also the grass is darker. It looks like D3D increases image colour contrast in general.

abstauber

When you least expect it, an Aeronuts Screenshot pops up :-D
I just wanted to mention, that the sources have been updated to AGS 3.3. Just in case the D3D rendering has changed between 3.2 and 3.3

Snarky

Quote from: Crimson Wizard on Sat 04/02/2017 19:28:18
3. Supports only up to 75 sprites (character and objects) displayed at the same time.
Mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51823.msg636508899#msg636508899
This is a ridiculous problem that can be fixed in no time.

For the record, the problem can be experienced with the 2014 AGS Awards client, which runs in AGS 3.3.3.0 (set the renderer to Direct3D, start the game, select a character/name; as soon as the intro is over and the character tries to enter the main hall, the game will crash with a Windows error). Project source here.

Crimson Wizard

Quote from: Snarky on Tue 07/02/2017 07:58:47
For the record, the problem can be experienced with the 2014 AGS Awards client, which runs in AGS 3.3.3.0 (set the renderer to Direct3D, start the game, select a character/name; as soon as the intro is over and the character tries to enter the main hall, the game will crash with a Windows error). Project source here.

When I try to start, it tells me "Connection failed" all the time. Is there anything I need to set up first?

Snarky

#8
No, I think the IRC server or channels from back then aren't available any more, so you won't be able to get into the hall, but in Direct3D it should crash before you get to that point (unless there's some race condition going on to see what error happens first). If for some reason you really need to connect, I can look into changing the IRC settings.

Crimson Wizard

#9
Quote from: Snarky on Wed 08/02/2017 20:25:27
No, I think the IRC server or channels from back then aren't available any more, so you won't be able to get into the hall, but in Direct3D it should crash before you get to that point (unless there's some race condition going on to see what error happens first). If for some reason you really need to connect, I can look into changing the IRC settings.

Oh right, it actually does crash in the original game, but not after my fix, so it gets to connecting instead.


Regarding colour distortion, this may be because Direct3D converts 16-bit images to 15-bit first. I am not completely sure why, but it looks like that was only way to support transparency on textures, as A1R5G5B5 pixel format (15-bit for RGB and 1 bit for alpha channel).
The most straightforward solution that comes to my mind is to convert 16-bit sprites to 32-bit at runtime.

Crimson Wizard

#10
Well... looks like two latter Direct3D problems are fixed in this build too:
http://www.mediafire.com/file/on8el7ebw2a6o8c/acwin--direct3d-fixes-for-341.zip

The code is not perfect yet, and I found one game crashing case (if more than 1 room background frame is used), but I think I will be able to make it work soon.

I am actually converting 16-bit bitmaps to 32-bit textures now, although the display mode is still 16-bit, which probably does not make much sense... but D3D can handle that at least.

Maybe the right thing is to create 32-bit display mode even for 16-bit games. I think OpenGL renderer does exactly same on Android & iOS.


PS.
All this actually made me think, what if it may be possible to run 8-bit games on Direct3D, in 32-bit display mode?
8-bit images and palette is in control of Allegro library, and it is possible to just copy their contents to the texture using rather simple pixel conversion algorithms.

Danvzare

Quote from: Crimson Wizard on Wed 08/02/2017 20:59:18
Regarding colour distortion, this may be because Direct3D converts 16-bit images to 15-bit first. I am not completely sure why, but it looks like that was only way to support transparency on textures, as A1R5G5B5 pixel format (15-bit for RGB and 1 bit for alpha channel).
The most straightforward solution that comes to my mind is to convert 16-bit sprites to 32-bit at runtime.
May I make a suggestion to keep the old 16-bit version of Direct3D with the colour distortion, as a hidden setting for compatibility reasons.
I doubt it will ever be used, but it could be useful for a computer which can't run DirectDraw or 16-bit.
There's bound to be at least one computer like that somewhere.

Crimson Wizard

Quote from: Danvzare on Wed 08/02/2017 21:39:29
May I make a suggestion to keep the old 16-bit version of Direct3D with the colour distortion, as a hidden setting for compatibility reasons.

I'd rather find a way to detect supported modes automatically. It's not like there are different versions of renderer, it's just what parameters it uses.

Gilbert

Quote from: Crimson Wizard on Wed 08/02/2017 21:14:52
PS.
All this actually made me think, what if it may be possible to run 8-bit games on Direct3D, in 32-bit display mode?
8-bit images and palette is in control of Allegro library, and it is possible to just copy their contents to the texture using rather simple pixel conversion algorithms.
If this is possible, would the conversion be done in every single frame (my guess is this isn't necessary for 16-bit games)? Otherwise I don't think palette effects could ever be done. I mainly work with 8-bit graphics as I abuse palette effects, and that the games won't even run under D3D is a real bummer(considering that more and more people claim that DX doesn't work in their rigs). I wonder whether it will cause much slowdowns if it's to be done every frame, but if palette effects have to be sacrificed to use the D3D renderer IMO it's just useless. I remembered 8-bit games work under Android (checked very old JJS builds only; not checked recent builds yet). How is this done? Does OGL just use 8-bit textures directly? In that case, maybe making OGL selectable in the Windows engine is also a solution? (I haven't checked the recent versions yet, so if this is already possible just ignore me.)

Crimson Wizard

Quote from: Gilbert on Thu 09/02/2017 05:15:09
Quote from: Crimson Wizard on Wed 08/02/2017 21:14:52
PS.
All this actually made me think, what if it may be possible to run 8-bit games on Direct3D, in 32-bit display mode?
8-bit images and palette is in control of Allegro library, and it is possible to just copy their contents to the texture using rather simple pixel conversion algorithms.
If this is possible, would the conversion be done in every single frame (my guess is this isn't necessary for 16-bit games)? Otherwise I don't think palette effects could ever be done.

I had same thoughts recently; and I guess this makes things more complicated. The process could be optimized by only updating textures when palette changes (this is possible to detect).
Alternative solution was always to use shaders for palette effects, but I do not know how this works exactly.
In any case, I do not think I'll be working on this right now.


Quote from: Gilbert on Thu 09/02/2017 05:15:09
I remembered 8-bit games work under Android (checked very old JJS builds only; not checked recent builds yet). How is this done? Does OGL just use 8-bit textures directly? In that case, maybe making OGL selectable in the Windows engine is also a solution? (I haven't checked the recent versions yet, so if this is already possible just ignore me.)
I do not know if it does...
OpenGL renderer is potentially working on Win, but it is not finished, for example it is currently hardcoded to run in 1000x500 window and no fullscreen. Never found time to look into finishing it.

Crimson Wizard

#15
While preparing 3.4.1 release, I returned to this problem. Here is the new build, which should have named D3D issues fixed:
http://www.mediafire.com/file/csc6ccvl3cx6ibf/acwin-3.4.1-d3d-ogl.zip

It changed the rules of how display mode is chosen for hardware-accelerated mode. It runs in 32-bit mode by default regardless of game native color depth, unless you tick "Downgrade graphics to 16-bit" checkbox in setup. I am not sure if that is ever needed in year 2017, but I left it just in case for now.

There are two things that are still bothering me:
- first, I found that along with the aforementioned limit of 75 sprites, it also has a limit of 200 sprites in another place... which is less problem, but still. I will remove it.
- some 8-bit bitmaps found in non-8bit games are still not converted 100% accurately. I do not know what can be wrong there, because the code looks generally OK, but maybe there is a nuance I am not aware about.


Along with fixed D3D, this build also has a surpise: a working (sort of) OpenGL renderer for Windows. TBH, it works correctly only if you run it in the small window, otherwise game is displayed unscaled in the center of screen, and mouse is locked to the small region at the top-left corner of screen...
PS. I found it CAN run very certain games properly, but I could not understand what's so different about them. Anyway, that's not important.

EDIT: Hmm, I kinda think it runs properly only hi-res games, but not 320x200 and 320x240 games. So that needs fixing first. But hopes are very high.

Crimson Wizard

Hmmmm.... this was not in current plans, but it turned out Direct3D can now run 8-bit games :=

Dynamic palette cycling does not work still (we need shaders for these), but apart from that they run without problems.

Crimson Wizard

Update, as of 3.4.1 only following issues remain:

4. 8-bit games do not work with Direct3D.
5. IgnoreWalkbehinds property does not work properly in Direct3D mode (probably something that is not meant to be fixed)
7. 8-bit sprites are not converted 100% accurately (in non-8bit games), compared to software renderer. (IDK what is going on there, may be some oversight, or palette do not load up correctly for any reason).

Since this is mostly 8-bit incompatibility, I am unsticking the thread now.

Snarky

Quote from: Crimson Wizard on Thu 29/06/2017 14:11:08
5. IgnoreWalkbehinds property does not work properly in Direct3D mode (probably something that is not meant to be fixed)

Yeah, CJ talked about this a long ago. IgnoreWalkbehinds potentially screws up the Z-order of sprites in the scene (because if a sprite ignores walkbehinds â€" i.e. it is in front of any walkbehind â€" but is behind a sprite that is behind a walkbehind, you have a loop in the "in front of" graph, and what to actually render is undefined), and therefore isn't really compatible the D3D method of rendering the scene.

SMF spam blocked by CleanTalk