Dr.Disaster wrote:badhabit wrote:PLEASE stop now defending bugs and bad code! Being Indie with limited ressources is NOT a acceptable excuse here as this is really simple basic stuff... and not more than 2-3 lines of code to change.
You call it bad code. I call it stuff no sane person would try i.e. placing over-sized 4:3 ratio windows on a 16:9 ratio display.
I can safely assume you are not programmer and therefore seems to have no expoerience in debugging and creating test cases.
Also, for the XXXX time this stuff is useful and needed for general multimonitor support it's just a "viewport" which one can place in the space created by multiple monitors. It's completly OK and correctly handled by OS, graphic card and driver. Just LoG made it wrong.
Dr.Disaster wrote:
This "report" only states that the Options menu is unusable. It does not give any details beside this statement. There is no word about a missing apply button in it.
What a weak argument. *hand-over-some-vitamins-to-argument-weakling* "Come back when your are grown up!"
Dr.Disaster wrote:badhabit wrote:PPS: another example this time phyiscal AND window size >= 1024 x 768
Why more tests on opening windows with one axis forced to be larger then the display reporting to support?
Because you was keeping crying about "
OHHH you are outside the specification your fault" I'm inside the specification (even more restrictive than written down), so what now?
Dr.Disaster wrote:
The real question to ask is what should an OS do when it receives a request to open a window with one axis being larger than the display's resolution? The correct answer is to deny such requests but no OS known to me delivers this. Instead the requested window is created, but cut down in size so it does not overshot screen edges.
My impression is that LoG hits exactly this OS-bug. It tells the OS to open a window with the requested size but the OS denies any axis to be larger then the current display resolution. After that LoG just centeres it's hopefully correctly sized window on screen. In case the OS did not create the window with the requested size you get results like those you just posted.
*Wow* that I call lunatic. you assume a OS bug in a billion $ dollar operation system which has matured for years is more likly than a bug in application?
Just checked it, FTL game which has a minimum reuqirement of 1280×720 (
http://www.ftlgame.com/?page_id=192#reqs) is handled right in windowed mode correctly even down to 800x600. Window is not miscentered and has the right size, no problem.
Dr.Disaster wrote:
btw, just in case you did not notice it yet: LoG's Options menu never scales.
It's height is fixed because it's designed to look the way it looks. Changing it to scalable will require a re-design.
In addition: this discussion adds nothing to solve OT's scaling problem. None of LoG's reported "strange scaling conditions" explain the games zoom behavior on OT's system.
Yeah, thats seems part of the problem and will become a readability problem on high enough resolutions and with enough monitors.
Again, obviously you are not programmer and therefore unable to see the connection in the screen handling code. Please, don't continue.
And to AH: Please, Petri, I beg you in the name of all what is good and holy for programers, fix this da...ed rendering & scaling code so that this can finally end! PLEASSSSE, this code piece fall short in comparision with the rest of LoG, is a pain for every rightous programer & all the demoscenerz droop... My fingers are itching, wants to fix it myself *argghHHHH* Don't let me start with debugging and binary hacking on poor LoG!