View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002371 | Dwarf Fortress | Technical -- General | public | 2010-06-18 16:30 | 2012-02-15 07:21 |
| Reporter | BubbaBrown | Assigned To | Baughn | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | Windows 64-bit | OS Version | 7 |
| Product Version | 0.31.06 | ||||
| Summary | 0002371: OpenGL Drawing Artifacts | ||||
| Description | Throughout the game and even at the starting menus, there seems to be an erratic OpenGL drawing glitch which produces a "star burst" pattern in the background starting from the upper left hand corner and outwards across the DF window. It seems that the drawing updates to the screen and the rendering are out of sync, so an intermediate state of the rendering process is being shown. Or, a buffer isn't being cleared properly. This seems to happen on all OpenGL drawing modes, but never on the standard 2D modes. | ||||
| Steps To Reproduce | Run the game with any OpenGL display mode. | ||||
| Additional Information | ATI Radeon HD4890, Catalyst Drivers 9.12 Maximum "rendering" FPS is set to 200. Maximum "display" FPS is set to 60. | ||||
| Tags | SDL-only | ||||
|
|
It looks like the current Catalyst version is 10.6: http://game.amd.com/us-en/drivers_catalyst.aspx You should probably try updating. |
|
|
I doubt it's a driver issue. DF makes use of basic OpenGL functionality, and I've never seen this kind of issue in any other OpenGL application and benchmarks this particular machine has run. (3DMark, FurMark, etc...) And pulling from my past OpenGL experiences, it seems like improper ordering of OpenGL calls... an overly aggressive use of glFlush() or a premature (or missing) glEnd()? I can only make stabs in the dark without seeing the code. :P |
|
|
DF makes use of basic OpenGL functionality I'm not sure which version you're referring to, but if you're using 31.06 SDL (as opposed to 31.06 Legacy), that one has had all of its rendering code rewritten. Outdated drivers (particularly on Windows 7, which had buggy launch drivers) have been a major cause of crashes, artifacts, etc in the SDL versions. I strongly suggest updating -- as in, we really can't do anything with this report until that possibility is ruled out. |
|
|
I am using 31.06 SDL. Updated the graphics drivers, still does it. The point of origin for the starburst is in the upper left hand corner, which usually is 0,0 origin for most drawing. I tried to capture a FRAPS of it, but FRAPS actually helped the issue, greatly. The issue came back once I unloaded FRAPS and changed to another menu screen. I can load and unload FRAPS to control the artifact's appearance along with changing menus. So, the hooks that FRAPS does to either the system's or OpenGL rendering pipeline to capture the output may alter the timing enough to stop the artifact from occurring. On a side note, FRAPS's frame rate counter has shown some strange fluxes on a unchanging, still screen on start up. |
|
|
What PRINT_MODE are you using in /data/init/init.txt? Try using a different one (also, if you copied your init.txt from a previous versoin, don't do that). |
|
|
The init.txt is clean with the only modifications being to add graphics and a tileset. I tried a few of the modes: NORMAL - Glitch as described. VBO - Glitch as described. FRAME_BUFFER - Okay from what I saw. ACCUM_BUFFER - Broken, accumulating too much and keeping it for too long. PARTIAL - Like the ACCUM_BUFFER, but not quite as bad. Number changes made no real difference. |
|
|
Looking at the related issue, I remember a few things about the difference between how Nvidia and ATI handle OpenGL drawing errors. Nvidia drivers typically allow errors and bad calls to go through without intervening. ATI drivers will detect bad call practices and errors and will actually attempt to correct those errors to prevent complete failures. It's been awhile since I've messed with them, but it was enough of a difference between the two manufacturers that OpenGL class projects had to be tested on both to make sure they worked correctly overall. Again, I suggest looking at the OpenGL API calls and the ordering to make sure they are started and ended properly. And if there is some threading going on, make sure threading doesn't allow interruptions to this call order. |
|
|
Reminder sent to: Baughn Hey Baughn -- in case you didn't see this one already. |
|
|
It doesn't happen on nvidia, but I'm getting a new laptop with an ati card in a few days (I hope!). So I'll try it then. |
|
|
My machine's CPU is an Intel Core i7 920, so there could be threading issues involved with Windows trying to distribute the work out at the OS level. |
|
|
Please reopen this report or PM me on the forums if this problem still exists. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-06-18 16:30 | BubbaBrown | New Issue | |
| 2010-06-18 16:37 |
|
Note Added: 0008643 | |
| 2010-06-18 19:40 | BubbaBrown | Note Added: 0008652 | |
| 2010-06-18 20:17 |
|
Note Added: 0008653 | |
| 2010-06-18 20:21 |
|
Note Edited: 0008653 | |
| 2010-06-18 21:09 | BubbaBrown | Note Added: 0008655 | |
| 2010-06-18 21:24 |
|
Note Added: 0008656 | |
| 2010-06-18 21:24 |
|
Note Edited: 0008656 | |
| 2010-06-18 22:36 | BubbaBrown | Note Added: 0008663 | |
| 2010-06-21 11:36 |
|
Relationship added | related to 0002312 |
| 2010-06-21 11:38 |
|
Tag Attached: SDL-only | |
| 2010-06-22 21:23 | BubbaBrown | Note Added: 0008997 | |
| 2010-06-22 21:47 |
|
Note Added: 0008998 | |
| 2010-06-23 03:21 | Baughn | Note Added: 0009003 | |
| 2010-06-23 03:21 | Baughn | Status | new => assigned |
| 2010-06-23 03:21 | Baughn | Assigned To | => Baughn |
| 2010-06-26 15:06 | BubbaBrown | Note Added: 0009149 | |
| 2010-06-29 07:38 |
|
Category | Technical => Technical -- General |
| 2012-02-15 07:21 |
|
Note Added: 0019636 | |
| 2012-02-15 07:21 |
|
Status | assigned => resolved |
| 2012-02-15 07:21 |
|
Resolution | open => fixed |
