DirectX 1920 x 1200 Fullscreen = Hang?
BlitzMax Forums/BlitzMax Programming/DirectX 1920 x 1200 Fullscreen = Hang?
| ||
| Hi All, One of my customers is having issues running Chef Solitaire on his PC: Windows 7 64bit 2 x ATI HD 5980's ASUS P6X58D-E Motherboard. Intel CPU i7 X 980 @ 3.33 GHz 6.00 Gb RAM I've knocked up a simple app to test: https://www.dropbox.com/s/1sii58vq9gncfbb/test.exe?dl=0 Does this work for anyone with that resolution? Cheers, Steve |
| ||
Ow ow my eyes ! Ok, I'm at 1920x1080 to try and help, highest res I can go. Tried to run your program, got an error on line 120.Local my_graphics:TD3D9Graphics = my_driver.Graphics() Compile Error - Identifier 'Graphics' not found [OK] |
| ||
| Mee to, it seems like the Graphics() method was never implemented for D3D9, it is for D3D7 though. Thankfully you can just disable that part and use the old GetActiveWindow(), its just a test afterall :) EDIT: This test shouldnt fail though, unless DesktopXXX() somehow reports wrong results. |
| ||
| If you get the code running I'll try again ? |
| ||
Sorry guys, I'd forgotten I added it d3d9graphics.bmx. You can quickly add it to TD3D9GraphicsDriver class:Method Graphics:TD3D9Graphics() Return _graphics End Method |
| ||
I just commented out everything butReturn GetActiveWindow()in that function. But sadly i dont have a 1920x1200 monitor, so the test worked as expected. I would rather expect something else than your code being the culprit honestly. The monitor could run at below 60Hhz. Or it could be like on my netbook, only 1 dx application can be running at the same time. Though that wouldnt account for opengl. |
| ||
| I've sent the customer this test app, waiting for him to get back (he's in the UK and went to bed at 3am over there... hopefully see what he says his tomorrow). |
| ||
| If your framework used some potential debug statements /logging - I would enable it (so you see the position of the crash). I assume that it has to do with the hertz value - some screens run at 59 hertz. But it also depends what you see as "crash": the nonexistence of your graphics context or a segfault. Instead of relying to set the fixed render engine I use the approach to try the first - if that fails, the second, if that fails the third... The Windows-part (Linux/Mac only have the OGL ones) https://github.com/GWRon/Dig/blob/master/base.util.graphicsmanager.win32.bmx So if one had issues with DX it would fall back to OGL. Maybe you could try something similar bye Ron |
| ||
| Appears to work OK for me. Graphics opens screen at 2560x1440 resolution, and prints text there. Desktop Width = 2560 Desktop Height = 1440 Graphics Modes = 45 Hertz Hz = 60 Desktop Hz = 60 Game Hz = -1 Driver = DirectX DirectX 9 640,480,32,75 640,480,32,72 640,480,32,67 640,480,32,60 640,480,32,59 720,480,32,75 720,480,32,72 720,480,32,60 720,480,32,56 720,576,32,75 720,576,32,72 720,576,32,60 720,576,32,56 800,600,32,75 800,600,32,72 800,600,32,60 800,600,32,56 1024,768,32,75 1024,768,32,70 1024,768,32,60 1152,648,32,50 1152,864,32,75 1152,864,32,60 1280,720,32,59 1280,720,32,60 1280,720,32,50 1280,768,32,60 1280,800,32,60 1280,960,32,75 1280,960,32,60 1280,1024,32,75 1280,1024,32,60 1440,900,32,60 1600,900,32,60 1600,1200,32,60 1680,1050,32,60 1776,1000,32,50 1792,1344,32,60 1800,1440,32,60 1856,1392,32,60 1920,1080,32,59 1920,1080,32,60 1920,1080,32,50 1920,1200,32,60 2560,1440,32,60 Using DX9... GetActiveWindowSafe GetActiveWindowSafe - DX9 The 2560x1440 your program starts in is the native res of my current monitor (32" LCD), my previous monitor was 1920x1200 and never ran into issues running blitzmax at that resolution either as far as I recall. |
| ||
| Just tested explicitly opening a 1920,1200,32,60 screen on my PC, and did notice something odd: 1) Using SetGraphicsDriver D3D7Max2DDriver() , opening the screen, doing a drawtext and flipping, the contents are visible. 2) Using SetGraphicsDriver D3D9Max2DDriver() , opening the screen, doing a drawtext and flipping, the text is visible for a split second, and the screen then turns black and stays that way until I draw or print something else -- any subsequent drawing operation DO show up and remain, as you'd expect. In order for it to immediately show what I wanted it to, I had to throw one or two flip statements immediately after the graphics command first. |
| ||
| Thanks Xlsior. Using SetGraphicsDriver D3D9Max2DDriver() , opening the screen, doing a drawtext and flipping, the text is visible for a split second, and the screen then turns black and stays that way until I draw or print something else -- any subsequent drawing operation DO show up and remain, as you'd expect. In order for it to immediately show what I wanted it to, I had to throw one or two flip statements immediately after the graphics command first. That sounds strange... could you post the code you needed to do to get it to draw correctly? |
| ||
| That sounds strange... could you post the code you needed to do to get it to draw correctly? This just flashes the text and ended up with a blank screen until the next drawing/flip operation: SetGraphicsDriver D3D9Max2DDriver()
Graphics 1920,1200,32,60
DrawText ("TEST",100,100)
Flip
WaitKey()While this left the text on the screen as expected: SetGraphicsDriver D3D9Max2DDriver()
Graphics 1920,1200,32,60
Flip
DrawText ("TEST",100,100)
Flip
WaitKey()Of course you'd typically have an on-going draw loop so it shouldn't be an issue with a real life program, it's still a bit odd. |
| ||
Well the customer got back and can see the text fine in full screen mode... back to the drawing board.Hello.. ESCAPE to quit DesktopWidth = 1920 Desktopheight = 1200 GraphicsModes = 34 Hertz Hz = 60 Desktop Hz = 60 Game Hz = -1 Driver = DIRECTX DIRECTX9 He didnt want to type out all the resolutions :) Maybe something with the virtual resolution... |
| ||
| Okay next test: https://www.dropbox.com/s/hq8wg5jzcri87ao/virtual_res_text.exe?dl=0 |
| ||
| Tried your code as is, screen went black and THEN my keyboard locked (couldn't do Alt-Tab), finally had to do hit ALT TAB to shut down the EXE manually. It may just be me but I really don't like hardware snap resolutions. The only safe SNAP I have seen that is pretty well used universally for full-screen games is 800x600. I'm guessing if it crashed here, that might be why the client had problems. I see you're using virtual resolution. Maybe I'm not reading enough into this. Here's some very safe code. This can be optimized for speed, but you get the idea. You can have a nice virtual screen that matches anyone's resolution with this method that resizes all pixels to the correct scale. |
| ||
| @therevills Works here - with all the known flaws of vanilla BlitzMax Max2D. I have two screens here (extended view) - your app is drawn in the center of both screens. when manually overriding to use the desktop-size of one single screen both screens (both 19" screens) show the app (like in "cloning mode"). Maybe that special behavior is specific to my linux environment/setup. Brucey once mentioned, that his SDL wrapper has the benefit of better incorporation of multi-screen-setups. Nonetheless: it seems to work and does not "stall". bye Ron |
| ||
| The 'next test' one works perfectly fine on my PC as well, no problems at all.. 2560x1440 resolution, 1366x768 virtual res. |
| ||
| @dw817 - Thanks for testing, but sorry what do you mean by SNAP? @Ron and xlsior - again thanks for testing... The customer has also tested this app with this comment "Nice one. I've paid money for worse games than that lol." LOL! Okay there must be something deep in the framework work which is not quite working for some reason... The hunt begins... |
| ||
| Hi Therevills. By SNAP I mean your monitor goes solid black like the power went off, then your monitor has a conniption as it tries to SNAP into a hardware resolution mode that's not the regular resolution you operate your PC in, such as 640x480 or 800x600. Really anything less than 1024x768 I call a SNAP resolution. It may be great for games and stuff, I'm just worried it'll damage my monitor. That's why first convenience I bring up config and say WINDOWED mode. I have this OTHER program, a nice Freeware one, that takes any windows app and stretches the screen so the game plays the way I like, full-screen, no snap, and I can see the clock to see what time it is. That's important to me ! :) |
| ||
| Please hand the customer 3 versions when you send him the next "test": - enforced DX9 (this is what is used by default in your setup) - enforced DX7 - enforced OpenGL (-enforced BufferedOpenGL if you have that module running) In my framework I have also an automatic order but I also had people having trouble with the DX9-renderer, so I added app-arguments and config-file-options to override Renderer and SoundEngine (having users with Linux distributions _not_ providing PulseAudio preinstalled). While your current app does not seem to be troublesome, special circumstance might bug out the whole thing (big images/sprite-atlases, non-power-of-two-thingies, ...). Do you use threading? If that customer is a bit more experienced you might hand him the debugbuild and he could run it via the Gnu Debugger (gdb) and the backtrace might be of help (if you'd compiled with NG you would then even get the corresponding code line number and even more). Could you elaborate on what the customer experiences? Crash after startup - or within the game? You might have to fill a big logfile in your game so you could see how things go on his computer ("[08:15:12] PlaySound(xyz)"). Instead of logging "Update()" you log all extraordinary things ("CollapseBlocks" "GiveScore" ... think you know what I am talking about). Maybe this helps to track down things. Is your code "superstrict" ? Do you use Bruceys TList-variant (in debugbuild it notifies you if your code modifys a list concurrently) ? I had trouble with "concurrent list modification" in my game - not everytime but everyonce. So while iterating over a list I removed "dead" entries. This should be avoided: a) two loops, 1st updates and adds toDelete to an array, 2nd over the array deleting from the list b) one loop over a list.copy() so it is save to modify the original one So if you are not sure: use Bruceys TList-variant, compile and run a debug-build of your game. Play around a bit and check if it "stops" you somewhere in the code. This is the change to the linkedList.mod: https://github.com/bmx-ng/brl.mod/commit/01fb9f0ffd53cef697e1febc48c7cd2965f3e53d Similar was done to Map.mod (if you use maps). Maybe this helps. EDIT: @DW I think what you are talking about (without seeing the clock while playing) is similar to a "windowed fullscreen mode" or "borderless fullscreen mode". On linux this is often used to allow seamless task switching (eg. WarCraft III on wine crashed when alt-tabbing from real fullscreen mode). http://pcgamingwiki.com/wiki/Glossary:Borderless_fullscreen_windowed The problem with taskbars is, that their size is individual - so you cannot just decrease height without adding black bars at the left and right (which is what TVirtualGFX does allow you to do). To avoid "snapping" you must use the original desktop resolution (and depth) as this avoids a mode switch. More important, if you have eg. VirtualBox running next to your app, the contained OS wont get resized if you use another resolution than the one running currently. On the other side, "snapping" allows to save GPU power. As then it is up to the monitor/screen to do the scaling. Of course GPUs might do better scaling then screens. Also it is important whether your GPU/drivers allow letterboxing or if they stretch everything to the hardware given resolution. Same thoughts for the screen (older screens had trouble with 4:3 on 16:10 screens - they stretched the content). bye Ron |
| ||
| dw817: So just normal behavior for a monitor then. Trust me, it wont brake unless its a REALLY old CRT. |
| ||
| I've strip back to the simplest framework example: https://www.dropbox.com/s/u13lubnc9lvbhp7/Test.zip?dl=0 @Ron - Thanks for the ideas. All my code is SuperStrict :) |
| ||
| Well ... *scratches chin* I dunno, It's all so ATARI to force a lower resolution is the way I see it. And there is some great code out there to give you a full-screen, frameless, no snap, with your taskbar easily viewed below. |
| ||
| @dw817 Not cross-platform (limited renderer + windows calls). Even when fixing your code (needs gtkmaxgui on my box) this then not work as intended (see your snow-thread). @Therevills Before searching through thousand lines of code it might be a time saver to use the "modded tlist/tmap" and check if a debug build blames something. Maybe only a little chance - but at least a chance. bye Ron |
| ||
Customer has tested the newest test app:Well yeah that one just did the exact same thing as it did at first with the driver 0 on the game. Total blackscreen. Blue working icon just spinning. Couldn't even get the process up to kill it. Just went back to the game screen locked up every time I tried to start task manager. Though it did seem to be advancing half a frame each time. Because the kitchen display came up after 10 or so attempts. Frozen. But there. Managed to shut the comp down from the ctrl+alt+delete screen to reboot. Log to follow in serarate post. Hmmmm.... sounds like an infinite loop somewhere... but why would it work in window mode (DX) and OpenGL fullscreen... |
| ||
| Therevills, your drop box demo works here. Minju, it takes like 4-seconds for the screen to appear. Then I tried something. I moved the cursor all the way to the right and clicked there, the regular Windows screen appeared w the taskbar but your program kept running in the background. I had to task kill it as it wouldn't die on its own. |
| ||
| If rendermodes decide whether something runs or not - I would look at the implementations / modules. I did not really find something within d3d9max2d.mod (loop wise)... I assume OGL windowed would work too and only DX fullscreen is troublesome? Did you ask him about his monitor setup (dual screen, attached TV via HDMI, ...) maybe this causes trouble. I do not assume the customer is using such a setup, but better put it on your list of Q than not. Did it crash for both DX variants (7 and 9)? @not being able to kill app I think the infinite loop did not process events meanwhile, so app wont respond and if it eats the cpu task killing could become tedious. @"kitchen display" I do not know what your test app does, but if this is one of the first things to display to the user, then you already narrowed things down to: - startup logic - used modules code So: If it is within startup - does it already bork when drawing a "developed by x" screen, or when reaching the start screen? This might help to narrow it down even more (hope you do not understand my phrases as If I am talking to a "newbie" - but sometimes one just does not see the obvious things) Maybe on DX9 the user has trouble of creating so many 2048x2048 sized textures (power-of-two from 1920x1200) - depending on whether you use fullscreen backdrops. Kind of checklist: - checked if media (images) got loaded in a corrupted way? - checked if media (audio) is troublesome (eg. oggvorbis.mod/oggdecoder.c contains a bug which in rare situations results in an infinite loop, but this would bork up the game for all players I think)? - check if audio playback is creating trouble (just disable it for test purposes - if it gets used right at the startscreen, but then: why should that happen only in fullscreen mode) - fullscreen: your code uses 32bit colordepth, in windowed mode the colordepth of the desktop is used, checked? Regardless of your response: once you find out _what_ the reason was, please tell us about, I am always interested in avoiding obstacles in my projects then :-p bye Ron |
| ||
| I've sent him another build we more logging... hope he doesnt get sick of running these tests for me. The test app, all it does is set up a player profile (in ProgramData folders - works fine), displays a loading bar (although due to the switch to full screen, I cant see it) and displays the "TitleScreen" class which show an image of a kitchen from the game. The app doesnt have any sound, but uses virtual resolution to display a 1366x768 game resolution on the users desktop resolution. I'll ask about his monitor setup. Havent tested DX7 yet. OGL works fine full screen and windowed. Thanks for the ideas! Cheers, Steve |
| ||
| Loading Bar ... Does this use SetViewport or a custom variant (didn't there exist issues with SetViewport - which is why GreyAlien did a ccSetViewport() then) So if you do so, it might be a "black screen" because of some broken viewport things (or you forgot the virtualGFX-offsets in a call) - but this does not explain the lock up ... hmm. @Title-Screen class This does prepare, update and render (and other things) - so this is surely a good point for logging. @DX / OGL Might be useless information but - DX and OGL might differ on whether they immediately do the GPU transfer (on DrawImage) or whether they do it with the flip(). So issues with the GPU (driver problems) might happen on "flip()" instead on "DrawImage()". But I assume it is hidden somewhere in your code (or Blitzmax' modules) and not a driver issue on the customer computer. @"2 x ATI HD 5980's" Hmm, I do only use 1 GPU ... how about you, are you using crossfire? Maybe there is a problem there ... hmm even this sounds like the last thread of hope :-) Sorry for bombing you with my posts. Good Luck with the customer (and if he agrees, mention him in the update of your game ... people like such things). bye Ron |
| ||
| So you got the "next test" running ? That's really strange ... you shouldn't ^^ -> You replaced the cls function and call it in the VirtualGfx.SetVirtualGraphics function before creating the VG instance. As your overriden Cls function call VirtualGfx.VG for the SetViewport, you should run an unhandled exception. This kind of error does not appear in release mode, but as it's the third time in the month I'm the only one running an exception on such a code that only generate errors with debugmode (like array index out of bounds), Am I really the only one running apps with debug enabled with Blitzmax ? I fill alone :) BTW, you can fix the error just by calling the full path for Cls as you have done later on the Cls overriden function. Function SetVirtualGraphics (vwidth:Int, vheight:Int, monitor_stretch:Int = False) [...] SetClsColor 0, 0, 0 ' Got to clear both front AND back buffers or it flickers if new display area is smaller... ' Set to black... SetClsColor 0, 0, 0 ' Got to clear both front AND back buffers or it flickers if new display area is smaller... brl.max2d.Cls() 'Cls Flip brl.max2d.Cls() 'Cls Flip brl.max2d.Cls() 'Cls Flip |
| ||
| @Boby That test works in release mode, running in debug resulted in two black screens, the cursor went "greenish/dark" on the second screen when moving. Alt+Tab was not possible (I think because MaxIDE already displayed the error notification window). Had to move to another console and "killall untitled1.debug" ... You are right, we should run things in debug mode (but MaxIDE is just... you cannot work with it as even "undo" is flawed and removes the wrong lines). I just fire up MaxIDE to run already written code, rest is done via Geany + my plugin to compile (no debugger support). Instead of "brl.max2d.Cls()" you could call the superscoped ".Cls()". This allows an easier replacement of "brl.max2d" with something else, also providing a Cls() Function. Dunno if this is better (at least brl.max2d.cls() is easier to distinguish from "cls()") - but I was using this in my framework when accessing virtual graphics. bye Ron |
| ||
| I suppose I understand the problem. 1/ I use Blide, the stack trace works fine on it. 2/ I also always remove any FullScreen mode when I test a code from some users before going further. -> To be honest, I hate having to debug something fullscreened ... On old computers, I had to reboot several times due to graphic drivers issues on non-supported modes or neverending loops that consumed 100% CPU and never be abled to get back to the desktop for some reason. And for sure, there are some people that publish very crappy codes ... It's a bit hazardous to run it without a bit of precaution ^_^ So, here too, I removed the fullscreen for testing the stability of the code ... And as it failed on Cls without other issue related to a black screen related to the fullscreen mode (as I wasn't in fullscreen) I could notice the Cls bug. for the superscoped cls method, that's true, but when you come to use some function naming that already exists, you reach very fastly the point when you don't remember what is called from what and from where it is called ... At least with full module path, it's not very nice but it's explicit. |
| ||
| @Bobysait - I am overloading Cls for a reason and it works fine on many PCs. Does it fail on yours? Which post are you talking about too? I've got a trace log from the customer: 15:30:48: Entering main loop... 15:30:48: Before repeat 15:30:48: FixedRateLogic.NumTicks = 0.20000000000000001 0.00000000000000000 15:30:48: remainder = 0.200000003 15:30:48: FixedRateLogic.NumTicks = 2.6000000000000001 2.0000000000000000 15:30:48: remainder = 0.600000024 15:30:48: FixedRateLogic.NumTicks = 2.7999999999999998 2.0000000000000000 15:31:01: remainder = 0.600000024 15:31:01: FixedRateLogic.NumTicks = 0.59999999999999998 0.00000000000000000 15:31:01: remainder = 0.600000024 15:31:01: FixedRateLogic.NumTicks = 0.59999999999999998 0.00000000000000000 15:31:01: remainder = 0.600000024 Notice the second value on the FixedRateLogic.NumTicks line, that is the Floored value of the first value: DebugLog "FixedRateLogic.NumTicks = "+FixedRateLogic.NumTicks + " " + Floor(FixedRateLogic.NumTicks) For Local i% = 1 To Floor(FixedRateLogic.NumTicks) FixedRateLogic.SetDelta(1) If LogicWrapper() = -1 Then Return -1 Next So the code is trying to do a FOR loop from 1 to 0.... Just below that code the reminder is calculated: 'Is there a remaining bit in the Numticks float? Local remainder# = FixedRateLogic.NumTicks Mod 1 DebugLog "remainder = "+remainder If remainder > 0 Then FixedRateLogic.SetDelta(remainder) If LogicWrapper() = -1 Then Return -1 EndIf So the logic should still run, but very slowly... And his monitor is the Samsung T240 model. |
| ||
| He was talking about post #14 (which crashed here too - when running the debug-variant). @for loop You could replace it with a while and a "ticksToGo"-counter which you decrease. Wend is then on "ticksToGo <= 0" For i = 1 to 0 '... Next Ist just doing nothing. So the problem might be in your case that "FixedRateLogic.SetDelta(1)" was not called when it reached the code after "next" for the first time (so calling SetDelta(value < 1)). What I do not understand is why you do this: 1) run FixedRateLogic.SetDelta(1) for every "integer"of your numticks 2) run FixedRateLogic.SetDelta(remainder) for the fraction part of numticks So for numticks 2.56 you run 2 times SetDelta(1) and 1 time SetDelta(0.56). Is this correct? If so, you just could have one while loop and subtract "1" until the "ticksToGo" is < 0 DebugLog "FixedRateLogic.NumTicks = "+FixedRateLogic.NumTicks + " " + Floor(FixedRateLogic.NumTicks) Local ticksToGo# = FixedRateLogic.NumTicks while ticksToGo > 0 'Min(...) => use ticksToGo if < 1.0 - or else use 1.0 FixedRateLogic.SetDelta( Min(1.0, ticksToGo) ) ticksToGo :- 1 If LogicWrapper() = -1 Then Return -1 Wend Feel free to skip above (especially if you do not like others "reviewing" your code). @FixedRateLogic.SetDelta() and LogicWrapper() Both do not struggle with the first call to it being with a delta value < 1.0 ? Else I cannot see problems in the code you posted, maybe Bobysait has eagle eyes again. As the trace log seems to continue slowly but steadily (like you commented too) the problem should then be somewhere in that SetDelta(<1.0) or LogicWrapper(). Even more problematic is, that the log continues to grow, so it is not stalled at all (it is just not showing something). If it is not showing something, the problem might be some fader or whatever adjusts visibility (color fader, alphafader, position of the images...) @monitor So a single-monitor-setup... Do you use Sli/Crossfire (more than 1 gpu simultaneously)? Maybe the dual-gpu-solution creates trouble with some textures and Max2D. bye Ron |
| ||
| He was talking about post #14 (which crashed here too - when running the debug-variant). Ah, fair enough... yeah I see the issue. The game framework does do it differently. What I do not understand is why you do this: 1) run FixedRateLogic.SetDelta(1) for every "integer"of your numticks 2) run FixedRateLogic.SetDelta(remainder) for the fraction part of numticks So for numticks 2.56 you run 2 times SetDelta(1) and 1 time SetDelta(0.56). Is this correct? Yeah... not my code part of the GAF. Do you use Sli/Crossfire (more than 1 gpu simultaneously)? Sorry I didnt answer this before - no I dont have SLI/Xfire (never seen the need for it really). If I run the test app with the log enabled it does display more logging like: Logic Titlescreen and Draw Titlescreen, which the user doesnt get at all. I'm going to do another build and put heaps of tracing in.... |
| ||
| @sli/crossfire This was just something to see if that could be an issue (like said I doubt that and am thinking the bug/issue is due to your code/logic). If neither "Logic" nor "Draw" is output at all - but follow up entries are printed, then this means this screen is never activated / assigned as current - assume your screen works similar to "diddy" (btw: your footer still links to code.google.com instead of github). Maybe you should have included such "custom things" in the vgfx-testapp too (as next step). Reading your replies sounds, as if you corner the bug/issue :-) bye Ron |
| ||
Got a new log from the user:13:58:01: Init: NOT UsingSteam 13:58:01: GraphicsCreate - Trying WindowWidth = 1366 13:58:01: GraphicsCreate - Trying WindowHeight = 768 13:58:01: GraphicsCreate - FullScreen = true 13:58:01: GraphicsCreate - WideScreen = true 13:58:01: GraphicsCreate - AspectRatioMode = true 13:58:01: CountGraphicsModes() = 34 13:58:01: Driver = 0 13:58:01: Driver=0 Trying DirectX 9... 13:58:01: DirectXVersion = 9.0c 13:58:01: DebugInt= 113 13:58:01: DesktopRefreshRate = 60 13:58:01: DriverDX9 = 1 13:58:01: Driver = 0 13:58:01: comparison = 1920x1200 13:58:01: comparisonWidth is greater than or equal to WindowWidth 13:58:01: comparisonHeight is greater than or equal to WindowHeight 13:58:01: NOT resExists 13:58:01: TRUE 13:58:01: in comparsion loop... 13:58:01: Window = 1366x768 WideScreen = 1 13:58:01: resExists = 1 13:58:01: resToTest = 3 13:58:01: GraphicsCreate - Final WindowWidth = 1366 13:58:01: GraphicsCreate - Final WindowHeight = 768 13:58:01: GraphicsCreate - Final Widescreen = 1 13:58:01: GraphicsCreate - WideScreenOffSetX = 171.000000 13:58:01: Trying full screen at 1920x1200 32bits... 13:58:42: DoSetVirtualResolution - Start 13:58:42: GetActiveWindowSafe 13:58:42: DX9... 13:58:42: GetActiveWindowSafe 13:58:42: DX9... 13:58:42: SpecialLoad- TLoadingScreen 13:58:42: Init - TLoading Bar 13:58:42: no of steps found in xml resources files: 0 13:58:42: No of images >2 13:58:42: moveBar images>0 13:58:42: finished xml... 13:58:42: mouse pointer 13:58:42: Loading Titlescreen... 13:58:42: MoveBar 13:58:42: Logic - Progress 13:58:42: Setting current screen to loading screen 13:58:42: Entering main loop... 13:58:42: Game.NoTiming = 0 13:58:42: Before repeat 13:58:43: Logic - LoadingScreen 13:58:43: TGameFade - Init 13:59:08: TGameFade - Finish 13:59:08: GameFade - GetDone - DONE! 13:59:08: Loading Titlescreen... 13:59:08: Start Titlescreen... 13:59:08: TGameFade - Init 13:59:32: TerminateFunction 13:59:32: TGameFade - Init 13:59:32: TerminateFunction 13:59:32: TGameFade - Init 13:59:45: TerminateFunction 13:59:45: TGameFade - Init 13:59:46: TerminateFunction 13:59:46: TGameFade - Init 13:59:54: TGameFade - Finish 13:59:54: GameFade - GetDone - DONE! Notice the large gap with these lines: 13:58:01: Trying full screen at 1920x1200 32bits... 13:58:42: DoSetVirtualResolution - Start On my PC it doesnt even take a second... Method DoSetVirtualResolution() DebugLog "DoSetVirtualResolution - Start" Local sw:Int Local sh:Int GetResolution(sw, sh) Hmmm..... And the Fade is taking far too long: 13:58:43: TGameFade - Init 13:59:08: TGameFade - Finish |
| ||
| 13:58:01: Trying full screen at 1920x1200 32bits... 13:58:42: DoSetVirtualResolution - Start If it changes the desktop resolution ( due to any different value for size, depth or hertz ), it may take time to switch. Maybe your config has identical parameters in fullscreen mode as your desktop, so it switches very fast. |
| ||
| it may take time to switch. Maybe, but using OpenGL its nearly instant for the user... DirectX9 Log: 17:32:12: Driver=0 Trying DirectX 9... 17:32:12: 1 Trying full screen at 1920x1200 32bits... 60Hz 17:32:12: 1 Before Graphics... 17:33:02: 1 OK 17:33:02: Before DoSetVirtualResolution.. 17:33:02: DoSetVirtualResolution - Start And the OpenGL Log: 17:36:54: Driver<>0 Setting OpenGL... 17:36:54: 1 Trying full screen at 1920x1200 32bits... 60Hz 17:36:54: 1 Before Graphics... 17:36:55: 1 OK 17:36:55: Before DoSetVirtualResolution.. 17:36:55: DoSetVirtualResolution - Start |
| ||
| Maybe there are issues with 2 GPUs being present? Someone here using 2 GPUs? Another possibility are "tools" which intercept such calls to optimized things (never used it - just saw these when doing setups for other user's computers). @Fade This of course does not explain the long fading-time. I assume there might be multiple issues coming together - with the fading being a logical (aka "in your code") error. I asked for the way you use the fader / screen setup - is it done similar to "Diddy" ? Maybe there are potential issues. You are surely splitting "Update" and "Render". Sometimes you do some logical things in "Render" (especially in the frame of the switch from old-to-new-screen). bye Ron |
| ||
| Yeah, it might be the multiple GPUs which are causing the slowness with the Graphics command. I've done a new build which uses Dave's (col) DirectX10/11 Driver and sent that to the user to see if it works any differently. Regarding the fade, yeah Diddy's screen framework is similar to GAF - but why would OpenGL work and not DirectX. Also this has worked for thousands of PCs... |
| ||
New log using the DirectX10/11:02:05:49: Driver=0 Trying DirectX 11... 02:05:49: 1 Trying full screen at 1920x1200 32bits... 60Hz 02:05:49: 1 Before Graphics... 02:05:50: 1 OK And it works... |
| ||
| You mean..and it does show the startscreen? Uf so..there is either an issue with the dx9 mod... or a problem with 2*gpu and dx 9 / the dx9 mod. Maybe we should ask the same question in a new thread ("dx9 and dual gpu") to attract people having such an setup. Maybe Col (who wrote the dx9 wrapper?) has some answers.. Now..if startscreen was working...I think we are more safe to declare the screen-code to do what it's expected to do. Bye Ron |
| ||
Yes, the startscreen is shown correctly and the amount of time it takes to initialize the graphics is good too:02:05:49: Driver=0 Trying DirectX 11... 02:05:49: 1 Trying full screen at 1920x1200 32bits... 60Hz 02:05:49: 1 Before Graphics... 02:05:50: 1 OK 02:05:50: Before DoSetVirtualResolution.. 02:05:50: DoSetVirtualResolution - Start Maybe Col (who wrote the dx9 wrapper?) has some answers.. I thought Col only wrote the DX10/11 wrapper and that DX9 wrapper was officially from BRL? Now..if startscreen was working...I think we are more safe to declare the screen-code to do what it's expected to do. Sorry I'm not sure what you mean? |
| ||
| I meant: if the "app specific" code is working, then we should no longer search for bugs in there (I mean the screen-logic, the deltatiming...). @dx9 DStastny was the one bringing dx9 to blitzmax. So sorry Col, no light cone of fame for you this time :-). bye Ron |
| ||
| :D Yeah, I can't claim any fame for Dx9. The current Dx9 driver is developed by BRL, and as Derron says DStastny made the original one. On topic. Am I right... 1. The problem is isolated to 1 user and 1 pc? 2. Just one gpu resolution ie 1920x1200? 3. Only Dx9? I know you going hate me for suggesting this but it does sound like a driver or gpu setting issue local to that pc, maybe the monitor driver even? 40 seconds to switch to full screen? Something's clearly not right there somewhere. If nothing is found then it may even be worth raising an issue to AMD/ATI about the specifics? |
| ||
| I am still throwing in "crossfire" as potential fault...it is the only "special" thing popping out. Bye Ron |
| ||
| It could be that too, I agree. Can that option be turned off or disabled? just for the sake of proving the point? |
| ||
| 1. The problem is isolated to 1 user and 1 pc? I've had two users complaining about similar issues. The user with crossfire has been really helpful. 2. Just one gpu resolution ie 1920x1200? One GPU? I've never used SLi/Crossfire - so you can set the GPUs to different resolutions? I know if you have multiple monitors you can set those to different resolutions.... 3. Only Dx9? I didnt get him to test DX7. OpenGL works fine.... and DX11 works too ;) |
| ||
| Ahh ok, do you have any hardware/software information reference the other users pc? 2. Just one gpu resolution ie 1920x1200? Sorry, re-phrase that to 2. Just one resolution ie 1920x1200? |
| ||
Sorry I totally forgot that the other user did inform me of they PC specs:mobo- Asus IV Rampage extreme cpu- intel core i7 3960X Graphics- (2) 980 Titan X 12 GB in SLI windows 7 ultimate 64 bit. So another multi-GPU setup... Never told me his resolution... Just one resolution ie 1920x1200? Yeah, in window mode 1366x768 it works fine. |
| ||
| At this stage I agree with Derron that sli is the likely potential candidate. Can you ask them to diasble sli just for testing? or would that be a bit much? |
| ||
| Interestingly the one dual gpu-user has an AMD card, the other one NVIDIA. So it is most likely not an issue of the GPU drivers, but of either DX9 itself or the dx9 module of BlitzMax. Maybe we could ask the forum first -- if there is someone out there using dual-gpu and Windows 7 (64bit) without trouble (regarding BlitzMax DX9). bye Ron |
   |