- Polygons will be clipped to bottomclip. If this is zero or below, they
will be clipped to the bottom of the screen instead. This keeps the
polygons from overwriting the status bar border for sofware 2D. The
hardware version ignores it, since it always draws the status bar border
every frame.
- check and use WGL_EXT_swap_control_tear extension. The above change makes the system always wait for a full vsync with a wglSwapInterval of 1, so it now uses the official extension that enables adaptive vsync. Hopefully this also works on the cards where the old setup did not.
The reason for this is that the macOS version uses a deprecated API and in order to correct this, the file needs to be compiled as Objective-C++ which requires a different extension.
After doing some profiling it was very obvious that this has better performance than client arrays. Persistent buffers are still better, though, especially for handling dynamic lights.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
This means that the varargs functions themselves are now responsible for parsing them into DrawParms.
This was done because DrawTextV made a blanket assumption that every single vararg has the size of a 32 bit integer and caused crashes when anything else was passed. It also failed to eliminate any tag that is incompatible with text display. These will now abort DrawText and trigger an assert.
In order to avoid passing around tag lists, DrawTextV needs to parse everything itself and then pass a fully initialized structure to DrawTexture. This cannot be done if all variants require a varargs tag list.
Apparently the only reason for the old approach was the 'hw' parameter which was never used.
- Converted P_MovePlayer and all associated variables to floating point because this wasn't working well with a mixture between float and fixed.
Like the angle commit this has just been patched up to compile, the bulk of work is yet to be done.
This cuts down on as much message noise as possible, outputs everything to a file specified as a parameter and then quits immediately, allowing this to run from a batch that's supposed to check a larger list of files for errors.
Multiple outputs get appended if the file already exists.
# Conflicts:
# src/CMakeLists.txt
# src/p_setup.cpp
# src/r_defs.h
# src/version.h
This only updates to a compileable state. The new portals are not yet functional in the hardware renderer because they require some refactoring in the data management first.
According to Blzut3:
The issue happens when the fullscreen resolution is the same as the desktop resolution. In this case WM_DISPLAYCHANGE doesn't occur so the editor never appears. This appears to be fixable by also catching WM_STYLECHANGED since at the very least the window caption will appear/disappear.
- The old algorithm is something I threw together that produced decent,
but not spectacular results since it had a tendency to waste space by
forcing everything onto "shelves".
The new packer is the Skyline-MinWaste-WasteMap-BestFirstFit algorithm
described by Jukka Jylanki in his paper *A Thousand Ways to Pack the Bin - A
Practical Approach to Two-Dimensional Rectangle Bin Packing*, which can
currently be read at http://clb.demon.fi/files/RectangleBinPack.pdf
This is minus the optimization to rotate rectangles to make better fits.
The RichEdit control can become quite slow with large amounts of text being added constantly.
Since anything that gets added while the game is running can't be seen anyway unless a fatal error is produced, it buffers the text locally now, without any processing, and only adds it to the RichEdit control in case a fatal error causes the control to be displayed again.
- Fixed: If you enlarged the game window (in windowed mode) so that the
window is bigger than the selected resolution, the menu would still take
its inputs from the portion in the upper left that matched the
resolution.
- GetSystemMetrics can lie about the window border sizes, so we can't
trust it if the executable is flagged as Vista-targetting
(default behavior for VS2012/2013).
Conflicts:
src/CMakeLists.txt
src/b_think.cpp
src/g_doom/a_doomweaps.cpp
src/g_hexen/a_clericstaff.cpp
src/g_hexen/a_fighterplayer.cpp
src/namedef.h
src/p_enemy.cpp
src/p_local.h
src/p_mobj.cpp
src/p_teleport.cpp
src/sc_man_tokens.h
src/thingdef/thingdef_codeptr.cpp
src/thingdef/thingdef_function.cpp
src/thingdef/thingdef_parse.cpp
wadsrc/static/actors/actor.txt
wadsrc/static/actors/constants.txt
wadsrc/static/actors/shared/inventory.txt
- Added register reuse to VMFunctionBuilder for FxPick's code emitter.
- Note to self: Need to reimplement IsPointerEqual and CheckClass, which
were added to thingdef_function.cpp over the past year, as this file no
longer exists in this branch.
GLEW has two major problems:
- it always includes everything, there is no way to restrict the header to a specific GL version
- it is mostly broken with a core profile and only works if all sanity checks get switched off.
There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers.
For the dynamic light buffer today's changes take care of that problem.
For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated.
To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension.
If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions.
This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver.
In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying.
A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
- we need to check all GL versions when trying to get a context because some drivers only give us the version we request, leaving out newer features that are not exposed via extension.
- added some status info about uniform blocks.
- reactivate alpha testing per fixed function pipeline
- use the 'modern' way to define clip planes (GL_CLIP_DISTANCE). This is far more portable than the old glClipPlane method and a lot more robust than checking this in the fragment shader.
- added version check for Windows 8. I also would have liked to add 8.1 but due to some incredibly stupid changes in the version API it's no longer possible to reliably retrieve the correct Windows version for later builds.
- commented out output of Cr0NpxState for floating point state because this variable was renamed in most recent Windows headers.
- added CMAKE option to generate assembly output for release builds.
- added my CMake-based project directory to .gitignore.
- Added I_GetLongPathName(). It wraps the Win32 API's GetLongPathName().
DArgs::CollectFiles() now calls this for every argument it processes, so
any arguments passed using short file names will be converted to long
file names. This is mainly of interest so that savegames will never
record the short file name, which can change based on what else is in
the directory.
- removed gl_vid_compatibility. With the bump to 1.4 no hardware requiring this flag is supported anymore.
- disabled 16 bit framebuffers for the same reason. As a conseqence all code for rendering without stencil could also be removed.
- Use functions in gitinfo.cpp to retrieve the strings from gitinfo.h so
that changes to gitinfo.h only require recompiling one file instead of
several.
defaults to 200. Setting it to 0 will restore the previous behavior of having no frame rate
limit. Note that vid_maxfps 35 is NOT the same as cl_capfps 1. cl_capfps caps the frame rate
by tying the video update directly to the game timer. With vid_maxfps 35, the video update and
game timer are running on separate timers, and results will not be as good as with cl_capfps 1,
which uses only one timer.
SVN r3872 (trunk)
it's far too early to be used with I_FatalError. (But since this should always be available on
every Windows version after 95, this should be a non-issue.)
- Make unknown OS versions default to Windows 2000 instead of Windows 95.
SVN r3802 (trunk)
the one responsible for the palette change.
- Fixed: DDrawFB::CreateSurfacesComplex() starting tries at 2 instead of 0 is not "debugging cruft"
since it counts down, not up. (Partially reverts r3195)
SVN r3733 (trunk)
- Fixed: Don't access class metadata at all in DObject::PropagateMark if the type system is shutdown.
- Fixed: If FCompressedMemFile::Reopen() fails, then it would try to double-free memory when deleted.
SVN r3688 (trunk)
decided there was nothing to draw. In practical terms, this means that if your weapon is
completely invisible, the game would not draw anything outside of the main play area because
the scissor test would be left on for the entire frame and not just the weapon's quad.
Making the call to SetStyle() before the scissor check is enough to fix this.
SVN r3412 (trunk)
also decided to compile some other shaders slightly differently, too.)
- Fixed: The InGameColormap had been designed without taking alpha into consideration.
As the least likely parameter to be used, desaturation has been moved into a constant
register to make room for the alpha parameter to live in the vertex's color value.
SVN r3208 (trunk)
- Fixed: When DDrawFB::Lock() has to recreate resources, it left the LockCount at 0. This causes
problems if something else locks it before it is unlocked, because the second locker will
think it is the first. This happens in R_RenderViewToCanvas(). See DDrawFB::PaletteChanged()
for the most common reason why Lock() would need to recreate resources.
- Fixed: DDrawFB::CreateSurfacesComplex() had debugging cruft left in that skipped all but the
last attempts.
- Fixed logging of video debug info to a file to not multiply define dbg.
SVN r3195 (trunk)
- allow setting 'Shadow' as default fuzz effect
- changed CVAR conversion that strings 'false' and 'true' get evaluated as integers 0 and 1 respectively so that changing boolean CVARs to int does not destroy their values.
SVN r3076 (trunk)
- set 'cursor' as default for Action Doom 2. Doom's bunny is probably not the best thing here...
- made cursor user-settable in the menu.
SVN r2855 (trunk)
Windows sends some when the mouseis ungrabbed even when it does not move.
This caused the currently selected menu item to get unselected.
SVN r2803 (trunk)
grabbed. At least if the pointer is visible when the debugger break happens, I don't worry
about it getting stuck hidden. (Note that that seems to be related to Alt+Tabbing out of the
game and coming back. I wish I knew what's going on.)
SVN r2497 (trunk)
example. Do not modify the window class pointer. I still had an instance where I was left with
an invisible pointer no matter where I moved it, so hopefully this takes care of that. (edit:
it doesn't.)
SVN r2496 (trunk)
- Two tweaks to raw mouse input to make it better behaved when the window suddenly has focus
removed (e.g. because of a debugger break):
* Keep the pointer centered in the window, as for Win32Mouse. Even though it's not generating
any traditional input events, it's still moving all over the screen. e.g. If we have focus
yanked away and you're pressing the right mouse button as it happens, you can suddenly find
yourself with a popup menu open.
* Use SetCursorState() like the other mouse modes instead of ShowCursor() to hide the
pointer. This way, we don't need to worry about being stuck with trying to use the system
with an invisible pointer, because only the game window will be pointer-less.
SVN r2495 (trunk)
since the screenwipe speedup fixes also mean that this function no longer operates directly
with the front buffer, but rather with a copy that is not letterboxed.
SVN r2355 (trunk)
some other application already has it. While technically this is a failure, the device is
still created, so we can continue using it anyway.
SVN r2326 (trunk)
Since we're already sending everything to a rich edit control hidden in the background,
we can just grab its contents for the report.
- Use code page 1252 when previewing text files in the crash dialog.
SVN r2185 (trunk)
specify a character advance separately from the glyph width. GetChar and GetCharWidth now
return this value in place of the glyph width. (For non-BMF fonts, these should still
return the same values as before.)
SVN r2180 (trunk)
Silverex's X-Chat comes with the former now. Unfortunately, I can't seem to actually
set the font when my system default code page is 932, since it wants to use some Kanji-
compatible font instead. I wonder if I can still use the Unicode RichEdit control with
Windows 9x. (Does it even matter? Windows 9x users make up less than 0.1% of all visitors
to zdoom.org these days.)
SVN r2176 (trunk)
machines, so when an NPC need to show the "enough" response, it has enough
information available to do so.
- Some new Strife Teaser fixes I forgot to commit are in here.
- Moved norawinput check into FindRawInputFunctions().
SVN r2120 (trunk)
swap between them each frame. The one that's not the TempRenderTexture is used
as the FrontCopySurface without the need for a copy operation. This removes the
performance penalty the previous commit introduced for these modes.
SVN r2014 (trunk)
properly in letterboxed modes.
- Added another surface to receive a copy of the top back buffer immediately
before it is presented. This effectively produces a copy of the front
buffer without the performance penalty of GetFrontBufferData, so fullscreen
wipe preparation and screenshots are faster now. At lower resolutions,
always copying the backbuffer does incur a slight FPS hit, but it's
practically free at higher resolutions.
SVN r2013 (trunk)
assumed that since the wipes only run at 35 FPS, the time spent DMA'ing
it from system to video memory would be acceptable. Apparently I was wrong.
In particular, updating the same surface several times probably has to
synchronize between each one, making melt particularly slower than it
needs to be.
SVN r2012 (trunk)
time as the polled timer so that the timer does not start running until the
first time it is used.
- Removed the srand() call from D_DoomMain(), because it started the game
timer running prematurely, and we never call rand() anywhere. (Not to
mention, even if we did use rand(), always seeding it with 0 is rather
pointless.)
SVN r1974 (trunk)
unsigned integer that can use all 32 bits. They must therefore use
the unsigned mul instruction rather than the signed imul instruction.
- Fixed several signed/unsigned comparison and possibly uninitialized
variable warnings flagged by GCC.
SVN r1965 (trunk)
player sprites will retain the same precision they had when they were
rendered as part of the 3D view. (needed for propery alignment of flashes
on top of weapon sprites) It worked just fine for D3D, but software
rendering was another matter. I consequently did battle with imprecisions
in the whole masked texture drawing routines that had previously been
partially masked by only drawing on whole pixel boundaries. Particularly,
the tops of posts are calculated by multiplying by spryscale, and the
texture mapping coordinates are calculated by multiplying by dc_iscale
(where dc_iscale = 1 / spryscale). Since these are both 16.16 fixed point
values, there is a significant variance. For best results, the drawing
routines should only use one of these values, but that would mean
introducing division into the inner loop. If the division removed the
necessity for the fudge code in R_DrawMaskedColumn(), would it be worth it?
Or would the divide be slower than the fudging? Or would I be better off
doing it like Build and using transparent pixel checks instead, not
bothering with skipping transparent areas? For now, I chop off the
fractional part of the top coordinate for software drawing, since it was
the easiest thing to do (even if it wasn't the most correct thing to do).
SVN r1955 (trunk)
