Hello, i submit a new ebuild for Vavoom, a 3D Engine capable to run Doom Series, Heretic, Hexen and Strife. It adds features like colored lightning, high resolution, OpenGL support, a powerful language to describe game logic (Vavoom C) and many other cool things... Tested on x86 and amd64 system, i've tried only SDL version, but Vavoom supports also Allegro Libraries. Feel free to try :) Some known issue: - It's important to copy at least one WAD file in /usr/share/games/vavoom, making theme readable by "games" group, otherwise vavoom breaks with a segfault. - GLBSP process of hexen.wad by vavoom executable doesn't work properly, to fix this bug emerge =games-util/glbsp-2.10 and run glbsp /usr/share/games/vavoom/hexen.wad -o ~/.vavoom/hexen.gwa before starting the game - for some unknown reason, timidity support is disabled, when you start a game for the first time. Edit ~/.vavoom/basev/<game>/config.cfg, find the line s_timidity "0" and change it to s_timidity "1" - To use MP3 or OGG music files, put theme in /usr/share/games/vavoom/<game>/music
Created attachment 86018 [details] Ebuild for games-fps/vavoom-1.20
Created attachment 86020 [details, diff] Patch to fix glvis process bug Put this patch in files/ subdir. It fixes a problem in glvis process of WAD files.
please readd amd64 once the ebuild is in the tree
Created attachment 86437 [details] Ebuild for games-fps/vavoom-1.20 Added updated ebuild, changed src_install behavior (now install only needed files), added "dedicated" USE, for building dedicated server.
Created attachment 86438 [details] Ebuild for games-fps/vavoom-1.20 Added updated ebuild, changed src_install behavior (now install only needed files), added "dedicated" USE, for building dedicated server.
Created attachment 90377 [details] ebuild for games-fps/vavoom-1.20 Updated ebuild * Removed "sdl" USE flag, because libsdl is a necessary requirement * Added a check regarding libsdl compiled with opengl support, if "opengl" USE flag is enabled * Addes "debug" USE flag
(In reply to comment #0) > > - GLBSP process of hexen.wad by vavoom executable doesn't work properly, to fix > this bug emerge =games-util/glbsp-2.10 and run > > glbsp /usr/share/games/vavoom/hexen.wad -o ~/.vavoom/hexen.gwa > Same issue with Strife IWAD, to fix the problem run the similar command glbsp /usr/share/games/vavoom/strife1.wad -o ~/.vavoom/strife1.gwa
Created attachment 90874 [details] ebuild for games-fps/vavoom-1.20.ebuild Updated ebuild * fixed MAD support dependency on AMD64 (requires emul-linux-x86-medialibs) * revised dependencies for AMD64 systems (will be installed only required packages) * on AMD64, FLAC support will be disabled even if "flac" USE is enabled, because emul-linux-x86-medialibs lacks of flac libs
Created attachment 90875 [details] ebuild for games-fps/vavoom-9999 (SVN version) Added ebuild for SVN version of Vavoom The SVN code seems to be highly unstable, compile at your own risk :)
Created attachment 92646 [details] ebuild for games-fps/vavoom-1.21.1 Updated ebuild with new version For Changelog, look at website Not it compiles natively on AMD64 (with attached patch)
Created attachment 92647 [details, diff] compilation patch for AMD64 Compilation patch for AMD64 (regarding vcc issue)
Created attachment 92745 [details] ebuild for games-fps/vavoom-1.21.1 added "models" USE, for using 3D models ( see bug #141736 for related ebuild )
Created attachment 93212 [details] ebuild for games-fps/vavoom-1.21.1 Updated ebuild, it includes some patch for OpenAL compilation + Glbsp problem
Created attachment 93213 [details, diff] patch for openal compile error Added patch for vavoom-1.21.1: it fixes the error when compiling with "openal" USE enabled
Created attachment 93214 [details, diff] patch for glbsp problem with hexen IWAD Added patch for glbsp issue with Hexen IWAD: it fixex glbsp+glvis process issue of Hexen IWAD.
Created attachment 93750 [details] ebuild for games-fps/vavoom-1.21.1 Updated ebuild, for using merged patch
Created attachment 93751 [details, diff] various fixes for vavoom-1.21-1 Merged patch for following fixes: - Vcc compilation on AMD64 (already posted) - Building with OpenAL support (already posted) - glbsp/glvis process with Hexen IWAD (already posted) - Statusbar visualization (new patch)
Created attachment 93996 [details, diff] gcc4 compiling fixes for vavoom-1.21.1 Added patch for gcc4 compiling fixes
Created attachment 93997 [details] ebuild for games-fps/vavoom-1.21.1 Updated ebuild for vavoom-1.21.1 that includes patch for gcc4 compiling fixes
Created attachment 93998 [details] ebuild for games-fps/vavoom-9999 (SVN version) Updated ebuild for games-fps/vavoom-9999 (SVN version) Changed src_compile() and src_install() behaviour to follow SVN changes
Created attachment 94445 [details] ebuild for games-fps/vavoom-1.21.2 New version released (includes fixes of previous version)
Created attachment 95638 [details] ebuild for games-fps/vavoom-1.21.2 Updated ebuild with some minor changes/fixes
Created attachment 97585 [details] vavoom-1.21.2.ebuild tidied ebuild for 1.21.2 version - added "music" USE flag, that installs Enhanced OGG music (see bugs.gentoo.org/148427 for vavoom-music ebuild)
Created attachment 97586 [details] vavoom-9999.ebuild (SVN version) tidied ebuild for 9999 (SVN) version aligned with 1.21.2 contents
Created attachment 98927 [details] vavoom-1.21.2.ebuild Updated ebuild for vavoom-1.21.2 Added "tools" USE flag, it enables installation of some modding utility (see the postinst log) Changed RDEPEND to PDEPEND
Created attachment 98928 [details] vavoom-9999.ebuild Update ebuild for vavoom SVN version Aligned with 1.21.2 changes
Created attachment 100878 [details] vavoom-1.22.ebuild New version released. Just renamed the ebuild 8)
Created attachment 101353 [details] vavoom-1.22.ebuild Tidied ebuild, especially the dependencies and the default shared path. I haven't tried building it with allegro. The Makefiles themselves strip the executables, which is tricky to turn off.
Created attachment 101362 [details] vavoom-1.22.ebuild Reverted back to "emake install", to prevent the installation of compilation-only files.
I've tested the game compiled with allegro libs (4.2.0-r1 in portage): all seems to work fine! :)
Created attachment 104389 [details] vavoom-1.22.1.ebuild New version released, no ebuild contents changed
Created attachment 104390 [details] vavoom-9999.ebuild Aligned SVN version with latest changes in 1.22* ebuilds
Created attachment 104932 [details] vavoom-1.22.1.ebuild The previous 1.22.1 has a horrible bug :P (it contains some dependency that exists only in my local overlay ) * Added "textures" USE flag, that pull in games-fps/vavoom-textures package dependency (see #159374 bug for the ebuild) * removed the installation of vavoom.png in $GAMES_DATADIR/vavoom folder
Created attachment 104934 [details] vavoom-9999.ebuild Updated SVN version accordingly 8)
Created attachment 104950 [details] vavoom-1.22.1.ebuild Added missing dependency to media-libs/jpeg
Created attachment 104951 [details] vavoom-9999.ebuild Added missing dependency to media-libs/jpeg
I've made some change to current 1.22.1 ebuild: - added a boring (but IMHO useful) check for a correct configuration of graphic/sound/music support - choose default SDL backend if both "allegro" and "sdl" USE flags are enabled, or if both are disabled - added a check for vavoom-music support (Vavoom must be built with OGG/Vorbis support, so "vorbis" USE flag must be enabled" - fixed dependencies - fixed configure Feel free to test it 8)
Created attachment 107835 [details] vavoom-1.22.1.ebuild
Created attachment 110097 [details] vavoom-1.22.1.ebuild Fixed missing parenthesis on conditional dependencies
Created attachment 114704 [details] vavoom-1-22.1.ebuild * Added "-opengl" switch to desktop entry if "opengl" USE flag is enabled (so the game starts with the hardware renderer, if called from WM/DE menu) * fixed RDEPEND (it must includes ALL DEPEND items)
Created attachment 114706 [details] vavoom-9999.ebuild * Aligned SVN live ebuild to 1.22.1 contents * Changed KEYWORDS="-*" to KEYWORDS=""
Created attachment 120143 [details] vavoom-1.23.ebuild Bump to new 1.23 version WARNING: - this ebuild needs the two following patches - for 3D models is neeeded vavoom-models-1.4 or greater (see relevant bug for new ebuild)
Created attachment 120145 [details, diff] vavoom-1.23_amd64_fix.diff Small patch to fix a startup error on AMD64 archs
Created attachment 120146 [details] vavoom-1.23_gcc-4.1.2_fix.diff Small patch to fix a build error using gcc-4.1.2 (stable on Gentoo since some time)
Created attachment 120148 [details] vavoom-9999.ebuild Updated version for SVN "live" ebuild
Maybe I'm just a newb...but: $ patch vavoom-1.23.ebuild < vavoom-1.23_amd64_fix.diff patching file vavoom-1.23.ebuild Hunk #1 FAILED at 375. 1 out of 1 hunk FAILED -- saving rejects to file vavoom-1.23.ebuild.rej can't find file to patch at input line 13 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- source/vclass.cpp 2007/04/27 18:01:49 2191 |+++ source/vclass.cpp 2007/05/18 16:27:42 2241 -------------------------- File to patch: user@helix /home/user/v $
nevermind.. newb I am.
(In reply to comment #47) > nevermind.. > > newb I am. > :) You must put the .diff in files/ subdir (they're used by the "epatch" functions in the ebuild)
Created attachment 121294 [details] vavoom-1.23.1.ebuild Bump to version 1.23.1 (plus some changes) - previous 1.23 patches are obsiously included - now the client is *ALWAYS* built, instead the dedicated server is built is "dedicated" USE flag is enabled - happy heavy tidyup (thanks a lot to #gentoo-sunrise guys) - pkg_setup less verbose during "sanity check" pass - some fixes /me sends a prayer to Games Herd: "please consider putting this ebuild in Portage tree, i think is quite stable and ready to use for most users" 8)
Created attachment 121296 [details] vavoom-9999.ebuild Synced SVN live build contents with 1.23.1 changes
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/games-fps/vavoom
(In reply to comment #51) > This is now in the sunrise overlay. You can find it at: > > http://overlays.gentoo.org/proj/sunrise/browser/reviewed/games-fps/vavoom > Uhm... the right URL is http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-fps/vavoom/
Created attachment 122586 [details] vavoom-1.24.ebuild Version bumped to 1.24 (ebuild comes from Sunrise Overlay)
Created attachment 122587 [details] vavoom-9999.ebuild Updated SVN live ebuild from Sunrise Overlay
Created attachment 122732 [details] vavoom-1.24.ebuild - Added 'asm' USE flag, that enables use of (faster?) assembly code for rendering (it only applies to x86 archs) - added patch for Makefiles to get rid of executable wrappers
Created attachment 122734 [details] vavoom-9999.ebuild Same things for SVN live ebuild :)
Created attachment 122735 [details, diff] vavoom-makefile_nowrapper.patch Required patch for Makefiles (put it in files/ subdir :P )
Created attachment 122750 [details] vavoom-1.24.ebuild Fixed 1.24 ebuild (it requires vavoom-models >=1.4.1 )
Created attachment 122752 [details] vavoom-9999.ebuild Fixed SVN live ebuild (it requires vavoom-models >=1.4.1 )
Created attachment 127280 [details] vavoom-9999.ebuild Update SVN live ebuild: - Added 'wxwindows' USE flag, to enable installation of graphical launcher, based on WxWidgets toolkit (see http://vavoom-engine.com/forums/viewtopic.php?t=1093 for further details)
Please do not move this ebuild to the tree until this issue is fixed: CVE-2007-4535 [1]: The VStr::Resize function in str.cpp in Vavoom 1.24 and earlier allows remote attackers to cause a denial of service (daemon crash) via a string with a negative NewLen value within a certain UDP packet that triggers an assertion error. [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4535 The latest upstream release and the ebuild in Sunrise are still vulnerable. For questions please cc me on this bug.
...and these: CVE-2007-4534 [2]: Buffer overflow in the VThinker::BroadcastPrintf function in p_thinker.cpp in Vavoom 1.24 and earlier allows remote attackers to execute arbitrary code via (1) a long string in a chat message and possibly (2) a long name field. CVE-2007-4533 Format string vulnerability in the Say command in sv_main.cpp in Vavoom 1.24 and earlier allows remote attackers to execute arbitrary code via format string specifiers in a chat message, related to a call to the BroadcastPrintf function. [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4534 [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4533
These bugs has been fixed in current SVN code, in revision 2684-2686: http://vavoom.svn.sourceforge.net/viewvc/vavoom?view=rev&sortby=date&revision=2684 http://vavoom.svn.sourceforge.net/viewvc/vavoom?view=rev&sortby=date&revision=2685 http://vavoom.svn.sourceforge.net/viewvc/vavoom?view=rev&sortby=date&revision=2686 I provide a patch (with updated ebuild) for Vavoom 1.24 that includes these fixes.
Created attachment 132340 [details] vavoom-1.24-r1.ebuild Updated ebuild for Vavoom 1.24 (that applies the fixes to reported vulnerabilities)
Created attachment 132341 [details, diff] 1.24-vulnerabilities.patch Patchset for vulnerability fixes
Created attachment 132952 [details] vavoom-1.25.ebuild Bump to version 1.25. This version includes the fixes for previously reported vulnerabilities.
Created attachment 132954 [details] vavoom-9999.ebuild Updated dependencies (vavoom-models >= 1.4.2 needed) for SVN live ebuild
Created attachment 137756 [details] vavoom-1.25.ebuild Added patch to solve a compiling failure with =media-libs/flac-1.2*
Created attachment 137757 [details, diff] vavoom-1.25_flac-1.2_fix.patch Patch for above issue.
Created attachment 141736 [details] vavoom-1.26.ebuild Bump to version 1.26 (submitted ebuild includes some improvements/fixes made in sunrise overlay)
Created attachment 142349 [details] vavoom-9999.ebuild Updated version for SVN live ebuild. Upstream has switched the build system to CMake 8)
Created attachment 142350 [details, diff] vavoom_cmake_build.patch Required patch for latest SVN live ebuild.
Created attachment 142500 [details, diff] vavoom_cmake_build.patch Update Cmake patch to reflect upstream SVN changes (implemented custom DATADIR and BINDIR)
Created attachment 142673 [details] vavoom-1.26.ebuild Fixed 1.26 ebuild (removed unneeded patch that broke ebuild unpack process), and introduced EAPI feature like in SVN live ebuild.
Created attachment 148886 [details] vavoom-1.27.ebuild Version bump to 1.27 (and mark as obsolete previous patch files, because they aren't necessary anymore)
Created attachment 148888 [details] vavoom-9999.ebuild Updatet also SVN live ebuild
Created attachment 157689 [details] vavoom-1.28.ebuild Version bump
Created attachment 170775 [details] ebuild for vavoom-1.29 Version bump. Added vavoom-progs (is use-flag needed?).
Created attachment 170835 [details] ebuild for vavoom-1.29 Update. Use-flag 'progs' is added for vavoom-progs.
Created attachment 171217 [details] vavoom-1.29.ebuild Slightly and modified version of 1.29 ebuild. - No, the "progs" USE flag is useless. The progs are already installed in pk3 data files, so i've removed it. - Implemented EAPI2 "USE conditional dependencies" feature, to reduce ebuild size and complexity (>=sys-apps/portage-2.2* required)
Some trubles with paths: !!! dobin: utils/bin/acc does not exist !!! dobin: utils/bin/fixmd2 does not exist !!! dobin: utils/bin/vcc does not exist !!! dobin: utils/bin/vlumpy does not exist Is this bug, or my own truble?
PS ebuild from fresh sunrise
Created attachment 184901 [details] CMAKE_IN_SOURCE_BUILD=true CMAKE_IN_SOURCE_BUILD has been set to true to avoid some errors with path.
Created attachment 187639 [details] vavoom-1.30.ebuild Version bump. Included Jan's fix, and forced enabling of some USE to improve the default installation of Vavoom (EAPI 2 rulez 8-) )
Created attachment 187640 [details] vavoom-9999.ebuild Update live ebuild accordingly
Vavoom 1.31 is released http://www.doomworld.com/vb/doomworld-news/50413-vavoom-1-31-released/
Created attachment 233793 [details] vavoom crash report Recent upgrade to gcc 4.4.3 and Vavoom now fails to run. Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.10.1-r1, 2.6.27-gentoo-r8 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r8-x86_64-AMD_Opteron-tm-_Processor_246-with-gentoo-1.12.13 Timestamp of tree: Tue, 01 Jun 2010 05:15:03 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA dlj-1.1 PUEL Q3AEULA ut2003" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe -ggdb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=k8 -O3 -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://gentoo.mirrors.tds.net/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /usr/local/portage" SYNC="rsync://thetangos/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acl acpi alsa amd64 artworkextra avahi avi berkdb bzip2 cairo cdda cdparanoia cdr cli cracklib crypt cups cxx dbus device-mapper directfb divx divx4linux dlloaders dri dvd dvdr eds encode esd exif fbcon ffmpeg firefox flac fortran gb gdbm gdu gif gmedia gnome gnome-keyring gpm gstreamer gtk gtkhtml guile hal hbci iconv imagemagick imlib java jpeg jpeg2k lame libg++ libwww live mad mikmod mmx mmxext modules motif mp3 mpeg mudflap multilib nautilus ncurses network nls nptl nptlonly nsplugin ntp nvidia ofx ogg openal opengl openmp openxr oss pam pcre pdf perl png policykit pppd python quicktime readline reflection sdl seamonkey session sndfile spell spl sqlite sse sse2 ssl svg sysfs tcpd tetex tidy tiff timidity tng truetype unicode usb userlocales vcd vorbis wma wmf wmp xinerama xml xorg xprint xulrunner xv xvid zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I'm attaching a small rev bump for 1.32. It also includes two dependency changes: 1. Dependency for libsdl will now allow either ALSA or OSS support. Previously ALSA was required by the ebuild, but OSS works fine. In my case I need to use OSS (emulation) because the ALSA backend suffers from some pretty nasty distortion with some games. 2. timidity is only required if the music package is NOT installed. So, the dependency for sdl-mixer will now only require timidity support if the 'music' USE flag is disabled. And by the way, what's the status of getting this into portage? It works great, and seems to be much more reliable than doomsday (which freezes every time I try to enable high res textures). Regardless, thanks for all the work on this.
Created attachment 236793 [details] games-fps/vavoom-1.32.ebuild
(In reply to comment #89) > Created an attachment (id=236793) [details] > games-fps/vavoom-1.32.ebuild > Tried the 1.32-ebuild after vavoom-1.30 began crashing on start-up after the latest gcc update. While it builds, the program fails on start-up as did the 1.30 version. Fails with a Segmentation Violation. Trying to go back to the 1.30 ebuild completely fails. The ebuild posted here and in the sunrise overlay all fail to even compile anymore. I am on mostly stable amd64. I guess no one is working on this package anymore :(
I just tried reinstalling the 1.32 ebuild I posted last month and it (still) works fine for me on amd64. What are your USE flags, and how are you launching it? Maybe you're trying to use some feature that I don't. Here's how I compiled mine: [ebuild R ] games-fps/vavoom-1.32 USE="flac mad models openal opengl sdl textures vorbis -allegro (-asm) -debug -dedicated -mikmod -music -tools -wxwindows" And I launch with: vavoom -opengl -openal -nolan -heretic where heretic is, of course, replaced by the appropriate game. If you're doing something different, can you try building/playing with these options and see if that works?
(In reply to comment #91) > I just tried reinstalling the 1.32 ebuild I posted last month and it (still) > works fine for me on amd64. What are your USE flags, and how are you launching > it? Maybe you're trying to use some feature that I don't. Here's how I > compiled mine: > > [ebuild R ] games-fps/vavoom-1.32 USE="flac mad models openal opengl sdl > textures vorbis -allegro (-asm) -debug -dedicated -mikmod -music -tools > -wxwindows" > > And I launch with: > vavoom -opengl -openal -nolan -heretic > > where heretic is, of course, replaced by the appropriate game. If you're doing > something different, can you try building/playing with these options and see if > that works? > None of those options would allow the game to run. What did work was to change my CFLAGS to -O2 from -O3 rebuild gcc than [ebuild R ] games-fps/vavoom-1.32 USE="debug flac mad models music openal opengl sdl textures vorbis -allegro (-asm) -dedicated* -mikmod* -tools -wxwindows*" 0 kB [1] The game now runs but the 1.32 version appears extremely buggy. I am having troubles with the graphics stuttering and freezing in different maps and almost all of the doors that require the blue, red or yellow keys once opened will not reopen. So if you open one and don't go through it you can't reopen the door. If you go through the door you can't get back out. A few maps work fine but most do not. While the 1.30 version was extremely stable and worked very well on my system, I can no longer build it. It will fail when making if using wxwindows and if not it fails, [ 63%] Building CXX object source/CMakeFiles/vavoom.dir/r_tex_png.o /var/tmp/portage/games-fps/vavoom-1.30/work/vavoom-1.30/source/r_tex_png.cpp: In member function ‘virtual vuint8* VPngTexture::GetPixels()’: /var/tmp/portage/games-fps/vavoom-1.30/work/vavoom-1.30/source/r_tex_png.cpp:268: error: ‘png_set_gray_1_2_4_to_8’ was not declared in this scope make[2]: *** [source/CMakeFiles/vavoom.dir/r_tex_png.o] Error 1 make[1]: *** [source/CMakeFiles/vavoom.dir/all] Error 2 make: *** [all] Error 2 * ERROR: games-fps/vavoom-1.30 failed: * Make failed! These problems didn't pop up until gcc-4.4.3 went stable My system ran perfect using gcc-4.3.4 even using the -O3 option in my CFLAGS
(In reply to comment #92) > What did work was to change my CFLAGS to -O2 from -O3 rebuild gcc than [ebuild > R ] games-fps/vavoom-1.32 USE="debug flac mad models music openal opengl > sdl textures vorbis -allegro (-asm) -dedicated* -mikmod* -tools -wxwindows*" 0 > kB [1] > > The game now runs but the 1.32 version appears extremely buggy. I am having > troubles with the graphics stuttering and freezing in different maps and almost > all of the doors that require the blue, red or yellow keys once opened will not > reopen. So if you open one and don't go through it you can't reopen the door. > If you go through the door you can't get back out. A few maps work fine but > most do not Interesting. The -03 to -02 issue isn't terribly uncommon, though it is annoying. I use -02 by default these days so I don't have to worry about it. Running with debug enabled could introduce some of the stuttering you described. What happens if you rebuild with -debug? As for the key thing, I noticed that too in my testing, but that just involved few quick rounds of each game to verify everything worked, the upgraded textures were used, etc. I wasn't sure whether it was just me or not, and I haven't played the games since then, so I never bothered to investigate. Looks like maybe this is the bug? http://vavoom-engine.com/forums/viewtopic.php?f=8&t=3312 If so, it's been fixed in SVN.
(In reply to comment #93) > Looks like maybe this is the bug? > http://vavoom-engine.com/forums/viewtopic.php?f=8&t=3312 > > If so, it's been fixed in SVN. So I finally started playing through Doom using Vavoom, and I just ran into this bug. Yay. Since there hasn't been a newer official release containing the fix, I tracked down the code change, created a patch and updated the 1.32 ebuild accordingly. Compiling with the new ebuild should fix the problem. Odd thing, though, is that the "fix" seems to involve locked doors simply staying open once unlocked, at least in the couple doors I tested in Doom. I'm not sure if this is intentional or not, as it does fix the problem, but in a rather unexpected way. Regardless, the game is actually beatable now, so I'll call it a win. :-)
Created attachment 244625 [details, diff] locked doors patch for 1.32 (see comments 92-94)
Created attachment 244627 [details] games-fps/vavoom-1.32.ebuild (use w/ locked doors patch)
Created attachment 258606 [details] games-fps/vavoom-1.33.ebuild Updated ebuild for Vavoom 1.33. This release most noticeably removes the option for a software renderer, so OpenGL is now required. As a result, I removed the opengl USE flag and forced it on, updating the dependencies as required. I also made a few other changes to tidy things up: * Only sdl USE flag is enabled by default now; others (models, music, etc.) can/should be optionally enabled * wxwindows USE flag changed to wxwidgets * opengl disabled if and only if sdl and allegro are disabled AND dedicated is enabled * -opengl parameter removed from desktop entry as it is now always enabled * removed the 1.32 locked doors patch as it should no longer be needed Unfortunately, there's also one big caveat: using Allegro instead of SDL with this ebuild WILL NOT WORK. AllegroGL is required, and while this was previously handled by the media-libs/allegrogl, that ebuild has since been removed from portage. It seems like allegro[opengl] should provide this same functionality, but the vavoom cmake fails on AllegroGL detection. I spent a while troubleshooting, but didn't have much luck. As I really don't know anything about Allegro (never even heard of it before using this ebuild), I'm giving up on it. If you need/want to use Allegro, I recommend sticking with 1.32 for now. If any devs want to take a look at fixing Allegro support in the 1.33 ebuild, I'm wide open to suggestions.
Created attachment 282773 [details] games-fps/vavoom-1.33.ebuild Updated 1.33 ebuild with jpeg dependency changed to virtual/jpeg. This removes a hard dependency on media-libs/jpeg for users who prefer to use libjpeg-turbo (which is now the default jpeg library for Gentoo).
Created attachment 324270 [details] games-fps/vavoom-1.33.ebuild small, but important, update: includes fix for compilation against latest versions of zlib.
Probably should be updated to use REQUIRED_USE
Created attachment 324274 [details] games-fps/vavoom-1.33.ebuild Updated to use REQUIRED_USE, as suggested by Mr. Bones. I changed up a bit of the logic in prepare() and compile() to leverage this, so it probably wouldn't be a bad idea to get a second set of eyes on it to make sure everything still looks right. Did a few quick tests and it seems to work well, but I can't claim to have exhaustively tested all combinations.
1.33 in sunrise
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
