Page 13 of 15
Posted: Sun Apr 20, 2008 4:54
by chmmr
Coming to this party late, which patch(es) should I use if I have the latest (r96) SVN?
Posted: Sun Apr 20, 2008 10:52
by Costja
Only the latest patch.
Currently I check nearly every revision and post a new patch if a revision requires different changes than previous one.
Posted: Sun Apr 20, 2008 19:48
by chmmr
If I get rev 96 and then try to apply just the most recent (r92) patch, I get errors about missing files. What's the process if I'm starting from never-been-patched SVN?
Posted: Mon Apr 21, 2008 20:12
by Costja
Patch for r97 attached.
Graf Zahl, src/gl/gl_models_md2.cpp problem seems to be also a bug in Windows version. I hope my fix is correct.
Making makefile closer to zdoom's version is not needed?
chmmr,
UPDATED: the following works for me (trunk is a dir that contains src/ dir):
Code: Select all
cd <path to gzdoom r96 source>/trunk
patch -p0 < <path to the patch for r92>
Posted: Fri May 02, 2008 17:26
by Costja
Patches for r102:
- experimental patch. It should fix nearly all warnings and includes Makefile.linux patch described below. But as it includes a lot of changes it should be rechecked. I'm least sure about the following:
gl/gl_dynlight.cpp:1197
gl/gl_models.cpp:430
gl/gl_missingtexture.cpp:107
gl/gl_missingtexture.cpp:168
fragglescript/t_oper.cpp:84
- Makefile.linux patch, fixes only Makefile.linux. It enables making Brightmaps and lights pk3s and fixes xlat errors.
Posted: Mon May 26, 2008 16:07
by Costja
Patch for r110:
It's a newer version of the experimental patch. My lite patch (only Makefile.linux and p_map.cpp fixes) makes gzdoom crash on starting MAP01 so it can't be used. Makefile is fixed so updaterev is now called once.
ADDED: This patch is broken, use the patch in the post below. The patch in this post is still here only to provide ability revert changes.
Posted: Sat May 31, 2008 16:26
by GuntherDW
Costja, check
http://forum.drdteam.org/viewtopic.php?t=3277
does this happen for you as well?
also, i've been having this problem for a while now, even before the SVN versions came into play
it seems that certain sectors can make gzdoom slow down to a crawl, and even hang my pc for a couple of seconds
it doesn't happen when i look away from it, but when it's in the render range it renders fine for 0.5 secs and then hangs again for a couple of seconds
i'll post a screen to "fortify" my problem, it's one of the easiest to find places in kdizd (but it happens alot in other wads as well, most of the time it's a sector with 3D sectors attached)
Posted: Sat May 31, 2008 16:33
by GuntherDW
kdizd map z1m3
issue "warp -325 810" in the console, and look at the ladder going upwards
seeing as this is not an easy not to crack (i'm not a good explainer :p), i would even like to show the problem using an external cam to film it while it happens
(i think it won't be easy to do it on the same pc because even XMMS stops playing, just about everything *stops* for about 3-5 secs (and yes it's gzdoom, zdoom didn't have this problem, and it only happens when i'm playing with gzdoom and it's rendering those sectors :p
EDIT:
vid is up :
http://guntherdw.dommel.be/tmp/tv.enc2.avi
sorry for the horrid quality, had to do it with a webcam of horrid quality

but you can see what's going on
this is with a clean boot with nothing going on besides gzdoom (and my other pc in my room capturing it)
Posted: Mon Jun 02, 2008 7:01
by GuntherDW
bumping for great justice, even if it's just 2 threads up
i'm sick of that bug and would like to see it gone :p
are there any things i should/could try to see if it's on my end or on gzdoom's end?
zdoom works just fine on those parts, but is a hell of a lot slower on linux

Posted: Mon Jun 02, 2008 13:52
by Costja
Fixed r110 patch. Use the following to undo the previous patch:
ADDED: I experience slowdown to 12 fps near that ladder, but not freezing image to about 0-1 fps. BTW, I use full fixed patch for r110.
Posted: Mon Jun 02, 2008 18:08
by Graf Zahl
Just one thing. Any __asm nop you find is just for debugging. No need to make a GCC alternative for it (which is even less useful if you #ifdef unix it) Just remove such code.
Posted: Mon Jun 02, 2008 18:12
by Graf Zahl
I just committed your patch. Can you please re-check if everything is ok?
Posted: Mon Jun 02, 2008 18:52
by Costja
Got an error:
Code: Select all
src/gl/gl_walls.cpp: In member function ‘void GLWall::DoMidTexture(seg_t*, bool, sector_t*, sector_t*, fixed_t, fixed_t, fixed_t, fixed_t, fixed_t, fixed_t, fixed_t, fixed_t)’:
src/gl/gl_walls.cpp:900: error: ‘WALLF_ADDTRANS’ was not declared in this scope
src/gl/gl_walls.cpp:908: error: ‘WALLF_ADDTRANS’ cannot appear in a constant-expression
"__asm nop" is not compatible with gcc, so probably it should be removed/ifndef-ed.
Warnings:
src/namedef.h:370:16: warning: no newline at end of file
and few "comparison between signed and unsigned integer expressions" warnings
Posted: Mon Jun 02, 2008 19:15
by Graf Zahl
Shit. I forgot to change that piece of code. I just committed a fix for it.
If you find any __asm nop that throws an error with GCC it's just a leftpover and can be removed. Sometimes I forget them.
Posted: Mon Jun 02, 2008 19:22
by Costja
Yet another error after updating:
Code: Select all
releaseobj/gl_dynlight.o: In function `gl_InitializeActorLights()':
gl_dynlight.cpp:(.text+0x31d): undefined reference to `ADehackedPickup::States'
gl_dynlight.cpp:(.text+0x32f): undefined reference to `DehackedPickups'