Commit graph

8 commits

Author SHA1 Message Date
Christoph Oelckers
00d5bee72f - ...now where did that 'F' come from...?
SVN r4139 (trunk)
2013-02-16 10:48:03 +00:00
Christoph Oelckers
d71b0609f0 - fixed incorrect -= operators in vectors.h
SVN r4138 (trunk)
2013-02-16 09:41:54 +00:00
Randy Heit
b9ea9a415e - Added Polyobj_MoveTo, Polyobj_OR_MoveTo, and Polyobj_Stop.
- Cleaned up a couple of warnings.

SVN r2483 (trunk)
2010-08-01 19:14:10 +00:00
Randy Heit
344dda4a1a - Replaced toint/quickertoint with the portable routines from xs_Float.h. The
former used fistp, which is not portable across platforms, so cannot be
  used in the play simulation. They were only suitable for the renderer.
  xs_Float.h also has a very fast float->fixed conversion, so FLOAT2FIXED
  uses that now.
  (And I also learned that the FPU's round to nearest is not the rounding I
  learned in grade school but actually Banker's Rounding. I had no idea.)
  (Also, also, the only thing that could have made quickertoint faster than
  toint was that it stored a 32-bit int. I never timed them, and I doubt in
  practice there was any real difference between the two.)
- Changed atan2f to atan2. Using floats is not a win, because the result is
  returned as a double on the x87 stack, which the caller then needs to cast
  down to a float using fst/fld.

SVN r1990 (trunk)
2009-11-20 05:34:20 +00:00
Randy Heit
4ebfdac887 - Changed all coordinates for DrawTexture() to floating point so that the
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)
2009-11-01 01:27:33 +00:00
Christoph Oelckers
238d4c3fac - More things from Gez's experimental build:
* info CCMD to print extended actor information (not fully implemented yet)
  * summonmbf CCMD.
  * Beta BFG code pointer (but not the related missiles yet.)
  * PowerInvisibility enhancements.
  * ScoreItem with one significant change: Added a score variable that can be
    checked through ACS and DECORATE. The engine itself will do nothing with it.
  * Nailgun option for A_Explode.
  * A_PrintBold and A_Log.
  * A_SetSpecial.


SVN r1819 (trunk)
2009-09-14 19:44:14 +00:00
Randy Heit
47c401f4ec - Replaced the vector math routines with the ones I developed for the FP code.
SVN r454 (trunk)
2007-01-19 02:00:39 +00:00
Randy Heit
cf11cbdb30 Directory restructuring to make it easier to version projects that don't build zdoom.exe.
SVN r4 (trunk)
2006-02-24 04:48:15 +00:00