- some reorganization of texture precaching so that the renderer can decide what to do with actors.
Just marking the sprite textures loses too much info if more is needed than just loading the images into memory.
Ideally the warping shouldn't be a property of the texture class itself but an effect processor that can get added to a texture. Unfortunately the current setup will not allow this, requiring some significant refactoring of texture access first.
This was to resolve some circular dependencies with the portal code.
The most notable changees:
* FTextureID was moved from textures.h to doomtype.h because it is frequently needed in files that don't want to do anything with actual textures.
* split off the parts from p_maputl into a separate header.
* consolidated all blockmap related data into p_blockmap.h
* split off the polyobject parts into po_man.h
- This warning is about using zero-sized arrays in structs (aka flexible
member arrays). It's standard-enough for our purposes, so don't warn
about it, since neither GCC nor Clang do.
- Since Clang++, G++, and VC++ all support this extension (even though it's
technically officially only part of C99), use it. It lets Clang's array-
bounds checker know that these are meant to be accessed out of their so-called
"bounds".
- Fixed: If a part of a multipatch texture is replaced by a HIRESTEX
version, the original patch must not be deleted, since the multipatch
texture still needs it for compositing.
be used when for walls and floors when the renderer is paletted. The format
is very simple:
rgbtex1 paltex1
rgbtex2 paltex2
...
The first texture is the one to be used normally, and the second is the one
to be used in paletted modes.
The vid_nopalsubstitutions cvar can be used to ignore this lump.
SVN r3311 (trunk)
ignored the Y locations of patches drawn on two-sided midtextures and always drew them at the
top of the texture. Added a compatibility flag.
SVN r3205 (trunk)
* savegames stored an index in the switch table and performed no validation when loading a savegame.
* setting of a random switch animation duration was broken.
* separated the 2 values stored in the Time variable into 2 separate variables.
* defining a switch with one texture already belonging to another switch could leave broken definitions in the switch table.
- added function for serializing switch and door animation pointers.
- bumped min. savegame versions due to changes to DButtonThinker and removed all current savegame compatibility code.
SVN r3030 (trunk)
- moved all code and data for Build tile management into FTextureManager.
- moved texture animation management into FTextureManager.
- changed: Animate textures only once per frame, not per view. Otherwise with animations that have sub-frame accuracy camera textures of the same area can show different animation frames if the frame changes falls between the rendering of the different views.
SVN r3026 (trunk)
only has 64 entries and is not precise enough. It now uses finesine instead.
- fixed: When compositing a multipatch texture any patch that is a multpatch
texture itself and contains rotations may not be composited directly into
the destination buffer. This must be done with an intermediate buffer.
- Fixed: Drawing a slider in the options menu did not scale the x-coordinate.
- Fixed: If the alt HUD had to draw negative numbers the minus sign was misplaced
due to incorrect texture coordinate calculations.
- changed option menu scaling for widescreen modes so that it doesn't scale down
so quickly.
- made some error messages in DECORATE that don't affect the parsing non-fatal
so that the parser can continue to find more problems.
SVN r2076 (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)
for true color. Instead of using a clipping rectangle on the destination it
tried to alter the source offsets which produced incorrect results for
mirrored or rotated patches.
SVN r1889 (trunk)
