Refresh pull #1
Open
Refresh pull #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
and "Line" column narrower. The "Filename" columns weren't wide enough for many script filenames
Double-clicking an entry opens the script at the correct line. Single-clicking the breakpoint symbol in the list removes the breakpoint, and so does selecting the breakpoint in the list and pressing the Del key.
- Send scriptlist on connect. - upped version info
but it's still a bit wonky with DPI-scaling I also made the rect calculations a bit more intuitive and removed a misleading comment in my breakpoint list code
If a key is pressed whichs SDL_Keycode isn't known to Doom3 (has no corresponding K_* constant), its SDL_Scancode is mapped to the corresponding newly added K_SC_* scancode constant. I think I have K_SC_* constants for all keys that differ between keyboard layouts (which is mostly printable characters; F1-F12, Ctrl, Shift, ... should be the same on all layouts, which means that e.g. SDL_SCANCODE_F1 always belongs to SDLK_F1 which the old code already maps to Doom3's K_F1). What's extra nice (IMO) is that when Doom3 requests a *localized* name of the key (like for showing in the bindings menu), we actually use the name of the SDL_Keycode that *currently* belongs to the scancode, and esp. the "Western High-ASCII characters" (ISO-8859-1) supported by Doom3 like Ä or Ñ are displayed correctly. (I already implemented a very similar hack in Yamagi Quake II and reused the list of scancodes) This should fix most of the problems reported in #323
so far they were handled the same as their Left counterparts
It's set to 0 by default (which is the original behavior), if set to 1, SDL2 will grab the keyboard, so Alt-Tab or the Windows Key etc will not be handled by the operating system but by dhewm3 (=> you can bind the Windows key like any normal key and it won't open the start menu)
If in_ignoreConsoleKey is set, the console can only be opened with Shift+Esc, not `/^/whatever, so you can easily type whatever character is on your "console key" into the game, or even bind that key. Otherwise, with SDL2, that key (KEY_SCANCODE_GRAVE) always generates the newly added K_CONSOLE. in_kbd has a new (SDL2-only) "auto" mode which tries to detect the keyboard layout based on SDL_GetKeyFromScancode( SDL_SCANCODE_GRAVE ). Wherever Sys_GetConsoleKey() is called, I now take the current state of Shift into account, so we don't discard more chars than necessary, esp. when they keyboard-layout (in_kbd) is *not* correctly set. (TBH the only reason besides SDL1.2 to keep in_kbd around is to ignore the char generated by the "console key" in the console..)
The `const char* filename` arg is passed from idProgram::CompileText(), where it's from idProgram::filename - and that filename can get modified in idCompiler::NextToken() when it calls gameLocal.program.GetFilenum() and if the idStr grows and reallocates for that modification, the filename pointer becomes invalid. So store `filename` in an idStr and use that when logging the compile time.
and scale the breakpoint dots accordingly - now they don't looked all squashed anymore. I think ResizeImageList() is more correct now, at least this helped with the breakpoint dots.
and remove humble store from README, they don't sell Doom3 anymore
and print a message when libcurl has been found
as long as it's chars Doom3 supports, i.e. it can be converted to ISO-8859-1 also renamed kbdNames to _in_kbdNames to reduce likelyhood of clashes (as it can't be static)
so far the code assumed that "result.color" is always used directly, but the ARB shaders allow creating an alias with the aforementioned syntax. So turn that into an variable-alias for dhewm3tmpres.
and fix a typo in a comment in the shader gamma injection code
The problem was that negative values (from dhewm3tmpres.xyz) were passed to POW, and POW doesn't have to support negative bases, according to ARB_fragment_program.txt, and Intels Linux drive apparently doesn't, see also https://gitlab.freedesktop.org/mesa/mesa/-/issues/5131 Using MUL_SAT instead of MUL to clamp the value that gets passed to POW afterwards to [0, 1] fixes the problem without any disadvantages.
Passing the -mone-byte-bool flag when building for PPC on OS X overrides the defaults so that sizeof( bool )==1
CMAKE_SYSTEM_PROCESSOR used to be broken, CMake "fixed" it by redefining its meaning (from "Target CPU" to "Host CPU except when crosscompiling"). On Windows it always prints the host CPU, on Linux it at least made trouble in chroots and when running 64bit kernels with 32bit userlands (this used to be not totally uncommon on x86 before distros completely switched to amd64, and apparently Raspbian/Raspberry Pi OS does this on RPi4, see #267) Thankfully gcc and clang support "-dumpmachine" to print their (default) target system, so use that instead (MSVC already had a special case). On the upside, this allows getting rid of the MinGW special case. I hope this also works with Apple Clang..
- Fix build with SDL <=2.0.3 SDL_GetGlobalMouseState was introduced in 2.0.4 (which doesn't support OSX 10.5 or older) - Don't include execinfo.h on Mac OS X 10.4 This file isn't included in the 10.4 SDK - Use custom typedef for PFNGLSTENCILOPSEPARATEPROC on OSX 10.4/10.5 because the system OpenGL headers for those versions don't have it
glStencilOpSeparateATI() should behave exactly the same as glStencilOpSeparate() so supporting it is easy enough and might help some people with hardware or drivers that don't support OpenGL 2.0, like the Mac OSX versions for PPC.
the newline in ${cc_dumpmachine_out} was a bit ugly
cleaner than only setting it in CopyDepthbuffer()
needs SDL2 and GL_ARB_debug_output
before it displayed the float values from the depth buffers as byte-wise RGBA values, which looked weird and wasn't super helpful.. now it's displayed as luminance float (i.e. one float representing greyscale), and transformed in the same way the TDM particle shader transforms the depth values to doom units (and then scaled back to 0..1, with 1 representing 3000 units)
so when the shader writes a debug value as a color, I get to see that color
turned out the whole problem with soft particles what that the vertex shader used vertex.attrib[8] instead of vertex.texcoord (and with nvidia drivers those are equivalent) I integrated the shader source into the c++ code so I don't have to ship glprogs/soft_particles.vfp
r_skipDepthCapture is now called r_enableDepthCapture, and instead of being a bool it's now an int with -1 meaning "enable if soft particles are used"
if this is not set, using fminf() actually calls that libm function, if it is set, a CPU instruction that calculates the minimum is generated instead. likely similar for other functions. not sure if this causes trouble anywhere, but I don't think we rely on NaN or INF?
by default it's still compiled into the executable
this avoid breaking the game DLL ABI (framework/DeclParticle.h is part of the SDK), and for now doesn't make a difference, because that keyword was introduced by TDM and thus is only used in their particle defs. When we break the game ABI/API anyway (probably for high FPS support), this commit can just be reverted
Implement Soft Particles (and capturing depth buffer), based on old The Dark Mod code
the base game entry is now called "Doom 3 (base game)" instead of "dhewm3", which should be more obvious, and the d3xp entry now reads "Resurrection Of Evil (d3xp)" instead of just "d3xp", which certainly is clearer. d3xp now is also always second in the list (if installed) Added the freshly supported perfected_roe and sikkmodd3xp mods to the list of mods that need fs_game_base d3xp set, so they can be started from the menu. also added an entry for r_gammaInShader to Configuration.md
or at least if weaponDepthHack is set. That somehow broke muzzle flash effects in Dentonmod, see dhewm/dhewm3-sdk#36
The previous commit didn't fix the issue for the pistol and only was a workaround anyway. So I reverted that and fixed the issue properly. The underlying issue is that the particle's material sets the texture matrix (with "translate" or "scale" or whatever), and the soft particle rendering code (and shader) didn't take the texture matrix into account. Now it does, in a similar way as the interaction shader code. Fixes dhewm/dhewm3-sdk#36
When applying the currently configured graphics quality preset (it's set in the `com_machineSpec` CVar and applied with the `execMachineSpec` command, or by using the menu), now soft particles are disabled for all quality presets except for ultra, because this feature has a noticeable impact on performance with some (slower) GPUs.
what a lame 1000th commit :-p
and set the date for 1.5.4 and mention that Soft Particles can slow down rendering
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refresh codebase from newest code