New and weird display bug on a few PCs
BlitzMax Forums/BlitzMax Programming/New and weird display bug on a few PCs
| ||
| Hi all, Back in 2009 and in 2012 I made two games using BlitzMax. These games were made for French speech & language pathologists and a few hundreds or thousands of each have been sold, and until a few weeks ago no one complained about them. My second game is available for 2 years 1/2 and suddenly three new customers are reporting severe display bugs and can't use it at all. They all own not too old Win7 PCs. I've been trying to use OpenGL, DX7, DX9 and DX11 graphics drivers with no success. Here's what the title screen should look like :  And here's what it looks like :  I'm heavily using ViewPorts in my code and wonder if the trouble I'm in has anything to do with it. Other than that I have no clue at all..... Do you have any idea?? If so, thanks in advance for your help! |
| ||
| Hiya, Nothing obvious springs to mind as to why it would work for a couple of years and now there are issues but I've seen some strange bugs in my time that can stay hidden for no reason then become a show-stopper from a certain moment on. As you can imagine, your description is a little vague, but you have start somewhere eh, so as a first stake in the ground to work from... Looking at the two pics... the bottom window is wider and taller than the top, is that intentional or a side effect of the bug? If its part of the bug, whats related to setting the size of the window? A graphic image? A windows API call? Are all resources loading properly? Are you using fixed file name paths? Do you have error checks in place to check for resources loading correctly? An optional debugging log file is a MUST have when you have production code, and use it to dump megs of meaningful resource and data verfications - you can always set up your app to delete it afterwards when it next loads without the option of logging switched on. It looks as though the background image ( the one with 'exposer' on it ) hasn't loaded properly. Are you taking any parameters from that image and doing anything with them? resizing maybe? Any TPixmap or TImage manipulations? You say you're using SetViewport... Are you using CanvasGraphics and/or anything else tied to MaxGUI? SetViewport needs to be called after a window is resized? This still applies if the CanvasGraphics window size is changed without the main window being resized. I'd also find out a bit more about the customer machine specifications too. CPU make and model, GPU make and model, memory, what version of the graphics driver they have etc. to see if there are similarities in machine spec. The info maybe be useless but you never know. And to round off... I understand that you may not be able to do this but the best ( and usually most difficult ) thing is to post a working example code that reproduces the bug. 'If' you can do that, it usually doesn't take long to find out where the error is. |
| ||
| Thanks a lot for such a long answer! Yes the bottom window is indeed taller because the window size can be determined by the user in the prefs, to fit the screen size and the user's needs (it can't be resized during the game). It's somewhat silly but that's the way I designed it back then. If I were to start over I would use virtual resolution or something like that. It does look as if the background image hasn't loaded properly, but in fact it has : the game just randomly displays words all over the title screen, it's intended to do so. The game never crashes nor asks for anything it can't find... No pixmaps manipulations at all, no resizing either. No MaxGUI... I've asked about the specs and for myself couldn't find out similarities (don't have them with me right now)... What I'm doing at startup is drawing and grabbing images of the sidebar's background, the title and things like that, and then display it as images. The bug is there from the beginning of the game on three people's computers out of maybe 1000 people... I've never witnessed it myself. No particular part of the code goes wrong, the whole game does, from what users tell me... I have to add that the users are speech and language pathologists, not computer geeks, they don't answer my questions very accurately and sometimes do two or three weeks later. They are customers and just want it to work when they launch it... I think I'm gonna try to make things more simple, and maybe stop using viewports, I can't see what else could lead to this... I'm sorry not to be able to explain things more accurately, the game works absolutely flawlessly for years and suddenly it doesn't at all on just 3 machines... Thanks very much again, I'll keep you informed... |
| ||
| Thats cool, Just some ideas to look into... Viewports could be the problem but its hard to say. They do work without error, but as per the ole cliche - never say never. It could also be a possible mathematical error ( viewport related or not ) that only shows up at certain resolutions and layout positions. Depending on how your calculate the positions of the borders etc its easy to over look a possible freak bug occuring under one off circumstances. Do you use a '9 patch' style to laying the frames? I'd triple check any math and triple check it again with different random settings and resolutions etc. Do you know if the problem machines have similar but unusual resolutions set? |
| ||
| I can see that some of the elements are correctly displayed (the shadows for example) and some get weirdly resized and duplicated. I'll try to watch it carefully. I can't get why texts look so bad neither, but I'll look at it closely too. You're absolutely right about checking the math and the screen resolutions, thanks again... Yes I think I'm using some kind of 9 patch routine for some of the display, I'll check it all. The main problem is that I can't test anything myself and have to rely on a what a few busy and remote users can report... |
| ||
| I seem to remember Grey Alien and GfK posting about viewport problems a number of years ago - supposedly (and this is going a long way back) there were known issues with the way viewports were implemented in blitzmax that were liable to cause problems in rare cases....I will look it up... |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=62781#701838 Search under "viewport" by user Grey Alien....brings this up (see above) And a host of others... EDIT like this one: http://www.blitzbasic.com/Community/posts.php?topic=63264#706559 |
| ||
| Also this thread: http://www.blitzbasic.com/Community/posts.php?topic=92585 |
| ||
| From the screenshots (but more would be welcome to get a better idea), it looks like a code bug that would have hard time to adapt to a weird screen resolution rather than a video driver or bmax issue. Do you know the screen resolution used by the customers ? Do they use multiple screen monitor system ? |
| ||
| Thanksto you all! I'm beginning to see what I have to do... Yes Pingus I've asked the users to try different window sizes and what their screen resolution they use, waiting for the answer right now. At first it really looked like a video driver issue, hence my message here, but now I think I must test my code bit by bit, it's very procedural and messy, no separated logic/display loops and things like that. I'll try to tidy it up a bit. I'm not proud of it but until now, it used to work... Really thanks to a lot for helping so quickly and efficiently... |
| ||
| Note that if your code rely on GraphicsModes() to get all the available resolutions, it may fail as this function return a limited number of possible res (32 ?). With nowadays screens/video cards, there are much more video mode available. |
| ||
| Do yo use CreateCanvas() or MaxGui? |
| ||
| Hi! No, I didn't. I'm not even scaling things neither. I see that some of the display problems occur when using ViewPort, but some other don't. I will probably take me a few hours but I guess I'll find out what's wrong with my code. What makes it difficult too is that the users don't have much time to test what I send them and sometimes reply one or two weeks later... Thanks, |
   |