are scaled to the height of a 200 pixel tall sky. Skies taller than 240
use the same scale as a 240 tall sky but are shifted down to make the
top of the texture align with the top of the screen when looking fully up.
Thus, by using a sky texture with a height of 240 or more pixels, the sky
will be drawn with square pixels instead of the vertically elongated ones
imposed by Doom's native 320x200 resolution.
SVN r1978 (trunk)
- Improved sky stretching a bit: It now only stretches the sky as tall as it
needs to be: 228 pixels, not 256. It no longer stretches horizontally,
either.
The reason it stretches to 228 and not 200 pixels is because Doom shifted
its sky texture down 28 pixels. By stretching to 228 pixels, we can keep
the sky tiled at the same height on the horizon. Skies 200 pixels tall
(or more) will continue to tile at the center of the screen when looking
directly ahead.
SVN r1976 (trunk)
size textures at any scale. I also tried doing sky scrolling on the sky
cylinder, but that didn't look so good, so I left it in screen space.
SVN r1932 (trunk)
registers AMD64 provides, this routine still needs to be written as self-
modifying code for maximum performance. The additional registers do allow
for further optimization over the x86 version by allowing all four pixels
to be in flight at the same time. The end result is that AMD64 ASM is about
2.18 times faster than AMD64 C and about 1.06 times faster than x86 ASM.
(For further comparison, AMD64 C and x86 C are practically the same for
this function.) Should I port any more assembly to AMD64, mvlineasm4 is the
most likely candidate, but it's not used enough at this point to bother.
Also, this may or may not work with Linux at the moment, since it doesn't
have the eh_handler metadata. Win64 is easier, since I just need to
structure the function prologue and epilogue properly and use some
assembler directives/macros to automatically generate the metadata. And
that brings up another point: You need YASM to assemble the AMD64 code,
because NASM doesn't support the Win64 metadata directives.
- Added an SSE version of DoBlending. This is strictly C intrinsics.
VC++ still throws around unneccessary register moves. GCC seems to be
pretty close to optimal, requiring only about 2 cycles/color. They're
both faster than my hand-written MMX routine, so I don't need to feel
bad about not hand-optimizing this for x64 builds.
- Removed an extra instruction from DoBlending_MMX, transposed two
instructions, and unrolled it once, shaving off about 80 cycles from the
time required to blend 256 palette entries. Why? Because I tried writing
a C version of the routine using compiler intrinsics and was appalled by
all the extra movq's VC++ added to the code. GCC was better, but still
generated extra instructions. I only wanted a C version because I can't
use inline assembly with VC++'s x64 compiler, and x64 assembly is a bit
of a pain. (It's a pain because Linux and Windows have different calling
conventions, and you need to maintain extra metadata for functions.) So,
the assembly version stays and the C version stays out.
- Removed all the pixel doubling r_detail modes, since the one platform they
were intended to assist (486) actually sees very little benefit from them.
- Rewrote CheckMMX in C and renamed it to CheckCPU.
- Fixed: CPUID function 0x80000005 is specified to return detailed L1 cache
only for AMD processors, so we must not use it on other architectures, or
we end up overwriting the L1 cache line size with 0 or some other number
we don't actually understand.
SVN r1134 (trunk)
that animated icons can be done with it.
- Changed FImageCollection to use a TArray to hold its data.
- Fixed: SetChanHeadSettings did an assignment instead of comparing
the channel ID witg CHAN_CEILING.
- Changed sound sequence names for animated doors to FNames.
- Automatically fixed: DCeiling didn't properly serialize its texture id.
- Replaced integers as texture ID representation with a specific new type
to track down all potentially incorrect uses and remaining WORDs used
for texture IDs so that more than 32767 or 65535 textures can be defined.
SVN r1036 (trunk)
- Fixed: At resolutions taller than 600 pixels or so, tall sky textures were
drawn a row too low. This was quite visible on Hexen MAP06.
- Fixed: P_CheckSlopeWalk() must return false if floorsector != sector, or
the actor will be yanked down to the floorsector by P_TryMove().
- Fixed: ClearActorInventory, GiveActorInventory, and TakeActorInventory
only affected the first actor with the given TID.
- Fixed: The color boxes for the colorpicker menu items were drawn a little
too low.
SVN r603 (trunk)
rather than overriding the dmflags values, actually overwrote the dmflags
values, so they would continue to be in effect on later maps that didn't
explicitly specify them.
SVN r595 (trunk)
I got rid of the old tx and ty CVARs because they made the texture scaling
much more complicated than it was actually needed (and besides, they were completely
useless except for testing purposes anyway.)
SVN r522 (trunk)
- Fixed: SetTexture() in p_setup.cpp assumed that all color values were
six characters. Although this was the intended way to specify colors,
earlier versions did no error checking, so other lengths worked too.
- Fixed: FPatchTexture waited until MakeTexture() to call CalcBitSize(),
so the width and height bit sizes weren't available when using it as a
source for a warp texture.
- Fixed: R_InitSkyMap() should only warn about two sky textures not being
the same height when they are used as part of a double sky.
- Added a NULL state check in AActor::Tick() before advancing the current
state. Note that this should not happen, so there's an assert there for
the debug build as well as a regular check for the release build.
SVN r324 (trunk)
