2005-05-23 * FINAL: upload for release. * web/: pages for battleteam.net * mod_doom/: tested Beta4 release again Build 1302, added Neil's arcade map and related assets to it, updated README.TXT. * BUG: remember to make doomwaddir a CVar, find the gamepath and pass that down, later. 2005-05-22 2005-05-21 2005-05-19 2005-05-18 * DOC: revisions,images * mod_doom/materials/camera.mtr: experimented with nopicmip, no dice. The mipmapping on the camera surfaces is atrocious. Later: it appears that if you use two materials (wall, GUI) with the same TGA, there might be side-effects. It also appears that if you shift focus away from a GUI, there are effects. This will need some work to sort out, postpned. NOTE: modified Neil's new camtest, some camera fixes relating to model vs. view mismatches: "model" "models/mapobjects/camera/camera01.ase" "modelAxis" "1" "flipAxis" "1" "viewOffset" "0 0 16" Later: using "scanDist" "0" to prevent sweeps from being affected. The securitycamera aiming and sweeping seems hopelessly broken. Ref: see doom3world.org "Security Cameras Tutorial - Part 2". 2005-05-17 * DOC: revisions, some more screenshots. * SETUP: trying a Virtual Desktop http://sourceforge.net/projects/virtual-desktop NOTE: Microsoft's free PowerToy doesn't install on XP64. 2005-05-16 * mod_doom/materials/camera.mtr: three wall and three GUI camera materials, sharing camera1|2|3.tga. NOTE: you can add as many cameras as you want (TGA+material+GUI), as long as you have the framerate. Confirmed with two security cameras working in parallel. * game/TerminalDoom.h|cpp: use gui->SetStateString/StateChanged to dynamically assign a GUI background image using a "gui::" variable. * mod_doom/guis/doom.gui: use background "gui::doom_framebuffer" NOTE: setting aside the issue of making sure that the required images are in memory, this mechanism allows us to dynamically swap images between GUIs. In the extreme case every GUI entity has its own GUI standard script (editor generated), and we map images and camera Views to GUI screens as desired. This still has to bypass most of the GUI and handle its own widgets etc. NOTE: this method to retreive the GUI in Init() did not work idUserInterface* pGui = uiManager->FindGui( "guis/doom/doom.gui" ); probably needs a flag or setting to enter global namespace? * mod_doom/textures/camera2.tga: added. TGA's here apparently define the image memory if you want to use multiple cameras. Attempting to use "textures/cameraView2" (defined in aaduffyTest.mtr) without the placeholder TGA yields error "can't load image: textures/dynamic/camera2" To create more cameras, duplicate the material and add placeholders. Note that "textures/cameraimg1", "textures/cameraimg2" etc. are in proc files, hacking the map file alone does not work. NOTE: cameras are expensive, but with different images we can cache camera views. We could try staggering updates, so at 60Hz there could be max 6 screens at max 10 Hz, or (e.g. multiplayer) update only the GUI image in focus or near FOV. For multiplayer the local client will only update locally visible views. * guis/cameras/cmaera_on2.gui: added for multiple views. NOTE: trying out and modified test maps from Neil, uses cam_on.gui from Delta3: windowDef CamView { background "textures/cameraView1" } and targets both a billboard and a terminal as added. * SETUP: tried "Folder Options" to associate PK$ extension type with XP's builtin ZIP, not selectable from Winblows menus. NOTE: using a game01.pk4 shortcut to game01.zip doesn't work either. Later: trying WinRAR instead. NOTE: http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/ /RegistryTips/Disable-Hide/DisableWindowsXPsbuiltinzipsupport.html says: regsvr32 /u %windir%\system32\zipfldr.dll // disable regsvr32 %windir%\system32\zipfldr.dll // re-enable If you want to use WinZIP, rename zipfldr.dll after disabling it. 2005-05-15 * DOC: screenshots from DOOM3 Alpha Labs 2/3/4 and Delta 3. NOTE: Alpha4 has a Halo-style transparent GUI example, Delta3 has the tracking camera, Alpha2 the security "camera sees player", and Alpha3 the "manipulate crane in view" setup. 2005-05-14 2005-05-13 2005-05-12 * DOC: "Looking Glass" tech report draft. 2005-05-11 * DOC: DocBook setup (using Subversion docs as template). 2005-05-02 * game/doom/d_main.cpp: missing include NOTE: Linux version does not run singletics, ticrate broken. Windows version does not have InitSprite fix, bogus errors. No fix unless there is a new SDK version. * FINAL: files ready for release - uploaded - termdoom.zip Beta3 - release DLLs and packs - termdoom_debug.zip game02.pk4 with debug DLLs - linuxdoom2005.zip standalone binary * LINUX: final release and debug builds * mod_doom/README.TXT: comments on ZIP archives. * game/doom/r_things.cpp: fix bogus warning (bool vs. boolean) * game/doom/i_sound.cpp: fix USE_X11 compile. NOTE: standalone compile for linuxdoom2005.zip * Makefile: add release pack target, for convenience. * game/doom/d_main.cpp: singletics * game/TerminalDoom.h|cpp (USE_SINGLETICS): enable ticrate CVar for Linux as well, and make sure default is correct. NOTE: this cannot be disabled on Windows, Linux time does work. * game/doom/i_system.cpp (I_GetTime): try using Doom3 timer. Later: fails, lockup just as Windows. Ignore. * game/TerminalDoom.cpp: precompiled header is needed here. * WINDOWS: final release and debug builds. * mod_doom/README.txt: ensure DOS text format, revisions. * game/doom/m_menu.h|cpp (M_MenuSound): helper, play the same sound on Lock() as mainmenu.gui on "startgame". No sound on unlocking, it just confuses. * mod_doom/sound/doom.sndshd: dedicated enter/exit sounds. * mod_doom/sound/doom/gui/: two placeholder sounds for mainmenu. NOTE: when the mainmenu.gui is executed, the DOOM1 wad file has not been loaded yet on first play, so the sounds would be missing. * mod_doom/guis/mainmenu.gui: refinements. The mod is a trap for casual users that do not know how to get to the console and exit/quit by command. Add audio feedback (gui sounds). Add a timer delay. Update the text to show that ESC is unlock key for Doom1 and exits the mod in the menu. NOTE: if "wantenter" worked in this GUI, I'd still not use it unless Doom1 lock was triggered by CR as well. Default bindings do not use it. Later: added persistent "gui::doommenu" state. NOTE: overlooked the idUserInterface Get|SetStateString|Float path - declaring a "gui::" prefix GUI variable lets game code and GUI scripts access the same state. 2005-05-01 * game/TerminalDoom.cpp: add soft clamp and ticrate CVar. Doom1 TICRATE (35Hz) is default. Set to zero to bypass for timedemo-like behavior. Not (yet) in Linux build. * game/doom/i_system.cpp: QueryPerformanceCounter etc. * game/doom/d_main.cpp (I_GetTime): different versions. * game/TerminalDoom.h|cpp (GetTimeSeconds): using the Doom3 internal sys->GetClockTicks() (see Timer.h). NOTE: embedded Doom1 is no longer locked to one update per tick under Linux. Set singletics to true if you do not want to clamp to TICRATE, or set TICRATE to 60 if you want to lock to Doom3's max. Later: however, neither of the different timer versions works under Windows, for now stick to singletics=true. * game/doom/i_main.cpp (main): exclude from MSVC compile, but keep in project file for convenience. Needed for standlone. * game/doom/p_floor.cpp: unsafe doom1boolean == bool * game/doom/r_things.cpp: unsafe doom1boolean == bool * game/doom/tables.h: disable warning C4161 * game/doom/: fix up #pragma hdrstop again NOTE: apparently have to live with GCC warning. * WINDOWS: update mod_doom/ install, source snapshot. * idlib\math\Simd_AltiVec.h: disable PPC_INTRINSICS NOTE: idLib project excluded from solution. * LINUX: final release and debug builds. Back to Windows. * game/doom/d_main.cpp: switch singletics off by default. * game/TerminalDoom.cpp: make input CVars archived. * game/doom/i_video.cpp: removed old Doom1 scaling. * game/TerminalDoom.cpp (GetMouseEvent): scaling and smoothing CVars for low pass filtering and amplifying Doom3 generated mouse events. The unsmoothed Doom3 mouse inputs generated rather choppy moves and turns in Doom1. Scaling and smootheness can be adjusted separately for X and Y. NOTE: also tried using usercmd.mx|my directly, not good. Not surprising, there is at least aliasing the two axises, no matter what else is done to the raw mickeys. 2005-04-29 * TODO: - map mx/my to key turn/move instead? no.. - check mx==my==0 codepath - clean up mod_doom/ - back to windows - windows release build * mod_doom/README.txt: edits for Beta3. * LINUX: debug build version 1299 running. Later: release build. * game/doom/d_main.cpp: remove original D_Display(), and use the refactored single-step version for USE_X11 as well. Set singletics false by default for standalone version. Later: in D_DoomLoop do not tick state if we are doing a single step wipe, to prevent initial jump forward in demo playback. Later: remove the refactored version of the blocking wipe as well. * game/doom/: fix remaining warnings, more MSC_VER conditionals, remove redundant Doom3 header includes, cut down stderr debug spew. NOTE:standalone USE_X11 and Doom3 Linux build now cleaned up a bit. * game/TerminalDoom.h (TheTerminal): forwards to keep Doom3 idlib headers out of Doom1 (for Linux). 2005-04-28 * game/idlib/precompiled.h: create a dummy for includes * game/doom/doomtype.h: type "byte" * game/doom/*.cpp: idLib precompiled include fixes, misc. NOTE: minor (dirty) fix attempts for Windows-related changes. Conditional compiles are cleaner, starting to use them. Later: standalone USE_X11 compiles and runs. NOTE: use xterm, RedHat3 gnome terminals are shite for the error flood spewed by scons/gcc. * LINUX: a few problems with SDK. - new idLib/hasing directory - warning: SDK.py hookup failed - warning: Setup.py hookup failed - mixed case screwup on game/af.h|cpp, game/ik.h|cpp. game/ai/aas.h|cpp, game/ai/ai.h|cpp - mixed case duplicates in d3xp/, same as above NOTE: last looks like a Linux-Windows-Linux problem NOTE: set TAERGET_D3XP='0' to avoid all the d3xp hassle. NOTE: cut-off for Windows for now, back to Linux. Dual boot is a pain, esp. as there is no working "save desktop" on any OS. * game/doom/m_menu.cpp: pause will release mouse as well. NOTE: pause could also unlock the player. The whole get in/out transition can use some more polish, there are other variants to try, and re-entering the game could be streamlined as well. * mod_doom/materials/terminaldoom.mtr: added. NOTE: this uses the "textures/sfx/lagometer" material from materials/sfx_multiplayer.mtr as a template. Not translucent. The "nopicmip" keyword makes the difference. BUG: the reworked UploadImage path still blends between miplevels. If you like this effect, do not use a material, just use the default parameters. * INSTALL: Windows 1299 InstallShield truly is a piece of shit, no better than the Linux installer. A utility messing with the registry has no business being this fragile. http://support.microsoft.com/default.aspx?scid=kb;en-us;290301 Later: remove the Doom 1.3 install entry, re-run the installer. Do not rename Doom3.exe (possibly other files), always copy, or the installer fails again. * game/TerminalDoom.cpp: fixed UploadImage call again. * game/Player.h|cpp: manual merge * game/PLayerView.h|cpp: manual merge NOTE: lagometer related code moved into PlayerView * renderer/RenderSystem.h: * framework/BuildVersion.h: * game/Game_network.cpp: * game/Game_local.h|cpp: * game/Game.h: copy NOTE: the entirety of 1296 to 1299 changes 2005-04-27 * INSTALL: Linux 1299 + SDK NOTE: pak007.pak4 contains the lagometer related assets - materials/sfx_multiplayer.mtr - textures/sfx/lagometer.tga see also guis/mphud.gui - windowDef Lag, "guis/assets/hud/mp/lag" Later: pak008.pk4 updates sttp.gui? Later: * WARNINGS: there is still a large number of warnings such as C4805: '==' : unsafe mix of type 'boolean' and type 'bool' C4806: '&' : 'bool' promoted 'int' cannot equal given constant and, related to angle_t, C4146: unary minus operator applied to unsigned type Ignored for now, there is no obvious harm. Feature freeze. * game/doom/doomdef.h: doom1boolean typedef and CPP. This fixes the demo1 playback bug MSVC vs. gcc. BUG: only the first demo breaks early in playback, the second and third seems fine. Later: suspected the new wipe code not suspending engine updates, but the original code exhibits the exact same behavior. Later: it's not an initial condiction either, as the first demo is broken on repeat as well. Workaround: bypass the first demo for now (on windows). Later: on Linux, the player picks up 4 shells from the first shotgun sarge, on Windows it is 8. Looks like the weapon counts as MF_DROPPED in Windows, but not in Linux, hence the larger amount. Later: Doom1's custom type boolean is int, but did not use that typedef with MSVC (.e.g. Windows' RpcNdr.h defines this type). MF_DROPPED evaluated to 0 passed into P_GiveAmmo( .., boolean ) * BUG: intermission pictures are not stretched to cover the full screen. No fix - all the splashes have fixed screen coordinates. * game/TerminalDoom.cpp: new control scheme for movement keys. NOTE: wiping usercmd moves and buttons permits me to still bind these keys, and then continuously emit Doom1 keys based on the usercmd values per frame. This works really well compared to the fake reelaseEvent. Reduced latency value to prevent tail-lag, and bind differently for menu vs. in-game, so menu repeat is clean. Strafe now works! This will also permit tracking SHIFT, ALT, CTRL for QWERTY modes, which hacks around a whole host of issues. Doom3 key repeat should be fine for regular typewriting. * game/TerminalDoom.cpp: fix UploadImage changed signature. NOTE: this codepath now used for lagometer rendering. Using TF_NEAREST and TF_LINEAR has no effect. Using TF_DEFAULT now mip-maps between the original image, and the uploaded image. It appears the original image stays as miplevel 0, and the uploaded image is the miplevel below. The effect is interesting (it could be used as a nice fade from inactive screen including ambient reflections to the active image), but the previous version was better suited for attract mode. Later: upcoming 1299 will remove parameters and just use the defaults specified in the material. Example: LAGO_MATERIAL "textures/sfx/lagometer" Retry a material instead of straight TGA on surface? * game/doom/doomdef.h: F* keys not properly covered. Bug, fixed. * sys/scons/SConscript.idLib: copy * sys/scons/scons_util.py: copy * sys/scons/scons_util.pyc: removed * game\physics\Physics_Player.cpp: copy * game\gamesys\SysCvar.h: copy * game\gamesys\Class.cpp: copy * game\Game_network.cpp: copy * game\Game_local.cpp: copy * framework\FileSystem.h: copy * game\Player.h: lots * game\Player.cpp: lots * idLib\: swap * renderer\: swap * sound\: swap * framework\BuildDefines.h: ID_ALLOW_D3XP * game\Game.h: GAME_API_VERSION 4 (from 3) * framework\BuildVersion.h: 1297 (from 1289, based on 1296 SDK) * game\gamesys\GameTypeInfo.h: kept (remoced in 1296) NOTE: see debug code in TypeInfo.cpp Later: manual upgrade - have to get subversion up and branch and track properly from a second server - dual-booting back and forth ain't helping. * INSTALL: D-1.3-1296, D-1.3-1296 SDK, d1297.zip. * mod_doom/guis/doom/mainmenu.gui: below. * mod_doom/guis/mainmenu.gui: * mod_doom/guis/intro.gui: some more fixes, showcursor. NOTE: tried a more Doom-like red on the "click" text, decided to stick to white to visually match the white Doom3 cursor (as in: feature linking aids cognitive mapping). Reworded "click" to "hit" to remove out-of-game connotations. Now bringing up Doom3 cursor on GUI onMouseEnter, hiding it onAction, another appellative element. 2005-04-26 * BUG: demos are broken, getting out of sync on windows. * game/doom/st_stuff.cpp (ST_refreshBackground): bottom 8 rows were in a nice windows-alike blue, copied too much from statusbar assembly area. * game/Player.cpp (DrawHUD): no Doom3 HUD while Doom1 mouselocked. * mod_doom/guis/doom/mainmenu.gui: below. * mod_doom/guis/mainmenu.gui: some loading screen fix-ups, making "click to play" pop up onMouseEnter and vanish onAction, make visuals of loading screen match in-game. * mod_doom/guis/assets/splash/doom.tga: replaced placeholder. Instead of (copyrighted) FinalDOOM box art, both the loading splash and the inactive screen show a darkened DOOM1 title image. The "click to start" line on the loading GUI is now also a hint - remember to click on the screen to run it. * game/TerminalDoom.h|cpp: SetFlash() takes fadeTime, we flash on activating the attract screen. * game/doom/i_video.cpp: tried and rejected nonlinear (squared) Doom3 delta to Doom1 mickey mapping for mouse control. NOTE: mouse control is somewhat jittery in Doom1, needs tuning. * mod_doom/sound/doom.sndshd: reduce min/maxDistance, for a steeper audio fall-off (sound quality and balance against Doom3 footsteps), 1/10 vs. 4/15 for STTP3. NOTE: all of the above polish items. * game/TerminalDoom.h|cpp: below. * game/Player.h|.cpp: more utility code to debug view angles. Later: fixed random view jerk at mouselock release. NOTE: so far I wiped usercmd.angles[] during freeze. The problem is that the engine still updates the true usercmd.angles, and as soon as I unfreeze, the view jumps. Instead of trying to patch up the delta ViewAngles (which depends on the call order) the simple solution is to use player->SetViewAngle( freezeView ) to continuously have the existing code fix the delta against the usercmd.angles/player->cmdAngles. There is (surprisingly) no fallout with respect to player orientation (i.e. calls like player->GetPhysics()->GetAxis() player->SetAngles() don't seem to do anything useful by default), and luckily call order works out without a frame-to-frame jitter or drift. Invariant: viewAngle == cmdAngle+deltaAngle The engine drives cmdAngle(usercmd), and enforcing a constant view will change delta as needed, hence there is no longer a transition from locked usercmd to the actual one. 2005-04-25 * game/TerminalDoom.h|cpp: * game/Player.h|.cpp: utility code to track view angles. BUG: on mouselock release, the view snaps wildly as Doom3 did not fully ignore the mickeys fed to Doom1. Later: see UpdateViewAngles, consider terminal use a cutscene? * game/TerminalDoom.cpp: hook up Doom1 argc/argv to CVar * game/doom/d_main.h|cpp: reworked argc/argv handling Later: minimally tested, no idea whether PWADs etc. will work OK. * game/doom/d_main.cpp: attempt to fix screen melt wipe. Basic idea: the melt takes a snapshot of the old and the new screen, then loops until the melt is complete. The original code blocks in D_Display() and is time-based. Refactor rendering part of D_Display() into D_DisplayScreen(). Make a copy of gutted D_Display() branched by USE_X11. Add wipeState variable and3-stage transition. Later: works. Refresh of bottom 8 rows leaves a blue bar? 2005-04-23 * TODO (optional): Improvements: - change column/row blits to true color, remove index buffer - place idSoundEmitters for proper sound spatilization Code refactoring: - finalize UiPlugin ABC interface - refactor Doom1 into UiPlugin class (multiple instances) * mod_doom/README.txt: updates, removed TODO. * mod_doom/guis/assets/doom.tga: replaced placeholder screen. * game/doom/m_menu.h|cpp: Doom3 mouse release on being in a menu * game/doom/st_stuff.cpp: translate palettes into RGB for light flash * game/TerminalDoom.cpp: add SetFlash() for light support. Later: dynamically create GUI light at guiEntity position? * game/TerminalDoom.cpp: fix mouse drift. Fix mouse buttons (fire and move forward). Add mousewheel bind switching for Doom1 weapon cycle. 2005-04-22 * game/Player.cpp (Think): view centering (by default on mouse button) disabled if we have an active GUI. Right now we center first (changing the players view) before locking - with mouse re-routed to Doom1, there is no chance of correction, and it's a nuisance anyway. Later: fixed, GUI onAction also brings up the Doom1 menu. On exiting the game the view centers, acceptable hint to user. NOTE: ESC in Doom1 could release the mouse for Doom3. In reverse, we could lock the mouse only once we enter the game itself. * game/doom/i_video.cpp: post mouse events. * game/TerminalDoom.cpp (FilterUserCmd): added back in, try freezing view angles for mouselook support. Use RouteGui code sample to calculate deltas, make them accessible to Doom1. NOTE: working mouselook, but with drift. Codepath works, we can try variants. No longer need autorepeat for turns, let's get forward move on mousebutton. * BUG: Doom1 audio needs a steeper fall-off with distance. * BUG: demo playback is broken for Doom3 WindowsXP. No standalone Windows build, hoping to avoid it. Check on porting back to Linux. Ignore for now. 2005-04-21 * game/doom/v_video.cpp: fixed V_DrawPatchFull for CREDIT, HELP1/2 etc. Now these screens are stretched to fullscreen (no lerp, just re-drawing every 5th pixel to extend 200 to 240). NOTE: special case code - the 320x200 fullscreen images are stored as two-post columns of length 128 and 72, respectively. It is certainly possible to collapse the posts into a single 200 pixel stretch and then use one of the existing scaled wall column methods on it. * game/doom/m_misc.cpp: set initial sfx volume to max., music to zero Note: useTiMidity http://timidity.sourceforge.net/ to convert GENMIDI, if so inclined (Doom1 music) * game/TerminalDoom.h|cpp: * game/doom\isound.h|cpp: provide left|right volume, channel index with sound. Later: tried to use placed idSoundEmitters (left and right each 8 for doom1 NUM_CHANNELS), couldn't get this to work. Later: sound quality is atrocious. Currently playback from guiEntity location, volume adjusted per sound (tried average of left and right, now using just the pre-separation doom1 volume). Sound sample quality. Later: conversion to 16bit WAV is unsigned to signed, quality fixed. Note: Doom3 reads samples from outside the pak file, so no need to pack them. 2005-04-19 * game\doom\m_mic.cpp: key_* not set due to #ifdef NORMALUNIX, fixes movement. * game\doom\r_data.cpp: boolean maptexture_t::masked again - needs to be 4byte for raw data texture lump read. Wall blitting bug fixed. 2005-04-18 2005-04-17 2005-04-16 2005-04-15 2005-04-14 * on the road 2005-04-13 * Beta2-windows: game/doom/ source files added to solution, various compile fixes, ignoring some warnings for now (notably unary minus on unsigned angle_t). gamex86.dll successfully linked and launched, disabled and fixed a few asserts added during conversion, had to add on patch==NULL exit to wall drawing to make it work. Later: uploaded, notifier sent to Raven. Also uploading screenshots and source. 2005-04-12 * Beta2-windows: set up a WinXP/MSVC install, copied over a branch of the source tree and mod data. 2005-04-11 2005-04-10 2005-04-09 * on the road 2005-04-08 * Beta2: uploaded, notifier sent to id guys. * mod_doom/README.txt: updates. * SDK: merged up to version 1289. Installed build 1289. * game/Player.h|cpp: removed obsolete RouteGuiKeyboard path. * game/TerminalDoom.cpp: fixed onMouseExit bug. * game/doom/i_system.cpp (I_WaitVBL|Quit): USE_X11 * game/TerminalDoom.cpp (Tick): unlock. * game/doom/d_main.cpp (D_DoomLoop): * game/doom/m_menu.cpp (M_QuitResponse): re-entrant Doom1 exit. NOTE: player now locks to terminal, unlocks on "quitting" DOOM. * game/TerminalDoom.cpp: below. * game/doom/i_video.cpp (I_GetEvent): below. * game/doom/doomdef.h: MOUSE_BUTTON1,2,3 NOTE: button support w/o buttonRelease will be similarly handicapped. TODO: enable and test Doom1 mouse support. * mod_doom/guis/doom/doom.gui: doom_lock command onAction. NOTE: trying mouse support for Doom1. That requires an explicit lock on the player (including view, at least warping or filtering), which is done by clicking (attract mode still starts with onMouseEnter). Player control is good, as is player-awareness for the terminal. To unlock we'd use either external events (e.g. damage) or exiting the terminal application (Doom1). * game/TerminalDoom.h|cpp: added IsLocked, added keyDown/Held state tracking, reworked NextEvent, switched to using domdef.h KEY_* defines. Later:inputs now working, but in-game inputs are really sluggish if I fake my "up" events on the next frame. What is the Doom3 repeat rate? Later: frame counts, not timestamps for now. NOTE: Doom3 repeats every 2nd frames (if not framerate dependent), but the lead-in delay is almost 30 frames, for a framerate of 40fps. NOTE: this also applies to mouse buttons. Sigh. * game/TerminalDoom.cpp (Init): binding all keys except <~> that I can lay my hands on, unbinding all (overriding player's config file). Later: the "kp_*"bindings in mp_vchat.cfg do not seem to work anymore? Later: mainmenu.gui has a "loadBinds" command that does not work from console? NOTE: so here I am, un-abstracting an abstraction. There is so much wrong with this it's hard to know where to start. The information I need (key code, up or down) is somewhere in idSys::Sys_GetEvent, and if the input handling was cleanly exposed in the SDK, I could save myself a lot of typing. I can intercept most keys (not NumLock, some keypad keys, ESC etc.). I can restore the old settings with "exec DoomConfig.cfg" I have to guess key up/down from frame to frame by tracking. One more lucky break, the mouse delta x,y are still coming through, so mouselook still works - I can catch the cursor arrow keys w/o locking the player's FOV/LOS. Yay. If there was a push/popBinds, I could store and restore the existing config whenever I lock. common->WriteConfigToFile might emulate that, but it is slow. Instead, I'll enforce a standard default config (if somebody wants to change that they can load and parse the player's config themselves). Later: PerformImpulse for all "_impulse*" bindings, works nicely. Later: cmdSystem->BufferCommandText for regular commands. Later: idPlayer::HandleESC() chain of responsibility - works nicely. Problem: to prevent amcro/script cheats, movement keys are not known as commands.. Solution: we bind and re-bind these keys as needed. There is a fixed set (the ones we can call directly), a default set (those bound to commands we can't execute directly) and a locked set (replacing the default set while at a terminal)... works like a charm. Later: starting to make fixed set conditonal on IsLocked() 2005-04-07 * game/TerminalDoom.cpp (convert_doom3key): attempt to reconstruct doom1 key event from doom3 usercmd. NOTE: this is not working well at all. Intercepting usercmd at the beginning of idPLayer::Think() and wiping it if we are in lock to a terminal is fine (transition in and out of lock aside), but without access to the raw keypresses we (a) cannot cover all keycodes (no QWERTY) (b) cannot detect key_up w/o a lot of state management The low level stuff in sys/sys_public.h can't be used as it is outside idSys, and generates a link error. An OS-level peek (XPeekIfEvent) is useless here as I don't have the handles and can't peek beyond the first element anyway. http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP11.HTML Plus, I do not believe DirectInput has any peek capability at all. Later: possible workarounds - editDef? hud->HandleNamedEvent("pdaPickup")? Does not work in-game (chat, takenotes.gui). Try fullscreen menu gui? No, that defeats the purpose. Use a different DoomConfig.cfg? No, not in gamecode. I can't even set the default bindings in the game DLL? Idea: use onAction to lock all input to terminal, use exit from Doom to unlock, then use mouselook for movement in game as well. That way I don't have to guess which part of usercmd.angles is actually cursor vs.mouse, and I can wipe usercmd completely and avoid the game's ActiveGui() logic - it's a user decision (for the demo). ESC key? Try idPlayer::HandleESC(). For QWERTY: rewrite DoomConfig.cfg and make it read-only. Bind everything to custom Cmd functions, then replace the entire input handling? Tried bind "a" "key_a" and it works. Tried wiping all standard binds, seems to work. Tried a generic QWERTY function, does not work (idCmdArgs does not carry the key that was pressed), so I'd need one function bound per key. * game/doom/i_video.cpp (I_FinishUpdate): I_GetEvent polling, doom keycode conversions. * game/Player.cpp: hooks (below) * game/TerminalDoom.h|cpp: track active GUI, and filter usercmds if we have an active GUI. NOTE: filter only keyboard events, i.e. moves and impulses, but let mouselook pass. The UI transition is more dirty if the user can't look around (try a mousewarp/escape gesture solution later), so we keep mouselook unaffected. 2005-04-06 * game/Player.h|cpp: experiments in input filtering idPlayer::Think(). * game/TerminalDoom.cpp (StartSound): locate the doom GUI entity and gui by name, play sounds by name. NOTE: for now, the sounds are played at the location of the game terminal. Spatialization will have to wait until moving over to Windows, this RedHat install can't recognize a sound card (naturally). * game/doom/i_sound.cpp (addsfx): use Terminal::StartSound(name) NOTE: doom1 sounds are namespaced, function concats w/ prefix. * mod_doom/sound/doom/*.wav: generated * game/doom/m_misc.h|cpp: added M_CheckFile. * game/doom/i_sound.cpp (dumpsfx): added (also WriteWAVfile). Later: only generate if not yet found. 2005-04-05 * game/doom/s_sound.cpp: below. * game/doom/doomdef.h: * game/doom/d_main.cpp: * game/doom/m_misc.cpp: * game/doom/i_sound.cpp: remove SNDSERV, SNDINTR relics. NOTE: the signal based solution never quite worked, and the soundserver is not useful. Guarded the sound code with USE_X11 for standalone, but do not have working sound under Linux, hence orphaned. * game/doom/d_main.cpp: below. * game/doom/m_menu.cpp (M_DrawReadThis1,2): see below. * game/doom/v_video.h|cpp: attempt to add fullscreen blit for CREDIT, HELP1, HELP2, TITLEPIC (to stretch 200 to 240 lines). Later: can't simply stretch patch format. NOTE: blit some other picture in the bottom rows instead... * mod_doom/guis/mainmenu.gui: below * mod_doom/guis/intro.gui: minimize. NOTE: to load map directly from MODS menu, not just commandline. * mod_doom/map/doom/doom.map: renamed light to "doom_light" (for experiments in screen-flashing light and color change). NOTE: change player angle to look at screen, light position to point outwards from screen. * mod_doom/README.txt: add commandline. 2005-04-04 2005-04-03 2005-04-02 * on the road 2005-04-01 bernd kreimeier * Beta1: uploaded, notifier sent to id guys. * mod_doom/README.txt * doom.gui: have "rect 0,0,640,480". We want 320x240 centered on the 640x480 LWO model's screen. Try 512x256 texture, containing 320x240 picture. To center, we have a shift of 96,8, so the new line would be: "rect -96,-8,512,256" // nope - too small, upper left, 25% "rect -96,-8,320,240" // nope - even smaller, not 256x256 "rect -96,-8,640,480" // nope - right size, but 256x256 "rect -96,-8,640,480" // nope - right size, but 256x256 "rect -192,-16,832,496" // ditto NOTE: "scale 1.25,2.133333" is a NOP * game/doom/i_video.cpp (I_FinishUpdate): see below. Later: BUFFERWIDTH. Need to pass imageWidth/Height with pLFB. * game/TerminalDoom.cpp: switched to 512x256 * game/doom/i_video.h|cpp: I_UpdateBlank to clear screen. * game/TerminalDoom.cpp: add Enable() switch. Add Cmd and GUI event. NOTE: CPU penalty is actually too high, hence we'll do onEnter/Exit. Later: onExit does not seem to work, possibly race condition in Player.cpp * game/doom/d_main.cpp: * game/doom/i_net.cpp: re-enable code NOTE: TryRunTics - had gutted this, used all the time! Later: fixed. Blitting works! * game/doom/Makefile: cleanup, CPP only build * sys/scons/SConscript.game (game_string): removed i_main.c, switched to *.cpp files. Minimizing use of USE_X11 in merged code. * game/doom/d_main.c: enable singletics by default (X11 is *fast* :) NOTE: D_Display does not seem to call I_SetPalette in plugin mode? Later: gutted too much of the networking/input codepath.... 2005-03-31 * sound/doom/doom.sndshd: created using sttp sounds from the guitest.sndshd file as reference. * SOUND: Doom3 uses 1 or 2 channel, 16bit OGG or WAV files at 11025, 22050 or 44100 Hz sample rate. See http://www.iddevnet.com/doom3/sounds.php DOOM1 UDS [7-2]: Soundcard Sound Effects ======================================== DS* entries in the directory refer to lumps that are sound data for systems using soundcards. This data is in a RAW format for 8-bit 11 KHz mono sound - first is an 8-byte header composed of 4 unsigned short integers: (1) 3 (means what?) (2) 11025 (the sample rate, samples per second) (3) N (the number of samples) (4) 0 Each sample is a single byte, since they are 8-bit samples. The maximum number of samples is 65535, so at 11 KHz, a little less than 6 seconds is the longest possible sound effect. http://www.gamers.org/dhs/helpdocs/dmsp1666.html NOTE: try converting to Doom3 mono 16bit WAV from DOOM1 DS mono 8bit. Music will be ignored. Target base/sound/doom/*.wav and create a shader file doom.sndshd Downloaded sources to DeuTex and XWadTools for sound conversion http://www.teaser.fr/~amajorel/deutex/ http://public.planetmirror.com/pub/idgames/source/ Bobby Prince http://www.bpmusic.com/ * game/doom/s_sound.c: * game/doom/r_things.c: * game/doom/m_misc.c: * game/doom/p_floor.c: * game/doom/p_maputl.c: warnings * game/doom/d_main.c * game/doom/doomdef.h * game/doom/dstrings.h|c * game/doom/m_menu.c * game/doom/r_main.c * game/doom/st_lib.c * game/doom/st_stuff.h|c * game/doom/i_net.c: trivially merged NOTE: merging the 320x232 branch with the doom1-in-doom3 branch. I want to compile the standalone version from the same source to debug the changes to the main loop (for external ticking), and also want the plugin version to have the near 4:3 aspect ratio. The 320x232 version also has a few bug fixes (message string length). * TODO: + merger + test loop split with USE_X11 compile 2005-03-30 2005-03-29 2005-03-28 * on the road 2005-03-27 bernd kreimeier * game/TerminalDoom.cpp: simple (singleton) glue code NOTE: the Doom1 global variables would have to be bundled in a struct or class, and all methods made members, for multiple instances. This is pretty much a mechanical rewrite and not needed for the demo. * Mapping: the 320x200 background image I use gets mapped to a 256x256 texture, and mapped on a 640x480 surface. There is stretching in the vertical (200 to 256 to 2*240 effectively) and information loss in the horizontal (320 to 256 to 640). Try using larger windowDef::rect with negative offset and 512x512 texture (see guis/assets/marscity/fullpath.tga and the script guis/marscity/transport_intro.gui, might or might not work in-game). Try using 512x256 texture to save blits (no UploadSubImage). Try expanding Doom1 to 320x240 (fullscreen and statusbar at bottom). * game/doom/d_main.c (D_DoomMain): refactor for init/tick from game DLL. 2005-03-26 bernd kreimeier * sys/scons/SConscript.game: added doom/ sudirectory. NOTE: properly I should make the doom game a DLL and dlopen() it as a plugin using the idUiPlugin interface, but that can wait. * ran into lock-up Opening IP socket: localhost:-1 because my LAN is not connected to the net/the DNS setup is broken. * mod_doom: description, resources, new art etc. ./doom.x86 +set fs_game mod_doom +map doom/doom * workaround: tried a material doom.mtr with a noclamp diffuse map, no dice NOTE: textures/common/entitygui is returned with "r_showSurfaceInfo 1" * switched to SDK 1288, new textureRepeat_t repeat = TR_CLAMP works! 2005-03-24 * guis/marscity/sttp.gui: can't edit this w/o crashing on loading savegame Every time you want to edit a script you have to start from scratch... NOTE: use WinAmp mod as basis ./doom.x86 +set fs_game mod_jukebox +map jukebox * doom1.wad: from http://doomworld.com/pageofdoom/shareware.html 2005-03-23 * game/Player.cpp (UpdateTurkey): NOTE: TerminalDoom early beginnings.... ----------------------------------------------------------------------------- bk --------