When playing heretic and hexen, I've noticed some missing graphics. This is most noticable on the final level of heretic-shareware, in the elevated center room full of exploding green balls. Many of the balls are invisible, but sometimes reappear if you leave the room and come back, or simply turn around. Another place to see the problem is in the hexen demo. Play the first level as a mage. Your blue scepter shows a tracer when it fires, and you can see the damage done as it hits an opponent. Now advance to the second level. The blue scepter no longer shows the tracer nor does the damage to a foe appear (though the damage is done; hit them enough and they still die). The fireballs from the lizardmen on the second level also do not show up. I've tried this with several different bit depths, resolutions, windows vs. fullscreen, software rendering and opengl, and proprietary vs. free drivers for my nvidia card, but none of these combinations seems to fix the problem. I've also tried using the full versions of both games instead of the shareware/demo versions, but that did not help either. Version-Release number of selected component (if applicable): 1.23-2.fc6.x86_64
Hi, First of all I'm glad to see you're really seriously play-testing vavoom, thanks! About the bugs, could you attach some savegames, close to where the problems happen? Also I'm inclined to push this bug-report upstream, but before doing that, have you tried this on an i386 / 32 bit machine / version?
Created attachment 155600 [details] game save files showing the bug http://www.kobold.org/~wart/fedora/hexen-saves.tgz (also attached) There are two save files. The first is at the very start of hexen. Fire your scepter at the two-headed orc in front of you and you should see the blue traces and blood spatter. The second save file is at the start of map2. There are a couple of orcs in front of you. Fire your scepter again, but this time there are no traces or blood spatter. At other points in the game the blue traces will come and go. I haven't noticed a pattern yet on when they appear and don't, but it's definitely not an intended feature of the game. I've also tried this on FC7-test4 on i386, with the same results.
Hmm, for me the second savegame always crashes. Upstream has just released 1.23.1, can you rebuild the srpm / CVS with 1.23.1 (loose Patch2, it came from upstream CVS) and try that? If that doesn't help I'll ask upstream, upstream seems quite responsive to inquires so I've got good hope there.
Ok, I just tried 1.23.1, and there the trail of the scepter behaves funny at level 1 already, I'll contact upstream about this.
1.23.1 fails to build for me on FC6-x86_64. If you have such a build, then I'd be happy to install and test it on my system as well. Build error from mock: if g++ -I. -I. -DHAVE_INTTYPES_H=1 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -W -Wall -pthread -D_REENTRANT -MT _____MAIN_EXE_-s_flac.o -MD -MP -MF ".deps/_____MAIN_EXE_-s_flac.Tpo" -c -o _____MAIN_EXE_-s_flac.o `test -f 's_flac.cpp' || echo './'`s_flac.cpp; \ then mv -f ".deps/_____MAIN_EXE_-s_flac.Tpo" ".deps/_____MAIN_EXE_-s_flac.Po"; else rm -f ".deps/_____MAIN_EXE_-s_flac.Tpo"; exit 1; fi s_flac.cpp: In member function 'virtual void VFlacSampleLoader::Load(sfxinfo_t&, VStream&)': s_flac.cpp:149: error: cannot allocate an object of abstract type 'VFlacSampleLoader::FStream' s_flac.cpp:41: note: because the following virtual functions are pure within 'VFlacSampleLoader::FStream': /usr/include/FLAC++/decoder.h:139: note: virtual FLAC__StreamDecoderReadStatus FLAC::Decoder::Stream::read_callback(FLAC__byte*, unsigned int*) s_flac.cpp: In static member function 'static VAudioCodec* VFlacAudioCodec::Create(VStream*)': s_flac.cpp:604: error: cannot allocate an object of abstract type 'VFlacAudioCodec::FStream' s_flac.cpp:71: note: because the following virtual functions are pure within 'VFlacAudioCodec::FStream': /usr/include/FLAC++/decoder.h:139: note: virtual FLAC__StreamDecoderReadStatus FLAC::Decoder::Stream::read_callback(FLAC__byte*, unsigned int*) make[2]: *** [_____MAIN_EXE_-s_flac.o] Error 1
Thats because you're basing your 1.23.1 version on a devel SRPM/cvs base it on the FC-6 SRPM/cvs But as said with 1.23.1, with the software renderer. The tracer for the scepter behaves funny even at level 1 of the hexen demo. I'll send upstream a message about this in a couple of minutes.
Wart, Any success on getting 1.23.1 to run using the FC-6 srpm/cvs? As you have seen from upstreams mail upstream can't reproduce this. Also when you try 1.23.1 can you try with strict aliasing disabled, add these 2 lines to the spec above %configure: export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" export CXXFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"
I still had the problem with FC-6 and 1.23.1. I upgraded my primary box to F-7 last night and will try to reproduce it again this evening. I'll also try with your no-strict-aliasing mods to see if it makes any difference.
I've been doing some more testing, can you reach level 2 of the hexen-demo at all (on x86_64)? For me it always crashes when I enter the portal after the teleporter. If you can, could you try the following: start vavoom press '~' to activate the console type "test_standalone 1" press '~' to hide the console start game now the trace of the scepter should work even at level2
(In reply to comment #9) > I've been doing some more testing, can you reach level 2 of the hexen-demo at > all (on x86_64)? For me it always crashes when I enter the portal after the > teleporter. I've never had a problem with that. Works for me on both FC6-x86_64 and F7-x86_64. > If you can, could you try the following: > start vavoom > press '~' to activate the console > type "test_standalone 1" > press '~' to hide the console > start game > now the trace of the scepter should work even at level2 I'll give it a try once I get my mock setup working again in F-7.
(In reply to comment #10) > (In reply to comment #9) > > I've been doing some more testing, can you reach level 2 of the hexen-demo at > > all (on x86_64)? For me it always crashes when I enter the portal after the > > teleporter. > > I've never had a problem with that. Works for me on both FC6-x86_64 and F7-x86_64. > I just found out that it is the setting of test_standalone 1, that causes this :(
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > I've been doing some more testing, can you reach level 2 of the hexen-demo at > > > all (on x86_64)? For me it always crashes when I enter the portal after the > > > teleporter. > > > > I've never had a problem with that. Works for me on both FC6-x86_64 and > F7-x86_64. > > > > I just found out that it is the setting of test_standalone 1, that causes this :( I started a game without test_standalone set, progressed to the start of level 2, saved the game, then set test_standalone and restarted. This did indeed fix the problem on F-7 x86_64. Though the game crashed a few minutes later (which I'm trying to reproduce with a stack trace)
I've been using test_standalone a bit more, and it seems that it fixes the missing graphics problems, but does indeed cause the game to crash whenever entering a portal. If I reset test_standalone to 0, enter the portal, then set test_standalone back to 1, then things seem ok.
Created attachment 156003 [details] backtrace from portal crash Here is the gdb backtrace generated when vavoom crashes upon entering a portal.
Created attachment 156007 [details] error message when entering a different portal This time when I entered a portal I got a different error. This was even with test_standalone set to 0. It appears that there may be a 'clus1msg' lump missing from one of the wad files.
Hi Wart, Thanks for all the looking into this, but I think this is firmly on upstreams radar, and I think it would be best to let upstream handle this. So for now I'm just waiting for upstream to fix this, if that doesn't happen within a few weeks, then we can try to fix it ourselves.
Upstream has just released 1.24 which fixes this. Its available in both rawhide and in F7 updates-testing, as soon as it hits F7 updates proper I'll build it for Fc-6 too. You can greatly speed this up by testing the F7 updates-testing version for me. Notice that the F7 test update not be available until signed by rel-eng, when that happens bodhi should add a comment to this bug saying its available.
I'll give this a thorough test first thing after work. Hmm... maybe I need to leave work early today? :)
vavoom-1.24-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
So far the version in updates-testing (vavoom-1.24-1.fc7.x86_64) looks good. I ran into one 'Divide by zero' error that I'm trying to reproduce in a debugger, but I wouldn't consider it a blocker unless I manage to reproduce it.
The problem in comment #15 still occurs. However, this portal is the final portal in the demo, so the game would end here anyway. I found the missing lump in the retail version of the game, and patched it into the demo wad. The only thing this missing lump provides is some end-of-level text. It would be nice if the demo iwad included this lump, but it's not critical in my opinion.
Thanks. I'll push this to updates then. About the comment 15 issue, can you send a somewhat more detailed version upstream? Then they can maybe at a workaround. Upstreams mail is: vavoom _AT_ vavoom-engine _DOT_ com
vavoom-1.24-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.