Unhandled Exception in d3d7graphis.bmx - new info

BlitzMax Forums/BlitzMax Programming/Unhandled Exception in d3d7graphis.bmx - new info

sswift(Posted 2006) [#1]
I just did a test where I discovered that using the DirectX driver, which is the one we're haivng problems with, you can set a fullscreen mode, and then switch to a canvas for graphics and it works fine. But you cannot go from having a canvas to fullscreen. So my guess is that something is wrong in the code which shuts down the canvas graphics.


neilo(Posted 2006) [#2]
This describes an issue I've seen in my code.

I wonder if it's related to this bug?

At some point, the device is lost/dropped and things go splat.


Robert Cummings(Posted 2006) [#3]
I just did a test where I discovered that using the DirectX driver, which is the one we're haivng problems with, you can set a fullscreen mode, and then switch to a canvas for graphics and it works fine. But you cannot go from having a canvas to fullscreen. So my guess is that something is wrong in the code which shuts down the canvas graphics.


I have already reported this bug. It works fine in opengl, but not DX.


neilo(Posted 2006) [#4]
One Eyed Jack,


I have already reported this bug. It works fine in opengl, but not DX.


Which is exactly the behaviour of the other (multi canvas) bug. Works great in OGL, deadly in DX7.

Neil


skidracer(Posted 2006) [#5]
Please syncmods for a new version of dxgraphics/d3d7max2d modules, hopefully switching between fullscreen and windowed is now supported, please post code if you can get it to fail.


neilo(Posted 2006) [#6]
Skid,

Holy smoke! All those canvas bugs are gone!

Thanks!


sswift(Posted 2006) [#7]
I'm still getting a failure in my game, but my test program works fine. I may have changed how my game works though, so I'll look into that.


sswift(Posted 2006) [#8]
The program doesn't crash any more when you change video modes, but there's a couple new problems.




I have updated this test program. It starts up in fullscreem and from there you can hit F to toggle back and forth from fullscreen to windowed mode.

In DirectX, you can switch back to canvas, and from there back to fullscreen. But when I switch back to canvas again, I have all these black horizontal lines on the canvas, and everything slows to a crawl.

In OpenGL, which used to work fine, you can switch from fullscreen to windowed mode, and back, but when you go into fullscreen mode the second time, it now shows a flashing start bar at the bottom of the screen, as if you forgot to clear both buffers.

I have a Geforce 6800.


sswift(Posted 2006) [#9]
Here is another test app. It works the same as the above, but it uses a different method to attempt to change between modes.

The first app creates a canvas graphics context, and each time it switches to fullscreen it creates a new fullscreen graphics context.

This app creates a new fullscreen context each time you switch to fullscreen just like the other app, but it also creates a whole new canvas each time you switch to windowed mode, freeing the old one on switch to windowed mode.

This one displays the start menu bar flicker right away in OpenGL, and in DirectX fails to switch back to fullscreen from the canvas.




sswift(Posted 2006) [#10]
Here is yet another test program:




This version attempts to create a canvas when the window is created, then when switching to fullscreen for the first time, it uses CreateGraphics() to create a fullscreen graphics context. From there on, it attempts to switch between the two contexts with SetGraphics, and never tries to recreate either.

This version fails the worst though. In DirectX, it crashes when attempting to switch back to windowed from fullscreen, giving "createsurface failed" as the error. (If you alter the app to attempt to run in windowed mode first, it will switch from canvas to fullscreen but not back.) In OpenGL, things are even weirder than before. Not only do you have the flashing start menu bar at the bottom of the screen, but after you switch back to windowed mode, if you press F again, nothing happens! You have to actually click the window button on the task bar to get it to go back into fullscreen mode. And once there, the formerly flashing start menu bar in fullscreen now has flashing streaks of black over it, as if Flip True is no longer waiting for the vertical refresh.


skidracer(Posted 2006) [#11]
Hmm, CloseGraphics on a canvas graphics or a FreeGadget Canvas which calls CloseGraphics both seem to cause that failure. Will hopefully have it fixed tomorrow.


skidracer(Posted 2006) [#12]
OK try another syncmods.


Sswift, thanks heaps for the various examples, each one did need a different tweak and I'm sure you'll find some more ways of crashing it.

I'll hold off posting the recomended method of switching between fullscreen as I'm kindof curious if you can come up with any more exotic methods.

Also while i'm thinking of it you should probably use clientwidth and clientheight of the desktop in your code, the gadgetwidth and gadgetheight desktop() versions on a multimonitor setup return the combined size meaning your window sits between the two displays instead of being centered on the primary display.


sswift(Posted 2006) [#13]
Heh, well the reason I came up with all those examples was I was trying to find ONE method that worked, not cause I was being clever and coming up with ways to crash it intentionally. :-)

Thanks for the heads up on that desktop thing, I'll make that change in my code.

I'll try the syncmods thing and see if my three examples work. And if I can think of any other ways to switch between fullscreen and windowed, I'll let ya know. :-)


sswift(Posted 2006) [#14]
When running the first example in DirectX, switching to fullscreen from canvas works fine, but when you switch back you get garbage in the window... blocks of old buffer interspersed with blackness, and short horizontal lines missing throughout.

When running the first example in OpenGL, every other time you go fullscreen, you get the flashing start bar on the bottom of the screen.

---

When running the second example in DirectX, when you switch to canvas, my system slows to a crawl, but goes back to normal when I manage to switch back to fullscreen.

When running the second example in OpenGL, the flashing start bar appears in fullscreen every time.

---

When running the third example in DirectX, when you switch back to windowed from fullscreen everything slows to a crawl, and it fails to switch back to fullscreen mode.

When running th third example in OpenGL, once more, we have the flashing start menu bar, but this time you also get two window buttons on the start menu bar, and clicking one of them takes you back to fullscreen more.


I suspect the system is slowing to a crawl in those two examples because the Hz is getting messed up or something and Flip True in windowed mode is allowing the program to flip the buffer a thousand times a second rather than how it is normally limited to 60 or so.


All that said, I can confirm that within an actual GAME, the second method works. There's a start bar flash on the bottom of the screen for a moment while the screen is black and it is switching from windowed mode to fullscreen in OpenGL... And you see a large desktop image in the background for a moment when switching back.... But otherwise, it seems to work. It's just not as pretty as it should be. Also in DirectX, the start menu bar takes it's sweet time returning to normal and displaying the window's button on it when you return from fullscreen mode.

I'll have to try some of the other methods and see if one of them works better in the actual game environment.


Robert Cummings(Posted 2006) [#15]
I can confirm some odd slowdowns when using multiple canvases until I've gone fullscreen and back.