Serious ongoing issues with OpenGL
BlitzMax Forums/BlitzMax Programming/Serious ongoing issues with OpenGL
| ||
| I know how Mark hates when we don't post reproducible bug code (I will work on some, but I am away on vacation at the moment). I am getting a lot of complaints over garbled graphics on newer Macs. Several of these bugs are linked to the problems I mentioned in this bug report: http://www.blitzbasic.com/Community/posts.php?topic=88315 Here is one of many complaints I've gotten: http://www.basiliskgames.com/forums/viewtopic.php?f=10&t=3998 One of the biggest problems is that there is a direct problem with using DrawText under OpenGL. Many artifacts have popped up, and strangely it involves the letter "P"... http://basiliskgames.com/forums/viewtopic.php?f=21&t=3540&p=29283#p29283 I will say this again: I do not use anything but basic BlitzMax commands to initiate graphics or draw to the screen. I don't make any direct OpenGL calls or talk directly to the OS...all my games and tools are 100% native BlitzMax commands. |
| ||
| Could these artefacts be related to the font used? |
| ||
| From the complaints link it sounds like it happens after running for a while, most likely causes with the resolutions they're talking about would be Graphics card overheating: This happens on some imacs, minis, and macbooks with graphics heavy games if they don't have proper ventilation (and most people don't properly ventilate). There could be something in your code causing the graphics card to work harder than it really should be, like generating a lot of textures regularly (not sure but text could be causing this, have never gone poking into the drawtext command internally...). OpenGL does a lot of work on a mac as the whole OS GUI is run through it. Texture space overloading: the graphics getting loaded to the graphics card may be overloading the vram and rather than caching and paging, for some reason (heat?) it's just refusing to generate the texture properly when requested. A likely cause of this based on people fixing it with a restart of the app, and it tending to occur after running for a while would be a glitch in the garbage collector causing textures to not fully be released or dealloced properly. Did you compile with multithreading on? the MT garbage collector is all kinds of broken in my experience... Driver glitch: apple updates their drivers at odd intervals and it will only affect some cards on some systems when they do. e.g. they may update the driver for mid 2009 mac minis which is an nvidia geforce, but they might not update the mac pro 2009 with an nvidia card driver... generally they release nvidia or ati updates for all systems but not always. Most people don't look at the updates list when they come they just say go, so they may not be aware they recently updated the drivers, or the drivers might have been burried in with a bigger OS update. or they might NOT have updated to a driver that fixes a problem... Once other thing you could try, if you're building the windows version for direct x, try switching to the opengl driver there and see what happens. If you get similar problems you're likely making openGL mad somehow (garbage collector is my guess, or as was mentioned above it could be a font rendering issue...). |
| ||
| There was a bug with OpenGL AdjustTexSize function, which could be the problem - at least using miniB3D + DrawText on Intel GMA cards would crash my test program. I posted the fix somewhere, but can't find it right now :( Also, you should see if you're not running out of texture memory - here I posted some miniB3D code that works on nVidia and ATI cards... with the latest drivers to get the available VRAM for your program. Make sure also your customers are playing *just the game*, not running several programs on background (like iTunes or something) - this could steal video memory, and cause unexpected results. |
   |