Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / dbSync bug? Windows lock causes access violation

Author
Message
Haz
14
Years of Service
User Offline
Joined: 6th Oct 2010
Location:
Posted: 6th Oct 2010 17:47
This is easy to replicate.

Load up the simple 2D example game, the one with the scrolling asteroids, and start it up.
Lock the windows session while it's running (winkey-L).
Unlock session.
Access violation!

Does anyone know why dbSync would do that? And more importantly, is there a way for me to fix it or work around it?

I've tried suspending the thread or putting it to sleep, but no luck.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Oct 2010 00:16
DGDK is full of bugs... For a commercial product to have such a critical bug in it, that has been around since the beginning really is disgraceful.

Basically when any error happens in DGDK it doesn't properly report it and its memory management goes mad.

CSL
15
Years of Service
User Offline
Joined: 22nd Mar 2009
Location: USA
Posted: 7th Oct 2010 05:59
What OS are you using?
With Windows 7 you don't get an access violation, but the sprites turn into flying white squares, interesting.

CSL
Haz
14
Years of Service
User Offline
Joined: 6th Oct 2010
Location:
Posted: 7th Oct 2010 07:33
For what it's worth, disassembly shows the culprit to be in this method:

CSpriteManager::UpdateAndDrawInDrawList

Access violation is to location 0x00000170

I believe this happens here:
004EFA86 mov ecx,dword ptr [edx+170h]

A pointer is getting squashed to 0.
The windows session lock blows something away.

What are the chances of this getting fixed?

Otherwise, would anyone know a way to prevent the session lock from causing this?
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 7th Oct 2010 11:25
Haven't tested that, but probably the example executes in full screen mode, and all the video memory is lost when the windows task is switched (back to desktop).
It is responsability of the programmer to take this into account, and be ready to reload everything when this happens.
Since it is an example, it doesn't takes into account this, as it is trying to show some other things.
Not really a DGDK problem, in my opinion.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Oct 2010 15:25
It is a bug, access violations should never happen, especially not in common usage. Even if you use the API wrongly it should never crash like that, it should instead display an error message. It shouldn't be up to the user anyway, it should reload automatically.

JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 7th Oct 2010 16:30
Its a DX problem as Morcilla was saying. it's been a DX issue since day one. DX releases all of its resources when you do that - same as switching from fullscreen to windowed mode - look it up...

You have to build in your own recovery logic yourself. Now whether or not GDK releases the ID you created is unknown. I suspect it does not so a simple dbExist check should be done as well...


JTK
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Oct 2010 18:53
Quote: "Its a DX problem as Morcilla was saying. it's been a DX issue since day one. DX releases all of its resources when you do that - same as switching from fullscreen to windowed mode - look it up..."

I'm not disputing that. I'm just saying that DGDK should detect that and reload the resources. I don't think DGDK properly handles the situation, an access violation would suggest that.

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 7th Oct 2010 19:50
@Haz, the workaround is to run your app in Windowed Fullscreen mode. This bypasses the problem as it preserves the DX state. You do lose a bit of performance with this over Fullscreen Exclusive, but it's at least a workaround.

Haz
14
Years of Service
User Offline
Joined: 6th Oct 2010
Location:
Posted: 8th Oct 2010 06:35
Thanks for the suggestions! Unfortunately, I can't find a workaround yet.

The dbSpriteExist() and dbImageExist() functions don't reliably detect DirectX releasing those resources.

Also, the problem happens in both fullscreen and windowed modes.

Is there some sort of DirectX API call I can use to detect when it has released everything?
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Oct 2010 19:28
You could check in your main loop for the window losing focus. That should let you know when things are going to be released. Then have it go into a waiting loop, and when focus returns, reload the things needed to return to normal and return to the game loop.

Haz
14
Years of Service
User Offline
Joined: 6th Oct 2010
Location:
Posted: 8th Oct 2010 19:55
I was able to use GetFocus() to figure out when the game loses focus. However, DarkGDK properly handles most instances of DirectX releasing things. It has no trouble with maximizing a window, minimizing a window, restoring a window, or simply alt-tabbing. I would hate to lose that functionality. The only one it can't seem to handle is the windows session-lock/switch.

Also, my game has hundreds of assets that take several seconds to reload from files. Apparently, when DarkGDK works correctly, it stores these assets in memory and reloads the video buffer that way, as there is no noticeable delay. Is there a way I can do that manually instead of reloading from files?
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Oct 2010 23:45
Hmm.. There must be something key that Windows closes or locks out when you lock the session.

Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 9th Oct 2010 17:19 Edited at: 9th Oct 2010 17:25
EDIT disregard this post.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 9th Oct 2010 18:13
Checking whether dx needs to be reloaded before calling dbSync can't work 100% of the time because between the check and the call to dbSync dx may be unloaded. However, most of the time everything should be fine.

Login to post a reply

Server time is: 2024-11-19 18:36:58
Your offset time is: 2024-11-19 18:36:58