News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake SDL Version Beta
I just published a beta release of my SDL version of the Fitzquake engine. The main goal of this version is to allow Fitzquake to run on all major platforms. I provide builds for Windows, Mac OS X and Linux.

Grab them at http://www.kristianduske.com/fitzquake/

Windows and Linux users take note that you have to install SDL 1.2.10 or better.

Windows users please also be aware that this port does not do anything better on Windows than metlslimes original version. Actually, it does less, but I would still like to get your feedback because there's a chance that the official version will be switched to SDL eventually. That would go a lot smoother if we ironed out the bugs on all platforms first.

Have fun and don't forget to send in your feedback and bug reports.
First | Previous | Next | Last
Exe: 16:04:11 Jul 5 2008 
I opened 4 fitz windows for fun on my new (dualcore) PC and let the demos run. 2 windows closed after a short time with "Cache_MakeLRU: active link". 
Shit 
That's the same error people have seen on windows... once I get busy on Fitz .85, I'll try to track that one down. 
 
Totally the same error I have - a bit annoying with the random crashes (runs fine otherwise). 
0.85 Sound Fix 
Cool 
Will there be a binary for code-clueless people like me?

As noted in the Roman Wilderness thread, removing -sndspeed 44100 from my commandline seemed to make the crash go away. 
 
Played some more this morning. My fix doesn't seem to cut it *&^%! Removing "-sndspeed 44100" also borked once. Playing with both fixes i couldn't break it. .. Encouraging.

Sorry, but i can't make mac binaries, and it needs some testing anyway. 
 
You only need -sndspeed 44100 for mods/games that have 44100 Hz sounds, which to my knowledge aren't many (Nexuiz and RMQ and ???)

The fix seems to have a positive effect, I played for half an hour or so and restarted the engine a couple times too, and got no more of the Cache_makeLRU errors.

I got a segfault once, but those occur a lot more rarely. The LRU error was the bigger problem. I'll post if it does occur again :)

I did use -sndspeed 44100. 
 
-sndspeed 44100 only works for the sdl version? 
 
O_o really?

Most engines should support that. 
 
yeah, i tried to hack it into fitzquake but it kept crashing. :P 
Append 
tbh, i don't really care that much for 44khz because without some kind of support for a compressed format (like ogg, for example) if you're dumping 44khz pcm sounds in your pak file, the size can be unwieldy. 
 
Running with strace, the latest segfault produced this:

You got the nailgun
no weapon.
You get 1 rocket
FoundTarget: monster_wizard @ '-1792.0 -1376.0 -144.0' with spawnflags 1
HuntTarget: monster_wizard
You got armor
FoundTarget: monster_ogre @ '-1712.8 -937.6 -232.0' with spawnflags 0
HuntTarget: monster_ogre
You got armor
You got armor
You got armor
You got armor
FoundTarget: monster_zombie @ '-1851.8 -1188.8 -424.0' with spawnflags 0
HuntTarget: monster_zombie
FoundTarget: monster_zombie @ '-1870.1 -1235.9 -424.0' with spawnflags 0
HuntTarget: monster_zombie
FoundTarget: monster_zombie @ '-1884.7 -1155.1 -424.0' with spawnflags 0
HuntTarget: monster_zombie
FoundTarget: monster_wizard @ '-1957.6 -1054.0 -205.6' with spawnflags 1
HuntTarget: monster_wizard
FoundTarget: monster_ogre @ '-1993.7 -992.4 -232.0' with spawnflags 0
HuntTarget: monster_ogre
FoundTarget: monster_ogre @ '-1954.6 -1003.6 -232.0' with spawnflags 0
HuntTarget: monster_ogre
FoundTarget: monster_ogre @ '-1970.3 -986.7 -232.0' with spawnflags 0
HuntTarget: monster_ogre
HuntTarget: monster_wizard
FoundTarget: monster_zombie @ '-2102.1 -1495.4 -424.0' with spawnflags 0
HuntTarget: monster_zombie
]sky atsea_
FindFile: ./svn/gfx/env/atsea_rt.tga
FindFile: ./svn/gfx/env/atsea_bk.tga
FindFile: ./svn/gfx/env/atsea_lf.tga
FindFile: ./svn/gfx/env/atsea_ft.tga
FindFile: ./svn/gfx/env/atsea_up.tga
FindFile: ./svn/gfx/env/atsea_dn.tga
FoundTarget: monster_zombie @ '-2151.6 -1633.0 -424.0' with spawnflags 0
HuntTarget: monster_zombie
You receive 14 health
You got the nails
You got the shells
Warning: 1058 byte packet exceeds standard limit of 1024.
You got armor
[{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0) = 25635
fstat64(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8061000
write(2, "/home/*****/bin/rmq: line 4: 2563"..., 222/home/*****/bin/rmq: line 4: 25635 Segmentation fault ./fitzsdl_fix -w -window -width 640 -height 480 -heapsize 128000 -mem 128 -sndspeed 44100 +csqc_progname blah +sv_cheats 1 +developer 1 -game svn +skill 2 +map $1
) = 222
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, 0xbf965b58, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x8080ff5, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "\n#./tyrquake.59 -width 400 -heigh"..., 389) = 166
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, ""..., 389) = 0
exit_group(139) = ?


