Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Keldor]

UPDATE:

Turning off triple buffering in my graphics card settings solved the flashing problem.  However, you need to clear your buffers before using them for the first time, since I get garbage flashing in the unused areas of the screen during the intro.

The underlying problem still likely exists, however, and is probably also responsible for the afterimage Xs and the world maps underneath the titlescreen.  For dirty regions to work properly on all hardware, you must explicitly copy the previous frame into the next frame, since they are in physically different memory spaces, so changing one does not change the other.

[VPellen]

UPDATE:
Turning off triple buffering in my graphics card settings solved the flashing problem.

Added confirmation: I turned on triple buffering on my graphics card just to see what'd happen, and it created the flashing issues for me also.

[Skizelo]

I've also got the x thing (I thought it was a feature first time; "this is what you'll designate" sort of thing), and when genning a world, some words (region title + the abort instructions, I think) were strobing based on the year. The generation ended on a year with them visible, and they persisted unless obscured by something new -  I reached the main menu with a green "ace" on the bottom of the screen.

[Fourth Triad]

I have df with the standard 80x25 tiles, and 800x600 pixels(windowed), with 800x600 curses font. I get a weird display and map error when exporting a map during world gen. It's normal until I press 'p' to export then it looks like this(it only affects water squares): http://img385.imageshack.us/my.php?image=afternn7.png
Also the exported map looks weird: http://img185.imageshack.us/my.php?image=worldmapregion13001jd6.png

[Mookie Love]

The only time I got any sort of flickering at all so far is when I made the window larger than gridsize*tilesetsize covered, with blackspace set to ON. I usually estimate and overshoot the window size like that until I get unlazy enough to set it exactly.

The area of the window that wasn't covered by the game itself flickered like crazy. Needless to say, that made it necessary for me to go fix my settings right away.

[Zombie]

it's not happening here, because the black spaces are being printed for me.

Somehow I doubt that.

As an experiment, I replaced all of DF's black-space characters with random symbols. Here's the result.



There are no tiles being drawn. Nothing is being drawn on those spaces.

I think this has some merit, hence the quote. It's important to note if something is being drawn at all.

[TimeOut]

I am using

Code: [Select]

[GRID:158:80]
[WINDOWEDX:1264]
[WINDOWEDY:960]
[FONT:curses_640x300.bmp]
as my init settings.

I have an AMD Athlon X2 64 5000+ dualcore (2,6 each) and a 512 MB GeForce 6800 GTS by XFS, running Windows XP Professional currently. Using DirectX 9.0c and ForceWare 175.16. Triple Buffering is disabled as a default.

Edit: Will check what happens with triple buffering later. Also a wine/linux report in a few hours maybe.

At first glance I get no visible framerate improvements, but I couldn't check the "bigger" forts yet. Intro plays fine. Designation and world generation stuff is also fine.

But if I minimize the game in any way, it will only draw "new" tiles after I open it again. This is only mildly annoying, because you can easily save or open the stocks screen to get it to redraw nearly everything.

Just pressing Alt+Tab to switch to another window doesn't affect the game in any way.

[Eater of Vermin]

The second I've noticed is in mining designations in new areas.  The yellow "X" won't clear off the unmined areas while moving it around.

I'm also copping this, but only when placing the "X" with the mouse. 

If I position it with the keyboard, or place it nearby with the mouse then move it one square to where I want it with the keyboard, then it works fine.

So I suspect it's not a display problem...

[Toady One]

it's not happening here, because the black spaces are being printed for me.

Somehow I doubt that.

It's printing the foreground for me -- it uses the space character before the !, which I changed to a small o as a further check, and it was visible.  It's printing the black background square as well (the part that controls the color behind the letters).  I've verified this by changing the color of those prints to brown.  The small o and brown squares are printed and refresh properly when I move my cursor over them.  So, for the third time, the cursor trail is not reproducing on my computer.  I've never said it's not happening.  In fact, we discovered about an hour ago that it happens on my brother's computer, which is good news for testing, but I don't see why you'd attack my specific statement.

In any case, single buffering is heavily deprecated, so you'll need to render to an offscreen buffer, then copy it to the backbuffer each frame in order for it to run properly on newer hardware.

