eukara
/
duke3d
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
duke3d/buildengine/build2.txt

1666 lines
80 KiB
Plaintext
Executable File
Raw Permalink Blame History

// "Build Engine & Tools" Copyright (c) 1993-1997 Ken Silverman
// Ken Silverman's official web site: "http://www.advsys.net/ken"
// See the included license file "BUILDLIC.TXT" for license info.
BUILD engine Notes (7/24/96):
BUILD programmed by Ken Silverman
BUILD.TXT CONTINUED... (BUILD.TXT WAS GETTING TOO BIG!!!)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/12/95 - Added parameter to initmultiplayers to allow who becomes
master at the start of a multiplayer game.
- Added parallaxyscale variable to BUILD.H which control the ratio
at which the parallaxing skies scroll in relation to the
horizon. Default is 65536. With lower values, you don't
need as much artwork and can look higher, but I like 65536
because it is the correct projection.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/13/95 - Had MAJOR bug with my searchmap function. If you use it, please
re-copy from my game.c
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/14/95 - Fixed some EVIL bugs with Rt.ALT sector copying. It shouldn't
screw up your maps anymore! And if you have maps that were
screwed up with it, you can try my new map correcting key,
L.Ctrl+L.Shift+L.Enter. This key will not affect an already
perfect map. However it can SOMETIMES clean up a map that
was screwed up. I take no responsibility if it screws up
your map even more, so please check them before saving!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/16/95 - Added error correction to mmulti.obj. Mmulti.obj is like
multi.obj but it is made to work with Mark's real mode
multiplayer driver that he calls COMMIT.
MMULTI.OBJ vs. MULTI.OBJ:
* initmultiplayers is the same, but the parameters are ignored
* uninitmultiplayers can be called but does nothing.
* sendlogon can be called but does nothing.
* sendlogoff sends packet 255 to everybody else. It does not
need to be called any more.
* sendpacket and getpacket are the same.
* connecthead, connectpoint2[], numplayers, myconnectindex
are the same. They can be externed just like before.
* getoutputcirclesize always returns 0. It is not needed.
* setsocket does nothing. The socket is now in commit.dat.
* crctable can still be externed.
* syncstate can still be externed but is not used.
* Do not use the option[4] variable. Initmultiplayers will
always return a valid number in numplayers from 1-16.
You can link mmulti.obj in place of multi.obj and use
commit.dat as the setup file for multiplayer options.
There are 2 ways you can run your game through commit:
1. Set the launch name (usually game.exe) in commit.dat
and type something like "commit map01 /asdf"
2. Type "commit launch game map01 /asdf". This method
is easier if you want to use the debugger with commit
since you won't have to change commit.dat constantly.
Ex: "commit launch wd /tr=rsi game map01 /asdf"
I have not tested mmulti.obj with my BUILD game yet because
I have been using 2DRAW as my test program. I may put up a
new version of mmulti.obj with better error correction for
extremely error-prone lines soon.
- Kgroup can now accept a parameter as a filename with a list of
files to be put into the group file.
Ex: "kgroup @filelist.txt"
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/18/95 - Found a way to greatly reduce slave "hitching" on multiplayer
games for faketimerhandler style communications. It's pretty
simple.
Step 1: In the beginning of faketimerhandler, change
ototalclock = totalclock;
TO:
ototalclock += TICSPERFRAME;
This makes the timing of the game more constant and to
never miss ticks. I should have done this in the first
place all along.
Step 2: In getpackets, (for slaves only) count the number of
times movethings is called. Normally, movethings should
be called exactly once for every time getpackets is called
inside faketimerhandler. The hitching is because
movethings is called in a 0-2-0-2-0-2 cycle instead of the
standard 1-1-1-1-1-1 cycle. This happens because the
timers of the 2 computers are aligning in such a way that
the slave is receiving the master's packets at nearly the
same time as it calls getpackets. To correct the problem,
if movethings is called an even number of times, I randomly
add or subtract (TICSPERFRAME>>1) to ototalclock. Throw
this code at the end of getpackets:
Beginning of getpackets:
movecnt = 0;
Where slave receives buffer in getpackets, next to movethings:
movecnt++;
End of getpackets:
if ((myconnectindex != connecthead) && ((movecnt&1) == 0))
{
if (rand()&1) ototalclock += (TICSPERFRAME>>1);
else ototalclock -= (TICSPERFRAME>>1);
}
- Found a way to interpolate anything using the doanimations
code for faketimerhandler style multiplayer games. It's not
as hard as I thought it would be (and it doesn't waste too
much memory!) To smooth out doanimations, since there's no
temporary variables that can be thrown away like with tsprite,
the current doanimations positions must be backed up at the
beginning of drawscreen and restored at the end of drawscreen.
If you want smooth up&down doors, do this:
Global declaration:
static long oanimateval[MAXANIMATES];
Beginning of drawscreen:
for(i=animatecnt-1;i>=0;i--)
{
oanimateval[i] = *animateptr[i]; //Backup doanimations interpolation
j = *animateptr[i];
if (j < animategoal[i])
j = min(j+animatevel[i]*(totalclock-gotlastpacketclock),animategoal[i]);
else
j = max(j-animatevel[i]*(totalclock-gotlastpacketclock),animategoal[i]);
*animateptr[i] = j;
}
End of drawscreen:
//Restore doanimations interpolation
for(i=animatecnt-1;i>=0;i--) *animateptr[i] = oanimateval[i];
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/19/95 - Added global invisibility variable. Initengine sets it to 0
by default. If you set global invisibility to 1, then
all sprites with the invisible bit set (sprite[].cstat&0x8000)
will be shown. This is useful for editing invisiblie sprites.
- Made the hitscan blocking bit for sprites be the bit checked
when using cliptype 1 instead of the blocking bit. Before
I was accidently using the clipmove blocking bit on sprites
with cliptype 1. I should have done it this way in the first
place. I hope you haven't "built" around this bug too much!
Here's how everything works now:
Clipmove blocking bits:
Which bits:
wall[].cstat & 1
sprite[].cstat & 1
Used in these cases:
clipmove when cliptype = 0
getzrange when cliptype = 0
Hitscan blocking bits:
Which bits:
wall[].cstat & 64
sprite[].cstat & 256
Used in these cases:
clipmove when cliptype = 1
getzrange when cliptype = 1
hitscan always
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/20/95 - Reduced some overhead memory by combining 2 large internal
arrays which were used in different parts of the engine.
This is a total savings of about 90K.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/24/95 - Changed the way 'E' mode works on ceiling and floor textures.
64*64 and 128*128 textures are the same as before so I think
this won't screw up your existing maps. (But I can never be
sure) Now, 'E' mode always smooshes the texture size by 2 for
any size texture.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/29/95 - ÜÛÛÛÛÛÛÜ ÛÛ ÜÛÛÛÛÛÛÜ ÜÛÛÛÛÛÛÜ ÜÛÛÛÛÛÛÜ ÜÛÛÛÛÛÛÜ ÛÛ ÛÛ ÛÛ
ÛÛ ÛÛ ÛÛß ßÛÛ ÛÛ ÛÛ ÛÛ ÛÛ ÛÛ ÛÛ ÛÛ
ßÛÛÛÛÛÛÜ ÛÛ ÛÛ ÛÛ ÛÛÛÛÛÛÛß ÛÛÛÛÛÛ ßÛÛÛÛÛÛÜ ÛÛ ÛÛ ÛÛ
ÛÛ ÛÛ ÛÛÜ ÜÛÛ ÛÛ ÛÛ ÛÛ ßß ßß ßß
ßÛÛÛÛÛÛß ßÛÛÛÛÛÛÛ ßÛÛÛÛÛÛß ÛÛ ßÛÛÛÛÛÛß ßÛÛÛÛÛÛß ÛÛ ÛÛ ÛÛ
New 3D EDIT MODE BUILD keys:
Press [ or ] on a ceiling or floor to change the slope.
Shift + [ or ] on a ceiling or floor to adjust finely.
Press / to reset a ceiling or floor to slope 0.
Use Alt-F in either 2D or 3D mode to change the slope's hinge.
Sector fields used for slopes:
The useless groudraw fields, ceilingheinum and floorheinum,
are now being used as the slope value. They are treated
as signed shorts, where 0 is slope 0, of course. To enable
slope mode, you must also set bit 1 of the ceilingstat or
floorstat bits.
Known bugs:
There are still a few bugs that I haven't gotten around to
fixing yet. They're not necessarily hard to fix - it's just
that there are a lot of little things that need to be updated
(on my part).
- Hitscan does not hit slopes correctly.
- Rare divide overflow bug in my wallmost function only when
you're very close to a red sector line of a slope.
- Relative alignment for slopes not yet programmed. Relative
alignment for slopes will allow square aspect ratio for all
slopes of slopes.
- ALT-F code with passing loops would be nice.
- Visibility not implemented for slopes yet.
- Sometimes an annoying tiny wall is drawn at sector lines.
Don't call me to tell me about these bugs. I know about them.
And if I didn't list your favorite bug of the day, it will
probably be brought up by the 2 internal teams now working
with BUILD.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/4/95 - Made ALT-F select any wall of a sector, even crossing loops.
In 3D mode, ALT-F now sets the selected wall directly to the
first wall.
- Fixes related to slopes:
* Relative alignment now works. Use relative alignment on high
slopes if you don't like the way the texture is stretched
out.
* Flipping now works
* Panning now works
* Fixed seams for SOME (not all) slope borders
- My wonderful divide overflow bugs in wallmost aren't quite as
rare as they used to be. Wait a minute - I thought I was
supposed to document bug fixes here! This is what you get
for wanting BUILD tonight. As soon as I fix these darn
divide bugs, I'll put up a new version.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/5/95 - Fixed all known divide overflow bugs related to wallmost. I
haven't gotten a divide overflow yet in the last few hours,
but that doesn't guarantee that you'll never get one. Take a
look at GROULAND. It has a cool new cylindrical tunnel. On
the other side of the level is my house in Rhode Island.
Known bugs with slopes now:
- Hitscan does not hit slopes correctly.
- Visibility not implemented for slopes yet.
- Clipmove will not allow you to walk off high sloped cliffs.
- Also, I noticed a rare sprite drawing clipping bug. I
don't know if this is new or not.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/7/95 - Fixed an exception 0xe bug by using tsprite[MAXSPRITESONSCREEN-2]
instead of tsprite[MAXSPRITESONSCREEN-1]. I don't understand
why this fixed it so I expect that it will come back to haunt
me. Oh happy day. :(
- I forgot to document 2 new and useful functions in the engine:
long getceilzofslope(short sectnum, long x, long y); and
long getflorzofslope(short sectnum, long x, long y);
Returns the z coordinate of the ceiling/floor at that x, y
location. If the sector doesn't have a ceiling/floor slope
then it immediately returns the sector[].floorz or
sector[].ceilingz so it's not that slow. You may want to
check for slopes yourself ceilingstat&2/floorstat&2 if you
think the overhead of calling these functions are too slow.
- Made clipmove use getceilzofslope and getflorzofslope when
checking for overlapping.
- Cleaned up mirror code for non-chained modes a little bit. The
mirrors should no longer have a stay line on the right anymore
for these modes.
- Added Chain-Buffer mode. See my new SETUP.EXE. Chain-Buffer
is a combination of the chain and screen buffer modes - a
buffered chain mode. This mode is faster than standard chain
mode when a lot of screen memory is being read, for example
when you use transluscence or mirrors. Also, Chain-Buffer
mode is cleaner than screen-buffer mode since you don't see
memory being copied to the screen. Unfortunately, in most
cases, Chain-Buffer is the slowest of all modes. Actually,
Chain-Buffer mode sucks. There is a use for this mode,
however! In the future, I may make some kind of chain mode
automatically switch into chain-buffer mode for extra speed
when there is a large area of transluscence, etc.
ATTENTION PROGRAMMERS: Here is the new order of modes that
initengine accepts:
0 = Chain mode
1 = Chain-Buffer mode
2 = Screen-Buffer/VESA mode
3 = TSENG mode
4 = Paradise mode
5 = S3
6 = Crystal Eyes mode
7 = Red-Blue mode
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/9/95 - Fixed visibility for face sprites in high resolution modes.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/14/95 - Added a new bunch of graphics modes using the new VESA 2.0 linear
buffer. (I replaced the useless chain-buffer mode with VESA
2.0 modes) See my new SETUP. Since most cards only support
VESA 1.2 right now, you will probably need a VESA 2.0 driver.
I have been using the UniVBE(tm) 5.1 from SciTech Software
(ftp: ftp.scitechsoft.com, www: http://www.scitechsoft.com)
Note that since I inserted the new modes between chained mode
and screen buffer mode, you will need to update your setup
program and fix your initengine calls.
- Programmed a LRU/MRU-style cacheing system. It should be fully
compatible with the old cache1d except for the locking byte.
The locking byte would be better described as a priority byte.
Priority byte:
0 - non-cached memory, you NEVER set the byte to 0!
1-199 - cached unlocked memory
200-255 - cached locked memory
When the cacheing system needs to remove a memory block, it
will try to remove the FEWEST number of SMALLEST blocks with
the LOWEST priority.
Note: Never set the priority byte to a 0! Let the cacheing
system do that for you.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/15/95 - Optimized hitscan a little and made it work with slopes.
- Made some internal things in the build editor work better with
sprites on slopes.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/16/95 - Note: Initengine now only does memory allocation for the
graphics modes. The ylookup table is calculated in
setgamemode since with VESA, I don't know certain
variables such as bytesperline until the mode is
actually set.
- Cansee should now work with slopes properly.
- Added a new function which is a combination of the
getceilzofslope and getflorzofslope functions. Whenever you
need both the ceiling and floor, it is more optimal to call
this function instead. The parameters are just like the other
functions except the ceiling and floor are returned through
pointers instead of a return value.
getzsofslope(short sectnum, long x, long y,
long *ceilz, long *florz);
- Fixed recently introduced hitscan divide overflow bug.
- Fixed a sprite drawing clipping bug.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/17/95 - ATTENTION PROGRAMMERS: I moved the sprite shading code from
the engine into GAME/BSTUB. If you want sprites to shade
like they used to, be sure to copy the code I recently added
to the end of analyzesprites in GAME.C or ExtAnalyzeSprites
in BSTUB.C.
- Added 2 new interesting functions to the engine to make moving
slope programming easier. These functions will align a slope
to a given (x, y, z) point. It will make the slope pass
through the point. The function will do nothing if the point
is collinear to the first wall of the sector.
alignceilslope(short sectnum, long x, long y, long z);
and
alignflorslope(short sectnum, long x, long y, long z);
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/18/95 - Kgroup will now work with subdirectories.
- ATTENTION PROGRAMMERS: I have not done this yet, but I am
planning on doing a new map version! Before I do it, I
want to give you a chance to give me any suggestions you may
have. The only changes I am planning on, besides re-arranging
the structures for better alignment is to give the slopes some
more bits precision. This may limit slopes to a maximum slope
of 4 (almost 76ø) which is still extremely high. Here are the
new structures that I am proposing:
//40 bytes
typedef struct
{
long ceilingz, floorz;
unsigned short wallptr, wallnum;
short ceilingstat, floorstat;
short ceilingpicnum, ceilingheinum;
signed char ceilingshade;
char ceilingpal, ceilingxpanning, ceilingypanning;
short floorpicnum, floorheinum;
signed char floorshade;
char floorpal, floorxpanning, floorypanning;
char visibility, filler;
short lotag, hitag, extra;
} sectortype;
//32 bytes
typedef struct
{
long x, y;
short point2, nextwall, nextsector, cstat;
short picnum, overpicnum;
signed char shade;
char pal, xrepeat, yrepeat, xpanning, ypanning;
short lotag, hitag, extra;
} walltype;
//44 bytes
typedef struct
{
long x, y, z;
short cstat, picnum;
signed char shade;
char pal, clipdist, filler;
unsigned char xrepeat, yrepeat;
signed char xoffset, yoffset;
short sectnum, statnum;
short ang, owner, xvel, yvel, zvel;
short lotag, hitag, extra;
} spritetype;
Note that I am adding 1 byte of filler to the sprite structure
(4K more) and 3 bytes of filler to the sector structure
(3K more). (If I'm a nice guy, one of those bytes may even
be use for fog. (DOH!))
- Fixed another wonderful hitscan divide bug.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/22/95 - Optimized slopes. On a 486-66 w/ local bus in VESA 2.0 320*200
mode, a full screen slope was optimized from 24fps to 35fps!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/25/95 - Re-optimized some more assembly.
- ATTENTION EVERYONE! CONVMAP7! You know what this means. Just
type "convmap7 *.map" and you'll be back in business. P.S.
enjoy the newly aligned structures!
- ATTENTION PROGRAMMERS! New TRANSPAL! You can now use 2 levels
of transluscence by using just a single 64K transluscent
buffer, such as 33/67 and 67/33 transluscence. I changed the
format of palette.dat, so please run TRANSPAL before you try
running the game with the new OBJS! If you don't, the palette
tables will be screwed up.
Old PALETTE.DAT:
768 bytes - VGA palette
numshades*256 bytes - palookup[0] table
32640 bytes- transluscent palette (smaller from symmetry)
The way I used to get numshades (fun):
numshades = ((filelength-32640-768)>>8)
New PALETTE.DAT:
768 - VGA palette
2 - numshades
numshades*256 - palookup[0] table
65536 - transluscent table
To keep things less confusing, could you all use a
transluscent constant >= 128. For example, I used 170 on
my PALETTE.DAT.
READ THIS! New bits added to things:
Bit 5 of rotatesprite, bit 9 of both sprite[].cstat
and bit 9 of wall[].cstat are now used for reverse
transluscence.
- Added super-cool new feature to 2D EDIT MODE (that should have
been there from the start). Try inserting some points!
- ATTENTION PROGRAMMERS! Removed overwritesprite. Use
rotatesprite instead. I don't want to support a function that
can totally be done with another better function. I will
eventually optimize rotatesprite for 90ø cases so it's even
faster than the current overwritesprite. If you're too lazy
to convert right now, then you can use this overwritesprite
stub function:
overwritesprite (long thex, long they, short tilenum,
signed char shade, char stat, char dapalnum)
{
rotatesprite(thex<<16,they<<16,65536L,(stat&8)<<7,tilenum,shade,dapalnum,
((stat&1^1)<<4)+(stat&2)+((stat&4)>>2)+((stat&16)>>2)^((stat&8)>>1),
windowx1,windowy1,windowx2,windowy2);
}
- Fixed the rotatesprite centerting bug in y-flipping mode. Oh
by the way, you know how I originally said the flipping bit
was x? Well, I screwed it up. It was actually y-flipping all
along.
- This one's for hackers (N&P/Qs) In the engine, I call
getpalookup every time I need a pointer to a 256-byte
palookup table. One big limitation right now is that each
bunch of 256-byte tables has a limit of 64K because a shade
is being returned, not a 4-byte pointer. This means you
could have a maximum of 8 shades, with 8 fogs per palookup.
It's not as expandable as I originally intended since this is
a speed-critical function. It is called EVERY single time a
line is drawn - probably called 50 times more often than
faketimerhandler.
#pragma aux bound32 =\
"test eax, 0ffffffe0h",\
"jz endit",\
"cmp eax, 80000000h",\
"sbb eax, eax",\
"and eax, 31",\
"endit:",\
parm [eax]\
getpalookup(long davis, long dashade)
{
return(bound32(dashade+(davis>>8)));
}
This is just a start. Eventually I hope to use some kind of
lookup table, such as: palookup = palptr[davis][dashade],
but I couldn't think of a good way to make the array small
enough for what people need.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/26/95 - Fixed drawmapview so it actually clips to the rectangular window
properly. It does not clip to startumost/startdmost so you
should call a rotatesprite to draw the status bar every frame
if it is not rectangular.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/30/95 - Fixed recently introduced mirror bug.
- Fixed rotatesprite x-positioning bug in scale mode for weird
resolutions.
- Fixed tilting for pure chained modes.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/2/95 - Changed setbrightness call:
setbrightness(char dabrightness, char *dapal)
dabrightness is gamma level(0-15)
dapal is pointer to standard VGA 768 byte palette.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/3/95 - Fixed flicker in UNIVBE modes.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/6/95 - Added a global visibility variable to BUILD.H specific for
p-skies called parallaxvisibility. Now you can do lightning
effects without modifying the visibility for everything.
- Really fixed the drawmapview window clipping this time.
- Made my clearview function clip to the viewing window since it
is usually used just before the drawmapview function.
- You can now use bit 6 (64) to tell rotatesprite whether or not
the tile has transparent regions or not. If there are no
transparent regions, then it would be faster to set this bit
because it doesn't have to check for color 255 at every pixel.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/11/95 - Back in RI!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/13/95 - Cleaned up setup program by having only 1 VESA menu for all
possible VESA modes. The engine will now auto-detect whether
or not your computer supports VESA 2.0. The screen buffer
menu now only supports 320*200. (I noticed that Mark's setup
program doesn't list 320*400 mode even though it is supported
by my game and UNIVBE. 320*400 is considered by some people
the next best mode after 320*200 and 640*480. You have my
permission to annoy him.)
- I bought UNIVBE by credit card for $28! When you buy UNIVBE,
you don't have to struggle with beeps or date changing - and
it loads instantly. I try not to use TSR's whenever possible,
but I found that UNIVBE is worth wasting 8K. I don't think my
computer has ever crashed due to something related to UNIVBE.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/17/95 - Found an easy way to interpolate everything for faketimerhandler
in my game, including swinging doors, revolving doors, and
other moving sectors. My doanimations interpolation now uses
these functions instead. Check them out in my GAME:
setinterpolation(long *posptr); //Call when door starts
stopinterpolation(long *posptr); //Call when door stops
updateinterpolations(); //Call at start of domovethings
dointerpolations() //Call at start of drawscreen
restoreinterpolations() //Call at end of drawscreen
Call setinterpolation with a pointer to the long variable
being interpolated. If an object stops moving, you can
speed things up by calling stopinterpolation. For things
that always move, you can call setinterpolation in pre-map
and don't stopinterpolation for those things. Don't forget
to set numinterpolations to 0 in premap whenever changing
levels in the game.
- Optimized lava. You can re-copy my code if you want.
- Added auto screen-buffering mode for linear VESA modes. (In
case you didn't know, reading video memory can be 10 times
slower than reading non-video memory.) Auto-buffering
means that if the engine detects that more than 1/8th of the
screen has transluscence or mirrors, then it will switch into
a screen-buffering mode. Screen-buffer mode in linear VESA
not only will still have smooth page flipping, but will be
faster than standard screen buffer mode on some video cards
just because it's linear memory. (That's a good thing)
- Optimized screen buffer modes so they copy only the viewing
window instead of the whole screen from non-video memory to
video memory. If a permanent sprite is written, as a special
case, it will copy the whole screen - but this doesn't affect
you. Me and my engine babble.
- Moved the printext function out of the engine and into my game.
Use printext16/printext256 instead.
- I tried removing chain mode twice and it didn't improve the frame
rates of the other modes at all. So it stays! If you don't
like it, then don't include it in your setup program.
- Made allocatepermanenttile return 0 instead of -1 if something
bad happens. My GAME.C was crashing in windows with a memory
error because I was assuming all memory pointers were
positive. Please make sure your code will work if an
allocation function returns a negative pointer (Windows often
returns negative pointers).
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/19/95 - Tried to make pushmove work with face sprites, but it kept making
the player die too much. Also it presented some interesting
new problems, such as: You get pushed by your own bullets
that you just shot - and get this - if you don't temporarily
set yourself to non-blocking you kill yourself because you're
inside you're own sprite! So I have decided to comment out
this code for now.
- Fixed hitscan bug with ceiling slopes.
- ATTENTION PROGRAMMERS!!! PERMANENTWRITESPRITE was removed from
the engine and be put into my game as an emulated function.
If you still use permanentwritesprite, get the emulated
function out of my GAME.C.
Drawing permanent areas is now easier than ever!!! Simply
call rotatesprite with bit 3 (&8) set or the
permanentwritesprite stub call, and the engine now
automatically takes care of copying the permanent region
to all necessary pages in the future. It even keeps track
of whether the call was before or after drawrooms!
I am using an internal fifo to back up the parameters for each
rotatesprite call. It can support up to 512 calls per
page right now. This number can get reached quicker than
you think, especially if you use fonts with shadows behind
each character. Permanentwritespritetile could also go
over the limit in hi-res modes since each tile is considered
a separate call.
I optimized out the case where an older rotatesprite region gets
completely covered by a newer rotatesprite region with bit 6
(&64 for non-masking) set. Currently this has a few
limitations - such as the x, y, zoom, and ang must be the same
right now to knock out an older rotatesprite.
- I corrected an off-by 1 error in my GAME.C for window size
calculations. I simply used more precision. Ex:
* changing (xdim>>1)-(screensize>>1) to ((xdim-screensize)>>1)
* using the scale function instead of a separate mul & div.
By the way, if you haven't already, please stick your screen
re-sizing code BEFORE drawrooms. It will make the screen
re-size update more responsively and you're less likely to get
drawing bugs.
- Future plans for possible rotatesprite optimizations:
1. Angle is 0, 512, 1024, 1536
2. Bit 6 (&64) is set for non-masking mode
3. tilesizy[tilenum] is a power of 2
4. If coincidentally, x=34562, y=34682, and zoom=67275
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/20/95 - Fixed vertical line shading bugs when looking at walls at harsh
angles.
- Made masked walls clip to slopes properly. TRY IT!
(hope you didn't "BUILD" on this bug!)
- Fixed overflow and precision bugs with extremely long walls.
I even got the chance to optimize out a multiply in the
wallmost clipping code!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/25/95 - Now absolutely everything in my game is being interpolated
for smooth play - including subways! No interpolation
disable variable exists any more. The setinterpolation
function is really easy to use. Try it!
- Programmed VISIBILITY for slopes!!!!! On my P-100, the slopes
are almost as fast as they used to be. You can now start
adjusting the shades of slopes.
- The shading lines on ceilings and floors now match to the shading
lines on walls. Before they didn't match. (oops).
- For those of you who want to program their own palette functions,
using my gamma correction lookup table, here's the code:
extern char britable[16][64];
koutp(0x3c8,0);
for(i=0;i<768;i++)
koutp(0x3c9,britable[curbrightness][palette[i]]);
If you use this code, don't bother calling setbrightness any
more. The only bad thing about programming this yourself
is that you lose support for red-blue glasses mode.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/26/95 - Added support for VESA 2.0 protected mode extensions. With the
protected mode extensions, the page-flipping is less likely to
flicker, if at all. This is because the retrace timing isn't
screwed up as badly as if it had to switch to real mode.
- Fixed a weird buffer bug in my GAME.C. I was using tempbuf in
faketimerhandler/getpackets for sending packets. I was also
using tempbuf in many other places, such as my printext
function. Unfortunately, since rotatesprite is now called
for each character, faketimerhandler would sometimes get
called and the rest of the word got screwed up. Please make
sure you are not sharing any buffers in faketimerhandler /
getpackets with the rest of your code.
- Fixed a bug for linear VESA modes. Now, the screen will update
properly when calling rotatesprite and nextpage for the first
time before any drawrooms calls. This used to not work right
at my "waiting for other players" code in this mode.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/27/95 - Did you notice I fixed some of the weird cases with slope drawing
in the last upload? I fixed things like when a ceiling of
one sector is partially below the floor of another, etc.
- Fixed precision of shading lines on slopes.
- Fixed visibility overflow when slopes are near horizons. This
means you won't see ugly bright pixels any more when you're
looking at a slope at an extremely sharp angle.
- Fixed a bug in BUILD 3D EDIT MODE with slopes. Now when you
press '/' on a ceiling or floor slope, it stays straight
until you press [ or ] on it again. Before, sometimes the
ceiling would stupidly get sloped again if you pressed [ or ]
on the floor and vice versa.
- Removed some unnecessary sounds from my game. This doesn't
really affect you people out there.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/30/95 - Fixed recently screwed up p-sky tiling.
- Made Editart work with map version 7 for tile sorting and the
Alt-R command. Alt-R does not scan the heinum's of sectors
any more, and only adds in the overpicnum if a masked or
1-way wall is actually defined on the map.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/31/95 - Fixed a bug with my slopalookup array. It was sometimes writing
up to 3 bytes after the end of the array.
- Fixed recently screwed up p-sky tiling for real this time.
- Permanentwritesprite is out of my game. Here it is just in case
I will need it again for future reference.
permanentwritesprite (long thex, long they, short tilenum,
signed char shade, long cx1, long cy1,
long cx2, long cy2, char dapalnum)
{
rotatesprite(thex<<16,they<<16,65536L,0,tilenum,shade,
dapalnum,8+16,cx1,cy1,cx2,cy2);
}
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/1/95 - Guess what? I turned 20 today. This means I'm no longer a
teenage programming genius. Doesn't that just suck. If you
guys don't get a game out by the next time my age plus
plusses, I'm going to get really p-skied off and kill some
people. That would be bad. (When I say killing, I mean
virtual killing in the entertaining game of Ken-Build
in which a fun time is always had by all.) So put on your
happy fun smiles and work out all those rotatesprites,
fsyncsyncvel.bits, and interpolation fifos before it's
ototalclock!
- Optimized the NON-MASKING cases of rotatesprite for
NON-(un)CHAINED modes. This means that low detail modes,
status bars, and permanent background tiles are now drawn
about as fast as they're ever going to be drawn! Try the
F5 key in my game to compare frame rates if you want. I have
not optimized guns and stuff yet. That's next on my list.
- Made the engine call new internal functions, kmalloc and kfree,
instead of malloc or free. Unless you're a hacker and wrote
your own memory manager (like N&P/Qs) you can just ignore
this message.
void *kmalloc(size_t size) { return(malloc(size)); }
void kfree(void *buffer) { free(buffer); }
- Supposedly fixed the new rotatesprite and linear vesa crashing
bugs. Since I'm not totally sure that I fixed the problems,
all I can do is hope that I don't get too many phone calls!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/4/95 - Did some neat optimizations that will make the drawing code
faster, especially in hi-res modes, but I'm sure nobody cares.
Instead I'm probably just going to get 10 totally different
bug report stories. So I'll be talking to you soon!
- Fixed stupid bugs in cansee. If the 2 objects were in the same
place, sometimes it returned 1 even if it couldn't see you.
I made 2 fixes:
This one to fix overlapping:
if ((xs == xe) && (ys == ye)) return(sects == secte);
And I removed the early out return(1) optimization - I
put this after the big loop instead:
for(i=danum-1;i>=0;i--)
if (clipsectorlist[i] == secte) return(1);
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/7/95 - Optimized the awful shld's out of my divscale's in pragmas.h.
You can update to the new pragmas.h if you actually use it.
- Remember the lovely horizontal lines on top of face sprites.
Well you won't be seeing them any more. At least the case
I trapped works better than before.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/8/95 - Made krand generate better random seeds.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/9/95 - ATTENTION PROGRAMMERS! Moved part of stat bit 3 of rotatesprite
to bit 7. Have you noticed that your menu code was kind of
screwy in modes where numpages > 1? This is because I made
rotatesprite automatically copy to all pages whenever the
"don't clip to startmost's bit" (bit 3 or +8) was set in
the stat bit of rotatesprite. To give you more control, I
moved the auto copy to all pages bit to bit 7 and left bit 3
as the don't clip to startmosts bit. If you want your code
to work the same as the last update of BUILD, simply go
through all your rotatesprite calls and add 128 in addition
to the stat bit whenever you were adding 8 before. See the
revised rotatesprite documentation:
rotatesprite (long sx, long sy, long z, short a, short picnum,
signed char dashade, char dapalnum, char dastat,
long cx1, long cy1, long cx2, long cy2)
(sx, sy) is the center of the sprite to draw defined as screen coordinates
shifted up by 16. In auto-scale mode, be sure that (sx, sy) is using
a 320*200 size screen even though the real resolution may be different.
(z) is the zoom. Normal zoom is 65536. > is zoomed in, < is zoomed out.
(a) is the angle (0 is straight up)
(picnum) is the tile number
(dashade) is shade number
(dapalnum) is the palookup number
if ((dastat&1) != 0) - transluscence
if ((dastat&2) != 0) - auto-scale mode
Auto-scale mode will automatically scale from 320*200 resolution
coordinates to the clipping window passed (cx1, cy1, cx2, cy2). In
auto-scale mode, don't pre-scale the (sx, sy) coordinates. Simply pass
(sx, sy) as if the resolution was 320*200 even though it may be
different. This means that you shouldn't use xdim or ydim to get
(sx, sy).
if ((dastat&4) != 0) - y-flip image
if ((dastat&8) != 0) - don't clip to startumost/startdmost
if ((dastat&16) == 0) - use Editart center as point passed
if ((dastat&16) != 0) - force point passed to be top-left corner
if ((dastat&32) != 0) - use reverse transluscence
if ((dastat&64) == 0) - masked drawing (check 255's) (slower)
if ((dastat&64) != 0) - draw everything (don't check 255's) (faster)
if ((dastat&128) != 0) - automatically draws to all pages as they come
(cx1, cy1, cx2, cy2) - The clipping window. These coordinates are never
scaled, not even in auto-scale mode. Usually you should pass them as
(windowx1,windowy1,windowx2,windowy2) for things scaled to the viewing
window or (0L,0L,xdim-1L,ydim-1L) for things scaled to full screen.
Probably the only time you wouldn't follow this rule is if you program
a non-scaled tiled background function.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
11/21/95 - Optimized cansee - before it was checking each red wall 2 times
as much as it needed to. Now it only checks the side facing
the first object passed to cansee. Since this optimization
is only 1 line, I don't think I messed anything up this time.
- Made cansee not pass through 1-way walls. This means that the
order of points passed to cansee could give you different
results, but only for 1-way walls.
- FIXED CRASHING AND PRECISION ON HIGH SLOPES!!! Try it for the
first time again! The bug was: In wallmost, if a slope's
line was getting clipped by both the top and bottom of the
screen, the x-intercept of the bottom was calculated wrong.
And if you were real lucky, if the x-intercept could have been
so wrong that a loop would happily overwrite random chunks of
memory.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/1/95 - In my GAME.C, made tilting zoom in smoothly as it rotates to
hide the ugly corners.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/4/95 - Made some more optimizations to rotatesprite - added more cases
for removing things from the permanent list early, such as:
any full screen rotatesprite with 64 knocks everything else
off the list, and any rotatesprites with zoom=65536,ang=0,
stat&64 will knock out anything totally under its rectangle.
These optimizations seemed to actually fix some bugs.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/10/95 - Well, well, well. It has now been 2 years since you know what
was released and Apogee still hasn't put out a (real) Build
game. Trivia of the year: Did you know that the first Build
game was originally scheduled to be released a month before
Doom was to be released? Maybe I should rename the "Build"
engine to the "ROTTT" engine because it's probably just going
to rot on my hard drive for another year until all the games
just get cancelled. PROVE ME WRONG!
- Added selectable viewing angles - not locked at 90ø anymore!
Try playing around with the ( ) - = keys on the main keyboard
in my new BSTUB.C. See the example code in BSTUB for setaspect.
Use the setaspect function to control both the viewing range
angle and the y/x aspect ratio.
setaspect(long daxrange, long daaspect)
For a standard 90ø 320*200 screen, daxrange and daaspect are
65536. For square aspect ratio at 320*400, set daaspect
to 131072. Since daxrange is actually zoom, you must
modify the aspect ratio inversely if you only want to
change the viewing angle.
ATTENTION EVERYONE! To make parallaxing skies work with larger
than 90ø viewing ranges, I had to change some things around
in TABLES.DAT. Don't forget to update to the new one! The
new one is smaller because I removed a useless array.
- Improved red-blue glasses mode by fixing some palette problems
and removing the overlap problem on the right side of the
screen. It still has some things wrong with it though.
- Perfected screen tilting by using the new setaspect function. It
now tilts all 360ø smoothly with no zoom change and with no
ugly corners. This is possible only because you can now set
the viewing angle higher than 90ø.
- Fixed a flicker bug with permanent rotatesprites in multi-page
modes. When rotatesprite was called because drawrooms in a
multipage mode, the rotatesprites were being called in the
wrong order from the fifo for the first page. Note that
before, the auto-knock out feature sometimes hid the problem.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/11/95 - Made EDITART work with the new TABLES.DAT.
- Upgraded to Watcom 10.5. The engine is now about 1K larger,
and 0.0000001% faster.
- Added some interesting compression routines to cache1d.obj,
dfread and dfwrite. These functions take the same parameters
as fread and fwrite respectively. These functions are useful
for loading/saving games or for recording demos.
Note: Since these functions need to allocate 118K off of my LRU
cacheing system, you must not call them before
initcache(loadpics) is called.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/18/95 - Made rotatesprite use getpalookup to get the palette shade.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/31/95 - Cleaned up KGROUP.EXE and wrote a KEXTRACT.EXE utility. With
KEXTRACT, you can extract any files from a group file.
Note that in KGROUP, DOS handles the ? and * wildcards whereas
in KEXTRACT, I had to program the wildcards myself for finding
files inside the group file. The following combinations
should work: *.*, *.map, game.*, tiles???.art, *.k??
- NEW NETWORK METHODS! TRY MY GAME IN MULTIPLAYER MODE! MODEM!
SUMMARY: Lag Time: ZERO! That's right Z.E.R.O. (0)
Smoothness: Perfect on ALL computers!
My new network code builds upon everything you've already
programed with faketimerhandler, getpackets, movethings, and
domovethings, so you don't need to throw away any of that
great stuff. There are actually 2 totally separate things I
did to improve the multiplayer performance. First I added a
new network mode which sends packets in a different way (this
is way Doom actually does it) Then I found a way to reduce
lag-time to 0 with perfect smoothness. (Doom does NOT do
this, but G&S like it anyway for some reason.) I will first
describe the new network mode:
-------------------------------------------------------------
1. First, let me describe the new network mode. Instead of
a master/slave system, every computer sends its own controls
to every other. You are currently using the master/slave
system which sends 2(n-1) packets per frame where n is the
number of players. My new network mode sends n(n-1) packets
per frame and treats every player evenly. See the chart
below of packets per frame:
2(n-1) method: n(n-1) method:
2 players 2 2
3 players 4 6
4 players 6 12
5 players 8 20 (OUCH!)
6 players 10 30 (OUCH!)
7 players 12 42 (OUCH!)
8 players 14 56 (OUCH!)
You may be asking why I am bothering you with this new
network method if it sends more packets then the old one?
I'll explain: With the old network method, slaves had to
wait for their packets to take 2 trips before they could move,
whereas with the new method the packets need to take only 1
trip. Also with the new method the players are treated
evenly. For 2 players, the new network method is definitly
the mode of choice since it sends the same number of packets
AND the packets can be smaller since each computer only needs
to send its own controls to the other computer, not everyone's
controls (good for modem play). It's up to you what your
break even point is before you switch into the old network
method. I recommend: 1-4 New, 5+ Old.
Now let me explain how the new method REALLY works. Since
every computer must call the movement code in the same order
to stay in sync, all computers must wait until every packet
is received for that frame before it can actually go into
the movement code. You could say that all the computers are
half-slaves. Your computer should always be ahead of the
other computers. If you are player 0, the packets you
currently have might look like this:
Chart for Player 0:
Player 0 Player 1 Player 2
Tic 0: GOTMINE------GOT--------GOT------> MOVE!
Tic 1: GOTMINE------GOT--------GOT------> MOVE!
Tic 2: GOTMINE--X WAITING... GOT CAN'T MOVE!
Tic 3: GOTMINE WAITING... WAITING... CAN'T MOVE!
Tic 4: GOTMINE WAITING... WAITING... CAN'T MOVE!
As soon as player 0 receives player 1's next packet,
player 0 can call domovethings for tic 2.
One interesting complication of the new network method is
the timing. If for some reason player 0 sends packets faster
than player 1, then player 1 will have no lag and player 0
will start with twice the normal lag which will increase
until bad things happen. See this chart:
Player 0's side: | Player 1's side:
Player 0: Player 1: | Player 0: Player 1:
Tic 5: GOTMINE GOT (MOVE) | GOT GOTMINE (MOVE)
Tic 6: GOTMINE WAITING | GOT GOTMINE (MOVE)
Tic 7: GOTMINE WAITING | GOT GOTMINE (MOVE)
Tic 8: GOTMINE WAITING | GOT GOTMINE (MOVE)
Tic 9: GOTMINE WAITING | GOT GOTMINE (MOVE)
| GOT
| GOT
| GOT
This can be corrected by sending a byte which tells the
other computer how many packets behind it is. You want the
other computer to be a little behind. Player 0's packet
delta in this case would be 4. Player 1's would be -3.
Another interesting thing about this network method is
that a slave's packet cannot be skipped like in the
master/slave system.
The actual code for everything described above is already
in my GAME.C and working perfectly. Go through the file
searching for the keyword, "networkmode". If it is non-zero,
that's the new mode. Look mainly at the section inside
faketimerhandler and case 17 of getpackets.
(I've talked about "2(n-1)" and "n(n-1)" networking modes.
Believe it or not, it's possible to do a network mode as
low as an "n" mode. I haven't done it due to some
inherent problems. I'd be impressed if you can figure out
how this one works)
-------------------------------------------------------------
2. Now I'll type about the "KLAG-0 Technology" I promised you.
The secret to life is, "
NO CARRIER
Why do you have to wait for another computer to tell you
when to move when you already know where you want to go?
So I added a fake set of variables that simulate
where the player's x, y, z, and ang variables will be after
it does sync crap with other computers. I added a function
called fakedomovethings which is called in the same fashion
that domovethings would be called in a 1-player game.
Fakedomovethings modifies ONLY the fake x, y, z, and ang
variables. It is a shadow of the processinput function. It
only needs the parts of processinput that modify the position
of player[myconnectindex]. If it modifies real variables,
the game will get out of sync.
Sometimes the fake variables can get out of sync with the
real variables. This can happen if you walk into another
player or anything else that moves. This doesn't happen too
often though and when it does, there are things that you can
do to smooth out the jump to the right position. This brings
me to my other new function: fakedomovethingscorrect.
The easy way to correct the player's position in a smooth
way is to say something like: fakex += ((realx-fakex)>>3);
This would effectively move the player 1/8th of the way closer
to the real position. The problem with this method is that
the realx and fakex are not sampled at the same time,
therefore creating more error than isn't any.
So instead of comparing your fake position with where the
real position was a few tics ago, I chose to compare both
of them a few tics ago. FIFO time! To do this, I am keeping
a fifo of the new fake positions and comparing the positions
as the real positions come. Now that they're being compared
at the same tic, correction will only occur when you've truly
run into a moving object.
-------------------------------------------------------------
I hope all this was as much fun for you to read as it was for
me to type. If you don't understand it, then I was probably
just trying to confuse you with all the possible word
combinations I could come up with that contain the letters in:
"fake", "sync", and "fifo".
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/6/96 - Made RT.SHIFT highlighting in build.obj not pick up non-existent
sprites in the selection rectangle.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/9/96 - Fixed a rare hitscan overflow bug for sectors that had a
ceiling&floor z-difference of more than 400000 z-units.
(About 20 stories tall)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/15/96 - Changed something in rotatesprite so that status bars could be
clipped easily by using the clipping parameters. (I never
knew this didn't work until now) This change will only affect
your code if you were using bits 2+8 and the clipping window
was something other than the standard (0,0,xdim-1,ydim-1).
- Improved fakedomovethingscorrect. Before when there was an
error, I was adding the difference into the current
position. This method conflicted with pushmove - where
sometimes it never fully corrected the position leaving you
stuck behind a wall. Now I make your position the position
it would have been if it had predicted the right position
several ticks ago. In other words, I set the my... variables
to the real, older position then call fakedomovethings for
every tic from the time of the real, older position up to
the current time.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/19/96 - Added snow reduction code to setpalette. It takes about 4 ms
to set a full palette. I write during the horizontal retrace
period to save time.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/23/96 - Added hack to loadboard to make it load a board only from the
group file if the last character of the filename is a 255.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1/25/96 - Fixed a stupid bug in UNIVBE segmented modes so it doesn't
flicker anymore. Why didn't you guys tell me about this
sooner!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/1/96 - Optimized cansee according to Peter's suggestions.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/2/96 - Made setview calls not mess up the stereo vision variables.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/5/96 - ATTENTIONS ALL PROGRAMMERS!!! If you use use any VGA registers
(such as 0x3da, or 0x3c6 - 0x3c9), you will need to re-code
those sections of code. Please make your BSTUB's work with
this too!
1. If you use register 0x3da, limitrate, or qlimitrate, you
will need to do a special check to see whether or not the
video mode is VGA register compatible. If you do not
check this, then the computer may lock up because register
0x3da simply doesn't change on certain video cards.
Unless you know the code won't be called in VESA mode, you
need to perform this check. Here's an example of how you
can do this check:
Instead of calling limitrate (or your own 0x3da function):
limitrate();
Do this:
//extern char vgacompatible;
if ((vidoption != 1) || (vgacompatible == 1)) limitrate();
2. You must now use my function to set or get any palette
registers. This means that the keywords "3c7", "3c8",
and "3c9" should not even exist in your code. I really
didn't want to force you to use my palette functions, but
since VESA 2.0 supports non VGA compatible cards, you must
do it this way. If you use setbrightness for all of your
palette setting, then you can ignore this. Note that the
palette format here is VESA's palette format, which is
different than my other palette control functions. It's
4 bytes and RGB are backwards. Here are the function
prototypes:
VBE_setPalette(long palstart, long palnum, char *dapal);
VBE_getPalette(long palstart, long palnum, char *dapal);
palstart is the offset of the first palette to set
palnum is the number of the palette entries to set
dapal is a pointer to the palette buffer. The palette
buffer must be in this format:
char Blue, Green, Red, reserved;
I think this format stinks, but since VESA 2.0 uses
it, the code will run fastest if the buffer is not
copied. You can make your own cover up function if
you don't like this format.
This example sets up a wasteful gray scale palette:
char mypalette[1024];
for(i=0;i<256;i++)
{
mypalette[i*4+0] = (i>>2); //Blue
mypalette[i*4+1] = (i>>2); //Green
mypalette[i*4+2] = (i>>2); //Red
mypalette[i*4+3] = 0; //reserved
}
VBE_setPalette(0,256,mypalette);
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/7/96 - Did some minor optimizations to functions that use cliptype.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/9/96 - ATTENTION PROGRAMMERS!!! There is no such thing as a cliptype
anymore! Instead you use clipmasks. Clipmasks are much better
because it gives you full control of which bits are used to
test whether or not a sprite or wall will block things.
Let me refresh your memory on how cliptypes used to work:
For CLIPMOVE, PUSHMOVE, and GETZRANGE:
If (cliptype == 0) these bits were the blocking bits:
(wall[].cstat&1), (sprite[].cstat&1)
If (cliptype == 1) these bits were the blocking bits:
(wall[].cstat&64), (sprite[].cstat&256)
For HITSCAN, cliptype was not passed and assumed to be 1:
(wall[].cstat&64), (sprite[].cstat&256)
Note that I added these 2 defines in BUILD.H:
#define CLIPMASK0 (((1L)<<16)+1L)
#define CLIPMASK1 (((256L)<<16)+64L)
In order to make clipmasks work, I had to change the parameters
to these 4 important functions. CLIPMOVE, PUSHMOVE, GETZRANGE,
and HITSCAN. For CLIPMOVE, PUSHMOVE, and GETZRANGE, I simply
made the cliptype from a char to a long. For HITSCAN, I had to
add the clipmask parameter at the end. Here are the new function
prototypes:
clipmove (long *x, long *y, long *z, short *sectnum, long xvect, long yvect,
long walldist, long ceildist, long flordist, unsigned long clipmask)
pushmove (long *x, long *y, long *z, short *sectnum,
long walldist, long ceildist, long flordist, unsigned long clipmask)
getzrange (long x, long y, long z, short sectnum,
long *ceilz, long *ceilhit, long *florz, long *florhit,
long walldist, unsigned long clipmask)
hitscan (long xs, long ys, long zs, short sectnum, long vx, long vy, long vz,
short *hitsect, short *hitwall, short *hitsprite,
long *hitx, long *hity, long *hitz, unsigned long clipmask)
You should convert your source code using these rules:
* For CLIPMOVE, PUSHMOVE, and GETZRANGE, look at the last
parameter. If it is a 0, then change it to say CLIPMASK0.
If it is a 1, then change it to say CLIPMASK1.
* For HITSCAN, add a new parameter that says CLIPMASK1.
* If you have your own movesprite function, then you will
need to make the cliptype parameter into a long variable.
- If you want to set a range for hitscan, or optimize its
performance, you can now extern these 2 variables from
the engine. You can set them just before you call hitscan.
If you DO choose to screw around with these variables, then
you must set them before EVERY hitscan in your code.
I have them defaulting to a really high number, totally out
of range of the map, but not high enough for a subtraction
to overflow it. These variables are used in hitscan only
to compare whether the new hit is closer then the last one.
long hitscangoalx = (1<<29)-1, hitscangoaly = (1<<29)-1;
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/13/96 - Fixed a bug in clipmove that showed up in the latest upload
related to sector searching.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/18/96 - Re-wrote waitforeverybody / case 250 of getpackets, so the slave
sends acknowledge packets in a better way. Before there was
a possibility of a slave sending an invalid acknowledge
packet if the last packet received was not 250.
- ATTENTION PROGRAMMERS! Setgamemode now returns -1 if the mode
is invalid or 0 if it is valid. Since the engine no longer
quits to DOS from an invalid video mode, you must program the
-1 case or else the computer will probably lock up!
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
3/5/96 - Solved tile index corruption bug in EDITART. After looking at
the latest art files I have from you, It looks like SW has
this problem, but DUKE and BLOOD seem ok. Let me explain:
In Editart 'V' mode (with no tile report), when you use
INSERT or DELETE, it very quickly moves all tiles after the
cursor forward or back 1. With multiple art files, this
operation would be very slow, since I'd have to load and
save every art file after the current one. But I figured
out a way to still keep it fast - instead of reading and
writing all the later art files, I instead changed just the
headers that tell which tile indeces the art files start and
end with. This works nice when you have 1 big art file, or
only 1 person using EDITART to change stuff.
Unfortunately, some of you have been passing around
individual art files and this is where the problem comes in.
If either person used INSERT of DELETE in 'V' mode and passed
an individual art file to another person, the headers could
possibly conflict and cause strange lockups or crashes in
EDITART, BUILD, or GAME.
So I fixed the problem by making EDITART only change the
CURRENT art file. Insert mode will now delete the last
tile in the CURRENT art file, so be careful that the last
tile in the CURRENT art file is blank. Delete will now
insert a blank tile at the end of the CURRENT art file.
If your ART files are already corrupt, you can run
RSIZEART.EXE and agree on a number of tiles per file.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
4/27/96 - Fixed a bug where rotatesprite seemed to clip the tile
to the viewing window even though stat&8 (don't clip
to startumosts/startdmosts) was set. The problem was
actually related to an optimization in the VESA blitting
code that copies only the screen if it thinks nothing
was drawn outside of the viewing window.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
6/15/96 - I must have added a whole bunch of unnoticable optimizations
since the last time I typed stuff into this file, but since
I didn't keeping track of it, I couldn't tell you what they
were off hand.
- I added support for the 'new' Crystal Eyes in such a way where
you don't have to mess with the timer. I use the real-time
clock (IRQ8) in order to avoid conflicts. Crystal Eyes mode
works only in VESA 2.0 modes with at least 4 pages. The nice
thing about this mode is that you can switch in and out of
it easily during the game. There are 2 very simple functions
and 3 variables you can extern. To use Crystal Eyes mode,
simply call initstereo(). Initstereo should be called after
setgamemode and the palette is loaded into the VGA. To
return back to normal mode, simply call uninitstereo().
Here's what the code would look like:
extern long stereomode, stereowidth, stereopixelwidth;
if (KEYTOTOGGLESTEREOMODE)
{
KEYTOTOGGLESTEREOMODE = 0;
if (stereomode == 0)
initstereo();
else
uninitstereo();
}
Notes:
* The following 2 variables can be changed any time, and
should always be >= 0.
stereowidth: distance between left and right eyes
stereopixelwidth: parallax - pan offset in pixels between
left & right screens
* initstereo automatically sets stereomode to nonzero and
uninitstereo automatically sets stereomode to 0.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
7/5/96 - Made cache1d.obj support up to 4 group files at the same time.
To use multiple group files, simply call initgroupfile again.
You need to uninitgroupfile only once. This is useful if
users want to add their own .ART, .VOC, or other files and
distribute it all in one file without telling people they
need to back up stuff. For example:
Beginning of program:
initgroupfile("duke3d.grp");
if (usergroupfile)
initgroupfile(usergroufile);
End of program:
uninitgroupfile();
Here's the order cache1d will search for a file when
kopen4load is called. Remember that the second parameter
to kopen4load is the searchfirst parameter. If you set
this variable to non-zero, you can tell kopen4load to search
the main group file only. This is useful if invalid user
files are detected.
if (searchfirst == 0)
{
1. Look for it as a stand-alone file
2. Look for it in the 4th group file (user group file)
3. Look for it in the 3rd group file (user group file)
4. Look for it in the 2nd group file (user group file)
}
5. Look for it in the 1st groupfile ("duke3d.grp")
6. If file still not found, return -1
- Fixed a stupid bug with choosing the side of a red line in BUILD
2D edit mode.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
7/24/96 - Increased MAXTILES to 6144. Fixed some scrolling errors related
to MAXTILES in 'V' mode of EDITART and BUILD.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
8/20/96 - Made it possible to safely default to NORMAL mode 320*200 when
VESA is not supported or found. Check out the beginning of
my setup3dscreen function. It shows how you can offer the
player a choice of quitting to DOS or continuing in NORMAL
mode. It is very annoying when setting up multiplayer games
when the game always quits to DOS because somebody forgot
to load their VESA driver.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/6/96 - Moved internal function, setfirstwall, in BUILD.OBJ into
ENGINE.OBJ because it can be useful to game programmers.
This function sets the first wall of a sector to be the
wall index passed. This function is useful for setting
the hinge wall for slopes or relative alignment. (ALT-F
uses this function) Here's the function:
setfirstwall(short sectnum, short newfirstwall)
- Added a variable, clipmoveboxtracenum, to ENGINE.OBJ which can
be externed. As a special case, if you set it to 1 just
before calling clipmove, then clipmove will return when it
first hits a wall - in other words, the (x,y,z) that clipmove
returns will be before any sliding calculations occur. Be
sure to set clipmoveboxtracenum back to 3 after calling
clipmove.
This is how it is defined in ENGINE.OBJ:
long clipmoveboxtracenum = 3;
Example of calling clipmove with no sliding:
clipmoveboxtracenum = 1;
i = clipmove(...);
clipmoveboxtracenum = 3;
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
9/25/96 - Removed support for specially optimized TSENG, Paradise, and S3
modes. If you want the engine to run as fast on these cards,
get Scitech Software's latest Vesa 2.0 driver.
- ATTENTION PROGRAMMERS! Added video mode changing during the game.
I moved the option, xdim, and ydim parameters from initengine
into the setgamemode function.
Here are the updated prototypes for the 2 functions:
initengine();
setgamemode(char newvidoption, long newxdim, long newydim);
You are free to call setgamemode as often as you like. If you
have very low memory, it's possible that the call will fail
and quit to DOS with one of those awful CACHE SPACE ALL LOCKED
UP messages.
Note: When updating your code, be careful to not rely on
vidoption, xdim, of ydim being valid until your first
setgamemode call. If you're not careful with this, you may
get a divide by zero or something. I had a bug in my GAME.C
where I was calling setview between initengine and
setgamemode. I had to move setview after setgamemode.
- Added function to the engine that returns all valid VESA modes.
getvalidvesamodes();
This function prepares the list of valid VESA modes in these
new variables which I put in BUILD.H. This function needs to
only be called once, but it doesn't hurt to call it multiple
times since I have a flag that checks if it has already been
called.
EXTERN long validmodecnt;
EXTERN short validmode[256];
EXTERN long validmodexdim[256], validmodeydim[256];
validmodecnt - number of available 256 color VESA modes.
validmode[] - array of vesa mode numbers (640*480 is 0x101, etc.)
validmodexdim[] - array of x dimensions for each mode
validmodeydim[] - array of y dimensions for each mode
In my GAME.C, I have code that cycles through all VESA modes
and screen buffer mode when you press F4. Search for the
keyword "//F4" to find it.
Note: Be careful when you call setgamemode! Be sure that it
is not called inside any function of sub-function of
faketimerhandler because this would be in the middle of the
drawing code. Actually, the safest place to call setgamemode is
right after nextpage in your main drawing loop.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
12/13/96 - Fixed the nasty caching bug first found in the Plutonium version
of Duke3D. I was using copybuf when I should have been using
copybufbyte.
- Made the '>' key in 3D EDIT MODE not lock up any more for
textures that have non power of 2 tilesizy's.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
2/12/97 - Optimized mirror code so it x-flips only the bounding rectangle
(x AND y). Actually calculates left & right boundaries instead
of using the horizontal line checking stuff which didn't really
work all the time anyway.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
5/22/97 - Frank noticed a divide overflow in clippoly when drawmapview was
in hi-res mode. -fixed by lowered precision from 16 to 12
bits.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
6/2/97 - Added support for the Nuvision 3D-Spex stereo glasses. I renamed
initstereo to setstereo and got rid of uninitstereo. Here's
complete documentation for all of the new stereo glasses stuff:
setstereo(0); //Set to default normal non-stereo mode
setstereo(1); //Use Stereographics Simuleyes (white line code)
setstereo(2); //Use Nuvision 3-D Spex stereo (uses LPT1)
//You can extern these 2 variables from the engine to add
//your own stereo adjustment code
extern long stereowidth = 23040;
extern long stereopixelwidth = 28;
It would be nice to allow the adjustment of these variables
inside the game, but if you're too lazy, it would be nice to
have some way of modifying it.
Please do not extern stereomode any more since I use it now
to uninit the old mode automatically. Use your own current
stereo mode variable.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
10/4/97 - I have upgraded to Watcom 11.0. The only changes I had to make
in the engine were some "#pragma push" and "#pragma pop"
calls in BUILD.H since the default structure packing alignment
was moved from 1 to 8. The sector, wall, and sprite structures
are already aligned well and must remain the same for .MAP
files to remain compatible.
- Increase MAXTILES for all utilities (EDITART,BUILD,GAME,etc.) to
9216 for Xatrix.
You may have some initial bugs with EDITART when you add new
tiles for the first time. I haven't touched the code in years
and I'm afraid if I did, I'd mess it up more. One bug I know
of is this: Let's say you have 256 tiles per art file, and
then you add 1 silly tile way up at picnum=8500. When you
save and quit, your directory may look like this:
TILES000.ART
TILES001.ART
TILES002.ART
TILES029.ART
When you load EDITART again, that 1 tile will not appear unless
you kind of mess with it and scroll around for a while. This
is because EDITART loads TILES###.ART files until 1 is not
found, meaning that it will stop when it doesn't find
TILES003.ART. There are probably some other nasty bugs like
this. To get around it, you could add 1 tile to the next file,
save and quit. Or you could use RSIZEART.EXE to make 1 huge
ART file, add 1 tile way up high (if you have enough memory),
and then run RSIZEART.EXE again to 256 tiles per file or
whatever you like. Remember that the ART files need to be split
in such a way that each individual .ART file must fit in
memory, or else EDITART will crash.
- It's time I document how you can add voxels to the Build engine.
The code is not the cleanest, but at least it works. First
you must load each voxel into memory using the qloadkvx
function. You specify the filename of the .KVX file and an
index that you want to use to reference the voxel. You can
pack .KVX files in a .GRP file if you want. The index must
be in this range: 0 <= index < MAXVOXELS where MAXVOXELS is
currently 512. This index works sort of like a picnum, but I
have a totally separate array for these indeces so you don't
need to mess with your art file at all. Since qloadkvx
allocates memory off of my cacheing system, you must call it
after loadpics which allocates all memory.
Function parameters:
void qloadkvx(long voxindex, char *filename)
loadpics("tiles000.art");
qloadkvx(0L,"voxel000.kvx");
qloadkvx(1L,"voxel001.kvx");
Now to actually display the voxel, you need to set the
(sprite[?].cstat&48) to equal 48 like this:
sprite[?].cstat |= 48;
I have no special collision code for voxels. They are simply
treated as face sprites.
If ((sprite[?].cstat&48) == 48)
You should set the sprite[?].picnum to equal the VOXEL
index of the voxel that you passed to qloadkvx. If you don't
do this you will see nothing. To handle this index remapping
it is a good idea to make some array like this:
short picnumtovox[MAXTILES];
and save the array in some file (or in the .GRP file)
Many other fields of the sprite structure also affect voxels,
such as: ang, shade, pal, xrepeat, yrepeat.
Note: To view voxels in the Build editor, you will need to do
the same qloadkvx calls in your BSTUB.C.
And now a warning: Voxels tend to draw the fastest when
they are tall and thin. For example, a telephone poll
would work just great. They slow down very quickly as
you add detail. This is why you don't see any large
voxels in SW and Blood.
- Something you should know about this version of the engine:
Over the summer, I got a lot of pressure from GT to add
MMX support to the Build engine, so I bought a Pentium II.
I messed around with the code quite a bit and discovered
that MMX really didn't help at all. In fact, in some ways
it made the code slower. The problem is that the inner
loops of Build are already optimized really well. I have
found that MMX is useful only because it gives you extra
registers. Unfortunately, the Build loops don't need extra
registers since they aren't very complex.
Now there are 2 major differences between an old Pentium and
a Pentium II. A Pentium II is like a Pentium PRO with MMX.
So I tried to optimize Build for Pentium PRO's. I was
actually able to get about a 50% speed increase mostly due
to avoiding those awful partial stalls. But there are
SEVERAL catches:
1. First of all, you need to enable WRITE-COMBINING for
video memory to get all this extra speed. One popular
program which does this is FASTVID. You should be able
to find it easily on the net. If you do not enable
WRITE-COMBINING, the engine actually runs SLOWER than
the original version! Unfortunately, neither DOS nor
WINDOWS 95 enable WRITE-COMBINING by default, so you need to
load a driver. Even worse, if you're in WINDOWS 95, the
program which enables WRITE-COMBINING will crash because
you can only set the PPRO registers in Priviledge Level 0.
You can still enable WRITE-COMBINING in WINDOWS 95, but you
have to run the program in your AUTOEXEC.BAT file. I wish
you all good luck on getting the average user to be able
to accomplish this feat. Quake has the same problem.
You'll find the same thing in their documentation.
2. The second catch is that my code tries to auto-detect
whether you have a Pentium, Pentium MMX, Pentium PRO, of
Pentium II. Of course this means, that if you don't have
an Intel processor, it's possible that the auto-detect code
may crash. I haven't had the opportunity to test this
myself. And since I can never guarantee it will always work
I made a way for you to disable the new code altogether
should this happen. Here's how you disable the new code
in the Build engine:
extern long dommxoverlay; //(from engine.obj)
Before you first call initengine, set dommxoverlay = 0;
The default is dommxoverlay = 1 and it will run the code.
!!! THIS IS NO LONGER TRUE.
!!! do #include "engine.h" in your code, and
!!! use setmmxoverlay(1) or setmmxoverlay(0) to set
!!! this BEFORE initengine. It defaults to 1, so you
!!! really only need to call this to disable the
!!! overlay. dommxoverlay is no longer exposed. You
!!! can also call int getmmxoverlay(void) to find out
!!! what you've set it to. The value is locked in
!!! once you call initengine(). --ryan. 05/22/2001
Reference in New Issue View Git Blame Copy Permalink