[r3008] 1600x900 video mode doesn't use the whole window

[Janizdreg]

The issue occurs in both windowed and fullscreen modes, but only using the resolution 1600x900. None of the other video modes I have available are effected. The native mode of my LED panel is 1920x1080, if that matters. Most commonly I play the game in a window set to mode 1600x900, with the Windows desktop set to the native res of the monitor.

Turning vid_hw2d off doesn't remove the bar, but it does affect the way it behaves a bit. While the setting is off, the player weapon sprite is drawn under the bar, and the bar also shows on the title screen, intermission screen and such.

EDIT: These tests were made with the setup I used before, apart from the updated Catalyst (now at 11.5) and ZDoom (now r3222).

[Zhs2]

Is this fullscreen or in a window?
Does it make a difference whether you run in fullscreen or a window?
Are you using an LCD panel with a native resolution of 1600x900?
Does every other available resolution work fine?
What difference does setting vid_hw2d to 0 make?

Happens either fullscreen or windowed. No difference whatsoever.

1600x900 is indeed the native resolution for this laptop, and there are no problems with this in any other 16:9 resolution, nor any of the other resolutions of other aspect ratios.

If vid_hw2d does what I think it does (i.e. switch between the Direct3D and DirectDraw methods,) then all it does is cause the sprite to be drawn below the black bar, which is the current behavior exhibited in Skulltag (which shares the same black bar problem in software modes.)

Oh, and the card is an ATi Mobility Radeon HD 4250. Has occurred with every Catalyst under the sun as far as I can remember (which goes back to the 10.x series. I've only had this laptop for a year)

If the hard drive in this laptop dies, I'm going to highly consider donating it to ZDoom science™.

[randi]

If vid_hw2d does what I think it does (i.e. switch between the Direct3D and DirectDraw methods,)

Not exactly, it disables hardware assistance for the 2D layer, but it still uses Direct3D to get the image data to the screen.

Anyway, do resolutions nearly identical to 1600x900 work?

• 1600x899
• 1600x901
• 1598x900
• 1602x900

If you don't have a program to do it for you, you can add custom resolutions for ATI cards by editing the registry and rebooting.

I also remembered that I had access to a machine with a Radeon HD 4850 and checked on there, and it was fine. That machine is also running Windows XP, if it makes a difference.

[Zhs2]

I couldn't do any testing with the larger resolutions (blah blah blah larger than my native resolution, can't let you do that Dave etc.) but testing with the smaller of the two produced some very interesting results; 1598x900 did not display the black bar problem, whereas it was still clearly present in 1600x899.

[randi]

For the 1600x899 one, is it just as much black as 1600x900, or is it one line less of black?

[Zhs2]

To that end, I did a little bit more testing to see where the tearing stopped, and there doesn't seem to be much progress on this front. I took a few screenshots in resolution height decrements of 10, but there seems to be little change in the status of the black bar (you can see where the top row of the black bar gets smaller between some of the shots in the eastern direction, but not much.) The shots can all be found here: http://zhs2.dyndns.org/Pics/ZDoomtest

[randi]

Weird. Are all resolutions with a width of 1600 affected?

Also, how do screen melts fare? Do they also have the black band where they don't draw?

[Zhs2]

Screen melts do not seem to be affected by the black bar problem; in fact, the black bar is included in the melt animation. Seems to only be a problem with rendering the game itself (it's not present on the titlepic either.)

I wish I could test heights above 900, but oh well. Going to try some smaller resolution heights and see if they have the same problem.

Edit: Yes, they do. I went all the way to 1600x400, but 1600x300 caused ZDoom to crash for likely very obvious reasons. Screenshot evidence can be found in the same location.

[randi]

So far this looks like a system-specific problem which I might be able to work around.

So, how does this executable fare? It does not try to be a fix. I want to see if I can draw to the bottom of the screen if I only update a portion of the texture. So this only draws the left half of your screen. But if we're lucky, it will be the full height.

[Zhs2]

---

Also, not sure if it matters, but a couple of debug assertion failures popped up on execution, although Ignore allowed me to see what I needed to. For reference, they were on lines 56 and 68 in isctype.c.

[randi]

Interesting. What was the specific text of the assertions? It might be related. (If you had a debugger, it would be nice to know what part of zdoom these ctype calls came from, too.)

[Zhs2]

(Also, I'm not sure if I have a debugger worth using (not sure if I'd do much good with whatever MinGW provides,) but the steps on how to get one would be nice indeed, seeing as Visual C++ seems to be the standard here)

[randi]

If you install Visual C++, you'll get the debugger with it. I'm afraid those errors aren't useful without breaking into a debugger at that point, since they're in generic functions that are called by every ctype function, including a locale-aware version. (I didn't think I used any locale-aware ctype functions?)

Anyway, I realized I was actually changing three separate things rather than just one with that binary, so here's a different one. It also prints some numbers if you would be so kind as to report what they are.

[Zhs2]

Wow, no black bar in software at 1600x900. I'm glad I was able to be of assistance. The numbers were 1600 1644 1644.

Also, weird. I've grabbed the distribution of VC++ 2005 from the [wiki=Compile_ZDoom_on_Windows]appropriate wiki page[/wiki], gonna get that set up so I can debug this and possibly tie up any loose ends.

Edit: No such luck with VC++ 2005... I'll try back a bit later after I've gotten some sleep with something newer.

[randi]

Thanks for the help.

To anyone wondering: This is not a driver bug. It was a ZDoom bug that required specific circumstances to show up.