I don't know very much about this stuff.  Isn't the back buffer an offscreen buffer?  You need another one?  I'm double buffering in the sense of requesting double buffering in the PIXELFORMATDESCRIPTOR, and I know I've got two buffers (a front and a back that get swapped) from some of the bugs I got while I was implementing this and a further test I performed now.  Is the PFD's double buffering what you mean by single buffering, and your double buffering means using a third independent buffer that then gets copied over to the back buffer?  My laptop has an ATI Mobility Radeon x600, and I don't know where that falls in terms of this sort of thing or if that's the part you're referring to -- the drivers are from 2005 if I remember.  If new things are more complicated, the buffer swapping (but not the latest changes) are all up on Kobold Quest (http://www.bay12games.com/games) if anybody wants to look at it and let me know what needs to be updated for newer machines.  KQ/DF uses a SwapBuffers() function that takes the window's device context, but I haven't created a third buffer.

[Geekman]

turning off triple buffering works for me.
( so i was really seeing 3 frames at once )
just tested a small game with world generation and i didn't see any other graphic glitches

sweitx> XP32 "Gold edition" (got a legit one but i've been too lazy to even unwrap it :p )

[Sean Mirrsen]

There are only a few display issues that I get in new DF. When the grid is larger than default, I get random chaotic vomit all across the screen when space-skipping the initial intros, around the default-sized area.

In addition to that, I get weird issues with nonstandard grid size and combat messages. For one, some of the longer messages scroll around to the other side of the screen instead of wrapping to the next line in the center. Another case seems to happen when the first message in a batch is related to a failed attack/counterattack, in which case the entire column of lines is centered on the standard 80-wide space instead of the actual screen width.

[pandamojo]

I'm getting a really odd problem WRT windowed mode and large grid/view sizes.  I have a dual 1280x1024 monitor set up, and to prevent DF from minimizing when tabbing to other programs I run it in windowed mode:

Code: [Select]

[WINDOWED:YES]
[GRID:160:85]
[WINDOWEDX:1280] # 8x160
[WINDOWEDY:1020] # 12x85
[FONT:plac1d_640x300.bmp] # 8x12 characters

Not counting the border and titlebar, this results in a window with a height of 1011 (/1036 counting border+titlebar), not the expected 1020 (/1045).  This results in an annoying glitch:

The first line is mostly cut off, the last line is fully visible.  However, mouse coordinates seem to be handled as if it were expecting the opposite -- clicking the mouse registers on the tile visible almost a full tile up from it's Y coordinate, rather than under the mouse itself.

As a workaround, I'm shaving off 1 y in my GRID and changing the resolution accordingly:

Code: [Select]

[GRID:160:84]
[WINDOWEDX:1280] # 160x8
[WINDOWEDY:1008] # 84x12

This still results in a window which, counting the titlebar and border, is still larger than my physical screen dimensions, but this seems to eliminate the window misshapen issue and the corresponding mouse/grid alignment being out of whack.  It's worth noting that changing the GRID alone does not fix it, as the screen is still rendered off-center (with BLACK_SPACE), with the mouse behaving "properly", highlighting tiles a little under 1 tile above it's location.

The bug occurs regardless of GRAPHICS or BLACK_SPACE being enabled, as long as the graphics settings correspond.  It seems to occur everywhere, from the main menu to dwarf fort mode.

Hope this helps.

[Veroule]

After reading all the display issue topics, I realized Keldor is partially correct.  The reason being the way SwapBuffer is actually implemented.  With many newer cards the buffer swap comes down to a single assembly instruction that actually swaps the addresses for the display and rendering buffers.  With some older cards the swap is done by locking the display and copying from the rendering buffer into the display buffer.

I am guessing the code updates reduce how much is examined for rendering, and then has some sort of list for what should be rendered.  So it looks something like this:
makecurrent
for things to be rendered do {
 determine oglCommands
 send oglCommands
}
swapbuffer

Now a system that preforms an actual swap instead of the copy has the 2 buffers out of synch.  The next update then changes a buffer that doesn't have the previous update, and they get further out of synch.  This would be the explaination for some display artifacts and flickering.

The simple solution is to copy the entire buffer to your own address space after the oglCommands and before SwapBuffer.  Then on the next draw copy your saved buffer in first.  The draw back to this is additional memory requirements and the small speed hit from copying.  The benefits are that gfx cards that force triple or quad buffering will display properly.

Edit: I posted this before finding all the replies in page 2.  If I get a chance I will look at the newer KQ and see if I can locate the correct spots to add the buffer initialization, and copying.

[TimeOut]

Now for the Wine/Linux update.

Everything except for minimizing and reopening works fine, Ubuntu 8.04 (2.6.24-19-generic), some sort of Pentium dual core or hyper threading-processor and an unspecified on board nvidia graphics card using the non-free driver installed by envy.

Basically the same as with my windows system at home. It works perfectly as long as you don't minimize the window.

Edit: wine-1.1.2

Second edit: Posted too soon. I get the repeating yellow X while designating with the cursor on black tiles.

[ghor]

I understand the yellow X problem as it's described, but like I said, it's not happening here, because the black spaces are being printed for me.

It only happens when the mini-map thing is being displayed, for some reason.