DRD Team

As I really hate repeating myself, I won't, just point you back to the thread, where I've explained the problem in detail.

On the other hand, a slightly different hack, that leads to somewhat interesting results.

- initial screen is in top left corner, but isn't stretched and its upper part is unnecessarily cleared
- load/save menu is drawn incorrectly, but still somewhat usable

- once the game starts, hud and menu are drawn in the top left corner in the internal res, the gamescreen itself is drawn at incorrect ratio (takes the whole width, but height is computed in an odd way - back on zdoom forum I've incorrectly called that "skybox", but with this hack it's more clear it's a mater of incorrect ratio)

On that last note, once the hack is turned into a proper fix, it might lead to a way for modifying GZDoom for a simple implementation of "keep original ratio in fullscreen" option.

...

Latest in the hack series. Funny thing: this one is both most broken and most working yet.
- I'm nearly sure it's broken on Windows
- I've tested only with internal res 800x600 (though should work with any of actual 4:3 (meaning - not for 320x200)) and a 16:10 screen
- before you ask: black bars at the sides were intended (for reasons that should be somewhat clear)
- game screen, hud and menus are drawn (AFAICT) correctly
- not the save/load screen though (didn't found the relevant code)
- oops, map is broken in a funny way (namely the content is correct, but not the background - any chance it's the same codepath as load/save menus ?)

Now, could I have some constructive feedback ?

...

...and shortly after writing the above, I found that place. As I guessed, it was the same place for both map and load save menu.
Now the only important thing remaining to complete this hack is finding where the little hickup upon loading a save comes from - for an eye blink or two screen size is wrong. Other than that, I'd call it done.

...

OK, a bit more tinkering has led to this. Sorry for history wipeout, but with 3 attachments per post limit, I needed to delete something - that didn't really mean I needed to delete all of it, but given somewhat still sub-par quality of the hack not all that much is lost.

That hickup were (as most of you had likely guessed) wipers.

Current issues:
- still most likely breaks Windows
- still just under previously mentioned int.res/monitor restrictions
- screenshots are incorrect (fixing that might be a bit more complicated than the wipers)
- not sure if that .ortho change in gl_renderer.cpp is needed (it just mirrors the separation in a different part of code)
- don't quite understand when 'bounds!=NULL' is hit in FGLRenderer::SetViewport, so can't tell if that part is correct
- somewhat uncertain about scaling the bounding box in FGLRenderer::Clear, but it seems to work
- some of the parts only work correctly cause in Linux GetHeight() == GetTrueHeight()
- as I don't really understand the renderer, I can't really tell if it would be possible for the Wiper to retrieve the texture at internal res and only render it as fullscreen res (would be more consistent)

Unrelated, but it seems that in FGLRenderer::DrawTexture, 'int btm = (SCREENHEIGHT - screen->GetHeight()) / 2;' is effectively 'int btm = 0;' for all of the current platforms.

...

Latest iteration (I wonder when I hit the size limit of a single post):
- screenshots seem fixed; as do savepics
- to fix savepics, I've made a change, reverting a part of my previous change to FGLRenderer::SetViewport (that 'bounds!=NULL'); as they put it "this code smells" - it gives me correct result, but in no way it should be right

Well, if anything's still broken (besides what was noted above), I'd like to know about it, as it's likely some part of the game I haven't looked at.

...

No real changes this time, just removed a use of a magic number (which would mater only for multihead setups, which I'm not really in position to test).
Removal of the previous version therefore deliberate.

...

A few months have passed...yet surprisingly little progress has been made.
OK, so this version does bring significant changes over the previous one (simplifying and correcting a function, dropping a few unnecessary changes, etc.), but basically this code is just bitrotting.
A minor catch about this version is that the whole SDLGLVideo::ScaleBoxSimple was written with my incomplete ratio hack in mind, therefore it looks quite well...as long as ZDoom isn't adding its own ratio corrections into the mix.
Still, even without that console text gets ridiculously small in fullscreen...

Hello. I'm experiencing the same problem as you. I'm using Win 8.1. I was planning to compile Gzdoom using your patch, but I couldn't get the source tarball for a95edc3. The SVN for gzdoom has been dropped, they now use git, and it seems to me (maybe it is due to my ignorance) that it isnt' accessible anymore.

Could you please share with me the binary with your patch attached so that I can use gzdoom in full screen?

Thank you very much in advance.

..:sigh:...

1. To state the obvious, a95edc3 refers to the git commit I've seen the problem for the first time
2. My binary would be kind of useless to you, as I'm on Linux
3. Given 2., it's highly unlikely you're seeing the same issue, as (AFAIK) Windows uses its native backend, not SDL2 (unless it's something like GZDoom using geometry shaders and your card lacking them).

Still, It's been awhile since I've been on this forum and while (again) very little progress has been made, recently I've made an interesting tweak, that simplified a change in another code point.

Namely, I've moved creating savepic into an offscreen VBO.

The patch is even more of an WIP than before, as I had an another idea, that I hadn't either fully implemented or dropped yet, so there a bit of "funny" code in this patch.

Sorry, but I have no idea what to do with this, so I'm just closing it.

@Graf Zahl : A simple question: are you or are you not able to reproduce the problem on Linux (cause SDL backend is only in use there...AFAIK (as OS X uses its own backend)) ?
What I want to establish is if the problem reproducible for other people.

Cause if it is, then perhaps Blzut3 could be talked into helping.

VoidMage wrote:@Graf Zahl : A simple question: are you or are you not able to reproduce the problem on Linux (cause SDL backend is only in use there...AFAIK (as OS X uses its own backend)) ?
What I want to establish is if the problem reproducible for other people.

Cause if it is, then perhaps Blzut3 could be talked into helping.

I can create a virtual machine to test Linux problems with, if it would help. It will have full OpenGL forwarding. You'll have to PM me when there is a problem though since I don't check the forums as frequently as Graf does.

Actually, I am gonna do that now regardless, since I have extra space on my external that I can still use. Ubuntu 14.04.2 64-bit.

So here's what happened when I tried it:

1) First attempt, I installed Ubuntu 14.04.2 64-bit into VirtualBox. I used my external hard drive to hold the virtual hard drive, everything went ok up until the VirtualBox additions. Load, compile, run GZDoom - it does not work. I can use the software renderer in GZDoom, but it flips out about OpenGL not being accelerated, despite it not being used. (seems to be a VirtualBox issue)
2) Thinking maybe something is up with Ubuntu, I then make a new VM, installing Fedora Workstation 21 (which I had handily downloaded at the time). Do the same thing - same problem.
3) Noticing that my Fedora is vastly outdated (I hate their release schedules, which is why it's not my distro of choice), I attempt to upgrade. 3 hours later, the upgrade process is taking too long, so I wipe the whole thing and download Fedora 23. Install from scratch, do the same thing - same result. "OpenGL is not accelerated!"
4) I read somewhere that VMWare supports a newer OpenGL version than VirtualBox did. I download VMWare, install a new Ubuntu 14.04.2 from scratch. Load, compile, run - same result - no acceleration.
5) I now have 3 different versions of Linux, all of which are essentially useless to me, so I try a different approach.
6) I install SSH into Ubuntu, and putty on the Windows host, with an Xming server. Tested - everything works. I can run "glxgears" from putty no problem.
7) Try once more - still having the acceleration error.
8) I pull 1.8.6 from the repo for testing purposes, recompile and run - this time, it works. However, it does not show any info about my OpenGL subsystem like it would show on Windows.
9) I open this thread again, discover that the problem is far newer than 1.8.6, so since GZDoom's OpenGL renderer no longer works in virtual machines, I cannot test this. Sorry.


EDIT: I did manage to run the Windows GZDoom 1.8.02 through WINE and got some very valuable information about the hardware that it "sees" - Basically, it only sees the MESA software renderer, and it has not caught up to OpenGL 3.3 yet (was 2.1). This is despite my efforts to try and enable an X server that fully supports OpenGL forwarding in Windows.

EDIT AGAIN: Well, I finally found a win32 X server that is actually hardware accelerated. But it's even worse than the mesa libraries, it only supported 1.4. Performance was considerably better though.