rendering of transparent walls is broken

[ketmar]

not semi-transparent, but doom ones. to see it, just go to the end of E1M1, where trasparent fences are. instead of holes being transparent, they are pitch black.

[_mental_]

The problem was introduced with this commit. Changes are quite significant and I was unable to find the cause.

[Graf Zahl]

I'm about to nuke that commit anyway and reconstruct a cleaner history. The problems in there were too much.

[ketmar]

ok, tnx. i haven't the slightest idea of what is going on in that commit too, so for now i simply reverted it in my local repo, so i can play the game without «black curtains mod» again, until the proper fix will be done. ;-)

p.s. sorry for not providing offending commit id by myself, but rebuilding gzdoom is somewhat... heavy task for my PC. especially considering the fact that i like to play gzdoom when compiler is already building huge codebase on background. ;-)

[Graf Zahl]

The reason was that I swapped two indices in a list but forgot to swap an array indexed by that list. As a result two-sided walls were considered solid and got rendered as such.
The mistake with that commit was that it did too many different things all at once. A second, similar one went right to the dumpster before anybody could see it.

[ketmar]

yeah, it is quite big. but i understand that refactoring work is hard, and sometimes you just want to make it all in one huge batch, 'cause it looks like less work than moving code piece by piece (because more fine-grained changes may require writing additional temporary code to make it work, and it may look like refactoring actually making things *worse* ;-).

but tbh, even with smaller commits, it wouldn't help me to find the cause of the bug, 'cause i absolutely don't know how gzdoom renderer works. debugging various segfaults looks much easier. ;-)

[Graf Zahl]

I force pushed the fix along with a redone weapon sprite refactor. Please make sure to update properly from Git.

[ketmar]

tnx. it works now. yet i beg you to not do force pushes: it is a PITA to rebase with those (i have my private branch, and doing "git rebase master" with rewritten master is not fun... ;-). please-please-please, just revert invalid patches. nobody will blame you for messy code -- nobody will notice, as zdoom is a giant pile of mess anyway! ;-)

[Graf Zahl]

I normally avoid force pushes, but this time there was no way around it as I couldn't merge the old with the new without messing things up totally.

[Blue Shadow]

So I did a pull from upstream, like I usually do, but got some conflicts this time. My 'master' branch should be the same as upstream's, i.e. I didn't do any changes of my own to it. How do I resolve this? No vague instructions, please. My knowledge is pretty basic when it comes to using Git/TortoiseGit.

[_mental_]

At the moment for master branch do in cmd.exe (with proper path to GZDoom source of course)

Code: Select all

cd <gzdoom-sources>
git reset --hard 2be84dc636d5cb5f6a89500a560ea00c02ce609f

I don't use TortoiseGit so can't help with it. There should be an Reset command with Hard option.

[Graf Zahl]

So I did a pull from upstream, like I usually do, but got some conflicts this time. My 'master' branch should be the same as upstream's, i.e. I didn't do any changes of my own to it. How do I resolve this? No vague instructions, please. My knowledge is pretty basic when it comes to using Git/TortoiseGit.

In TortoiseGit, open the log, right click on the new commit, then "Reset master to this", in the opening popup select "hard" and click ok.

[drfrag]

Do a hard reset to 'OPL Synth fix: Double-voice instruments randomly don't play second voice' in your master and then pull? With tortoisegit.
Wait for someone smarter to confirm.
Edit: i've seen _mental has proposed something. What Graf said i guess.

[ketmar]

yeah. basically, do "git reset --hard" on some older commit (anything older than two or three days, it doesn't matter), and then do the usual "git pull", and you will up to speed again. there is no need to be precise with resetting, so just kill several days of history.

p.s. of course, this is git, so there are at least five other ways to do the same thing, including low-level db manipulation. you can fetch, gentle checkout, delete branch and create new; or do a tricky rebase; or... ah, don't mind it! just do a hard reset several days back and pull it again. ;-)

p.p.s. i am not using any fancy git gui, so follow Graf's Uber-Manual to do it. ;-)

[Blue Shadow]

All fixed now. Thanks, guys.