|
Notes |
|
|
(0015969)
|
|
unknownna
|
2016-10-13 22:56
(edited on: 2016-10-13 23:19) |
|
I forgot to mention that GZDoom 1.8.6 doesn't have this issue.
I wonder if this is a minor side-effect of switching over to VC++ 2015 with cmake.
|
|
|
|
|
i wasnt able to reproduce the issue at first but i could once i switched to software
the official 151228-1140 beta (changeset: 4e5a837) can indeed reproduce the issue, but then unknownna's note got me curious so i built it using vs2005 and was unable to reproduce the issue
i even made 2 fresh clones afterwards and built 4e5a837 2 more times, once with cmake + vs2015 and once with vs2005, and the results were the same: issue is reproducable with the vs2015 build but not with the vs2005 build
thats all i have for now, but ill look more into it later |
|
|
|
|
|
If you can reproduce this with vs2015, can you check if it happens also with gzdoom 2.1 and 2.2 both in sw renderer (afair starting from 2.2 it is built with vs 2015)? |
|
|
|
|
|
I'm unable to reproduce the issue in GZDoom 2.1.0 or 2.2.0. |
|
|
|
|
Sorry, but just to be sure enough, can you check if it happens with any version after gzdoom 2.0?
|
|
|
|
|
It doesn't happene in any of them. I tested the following versions:
* 2.0.05
* 2.1.0
* 2.1.1
* 2.2.2 |
|
|
|
|
|
|
|
(0016263)
|
|
Edward-san
|
2016-11-21 19:33
(edited on: 2016-11-21 19:39) |
|
Torr, can you make a new zdoom-sync build or did you already post it somewhere else?
[edit] unknownna, do you use specific 'Text scaling' options? If you change them, does it make any difference?
|
|
|
|
|
|
The latest build I have at hand is this one. Since the problem is not even in GZDoom 2.0.05, this build should be new enough anyway. |
|
|
|
|
while the issue is not reproducable with the build torr linked, ive hit a snag trying to find the commit in the zdoom-sync repo that fixed it
trying to compile builds with cmake + vs2015 before changeset 3ce80d3 end in failure with a ton of errors, for example 'http://pastebin.com/Zqe99a6T [^]' which i got from trying to build changeset 4aede71
im assuming 'https://bitbucket.org/Torr_Samaho/zandronum-zdoom-sync/commits/7b90a18c2f77cd2500e562d7cd1e10376fb37a62 [^]' is whats fixing those errors, since changeset 3ce80d3 succeeds and 184b01f fails
i guess all i can do now is compile builds before the 3.0-151228-1140 beta and hope i can atleast find when it broke
|
|
|
|
|
Quote from WaTaKiD
im assuming'https://bitbucket.org/Torr_Samaho/zandronum-zdoom-sync/commits/7b90a18c2f77cd2500e562d7cd1e10376fb37a62 [^]' [^] is whats fixing those errors, since changeset 3ce80d3 succeeds and 184b01f fails
Yes, I'd say so too. You should be able to transplant this changeset on top of the 4.0 revisions you'd like to compile with "hg transplant".
Quote from WaTaKiD
i guess all i can do now is compile builds before the 3.0-151228-1140 beta and hope i can atleast find when it broke
Did it actually ever work in Zandronum with VC++ 2015? |
|
|
|
|
Quote from "Torr Samaho"
Yes, I'd say so too. You should be able to transplant this changeset on top of the 4.0 revisions you'd like to compile with "hg transplant".
it took me a minute to find out that in tortoisehg its actually called graft, but yea that was most definitely very useful, especially being able to graft multiple at once instead of one at a time
unfortunately, as unsurprising as this may sound, im likely doing something wrong
ive compiled many builds from the 'zdoom-sync' repo, even going as far back as changeset 9c3b373 (with a few grafted changesets) which is "equivalent to gzdoom 1.8.6" and i was unable to reproduce the issue
however when i build that same changeset from the 'zandronum' repo (with just as many grafts), the issue is reproducable
so idk, maybe im just biting off more than i can chew here and trying to rush through or something
Quote from "Torr Samaho"
Did it actually ever work in Zandronum with VC++ 2015?
good question, for all i know, the issue came with vs2015 by default and was later fixed by g/zdoom when they switched to vs2015 and noticed it
but again, im messing something up somewhere because my results arent making sense |
|
|
|
|
Quote from WaTaKiD
it took me a minute to find out that in tortoisehg its actually called graft, but yea that was most definitely very useful, especially being able to graft multiple at once instead of one at a time
FYI, graft and transplant are actually two different mechanisms that do almost the same thing. Now that you mention graft, it's actually better suited for your case. I usually use transplant, since I mostly transfer changes from one repo to another, which graft cannot do, but is also not needed for you.
Quote from WaTaKiD
unfortunately, as unsurprising as this may sound, im likely doing something wrong
ive compiled many builds from the 'zdoom-sync' repo, even going as far back as changeset 9c3b373 (with a few grafted changesets) which is "equivalent to gzdoom 1.8.6" and i was unable to reproduce the issue
however when i build that same changeset from the 'zandronum' repo (with just as many grafts), the issue is reproducable
That's could be a very important observation. It sounds as if this is actually a Zandronum and not a ZDoom bug.
So you say Zandronum based on GZDoom 1.8.6 + some grafts shows the problem, but the latest Zandronum version from the zdoom-sync-branch does not? If so, it should be possible to find out when this was fixed in Zandornum by bisection, shouldn't it? |
|
|
|
|
|
I can reproduce the issue with the binaries in "ZandroDev3.0-151228-1140windows.zip", but it works fine for me in the last beta build. So looks like one of our other fixes has taken care of this already. Can somebody confirm that this works fine now? |
|
|
|
|
r170416-0710
looked at every options menu in software singleplayer 400x300, nothing looked bad like that screenshot so I guess it's good |
|
|
|
|
|
I also didn't encounter any issues with text cut off with the latest beta. |
|
151228-1140.png (65,521) 2016-10-13 22:54