Question to all Linux (and Mac) users: do you get the IWAD selection box when starting ZDoom? Does the "queryiwad" console variable work?

I'm just wondering if there is a reason why this menu entry is filtered to be Windows only. Because as far as I know, there's a GTK implementation of that widget for Linux, and an Objective-C version for Mac.

Last edited by Gez on Tue Dec 14, 2010 12:45 pm, edited 1 time in total.

Gez wrote:Question to all Linux (and Mac) users: do you get the IWAD selection box when starting ZDoom? Does the "queryiwad" console command work?

I'm just wondering if there is a reason why this menu entry is filtered to be Windows only. Because as far as I know, there's a GTK implementation of that widget for Linux, and an Objective-C version for Mac.

Yes there is and the queryiwad variable does work. I actually noticed this about a week ago but forgot to actually fix it.

Chris wrote:I would recommend getting the version recommended in the wiki directly from FMOD's site, and extracting it into the fmod/ sub-directory of ZDoom's directory (so you get, eg, zdoom/fmod/api/lib/libfmodex*.so)

Okay. I installed the package, and ran zdoom again. It crashes only when attempting to load a map, and I can navigate the main menu.

The terminal appeared to be hanging, so after about 15 minutes, I canceled the action. The attached log is the result. By the way, this is my attempt on Arch, instead of the Debian system from a few posts back. Funnily enough after installing the ZDoom packages from the AUR build system, I get the same error as compiling it traditionally. It crashed when attempting to start a episode from the main menu.

Try applying this patch: viewtopic.php?f=34&t=28055#p536876And run the debug build normally (outside of gdb, othewrwise input may get locked). When ZDoom crashes, it will automatically run gdb and dump out a crash log.

You should also try to use the latest SVN, just to make sure the problem hasn't been inadvertently fixed.

Hmm. It seems it's crashing in the texture mapping assembly code. Somewhere around the dsm8 label, it looks like. I can't say how accurate that is, but the backtraces do show that it's in 'dsm8' right before the signal handler is called. You could try seeing if it works if you disable assembly (pass -DNO_ASM=1 to cmake).