Re: NEW: games/chocolate-doom
On Thursday 13 December 2007 05:49:41 Antti Harri wrote: > Hi, > > there's already games/prboom, so why another Doom-engine? Chocolate Doom and PrBoom have very different goals. PrBoom intends to add many features and remove many limits. Chocolate Doom intends to behave as much like the original DOS Doom executables (often called "vanilla Doom") as possible (no extra features, original limits), and be as compatible as possible (savegames, demos, configuration files are compatible between vanilla and Chocolate). This is useful for mappers intending to make vanilla compatible maps (which means pretty much every Doom source port would be able to run it, along with the original vanilla Doom), to run and record demos that other ports (such as PrBoom) can't do, for nostalgic reasons, etc. -- Mike
NEW: games/chocolate-doom
From the Chocolate Doom README: > Chocolate Doom is a Doom source port which aims to behave as closely > as possible to the original DOS Doom executables. > > Chocolate Doom aims to: > > * Be compatible with DOS Doom demos > * Be compatible with DOS Doom configuration files > * Be compatible with DOS Doom savegames > * Be compatible with DOS Doom bugs > * Provide the same "feel" as DOS Doom (display and input should behave >the same) > * As far as possible, provide all the same features that are available >using the DOS version. This is my first port... please test. Chocolate Doom should be architecture-portable (has been run on Linux/amd64 and Solaris/sparc). As I no longer use OpenBSD on my main desktop, I will probably not be around to continually update the port, I can't be the maintainer. -- Mike chocolate-doom.tar.gz Description: application/tgz
ZSNES 1.51
Hi, I've noticed ZSNES hasn't been updated in years, but I don't really know how to update it myself (I've tried, but it always fails at compiling at various ports; knowing emulator authors, it's probably filled with Windows and/or Linux-specific code anyway). I'm CCing this to both the official maintainer and the mailing list because I don't know if he's even still around anymore. Usual improvements are expected, increased compatibility, more features, etc (and a *real* NTSC emulation mode that's to die for).
can't play FLAC on Audacious
I don't seem to be able to play any FLAC files in Audacious anymore, OpenBSD-current snapshot on 2007-08-09 installed. When attempting to do it, a dialog pops up saying that they are in an unsupported format.
pidgin-2.1.0p0 cannot compile
Hi, I'm using an OpenBSD snapshot from 2007-08-06, and when I'm trying to update pidgin, it ends up like this: cc -O2 -pipe -o .libs/finch gntaccount.o gntblist.o gntconn.o gntconv.o gntdebug.o gntft.o finch.o gntidle.o gntnotify.o gntplugin.o gntpounce.o gntprefs.o gntrequest.o gntsound.o gntstatus.o gntui.o -pthread -Wl,-E -pthread -Wl,-E -L/usr/local/lib -L/usr/X11R6/lib -L./libgnt/.libs -lgnt -lpanel -L../libpurple/.libs -lpurple -lxml2 -lm -lz -lgthread-2.0 -lgmodule-2.0 -ldbus-glib-1 -lgobject-2.0 -lglib-2.0 -liconv -lintl -ldbus-1 -pthread -lncurses -Wl,-rpath,/usr/local/lib /usr/local/lib/libpurple.so.0.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libpurple.so.0.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libpurple.so.0.0: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libxml2.so.9.6: warning: strcat() is almost always misused, please use strlcat() gntaccount.o(.text+0x71d): In function `update_user_splits': : undefined reference to `purple_account_user_split_get_reverse' gntaccount.o(.text+0x16df): In function `finch_accounts_show_all': : undefined reference to `gnt_window_present' gntaccount.o(.text+0x19ab): In function `finch_accounts_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntaccount.o(.text+0x1aa8): In function `finch_accounts_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntblist.o(.text+0x11d1): In function `selection_activate': : undefined reference to `gnt_window_present' gntblist.o(.text+0x28ee): In function `draw_tooltip_real': : undefined reference to `gnt_text_view_set_flag' gntblist.o(.text+0x2d17): In function `key_pressed': : undefined reference to `gnt_tree_is_searching' gntblist.o(.text+0x4d3c): In function `blist_show': : undefined reference to `gnt_window_present' gntconv.o(.text+0x10dc): In function `finch_create_conversation': : undefined reference to `gnt_text_view_attach_pager_widget' gntdebug.o(.text+0x40d): In function `finch_debug_window_show': : undefined reference to `gnt_window_present' gntdebug.o(.text+0x80a): In function `finch_debug_window_show': : undefined reference to `gnt_text_view_attach_pager_widget' gntft.o(.text+0x3ff): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_width_ratio' gntft.o(.text+0x422): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x445): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x468): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x48b): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x837): In function `finch_xfer_dialog_show': : undefined reference to `gnt_window_present' gntnotify.o(.text+0xfde): In function `finch_notify_searchresults': : undefined reference to `gnt_tree_set_column_title' gntplugin.o(.text+0x7e7): In function `finch_plugins_show_all': : undefined reference to `gnt_window_present' gntpounce.o(.text+0xa8): In function `populate_pounces_list': : undefined reference to `purple_pounces_get_all_for_ui' gntpounce.o(.text+0x1b08): In function `finch_pounces_manager_show': : undefined reference to `gnt_window_present' gntpounce.o(.text+0x1cb5): In function `finch_pounces_manager_show': : undefined reference to `gnt_util_set_trigger_widget' gntpounce.o(.text+0x1d9f): In function `finch_pounces_manager_show': : undefined reference to `gnt_util_set_trigger_widget' gntprefs.o(.text+0x4b4): In function `finch_prefs_show_all': : undefined reference to `gnt_window_present' gntstatus.o(.text+0x2d4): In function `finch_savedstatus_show_all': : undefined reference to `gnt_window_present' gntstatus.o(.text+0x43d): In function `finch_savedstatus_show_all': : undefined reference to `gnt_tree_set_column_width_ratio' gntstatus.o(.text+0x56b): In function `finch_savedstatus_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntstatus.o(.text+0x64f): In function `finch_savedstatus_show_all': : undefined reference to `gnt_util_set_trigger_widget' collect2: ld returned 1 exit status gmake[3]: *** [finch] Error 1 gmake[3]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386/finch' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386/finch' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/net/pidgin (line 2063 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/net/pidgin (line 1373 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/net/pidgin (line 1861 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop
QEMU 0.9.0 cannot do warmboot
Hi, I noticed that with the current QEMU in the ports, I cannot do warmboots, the system appears frozen (I need to do system_reset from the monitor). This is probably easiest to reproduce with FreeDOS, the "FDAPM /WARMBOOT" command issues the instruction, but "FDAPM /COLDBOOT" still works fine. I cannot check at the moment, but I'm fairly sure than vanilla QEMU on Linux does not have this problem, nor did QEMU 0.8.2 (with OpenBSD 4.1) have it. Running on OpenBSD-current snapshot from August 1.
DOOM engines and possible SDL_mixer bug
When playing either PrBoom or Chocolate Doom, they always crash when starting DOOM 2 MAP02 or Ultimate DOOM E2M1. For PrBoom, I've tried both the packaged version and the latest, 2.4.6, from source; for Chocolate Doom, I installed 0.1.4 from source. I have SDL's libraries installed from packages, I am running OpenBSD/i386 3.9-release. Internally, both engines are quite different; PrBoom being the spawn of Boom, which was based on DOSDOOM (port back to MS-DOS), which was based on LxDoom (the version id released in source form, for Linux). Chocolate Doom, striving to be closest to the original MS-DOS DOOM 1.9 engines, instead had its development branched off of the original LxDoom source release, in order to immediately forget about feature bloat. It seems odd that both games have the same crash, thusly. Running in gdb, this is the result of Chocolate Doom crashing when attempting to enter Episode 2 of Ultimate DOOM: [Switching to process 22344, thread 0x868e1000] 0x072981c7 in _Mix_InitEffects () from /usr/local/lib/libSDL_mixer.so.3.0 I've no programming experience in C, and I also don't know for sure if this report in GDB really means that SDL_mixer has a bug. I've thought of trying a newer version of SDL, but I don't see any way to remove the existing SDL packages without also removing things that depend on it (though I suppose, they will need to be compiled again due to dynamic linking troubles; and I wouldn't really care to spend hours doing so). Any thoughts or solutions on this?