and I'm like, OOOOO KKKKKKK ......

what's that about the packet size? 
 
OK, I got a core dump with the debugging version.

This is what gdb says about the crash:

Core was generated by `./fitzsdl_fix -w -window -width 640 -height 480 -heapsize 128000 -mem 128 -snds'.
Program terminated with signal 11, Segmentation fault.
[New process 25978]
[New process 25979]
#0 0xb70a67b2 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
(gdb) where
#0 0xb70a67b2 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
#1 0x00000000 in ?? ()
(gdb)

It says "libGLcore.so.1" there.

Helpfully, the binary NVIDIA libraries have no debugging symbols, hence it only shows ??(). Anyway. This points to a problem with the binary NVIDIA drivers, more exactly their libGLcore.so.1 which is only available in binary form (yay for closed source).

Are you sure that all OpenGL calls in Fitzquake are clean and proper? 
 
Cache_MakeLRU is back. Sigh. 
Maybe 
I think i might be on to the problem, or at least the main one. It looks like the problem ~is~ video... or at least not sound, and caused by
excess use of the Draw_BeginDisc proc when loading uncached entities. Comment it out and see how it goes.

--- common.c.orig 2010-01-01 14:12:17.000000000 +1000
+++ common.c 2010-01-01 14:03:53.000000000 +1000
@@ -1646,7 +1646,7 @@

((byte *)buf)[len] = 0;

- Draw_BeginDisc ();
+// Draw_BeginDisc ();
Sys_FileRead (h, buf, len);
COM_CloseFile (h);

And is this line ~misplaced~ (snd_dma.c, line 235) ?

- Con_Printf ("Sound sampling rate: %in", shm->speed);

It causes FreeBSD to crash immediately. 
Cache_MakeLRU 
Anyway, Oz recons about this problem -
Well, that particular snd_sdl implementation does have locking problems, it easily shows itself on multicore or smp systems. After a few seconds of running, I got the infamous Sys_Error message "Cache_MakeLRU: active link" .... The issue shows itself regardless of the snd_dma.c fix I gave you was actually applied. I believe the thread issues you see are actuallly due to that locking problems. In our uhexen2, all such locking problems are fixed and it requires several serious changes in the in the sound layer.
 
 
> multicore or smp systems. After a few seconds of running, I got the infamous Sys_Error message "Cache_MakeLRU:

aaah.

Running two cores here. That could be it.

Ozkan has a point, it seems.

hexen2 to the rescue... seems to be a pattern...

Will see what the Draw_BeginDisc thing does when I'm fully awake... :) 
Dang 
I need to stop using ">" for quoting outside of the trac. 
 
[Cache_MakeLRU] Running two cores here. That could be it.
I have a smp enabled C2D too, but have never seen the "Cache_MakeLRU" error. Perhaps the latest SDL builds have addressed the issue ?
Will see what the Draw_BeginDisc thing does
This fix has been great for me. Not a single crash :>. Oz mentioned he disabled the spinning disc in hexen2 ages ago... for some reason. 
 
Running libsdl 1.2.14. 
1.2.13 here 
 
And is this line ~misplaced~ (snd_dma.c, line 235) ?

- Con_Printf ("Sound sampling rate: %in", shm->speed);

It causes FreeBSD to crash immediately.


I can't really comment on that. Why is that loadas8bit stuff even necessary - has anybody ever used "-simsound" on the command line? I didn't even know that existed.

I would just comment out the -simsound check and the whole if(fakedma) thing. I would say that it is unnecessary.

Then I'd put the Con_Printf sound sampling rate into the -sndspeed check.

Sorry, can't really post code here, it always cuts off long lines soomehow and I don't know if there is a formatting option for code (i3d is a lot better in that regard).

Basically remove the parts where it checks for "-simsound" and remove the if (fakedma) parts and the whole crap that belongs to it.

Unless someone has a very good explanation why the check for -simsound is needed.

And for the love of the gods, use tabs instead of spaces. 
 
+// Draw_BeginDisc ();

still get MakeLRU. 
Might Fix It.. 
MakeLRU is a thread thing, and not the same problem i had. But... I just upgraded to SDL-1.2.14... played through 1 level and got my first MakeLRU error! Downgraded to 1.2.13... three levels, no problem. In the 1.2.14 changelog there's mention of some thread "fixes". 
 
the plot thickens... 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.