return to castle wolfenstein port
Here's a quick and dirty port of return to castle wolfenstein which was just open sourced a few days ago. It's i386 only right now due to the codebase. There's a few problems that I've noticed so far: - the game uses oss for sound but it doesn't work for some reason. seems to be related to either DSP_CAP_TRIGGER or DSP_CAP_MMAP. - performance is spotty. it's either 4 or 40 fps on an atom 1.66ghz + intel 945. this game was released in late 2001 and the minimum requirements were 400mhz cpu + 16mb vram so i'd think it should be quite speedy on modernish budget hardware. - the game crashes when you die. it's probably something silly with dlopen()/dlclose() but i haven't looked at it yet. Let me know if you notice anything else. rtcw.tar.gz Description: Binary data
Re: return to castle wolfenstein port
Jolan Luff wrote: Here's a quick and dirty port of return to castle wolfenstein which was just open sourced a few days ago. It's i386 only right now due to the codebase. There's a few problems that I've noticed so far: - the game uses oss for sound but it doesn't work for some reason. seems to be related to either DSP_CAP_TRIGGER or DSP_CAP_MMAP. - performance is spotty. it's either 4 or 40 fps on an atom 1.66ghz + intel 945. this game was released in late 2001 and the minimum requirements were 400mhz cpu + 16mb vram so i'd think it should be quite speedy on modernish budget hardware. - the game crashes when you die. it's probably something silly with dlopen()/dlclose() but i haven't looked at it yet. Let me know if you notice anything else. While compiling the port, I recognized there was sth. dumping core: release-x86-OpenBSD-/game/game/g_combat.c:1: warning: -malign-loops is obsolete, use -falign-loops release-x86-OpenBSD-/game/game/g_combat.c:1: warning: -malign-jumps is obsolete, use -falign-jumps release-x86-OpenBSD-/game/game/g_combat.c:1: warning: -malign-functions is obsolete, use -falign-functions [perl] build_funcs() Building functions table in /home/ports/pobj/rtcw-1.31/RTCW-SP-GPL/src/game Abort trap (core dumped) gdb -c game/extractfuncs.core unix/extractfuncs GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd4.8... Core was generated by `extractfuncs'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libc.so.56.0...done. Loaded symbols for /usr/lib/libc.so.56.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x02bc6f4d in kill () from /usr/lib/libc.so.56.0 (gdb) bt #0 0x02bc6f4d in kill () from /usr/lib/libc.so.56.0 #1 0x02c293e3 in __stack_smash_handler (func=0x3ce0 DumpReplaceFunctions, damaged=-809731879) at /usr/src/lib/libc/sys/stack_protector.c:89 #2 0x1c0014e7 in DumpReplaceFunctions () at /home/ports/pobj/rtcw-1.31/RTCW-SP-GPL/src/extractfuncs/out/src/extractfuncs/extractfuncs.c:289 #3 0x672f656d in ?? () #4 0x6e75665f in ?? () #5 0x65645f63 in ?? () #6 0x682e7363 in ?? () #7 0x1c000d00 in __register_frame_info () Previous frame inner to this frame (corrupt stack?) it also doesn't seem to pick up CFLAGS and the like from mk.conf, therefore the backtrace is probably not much useful. Sebastian
Re: return to castle wolfenstein port
On Sun, Aug 15, 2010 at 12:41:40AM -0700, Jolan Luff wrote: Here's a quick and dirty port of return to castle wolfenstein which was just open sourced a few days ago. It's i386 only right now due to the codebase. There's a few problems that I've noticed so far: - the game uses oss for sound but it doesn't work for some reason. seems to be related to either DSP_CAP_TRIGGER or DSP_CAP_MMAP. - performance is spotty. it's either 4 or 40 fps on an atom 1.66ghz + intel 945. some common audio drivers like azalia and uaudio don't support mmap(). trigger should be ok if used correctly. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: return to castle wolfenstein port
Jolan Luff wrote: Here's a quick and dirty port of return to castle wolfenstein which was just open sourced a few days ago. It's i386 only right now due to the codebase. There's a few problems that I've noticed so far: - the game uses oss for sound but it doesn't work for some reason. seems to be related to either DSP_CAP_TRIGGER or DSP_CAP_MMAP. - performance is spotty. it's either 4 or 40 fps on an atom 1.66ghz + intel 945. this game was released in late 2001 and the minimum requirements were 400mhz cpu + 16mb vram so i'd think it should be quite speedy on modernish budget hardware. - the game crashes when you die. it's probably something silly with dlopen()/dlclose() but i haven't looked at it yet. Let me know if you notice anything else. It crashes on startup, it shortly switches to the 640x480 resolution, screen goes blank, I see the mouse arrow, then it crashes. Its on my libretto u100. Intel graphics card. Let me know if you need more information. Sebastian Wolf 1.41 OpenBSD-i386 Aug 15 2010 - FS_Startup - Current search path: /home/sebastia/.wolf/main /usr/local/rtcw/main/sp_pak4.pk3 (21 files) /usr/local/rtcw/main/sp_pak3.pk3 (14 files) /usr/local/rtcw/main/sp_pak2.pk3 (232 files) /usr/local/rtcw/main/sp_pak1.pk3 (1342 files) /usr/local/rtcw/main/pak0.pk3 (4775 files) /usr/local/rtcw/main -- 6384 files in pk3 files execing default.cfg couldn't exec language.cfg execing wolfconfig.cfg execing autoexec.cfg Hunk_Clear: reset the hunk ok Bypassing CD checks - Client Initialization - Cmd_AddCommand: map_restart already defined - Initializing Renderer --- - Client Initialization Complete - - R_Init - ...loading libGL.so: Initializing OpenGL display ...setting mode 3: 640 480 Using XFree86-VidModeExtension Version 2.2 XF86DGA Mouse (Version 2.0) initialized XFree86-VidModeExtension Activated at 640x480 Using 8/8/8 Color bits, 24 depth, 8 stencil display. GL_RENDERER: Mesa DRI Intel(R) 852GM/855GM GEM 20100328 2010Q1 x86/MMX/SSE2 Initializing OpenGL extensions ...GL_S3_s3tc not found ...ignoring GL_EXT_texture_env_add ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array ...GL_NV_fog_distance not found XF86 Gamma extension initialized GL_VENDOR: Tungsten Graphics, Inc GL_RENDERER: Mesa DRI Intel(R) 852GM/855GM GEM 20100328 2010Q1 x86/MMX/SSE2 GL_VERSION: 1.3 Mesa 7.8.2 GL_EXTENSIONS: GL_ARB_copy_buffer GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_half_float_pixel GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shading_language_120 GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_cull_vertex GL_EXT_compiled_vertex_array GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_framebuffer_blit GL_EXT_framebuffer_object GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_3DFX_texture_compression_FXT1 GL_APPLE_client_storage GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_APPLE_object_purgeable GL_ATI_blend_equation_separate GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_MAX_TEXTURE_SIZE: 2048 GL_MAX_ACTIVE_TEXTURES_ARB: 4 PIXELFORMAT: color(24-bits) Z(24-bit) stencil(8-bits) MODE: 3, 640 x 480 fullscreen hz:N/A GAMMA: hardware w/ 0 overbright bits CPU: rendering primitives: single
Re: return to castle wolfenstein port
On Sun, Aug 15, 2010 at 04:24:51PM +0200, Sebastian Reitenbach wrote: Jolan Luff wrote: Here's a quick and dirty port of return to castle wolfenstein which was just open sourced a few days ago. It's i386 only right now due to the codebase. There's a few problems that I've noticed so far: - the game uses oss for sound but it doesn't work for some reason. seems to be related to either DSP_CAP_TRIGGER or DSP_CAP_MMAP. sorry to hijack ... --- sound initialization --- - Sound Info - sound system is muted 1 stereo 30912 samples 16 samplebits 1 submission_chunk 22050 speed 0x8e332000 dma buffer not looked at the code, but this looks like quake startup messages. you can probably steal the sndio backend from games/quake. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: return to castle wolfenstein port
On Sun, Aug 15, 2010 at 04:24:51PM +0200, Sebastian Reitenbach wrote: Jolan Luff wrote: It crashes on startup, it shortly switches to the 640x480 resolution, screen goes blank, I see the mouse arrow, then it crashes. Its on my libretto u100. Intel graphics card. I'm not totally sure what it could be since it starts up fine here. I believe the default is 32bit color so if you're running with less you could try fiddling with the graphics options in ~/.wolf/main/wolfconfig.cfg: seta r_colorbits 32 = 0 seta r_fullscreen 1 = 0 Let me know if you need more information. To be honest, I probably won't try too hard to fix any bugs. It seems the ioquake3 people are already working on modernizing it. I just wanted to see if I could get it running until something more usable comes along.
Re: return to castle wolfenstein port
On Sun, Aug 15, 2010 at 03:05:42PM +, Jacob Meuser wrote: not looked at the code, but this looks like quake startup messages. you can probably steal the sndio backend from games/quake. Thanks for the pointer. This is actually quake3-based but the sound code still looks mostly the same.
Re: return to castle wolfenstein port
Excerpts from Jolan Luff's message of Sun Aug 15 12:06:52 -0700 2010: On Sun, Aug 15, 2010 at 04:24:51PM +0200, Sebastian Reitenbach wrote: Jolan Luff wrote: It crashes on startup, it shortly switches to the 640x480 resolution, screen goes blank, I see the mouse arrow, then it crashes. Its on my libretto u100. Intel graphics card. I'm not totally sure what it could be since it starts up fine here. I believe the default is 32bit color so if you're running with less you could try fiddling with the graphics options in ~/.wolf/main/wolfconfig.cfg: seta r_colorbits 32 = 0 seta r_fullscreen 1 = 0 Let me know if you need more information. To be honest, I probably won't try too hard to fix any bugs. It seems the ioquake3 people are already working on modernizing it. I just wanted to see if I could get it running until something more usable comes along. with regards to colorbits, just in my experience since i waste my time with games and openbsd far too much (games and unix in general, is where this comes from actually) but i thought i'd note to people trying to pinch out a bit more performance that going 16-bit doesn't -always- actually help. this applies more to what your actual x server is set to so setting 16-bit in-game won't see this as much; however i've found for opengl accelleration i used to think 'hey, less bits to have to use=more speed!' until one day i for whatever reason tried 24bit in my xconf and suddenly quake3 was running far faster. it seems to have to do with opengl and the extra bits enables your alpha channels, and most video adapters then do this in an accellerated manner, henceforth many opengl games run best when you use the full depth. again, this is just an aside, not really adding too much but if anyone is looking for more speed i am definitely always checking various ways with openbsd on my thinkpad t41p to squeeze out a couple more fps. after the recent gcc move or xserver 1.8 update or maybe even acpi (wish i took the time to figure out -exactly- what it was, but i don't want to make an ass of myself theorizing it was one thing when the real smarties laugh ;)) i have found major increases of speed in all areas of X, from opengl games playing much smoother all around to EXA working very well and making my openbsd workstation feel just as responsive as any other *nix-based workstation. openbsd is not that 'slow careful os' anymore! i still feel its very careful, but the right roads have been taken and now we have the best of anything. without the crappy code to get more speed lacking proper understanding too :) okay end of rant, i'll definitely be testing this as soon as i get home :D cheers! -ryan
ajaxterm not working
Hello, I tried www/ajaxterm and it is not working. I just only started it and tried to connect directly with Firefox 3.6.8 from our ports. I also tried it from http://anyterm.org/demos.html and it is not working either. Does it work for you in FF 3.6.x ? jirib
Re: New port: sysutils/dtpstree
On Sun, 15 Aug 2010 18:43:30 +0200 Henrik Hellerstedt hen...@hellerstedt.com wrote: On Sat, Aug 14, 2010 at 10:38, Douglas Thrift douglas...@gmail.com wrote: On 7/25/2010 11:03 PM, Douglas Thrift wrote: Hello, I would appreciate any comments on my port. Thanks! works on aug 11 amd64 snapshot /Henrik Hi Henrik, With reports like this on specific ports, you should post them to the ports@ mailing list and cc the submitter/maintainer. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: return to castle wolfenstein port
On Sun, Aug 15, 2010 at 12:10:22PM -0700, Jolan Luff wrote: On Sun, Aug 15, 2010 at 03:05:42PM +, Jacob Meuser wrote: not looked at the code, but this looks like quake startup messages. you can probably steal the sndio backend from games/quake. Thanks for the pointer. This is actually quake3-based but the sound code still looks mostly the same. ah ok. games/openarena would be even closer then ;) -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: NEW/UPDATE: games/ioquake3
Excerpts from Ryan Freeman's message of Sat May 02 02:42:32 -0700 2009: hello ports@ attached is an updated port from my original 'random svn checkout' port, thankfully they finally released a new complete version, 1.36. builds and runs/plays great here on i386. -ryan bump! just thought i'd revisit this and inform that i still use this port after over a year and through all snapshots, its only become better. present day sees quake3 running smooth as silk on my t41p, next to no sound issues (aucat -l -v 103 -b 1024 -z 512) and i regularly use it to play the urban terror mod. i will reattach for convenience sake, any additional comments at this time? -ryan ioquake3.tgz Description: GNU Unix tar archive
