zdoom WIP/RFC ( sources included )

[yoshi314]

ZDoom is an actively developed project based off GPL release of sources for id software's Doom engine. It can run pretty much all doom1/2-based games ( doom, doom2, heretix, hexen, strife, doom1 and doom2 from doom3 BFG edition ) and some unofficial doom based games ( chex quest, freedoom, action doom, etc).

http://zdoom.org/About

ZDoom does not require openGL - it's a software based engine, only utilizing 2d acceleration. I'm planning to package the openGL variant (GZdoom) as well in a couple of days.

Current problems / things i am unsure about :

- dependencies in .dep are for GTK2 build for now. gtk is only used to display a visual dialog if you have multiple valid game data files and haven't explictly selected which one to play through command line parameters. Doesn't seem really worth making a gtk2 build because of it.

making two builds for gtk and non-gtk zdoom atm.

- it's not possible to build non-SSE variant of zdoom at the moment. something is broken in upstream svn, and i've reported it. i probably will have to wait until it's resolved to submit the extension.

- game can statically link against fluidsynth (a midi playback engine) or use system one. i've opted to use system one.

- game uses FMOD library version 4.26 (not packaged yet). so i've included it into the package. it's not yet compatible with newer FMOD releases, so it will most likely have to stay bundled into the package ( should i do an SCM then ? )

- path to fluidsynth's soundfont *.sf2 file is hardcoded in the executable and will have to be altered (it looks under /usr/share/ at the moment ). lack of such file will not prevent zdoom from working.

fluidsynth soundfont path can be specified through variable.

- fluidsynth soundfont file has to be yet provided. i found a way to build public-domain sf2 that the game expects to find, but the resulting soundfont file is ~150MB (unpacked), and probably could go into a different package.packaged a generic soundfont

( reference : https://aur.archlinux.org/packages/fluidr3/ )

Build scripts for zdoom that i used (building straight off svn) : http://dl.dropbox.com/u/3873935/zdoom-src.tar.gz for people who want to play around with it.

The problem is - should i link statically against fluidsynth and include the soundfont file and make it all into scm, or is a classical extension more reasonable?

[curaga]

For the hardcoded path, does it work with a symlink? Then you could do a normal tcz, dynamically linking to fluidsynth, with instructions in the info file on where to place/link a soundfont file.

[yoshi314]

For the hardcoded path, does it work with a symlink? Then you could do a normal tcz, dynamically linking to fluidsynth, with instructions in the info file on where to place/link a soundfont file.

i think it would work fine.

i am just unsure where to put such file, so that i can patch the hardcoded path in advance. it's not critical to gameplay, will only prevent midi playback (although i think FMOD can play midi by itself, it might just sound badly).

on my gentoo box they're in

Code: [Select]

/usr/share/sounds/sf2/FluidR3_GM.sf2
/usr/share/sounds/sf2/FluidR3_GS.sf2

perhaps i shoud just do the same, with /usr/local/share/sounds/sf2 .

edit: i packaged the soundfont in separate tcz. works fine through symlinks from tce mounts. i'll post the dropbox link to it or something (it's fairly big, ~120MB), once i get it uploaded.  those soundfonts can be also used through timidity with other apps.

also, I modified the build scripts to fix the sf2 path : http://dl.dropbox.com/u/3873935/zdoom.tar.gz

edit2: after short back-and-forth with zdoom devs, it turns out that SSE cmake variable enables sse autodetection. zdoom will still work on non-sse cpus when built with SSE=ON cmake variable.

edit3: i've put build scripts on https://github.com/yoshi314/misc , for the curious. I think i'll submit the extensions today. One for GTK and one for non-GTK build (although GTK makes little difference in zdoom actually).