zdoom/gzdoom
0
0
Fork 0
mirror of https://github.com/ZDoom/gzdoom.git synced 2024-11-16 09:21:43 +00:00
Code Issues Projects Releases Packages Wiki Activity
gzdoom/src/p_setup.cpp

3792 lines
92 KiB
C++
Raw Normal View History

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
// Emacs style mode select -*- C++ -*-
//-----------------------------------------------------------------------------
//
// $Id:$
//
// Copyright (C) 1993-1996 by id Software, Inc.
//
// This source is available for distribution and/or modification
// only under the terms of the DOOM Source Code License as
// published by id Software. All rights reserved.
//
// The source is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// FITNESS FOR A PARTICULAR PURPOSE. See the DOOM Source Code License
// for more details.
//
// $Log:$
//
// DESCRIPTION:
// Do all the WAD I/O, get map description,
// set up initial state and misc. LUTs.
//
//-----------------------------------------------------------------------------
#include <math.h>
#ifdef _MSC_VER
#include <malloc.h> // for alloca()
#endif
#include "templates.h"
#include "m_alloc.h"
#include "m_argv.h"
#include "m_swap.h"
#include "m_bbox.h"
#include "g_game.h"
#include "i_system.h"
#include "w_wad.h"
#include "doomdef.h"
#include "p_local.h"
#include "p_effect.h"
#include "p_terrain.h"
#include "nodebuild.h"
#include "s_sound.h"
#include "doomstat.h"
#include "p_lnspec.h"
#include "v_palette.h"
#include "c_console.h"
#include "p_acs.h"
#include "vectors.h"
#include "announcer.h"
#include "wi_stuff.h"
#include "stats.h"
#include "doomerrors.h"
#include "gi.h"
#include "p_conversation.h"
#include "a_keys.h"
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
#include "s_sndseq.h"
#include "sbar.h"
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
#include "p_setup.h"
- Split off the entire translation code from r_draw.cpp into r_translate.cpp. - Moved the common code of ACS and DECORATE translation generation into the FRemapTable class. - Fixed: The DECORATE translation code was not changed for the new data structures. - Expanded range of ACS and DECORATE translations to 65535. - Fixed: R_CopyTranslation was not altered for the new functionality. I removed the function and replaced the one use with a simple assignment. SVN r644 (trunk)
2007-12-26 16:06:03 +00:00
#include "r_translate.h"
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
extern void P_SpawnMapThing (mapthing2_t *mthing, int position);
extern bool P_LoadBuildMap (BYTE *mapdata, size_t len, mapthing2_t **things, int *numthings);
extern void P_TranslateLineDef (line_t *ld, maplinedef_t *mld);
extern void P_TranslateTeleportThings (void);
extern int P_TranslateSectorSpecial (int);
extern int numinterpolations;
extern unsigned int R_OldBlend;
CVAR (Bool, genblockmap, false, CVAR_SERVERINFO|CVAR_GLOBALCONFIG);
CVAR (Bool, gennodes, false, CVAR_SERVERINFO|CVAR_GLOBALCONFIG);
CVAR (Bool, genglnodes, false, CVAR_SERVERINFO);
CVAR (Bool, showloadtimes, false, 0);
static void P_InitTagLists ();
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
static void P_Shutdown ();
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
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
//
// MAP related Lookup tables.
// Store VERTEXES, LINEDEFS, SIDEDEFS, etc.
//
int numvertexes;
vertex_t* vertexes;
int numsegs;
seg_t* segs;
int numsectors;
sector_t* sectors;
int numsubsectors;
subsector_t* subsectors;
int numnodes;
node_t* nodes;
int numlines;
line_t* lines;
int numsides;
side_t* sides;
int numzones;
zone_t* zones;
FExtraLight* ExtraLights;
FLightStack* LightStacks;
int sidecount;
struct sidei_t // [RH] Only keep BOOM sidedef init stuff around for init
{
union
{
// Used when unpacking sidedefs and assigning
// properties based on linedefs.
struct
{
short tag, special;
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
short alpha;
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
DWORD map;
} a;
// Used when grouping sidedefs into loops.
struct
{
DWORD first, next;
char lineside;
} b;
};
} *sidetemp;
static WORD *linemap;
bool UsingGLNodes;
// BLOCKMAP
// Created from axis aligned bounding box
// of the map, a rectangular array of
// blocks of size 256x256.
// Used to speed up collision detection
// by spatial subdivision in 2D.
//
// Blockmap size.
int bmapwidth;
int bmapheight; // size in mapblocks
int *blockmap; // int for larger maps ([RH] Made int because BOOM does)
int *blockmaplump; // offsets in blockmap are from here
fixed_t bmaporgx; // origin of block map
fixed_t bmaporgy;
FBlockNode** blocklinks; // for thing chains
// REJECT
// For fast sight rejection.
// Speeds up enemy AI by skipping detailed
// LineOf Sight calculation.
// Without special effect, this could be
// used as a PVS lookup as well.
//
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
BYTE* rejectmatrix;
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
static bool ForceNodeBuild;
// Maintain single and multi player starting spots.
TArray<mapthing2_t> deathmatchstarts (16);
mapthing2_t playerstarts[MAXPLAYERS];
static void P_AllocateSideDefs (int count);
static void P_SetSideNum (DWORD *sidenum_p, WORD sidenum);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
//
// GetMapIndex
//
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
// Gets the type of map lump or -1 if invalid or -2 if required and not found.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//
//===========================================================================
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
struct checkstruct
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{
- Fixed all the warnings from GCC 4.2, including a handful that were present in older GCCs. SVN r430 (trunk)
2006-12-29 03:38:37 +00:00
const char lumpname[9];
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
bool required;
};
static int GetMapIndex(const char *mapname, int lastindex, const char *lumpname, bool needrequired)
{
static const checkstruct check[] =
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{
- Fixed all the warnings from GCC 4.2, including a handful that were present in older GCCs. SVN r430 (trunk)
2006-12-29 03:38:37 +00:00
{"", true},
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
{"THINGS", true},
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{"LINEDEFS", true},
{"SIDEDEFS", true},
{"VERTEXES", true},
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
{"SEGS", false},
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{"SSECTORS", false},
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
{"NODES", false},
{"SECTORS", true},
{"REJECT", false},
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{"BLOCKMAP", false},
{"BEHAVIOR", false},
Fixed index variable in P_OpenMapData. SVN r192 (trunk)
2006-06-15 08:26:13 +00:00
//{"SCRIPTS", false},
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
};
if (lumpname==NULL) lumpname="";
for(size_t i=lastindex+1;i<countof(check);i++)
{
if (!strnicmp(lumpname, check[i].lumpname, 8))
return (int)i;
if (check[i].required)
{
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
if (needrequired)
{
I_Error("'%s' not found in %s\n", check[i].lumpname, mapname);
}
return -2;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
}
}
return -1; // End of map reached
}
//===========================================================================
//
// Opens a map for reading
//
//===========================================================================
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
MapData *P_OpenMapData(const char * mapname)
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{
MapData * map = new MapData;
bool externalfile = !strnicmp(mapname, "file:", 5);
if (externalfile)
{
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
mapname += 5;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!FileExists(mapname))
{
delete map;
return NULL;
}
map->file = new FileReader(mapname);
map->CloseOnDestruct = true;
}
else
{
FString fmt;
int lump_wad;
int lump_map;
int lump_name;
// Check for both *.wad and *.map in order to load Build maps
// as well. The higher one will take precedence.
lump_name = Wads.CheckNumForName(mapname);
fmt.Format("maps/%s.wad", mapname);
lump_wad = Wads.CheckNumForFullName(fmt);
fmt.Format("maps/%s.map", mapname);
lump_map = Wads.CheckNumForFullName(fmt);
if (lump_name > lump_wad && lump_name > lump_map && lump_name != -1)
{
- Did some minor reorganization of code in r_data.cpp (mostly to make handling of textures easier in GZDoom.) - Did some preparations to allow loading folders on the HD into the lump directory. SVN r298 (trunk)
2006-08-17 22:10:50 +00:00
int lumpfile=Wads.GetLumpFile(lump_name);
int nextfile=Wads.GetLumpFile(lump_name+1);
if (lumpfile != nextfile)
{
// The following lump is from a different file so whatever this is,
// it is not a multi-lump Doom level.
return map;
}
// This case can only happen if the lump is inside a real WAD file.
// As such any special handling for other types of lumps is skipped.
map->file = Wads.GetFileReader(lumpfile);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->CloseOnDestruct = false;
map->lumpnum = lump_name;
map->MapLumps[0].FilePos = Wads.GetLumpOffset(lump_name);
map->MapLumps[0].Size = Wads.LumpLength(lump_name);
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
map->Encrypted = Wads.IsEncryptedFile(lump_name);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
if (map->Encrypted)
{ // If it's encrypted, then it's a Blood file, presumably a map.
return map;
}
int index = 0;
for(int i = 1;; i++)
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
{
// Since levels must be stored in WADs they can't really have full
// names and for any valid level lump this always returns the short name.
const char * lumpname = Wads.GetLumpFullName(lump_name + i);
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
index = GetMapIndex(mapname, index, lumpname, i != 1 || map->MapLumps[0].Size == 0);
For some unknown reason the HasBehavior check in P_OpenMapData was gone. SVN r193 (trunk)
2006-06-15 16:23:41 +00:00
if (index == ML_BEHAVIOR) map->HasBehavior = true;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
// The next lump is not part of this map anymore
if (index < 0) break;
map->MapLumps[index].FilePos = Wads.GetLumpOffset(lump_name + i);
map->MapLumps[index].Size = Wads.LumpLength(lump_name + i);
Fixed index variable in P_OpenMapData. SVN r192 (trunk)
2006-06-15 08:26:13 +00:00
strncpy(map->MapLumps[index].Name, lumpname, 8);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
}
return map;
}
else
{
if (lump_map > lump_wad)
{
lump_wad = lump_map;
}
if (lump_wad == -1)
{
delete map;
return NULL;
}
map->lumpnum = lump_wad;
map->file = Wads.ReopenLumpNum(lump_wad);
map->CloseOnDestruct = true;
}
}
DWORD id;
(*map->file) >> id;
if (id == IWAD_ID || id == PWAD_ID)
{
char maplabel[9]="";
int index=0;
DWORD dirofs, numentries;
(*map->file) >> numentries >> dirofs;
map->file->Seek(dirofs, SEEK_SET);
for(DWORD i = 0; i < numentries; i++)
{
DWORD offset, size;
char lumpname[8];
(*map->file) >> offset >> size;
map->file->Read(lumpname, 8);
if (i>0)
{
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
index = GetMapIndex(maplabel, index, lumpname, true);
For some unknown reason the HasBehavior check in P_OpenMapData was gone. SVN r193 (trunk)
2006-06-15 16:23:41 +00:00
if (index == ML_BEHAVIOR) map->HasBehavior = true;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
// The next lump is not part of this map anymore
if (index < 0) break;
}
else
{
strncpy(maplabel, lumpname, 8);
maplabel[8]=0;
}
map->MapLumps[index].FilePos = offset;
map->MapLumps[index].Size = size;
Fixed index variable in P_OpenMapData. SVN r192 (trunk)
2006-06-15 08:26:13 +00:00
strncpy(map->MapLumps[index].Name, lumpname, 8);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
}
}
else
{
// This is a Build map and not subject to WAD consistency checks.
map->MapLumps[0].Size = map->file->GetLength();
}
return map;
}
//===========================================================================
//
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
// [RH] Figure out blends for deep water sectors
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//
//===========================================================================
- Fixed: Backpacks didn't increase the ammo capacity to BackpackMaxAmount if an ammo type's BackpackAmount was 0. - Fixed some minor bugs in custom skill code. SVN r562 (trunk)
2007-11-04 08:39:05 +00:00
static void SetTexture (int *texture, DWORD *blend, char *name8)
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
{
char name[9];
strncpy (name, name8, 8);
name[8] = 0;
if ((*blend = R_ColormapNumForName (name)) == 0)
{
if ((*texture = TexMan.CheckForTexture (name, FTexture::TEX_Wall,
FTextureManager::TEXMAN_Overridable|FTextureManager::TEXMAN_TryAny)
) == -1)
{
char name2[9];
char *stop;
strncpy (name2, name, 8);
name2[8] = 0;
*blend = strtoul (name2, &stop, 16);
*texture = 0;
}
else
{
*blend = 0;
}
}
else
{
*texture = 0;
}
}
- Fixed: Backpacks didn't increase the ammo capacity to BackpackMaxAmount if an ammo type's BackpackAmount was 0. - Fixed some minor bugs in custom skill code. SVN r562 (trunk)
2007-11-04 08:39:05 +00:00
static void SetTextureNoErr (int *texture, DWORD *color, char *name8, bool *validcolor)
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
{
char name[9];
strncpy (name, name8, 8);
name[8] = 0;
if ((*texture = TexMan.CheckForTexture (name, FTexture::TEX_Wall,
FTextureManager::TEXMAN_Overridable|FTextureManager::TEXMAN_TryAny)
) == -1)
{
char name2[9];
char *stop;
strncpy (name2, name, 8);
name2[8] = 0;
*color = strtoul (name2, &stop, 16);
*texture = 0;
- Fixed: Weapons did not give you double ammo at baby and nightmare skills. - 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)
2006-09-09 01:14:13 +00:00
*validcolor = (*stop == 0) && (stop >= name2 + 2) && (stop <= name2 + 6);
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
}
else
{
*validcolor = false;
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
//
// Sound enviroment handling
//
//===========================================================================
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
void P_FloodZone (sector_t *sec, int zonenum)
{
int i;
if (sec->ZoneNumber == zonenum)
return;
sec->ZoneNumber = zonenum;
for (i = 0; i < sec->linecount; ++i)
{
line_t *check = sec->lines[i];
sector_t *other;
if (check->sidenum[1] == NO_SIDE || (check->flags & ML_ZONEBOUNDARY))
continue;
if (check->frontsector == sec)
other = check->backsector;
else
other = check->frontsector;
if (other->ZoneNumber != zonenum)
P_FloodZone (other, zonenum);
}
}
void P_FloodZones ()
{
int z = 0, i;
for (i = 0; i < numsectors; ++i)
{
if (sectors[i].ZoneNumber == 0xFFFF)
{
P_FloodZone (&sectors[i], z++);
}
}
numzones = z;
zones = new zone_t[z];
for (i = 0; i < z; ++i)
{
zones[i].Environment = DefaultEnvironments[0];
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadVertexes
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadVertexes (MapData * map)
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
{
int i;
// Determine number of vertices:
// total lump length / vertex record length.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numvertexes = map->MapLumps[ML_VERTEXES].Size / sizeof(mapvertex_t);
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
if (numvertexes == 0)
{
I_Error ("Map has no vertices.\n");
}
// Allocate memory for buffer.
vertexes = new vertex_t[numvertexes];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_VERTEXES);
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
// Copy and convert vertex coordinates, internal representation as fixed.
for (i = 0; i < numvertexes; i++)
{
SWORD x, y;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
(*map->file) >> x >> y;
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
vertexes[i].x = x << FRACBITS;
vertexes[i].y = y << FRACBITS;
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadZSegs
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
void P_LoadZSegs (FileReaderZ &data)
{
for (int i = 0; i < numsegs; ++i)
{
line_t *ldef;
DWORD v1, v2;
WORD line;
BYTE side;
data >> v1 >> v2 >> line >> side;
segs[i].v1 = &vertexes[v1];
segs[i].v2 = &vertexes[v2];
segs[i].linedef = ldef = &lines[line];
segs[i].sidedef = &sides[ldef->sidenum[side]];
segs[i].PartnerSeg = NULL;
segs[i].frontsector = sides[ldef->sidenum[side]].sector;
if (ldef->flags & ML_TWOSIDED && ldef->sidenum[side^1] != NO_SIDE)
{
segs[i].backsector = sides[ldef->sidenum[side^1]].sector;
}
else
{
segs[i].backsector = 0;
ldef->flags &= ~ML_TWOSIDED;
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadGLZSegs
//
// This is the GL nodes version of the above function.
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
void P_LoadGLZSegs (FileReaderZ &data)
{
for (int i = 0; i < numsubsectors; ++i)
{
for (size_t j = 0; j < subsectors[i].numlines; ++j)
{
seg_t *seg;
DWORD v1, partner;
WORD line;
BYTE side;
data >> v1 >> partner >> line >> side;
seg = &segs[subsectors[i].firstline + j];
seg->v1 = &vertexes[v1];
if (j == 0)
{
seg[subsectors[i].numlines - 1].v2 = seg->v1;
}
else
{
seg[-1].v2 = seg->v1;
}
if (partner == 0xFFFFFFFF)
{
seg->PartnerSeg = NULL;
}
else
{
seg->PartnerSeg = &segs[partner];
}
if (line != 0xFFFF)
{
line_t *ldef;
seg->linedef = ldef = &lines[line];
seg->sidedef = &sides[ldef->sidenum[side]];
seg->frontsector = sides[ldef->sidenum[side]].sector;
if (ldef->flags & ML_TWOSIDED && ldef->sidenum[side^1] != NO_SIDE)
{
seg->backsector = sides[ldef->sidenum[side^1]].sector;
}
else
{
seg->backsector = 0;
ldef->flags &= ~ML_TWOSIDED;
}
}
else
{
seg->linedef = NULL;
seg->sidedef = NULL;
seg->frontsector = seg->backsector = segs[subsectors[i].firstline].frontsector;
}
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadZNodes
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
static void P_LoadZNodes (FileReader &dalump, DWORD id)
{
FileReaderZ data (dalump);
DWORD i;
// Read extra vertices added during node building
DWORD orgVerts, newVerts;
vertex_t *newvertarray;
data >> orgVerts >> newVerts;
if (orgVerts + newVerts == (DWORD)numvertexes)
{
newvertarray = vertexes;
}
else
{
newvertarray = new vertex_t[orgVerts + newVerts];
memcpy (newvertarray, vertexes, orgVerts * sizeof(vertex_t));
}
for (i = 0; i < newVerts; ++i)
{
data >> newvertarray[i + orgVerts].x >> newvertarray[i + orgVerts].y;
}
if (vertexes != newvertarray)
{
for (i = 0; i < (DWORD)numlines; ++i)
{
lines[i].v1 = lines[i].v1 - vertexes + newvertarray;
lines[i].v2 = lines[i].v2 - vertexes + newvertarray;
}
delete[] vertexes;
vertexes = newvertarray;
numvertexes = orgVerts + newVerts;
}
// Read the subsectors
DWORD numSubs, currSeg;
data >> numSubs;
numsubsectors = numSubs;
subsectors = new subsector_t[numSubs];
memset (subsectors, 0, numsubsectors*sizeof(subsector_t));
for (i = currSeg = 0; i < numSubs; ++i)
{
DWORD numsegs;
data >> numsegs;
subsectors[i].firstline = currSeg;
subsectors[i].numlines = numsegs;
currSeg += numsegs;
}
// Read the segs
DWORD numSegs;
data >> numSegs;
// The number of segs stored should match the number of
// segs used by subsectors.
if (numSegs != currSeg)
{
Printf ("Incorrect number of segs in nodes.\n");
delete[] subsectors;
ForceNodeBuild = true;
return;
}
numsegs = numSegs;
segs = new seg_t[numsegs];
memset (segs, 0, numsegs*sizeof(seg_t));
if (id == MAKE_ID('Z','N','O','D'))
{
P_LoadZSegs (data);
}
else
{
P_LoadGLZSegs (data);
}
// Read nodes
DWORD numNodes;
data >> numNodes;
numnodes = numNodes;
nodes = new node_t[numNodes];
memset (nodes, 0, sizeof(node_t)*numNodes);
for (i = 0; i < numNodes; ++i)
{
SWORD x, y, dx, dy;
data >> x >> y >> dx >> dy;
nodes[i].x = x << FRACBITS;
nodes[i].y = y << FRACBITS;
nodes[i].dx = dx << FRACBITS;
nodes[i].dy = dy << FRACBITS;
for (int j = 0; j < 2; ++j)
{
for (int k = 0; k < 4; ++k)
{
SWORD coord;
data >> coord;
nodes[i].bbox[j][k] = coord << FRACBITS;
}
}
for (int m = 0; m < 2; ++m)
{
DWORD child;
data >> child;
if (child & 0x80000000)
{
nodes[i].children[m] = (BYTE *)&subsectors[child & 0x7FFFFFFF] + 1;
}
else
{
nodes[i].children[m] = &nodes[child];
}
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadSegs
//
// killough 5/3/98: reformatted, cleaned up
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//
//===========================================================================
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadSegs (MapData * map)
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
{
int i;
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
BYTE *data;
BYTE *vertchanged = new BYTE[numvertexes]; // phares 10/4/98
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
DWORD segangle;
line_t* line; // phares 10/4/98
int ptp_angle; // phares 10/4/98
int delta_angle; // phares 10/4/98
int dis; // phares 10/4/98
int dx,dy; // phares 10/4/98
int vnum1,vnum2; // phares 10/4/98
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->MapLumps[ML_SEGS].Size;
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
memset (vertchanged,0,numvertexes); // phares 10/4/98
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numsegs = lumplen / sizeof(mapseg_t);
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
if (numsegs == 0)
{
Printf ("This map has no segs.\n");
delete[] subsectors;
delete[] nodes;
SVN r49 (trunk)
2006-04-16 13:29:50 +00:00
delete[] vertchanged;
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
ForceNodeBuild = true;
return;
}
segs = new seg_t[numsegs];
memset (segs, 0, numsegs*sizeof(seg_t));
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
data = new BYTE[lumplen];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Read(ML_SEGS, data);
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
// phares: 10/4/98: Vertchanged is an array that represents the vertices.
// Mark those used by linedefs. A marked vertex is one that is not a
// candidate for movement further down.
line = lines;
for (i = 0; i < numlines ; i++, line++)
{
vertchanged[line->v1 - vertexes] = vertchanged[line->v2 - vertexes] = 1;
}
try
{
for (i = 0; i < numsegs; i++)
{
seg_t *li = segs+i;
mapseg_t *ml = (mapseg_t *) data + i;
int side, linedef;
line_t *ldef;
- Version bump to 2.1.5. - Fixed: P_LoadSegs() checked for invalid vertices too late. SVN r320 (trunk)
2006-09-01 22:09:03 +00:00
vnum1 = LittleShort(ml->v1);
vnum2 = LittleShort(ml->v2);
if (vnum1 >= numvertexes || vnum2 >= numvertexes)
{
throw i * 4;
}
li->v1 = &vertexes[vnum1];
li->v2 = &vertexes[vnum2];
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
li->PartnerSeg = NULL;
segangle = (WORD)LittleShort(ml->angle);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
// phares 10/4/98: In the case of a lineseg that was created by splitting
// another line, it appears that the line angle is inherited from the
// father line. Due to roundoff, the new vertex may have been placed 'off
// the line'. When you get close to such a line, and it is very short,
// it's possible that the roundoff error causes 'firelines', the thin
// lines that can draw from screen top to screen bottom occasionally. This
// is due to all the angle calculations that are done based on the line
// angle, the angles from the viewer to the vertices, and the viewer's
// angle in the world. In the case of firelines, the rounded-off position
// of one of the vertices determines one of these angles, and introduces
// an error in the scaling factor for mapping textures and determining
// where on the screen the ceiling and floor spans should be shown. For a
// fireline, the engine thinks the ceiling bottom and floor top are at the
// midpoint of the screen. So you get ceilings drawn all the way down to the
// screen midpoint, and floors drawn all the way up. Thus 'firelines'. The
// name comes from the original sighting, which involved a fire texture.
//
// To correct this, reset the vertex that was added so that it sits ON the
// split line.
//
// To know which of the two vertices was added, its number is greater than
// that of the last of the author-created vertices. If both vertices of the
// line were added by splitting, pick the higher-numbered one. Once you've
// changed a vertex, don't change it again if it shows up in another seg.
//
// To determine if there's an error in the first place, find the
// angle of the line between the two seg vertices. If it's one degree or more
// off, then move one vertex. This may seem insignificant, but one degree
// errors _can_ cause firelines.
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
ptp_angle = R_PointToAngle2 (li->v1->x, li->v1->y, li->v2->x, li->v2->y);
dis = 0;
delta_angle = (abs(ptp_angle-(segangle<<16))>>ANGLETOFINESHIFT)*360/FINEANGLES;
if (delta_angle != 0)
{
segangle >>= (ANGLETOFINESHIFT-16);
dx = (li->v1->x - li->v2->x)>>FRACBITS;
dy = (li->v1->y - li->v2->y)>>FRACBITS;
dis = ((int) sqrt((double)(dx*dx + dy*dy)))<<FRACBITS;
dx = finecosine[segangle];
dy = finesine[segangle];
if ((vnum2 > vnum1) && (vertchanged[vnum2] == 0))
{
li->v2->x = li->v1->x + FixedMul(dis,dx);
li->v2->y = li->v1->y + FixedMul(dis,dy);
vertchanged[vnum2] = 1; // this was changed
}
else if (vertchanged[vnum1] == 0)
{
li->v1->x = li->v2->x - FixedMul(dis,dx);
li->v1->y = li->v2->y - FixedMul(dis,dy);
vertchanged[vnum1] = 1; // this was changed
}
}
linedef = LittleShort(ml->linedef);
if ((unsigned)linedef >= (unsigned)numlines)
{
throw i * 4 + 1;
}
ldef = &lines[linedef];
li->linedef = ldef;
side = LittleShort(ml->side);
if ((unsigned)ldef->sidenum[side] >= (unsigned)numsides)
{
throw i * 4 + 2;
}
li->sidedef = &sides[ldef->sidenum[side]];
li->frontsector = sides[ldef->sidenum[side]].sector;
// killough 5/3/98: ignore 2s flag if second sidedef missing:
if (ldef->flags & ML_TWOSIDED && ldef->sidenum[side^1] != NO_SIDE)
{
li->backsector = sides[ldef->sidenum[side^1]].sector;
}
else
{
li->backsector = 0;
ldef->flags &= ~ML_TWOSIDED;
}
}
}
catch (int foo)
{
switch (foo & 3)
{
case 0:
Printf ("Seg %d references a nonexistant vertex.\n", foo >> 2);
break;
case 1:
Printf ("Seg %d references a nonexistant linedef.\n", foo >> 2);
break;
case 2:
Printf ("The linedef for seg %d references a nonexistant sidedef.\n", foo >> 2);
break;
}
Printf ("The BSP will be rebuilt.\n");
delete[] segs;
delete[] subsectors;
delete[] nodes;
ForceNodeBuild = true;
}
delete[] vertchanged; // phares 10/4/98
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] data;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadSubsectors
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadSubsectors (MapData * map)
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
{
int i;
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
DWORD maxseg = map->Size(ML_SEGS) / sizeof(mapseg_t);
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numsubsectors = map->MapLumps[ML_SSECTORS].Size / sizeof(mapsubsector_t);
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (numsubsectors == 0 || maxseg == 0 )
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
{
Printf ("This map has an incomplete BSP tree.\n");
delete[] nodes;
ForceNodeBuild = true;
return;
}
subsectors = new subsector_t[numsubsectors];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_SSECTORS);
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
memset (subsectors, 0, numsubsectors*sizeof(subsector_t));
for (i = 0; i < numsubsectors; i++)
{
WORD numsegs, firstseg;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
(*map->file) >> numsegs >> firstseg;
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
if (numsegs == 0)
{
Printf ("Subsector %i is empty.\n", i);
delete[] subsectors;
delete[] nodes;
ForceNodeBuild = true;
return;
}
subsectors[i].numlines = numsegs;
subsectors[i].firstline = firstseg;
if (subsectors[i].firstline >= maxseg)
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
Printf ("Subsector %d contains invalid segs %u-%u\n"
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
"The BSP will be rebuilt.\n", i, subsectors[i].firstline,
subsectors[i].firstline + subsectors[i].numlines - 1);
ForceNodeBuild = true;
delete[] nodes;
delete[] subsectors;
break;
}
else if (subsectors[i].firstline + subsectors[i].numlines > maxseg)
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
Printf ("Subsector %d contains invalid segs %u-%u\n"
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
"The BSP will be rebuilt.\n", i, maxseg,
subsectors[i].firstline + subsectors[i].numlines - 1);
ForceNodeBuild = true;
delete[] nodes;
delete[] subsectors;
break;
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadSectors
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadSectors (MapData * map)
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
{
char fname[9];
int i;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
char *msp;
mapsector_t *ms;
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
sector_t* ss;
int defSeqType;
FDynamicColormap *fogMap, *normMap;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->Size(ML_SECTORS);
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numsectors = lumplen / sizeof(mapsector_t);
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
sectors = new sector_t[numsectors];
memset (sectors, 0, numsectors*sizeof(sector_t));
if (level.flags & LEVEL_SNDSEQTOTALCTRL)
defSeqType = 0;
else
defSeqType = -1;
fogMap = normMap = NULL;
fname[8] = 0;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
msp = new char[lumplen];
map->Read(ML_SECTORS, msp);
ms = (mapsector_t*)msp;
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
ss = sectors;
for (i = 0; i < numsectors; i++, ss++, ms++)
{
ss->floortexz = LittleShort(ms->floorheight)<<FRACBITS;
ss->floorplane.d = -ss->floortexz;
ss->floorplane.c = FRACUNIT;
ss->floorplane.ic = FRACUNIT;
ss->ceilingtexz = LittleShort(ms->ceilingheight)<<FRACBITS;
ss->ceilingplane.d = ss->ceilingtexz;
ss->ceilingplane.c = -FRACUNIT;
ss->ceilingplane.ic = -FRACUNIT;
strncpy (fname, ms->floorpic, 8);
ss->floorpic = TexMan.GetTexture (fname, FTexture::TEX_Flat, FTextureManager::TEXMAN_Overridable);
strncpy (fname, ms->ceilingpic, 8);
ss->ceilingpic = TexMan.GetTexture (fname, FTexture::TEX_Flat, FTextureManager::TEXMAN_Overridable);
ss->lightlevel = clamp (LittleShort(ms->lightlevel), (short)0, (short)255);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (map->HasBehavior)
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
ss->special = LittleShort(ms->special);
else // [RH] Translate to new sector special
ss->special = P_TranslateSectorSpecial (LittleShort(ms->special));
SVN r27 (trunk)
2006-04-11 16:27:41 +00:00
ss->oldspecial = !!(ss->special&SECRET_MASK);
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
ss->tag = LittleShort(ms->tag);
ss->thinglist = NULL;
ss->touching_thinglist = NULL; // phares 3/14/98
ss->seqType = defSeqType;
ss->nextsec = -1; //jff 2/26/98 add fields to support locking out
ss->prevsec = -1; // stair retriggering until build completes
// killough 3/7/98:
ss->floor_xscale = FRACUNIT; // [RH] floor and ceiling scaling
ss->floor_yscale = FRACUNIT;
ss->ceiling_xscale = FRACUNIT;
ss->ceiling_yscale = FRACUNIT;
ss->heightsec = NULL; // sector used to get floor and ceiling height
// killough 3/7/98: end changes
ss->gravity = 1.f; // [RH] Default sector gravity of 1.0
ss->ZoneNumber = 0xFFFF;
// [RH] Sectors default to white light with the default fade.
// If they are outside (have a sky ceiling), they use the outside fog.
- Added teamgame fix for menu by Karate Chris. - Added GZDoom's Sector_Outside sector type which forces outside fog regardless of ceiling texture. SVN r670 (trunk)
2008-01-06 10:05:24 +00:00
if (level.outsidefog != 0xff000000 && (ss->ceilingpic == skyflatnum || (ss->special&0xff) == Sector_Outside))
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
{
if (fogMap == NULL)
fogMap = GetSpecialLights (PalEntry (255,255,255), level.outsidefog, 0);
ss->ColorMap = fogMap;
}
else
{
if (normMap == NULL)
normMap = GetSpecialLights (PalEntry (255,255,255), level.fadeto, NormalLight.Desaturate);
ss->ColorMap = normMap;
}
// killough 8/28/98: initialize all sectors to normal friction
ss->friction = ORIG_FRICTION;
ss->movefactor = ORIG_FRICTION_FACTOR;
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] msp;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadNodes
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadNodes (MapData * map)
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
{
FMemLump data;
int i;
int j;
int k;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
char *mnp;
mapnode_t *mn;
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
node_t* no;
WORD* used;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->Size(ML_NODES);
int maxss = map->Size(ML_SSECTORS) / sizeof(mapsubsector_t);
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numnodes = lumplen / sizeof(mapnode_t);
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
if ((numnodes == 0 && maxss != 1) || maxss == 0)
{
ForceNodeBuild = true;
return;
}
nodes = new node_t[numnodes];
used = (WORD *)alloca (sizeof(WORD)*numnodes);
memset (used, 0, sizeof(WORD)*numnodes);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mnp = new char[lumplen];
mn = (mapnode_t*)mnp;
map->Read(ML_NODES, mn);
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
no = nodes;
for (i = 0; i < numnodes; i++, no++, mn++)
{
no->x = LittleShort(mn->x)<<FRACBITS;
no->y = LittleShort(mn->y)<<FRACBITS;
no->dx = LittleShort(mn->dx)<<FRACBITS;
no->dy = LittleShort(mn->dy)<<FRACBITS;
for (j = 0; j < 2; j++)
{
WORD child = LittleShort(mn->children[j]);
if (child & NF_SUBSECTOR)
{
child &= ~NF_SUBSECTOR;
if (child >= maxss)
{
Printf ("BSP node %d references invalid subsector %d.\n"
"The BSP will be rebuilt.\n", i, child);
ForceNodeBuild = true;
delete[] nodes;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mnp;
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
return;
}
no->children[j] = (BYTE *)&subsectors[child] + 1;
}
else if (child >= numnodes)
{
Printf ("BSP node %d references invalid node %d.\n"
"The BSP will be rebuilt.\n", i, (node_t *)no->children[j] - nodes);
ForceNodeBuild = true;
delete[] nodes;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mnp;
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
return;
}
else if (used[child])
{
Printf ("BSP node %d references node %d,\n"
"which is already used by node %d.\n"
"The BSP will be rebuilt.\n", i, child, used[child]-1);
ForceNodeBuild = true;
delete[] nodes;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mnp;
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
return;
}
else
{
no->children[j] = &nodes[child];
used[child] = j + 1;
}
for (k = 0; k < 4; k++)
{
no->bbox[j][k] = LittleShort(mn->bbox[j][k])<<FRACBITS;
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mnp;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadThings
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadThings (MapData * map, int position)
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
{
mapthing2_t mt2; // [RH] for translation
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->Size(ML_THINGS);
int numthings = lumplen / sizeof(mapthing_t);
char *mtp;
mapthing_t *mt;
mtp = new char[lumplen];
map->Read(ML_THINGS, mtp);
mt = (mapthing_t*)mtp;
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
// [RH] ZDoom now uses Hexen-style maps as its native format.
// Since this is the only place where Doom-style Things are ever
// referenced, we translate them into a Hexen-style thing.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
for (int i=0 ; i < numthings; i++, mt++)
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
{
// [RH] At this point, monsters unique to Doom II were weeded out
// if the IWAD wasn't for Doom II. R_SpawnMapThing() can now
// handle these and more cases better, so we just pass it
// everything and let it decide what to do with them.
// [RH] Need to translate the spawn flags to Hexen format.
short flags = LittleShort(mt->options);
memset (&mt2, 0, sizeof(mt2));
mt2.flags = (short)((flags & 0xf) | 0x7e0);
if (gameinfo.gametype == GAME_Strife)
{
mt2.flags &= ~MTF_AMBUSH;
if (flags & STF_SHADOW) mt2.flags |= MTF_SHADOW;
if (flags & STF_ALTSHADOW) mt2.flags |= MTF_ALTSHADOW;
if (flags & STF_STANDSTILL) mt2.flags |= MTF_STANDSTILL;
if (flags & STF_AMBUSH) mt2.flags |= MTF_AMBUSH;
if (flags & STF_FRIENDLY) mt2.flags |= MTF_FRIENDLY;
}
else
{
if (flags & BTF_BADEDITORCHECK)
{
flags &= 0x1F;
}
if (flags & BTF_NOTDEATHMATCH) mt2.flags &= ~MTF_DEATHMATCH;
if (flags & BTF_NOTCOOPERATIVE) mt2.flags &= ~MTF_COOPERATIVE;
if (flags & BTF_FRIENDLY) mt2.flags |= MTF_FRIENDLY;
}
if (flags & BTF_NOTSINGLE) mt2.flags &= ~MTF_SINGLE;
mt2.x = LittleShort(mt->x);
mt2.y = LittleShort(mt->y);
mt2.angle = LittleShort(mt->angle);
mt2.type = LittleShort(mt->type);
P_SpawnMapThing (&mt2, position);
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete [] mtp;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_SpawnSlopeMakers
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
static void P_SlopeLineToPoint (int lineid, fixed_t x, fixed_t y, fixed_t z, bool slopeCeil)
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
{
int linenum = -1;
while ((linenum = P_FindLineFromID (lineid, linenum)) != -1)
{
const line_t *line = &lines[linenum];
sector_t *sec;
secplane_t *plane;
if (P_PointOnLineSide (x, y, line) == 0)
{
sec = line->frontsector;
}
else
{
sec = line->backsector;
}
if (sec == NULL)
{
continue;
}
if (slopeCeil)
{
plane = &sec->ceilingplane;
}
else
{
plane = &sec->floorplane;
}
- 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
FVector3 p, v1, v2, cross;
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
p[0] = FIXED2FLOAT (line->v1->x);
p[1] = FIXED2FLOAT (line->v1->y);
p[2] = FIXED2FLOAT (plane->ZatPoint (line->v1->x, line->v1->y));
v1[0] = FIXED2FLOAT (line->dx);
v1[1] = FIXED2FLOAT (line->dy);
v1[2] = FIXED2FLOAT (plane->ZatPoint (line->v2->x, line->v2->y)) - p[2];
v2[0] = FIXED2FLOAT (x - line->v1->x);
v2[1] = FIXED2FLOAT (y - line->v1->y);
v2[2] = FIXED2FLOAT (z) - p[2];
- 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
cross = v1 ^ v2;
double len = cross.Length();
if (len == 0)
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
{
Fixed: Compiling with mingw once again works, although savegame loading problems are not yet fixed. SVN r31 (trunk)
2006-04-12 03:03:58 +00:00
Printf ("Slope thing at (%d,%d) lies directly on its target line.\n", int(x>>16), int(y>>16));
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
return;
}
- 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
cross /= len;
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
// Fix backward normals
- 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
if ((cross.Z < 0 && !slopeCeil) || (cross.Z > 0 && slopeCeil))
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
{
- 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
cross = -cross;
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
}
plane->a = FLOAT2FIXED (cross[0]);
plane->b = FLOAT2FIXED (cross[1]);
plane->c = FLOAT2FIXED (cross[2]);
//plane->ic = FLOAT2FIXED (1.f/cross[2]);
plane->ic = DivScale32 (1, plane->c);
plane->d = -TMulScale16 (plane->a, x,
plane->b, y,
plane->c, z);
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
//
// P_CopyPlane
//
//===========================================================================
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
static void P_CopyPlane (int tag, fixed_t x, fixed_t y, bool copyCeil)
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
{
- added a P_PointInSector function and replaced all calls to retrieve an actor's sector in the game engine code with it. This way there's a clear distinction between renderer-specific and game-specific calls. SVN r638 (trunk)
2007-12-25 10:07:58 +00:00
sector_t *dest = P_PointInSector (x, y);
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
sector_t *source;
int secnum;
size_t planeofs;
secnum = P_FindSectorFromTag (tag, -1);
if (secnum == -1)
{
return;
}
source = &sectors[secnum];
if (copyCeil)
{
planeofs = myoffsetof(sector_t, ceilingplane);
}
else
{
planeofs = myoffsetof(sector_t, floorplane);
}
*(secplane_t *)((BYTE *)dest + planeofs) = *(secplane_t *)((BYTE *)source + planeofs);
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
//
// P_SetSlope
//
//===========================================================================
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
void P_SetSlope (secplane_t *plane, bool setCeil, int xyangi, int zangi,
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
fixed_t x, fixed_t y, fixed_t z)
{
angle_t xyang;
angle_t zang;
if (zangi >= 180)
{
zang = ANGLE_180-ANGLE_1;
}
else if (zangi <= 0)
{
zang = ANGLE_1;
}
else
{
zang = Scale (zangi, ANGLE_90, 90);
}
if (setCeil)
{
zang += ANGLE_180;
}
zang >>= ANGLETOFINESHIFT;
xyang = (angle_t)Scale (xyangi, ANGLE_90, 90 << ANGLETOFINESHIFT);
- 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
FVector3 norm;
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
norm[0] = float(finecosine[zang]) * float(finecosine[xyang]);
norm[1] = float(finecosine[zang]) * float(finesine[xyang]);
norm[2] = float(finesine[zang]) * 65536.f;
- 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
norm.MakeUnit();
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
plane->a = (int)(norm[0] * 65536.f);
plane->b = (int)(norm[1] * 65536.f);
plane->c = (int)(norm[2] * 65536.f);
//plane->ic = (int)(65536.f / norm[2]);
plane->ic = DivScale32 (1, plane->c);
plane->d = -TMulScale16 (plane->a, x,
plane->b, y,
plane->c, z);
}
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
// P_VavoomSlope
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
void P_VavoomSlope(sector_t * sec, int id, fixed_t x, fixed_t y, fixed_t z, int which)
{
for (int i=0;i<sec->linecount;i++)
{
line_t * l=sec->lines[i];
if (l->args[0]==id)
{
- 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
FVector3 v1, v2, cross;
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
secplane_t *srcplane = (which == 0) ? &sec->floorplane : &sec->ceilingplane;
fixed_t srcheight = (which == 0) ? sec->floortexz : sec->ceilingtexz;
v1[0] = FIXED2FLOAT (x - l->v2->x);
v1[1] = FIXED2FLOAT (y - l->v2->y);
v1[2] = FIXED2FLOAT (z - srcheight);
v2[0] = FIXED2FLOAT (x - l->v1->x);
v2[1] = FIXED2FLOAT (y - l->v1->y);
v2[2] = FIXED2FLOAT (z - srcheight);
- 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
cross = v1 ^ v2;
double len = cross.Length();
if (len == 0)
{
Printf ("Slope thing at (%d,%d) lies directly on its target line.\n", int(x>>16), int(y>>16));
return;
}
cross /= len;
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
// Fix backward normals
- 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
if ((cross.Z < 0 && which == 0) || (cross.Z > 0 && which == 1))
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
{
- 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
cross = -cross;
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
}
srcplane->a = FLOAT2FIXED (cross[0]);
srcplane->b = FLOAT2FIXED (cross[1]);
srcplane->c = FLOAT2FIXED (cross[2]);
//plane->ic = FLOAT2FIXED (1.f/cross[2]);
srcplane->ic = DivScale32 (1, srcplane->c);
srcplane->d = -TMulScale16 (srcplane->a, x,
srcplane->b, y,
srcplane->c, z);
return;
}
}
}
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
enum
{
THING_SlopeFloorPointLine = 9500,
THING_SlopeCeilingPointLine = 9501,
THING_SetFloorSlope = 9502,
THING_SetCeilingSlope = 9503,
THING_CopyFloorPlane = 9510,
THING_CopyCeilingPlane = 9511,
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
THING_VavoomFloor=1500,
THING_VavoomCeiling=1501,
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
};
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
// P_SpawnSlopeMakers
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
static void P_SpawnSlopeMakers (mapthing2_t *firstmt, mapthing2_t *lastmt)
{
mapthing2_t *mt;
for (mt = firstmt; mt < lastmt; ++mt)
{
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
if ((mt->type >= THING_SlopeFloorPointLine &&
mt->type <= THING_SetCeilingSlope) ||
mt->type==THING_VavoomFloor || mt->type==THING_VavoomCeiling)
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
{
fixed_t x, y, z;
secplane_t *refplane;
sector_t *sec;
x = mt->x << FRACBITS;
y = mt->y << FRACBITS;
- added a P_PointInSector function and replaced all calls to retrieve an actor's sector in the game engine code with it. This way there's a clear distinction between renderer-specific and game-specific calls. SVN r638 (trunk)
2007-12-25 10:07:58 +00:00
sec = P_PointInSector (x, y);
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
if (mt->type & 1)
{
refplane = &sec->ceilingplane;
}
else
{
refplane = &sec->floorplane;
}
z = refplane->ZatPoint (x, y) + (mt->z << FRACBITS);
SVN r114 (trunk)
2006-05-14 14:30:13 +00:00
if (mt->type==THING_VavoomFloor || mt->type==THING_VavoomCeiling)
{
P_VavoomSlope(sec, mt->thingid, x, y, mt->z<<FRACBITS, mt->type & 1);
}
else if (mt->type <= THING_SlopeCeilingPointLine)
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
{
P_SlopeLineToPoint (mt->args[0], x, y, z, mt->type & 1);
}
else
{
P_SetSlope (refplane, mt->type & 1, mt->angle, mt->args[0], x, y, z);
}
mt->type = 0;
}
}
for (mt = firstmt; mt < lastmt; ++mt)
{
if (mt->type == THING_CopyFloorPlane ||
mt->type == THING_CopyCeilingPlane)
{
P_CopyPlane (mt->args[0], mt->x << FRACBITS, mt->y << FRACBITS, mt->type & 1);
mt->type = 0;
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
//
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
// [RH]
// P_LoadThings2
//
// Same as P_LoadThings() except it assumes Things are
// saved Hexen-style. Position also controls which single-
// player start spots are spawned by filtering out those
// whose first parameter don't match position.
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
void P_LoadThings2 (MapData * map, int position)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->MapLumps[ML_THINGS].Size;
int numthings = lumplen / sizeof(mapthing2_t);
int i;
char *mtp;
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
mapthing2_t *mt;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mtp = new char[lumplen];
map->Read(ML_THINGS, mtp);
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
#ifdef WORDS_BIGENDIAN
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
for (i=0, mt = (mapthing2_t*)mtp; i < numthings; i++,mt++)
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
{
mt->thingid = LittleShort(mt->thingid);
mt->x = LittleShort(mt->x);
mt->y = LittleShort(mt->y);
mt->z = LittleShort(mt->z);
mt->angle = LittleShort(mt->angle);
mt->type = LittleShort(mt->type);
mt->flags = LittleShort(mt->flags);
}
#endif
// [RH] Spawn slope creating things first.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_SpawnSlopeMakers ((mapthing2_t*)mtp, ((mapthing2_t*)mtp)+numthings);
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
for (i=0, mt = (mapthing2_t*)mtp; i < numthings; i++,mt++)
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
{
P_SpawnMapThing (mt, position);
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mtp;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//===========================================================================
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
//
// P_LoadLineDefs
//
// killough 4/4/98: split into two functions, to allow sidedef overloading
//
// [RH] Actually split into four functions to allow for Hexen and Doom
// linedefs.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
//
//===========================================================================
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
void P_AdjustLine (line_t *ld)
{
vertex_t *v1, *v2;
v1 = ld->v1;
v2 = ld->v2;
ld->dx = v2->x - v1->x;
ld->dy = v2->y - v1->y;
if (ld->dx == 0)
ld->slopetype = ST_VERTICAL;
else if (ld->dy == 0)
ld->slopetype = ST_HORIZONTAL;
else
ld->slopetype = ((ld->dy ^ ld->dx) >= 0) ? ST_POSITIVE : ST_NEGATIVE;
if (v1->x < v2->x)
{
ld->bbox[BOXLEFT] = v1->x;
ld->bbox[BOXRIGHT] = v2->x;
}
else
{
ld->bbox[BOXLEFT] = v2->x;
ld->bbox[BOXRIGHT] = v1->x;
}
if (v1->y < v2->y)
{
ld->bbox[BOXBOTTOM] = v1->y;
ld->bbox[BOXTOP] = v2->y;
}
else
{
ld->bbox[BOXBOTTOM] = v2->y;
ld->bbox[BOXTOP] = v1->y;
}
// [RH] Set line id (as appropriate) here
- Converted the stealth monsters to DECORATE. - Added string replacement option to obituary strings. - Changed lock and pickup message handling so that it is either a real string or a LANGUAGE identifier. The only reason I did the mixed format in the first place were Hexen's lock messages but they have been replaced by unique strings in the mean time so the feature isn't needed any more. - Added a flags parameter to TranslucentLine. - Extended the second arg of Line_SetIdentification to set not only ML_ZONEBOUNDARY but all 8 bits of the third byte in the flag word. This allows a relatively simple means of setting all the new flags directly. - Moved ML_ZONEBOUNDARY to doomdata.h so that it is in the same place as the other line flags. - Fixed: Strife's teleport swirl didn't loop its animation. - Fixed: Strife's rat is not supposed to be shootable. SVN r110 (trunk)
2006-05-11 17:56:35 +00:00
// for Doom format maps this must be done in P_TranslateLineDef because
// the tag doesn't always go into the first arg.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (level.flags & LEVEL_HEXENFORMAT)
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
{
- Removed the 64 seg limit for polyobjects defined with Polyobj_ExplicitLine. - Polyobj_StartLine and Polyobj_ExplicitLine can now set a line's ID. This is the fourth parameter for Polyobj_StartLine and the fifth parameter for Polyobj_ExplicitLine. SVN r310 (trunk)
2006-08-24 19:19:15 +00:00
switch (ld->special)
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
{
- Removed the 64 seg limit for polyobjects defined with Polyobj_ExplicitLine. - Polyobj_StartLine and Polyobj_ExplicitLine can now set a line's ID. This is the fourth parameter for Polyobj_StartLine and the fifth parameter for Polyobj_ExplicitLine. SVN r310 (trunk)
2006-08-24 19:19:15 +00:00
case Line_SetIdentification:
- Moved the sector type translation for Doom format maps into a simple lump in zdoom.pk3. - Changed Line_SetIdentification so that the fifth arg is a high-byte for the line ID. SVN r361 (trunk)
2006-10-25 16:21:08 +00:00
ld->id = ld->args[0] + 256 * ld->args[4];
- Converted the stealth monsters to DECORATE. - Added string replacement option to obituary strings. - Changed lock and pickup message handling so that it is either a real string or a LANGUAGE identifier. The only reason I did the mixed format in the first place were Hexen's lock messages but they have been replaced by unique strings in the mean time so the feature isn't needed any more. - Added a flags parameter to TranslucentLine. - Extended the second arg of Line_SetIdentification to set not only ML_ZONEBOUNDARY but all 8 bits of the third byte in the flag word. This allows a relatively simple means of setting all the new flags directly. - Moved ML_ZONEBOUNDARY to doomdata.h so that it is in the same place as the other line flags. - Fixed: Strife's teleport swirl didn't loop its animation. - Fixed: Strife's rat is not supposed to be shootable. SVN r110 (trunk)
2006-05-11 17:56:35 +00:00
ld->flags |= ld->args[1]<<16;
- Removed the 64 seg limit for polyobjects defined with Polyobj_ExplicitLine. - Polyobj_StartLine and Polyobj_ExplicitLine can now set a line's ID. This is the fourth parameter for Polyobj_StartLine and the fifth parameter for Polyobj_ExplicitLine. SVN r310 (trunk)
2006-08-24 19:19:15 +00:00
break;
case TranslucentLine:
- Converted the stealth monsters to DECORATE. - Added string replacement option to obituary strings. - Changed lock and pickup message handling so that it is either a real string or a LANGUAGE identifier. The only reason I did the mixed format in the first place were Hexen's lock messages but they have been replaced by unique strings in the mean time so the feature isn't needed any more. - Added a flags parameter to TranslucentLine. - Extended the second arg of Line_SetIdentification to set not only ML_ZONEBOUNDARY but all 8 bits of the third byte in the flag word. This allows a relatively simple means of setting all the new flags directly. - Moved ML_ZONEBOUNDARY to doomdata.h so that it is in the same place as the other line flags. - Fixed: Strife's teleport swirl didn't loop its animation. - Fixed: Strife's rat is not supposed to be shootable. SVN r110 (trunk)
2006-05-11 17:56:35 +00:00
ld->id = ld->args[0];
ld->flags |= ld->args[3]<<16;
- Removed the 64 seg limit for polyobjects defined with Polyobj_ExplicitLine. - Polyobj_StartLine and Polyobj_ExplicitLine can now set a line's ID. This is the fourth parameter for Polyobj_StartLine and the fifth parameter for Polyobj_ExplicitLine. SVN r310 (trunk)
2006-08-24 19:19:15 +00:00
break;
case Teleport_Line:
case Scroll_Texture_Model:
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
ld->id = ld->args[0];
- Removed the 64 seg limit for polyobjects defined with Polyobj_ExplicitLine. - Polyobj_StartLine and Polyobj_ExplicitLine can now set a line's ID. This is the fourth parameter for Polyobj_StartLine and the fifth parameter for Polyobj_ExplicitLine. SVN r310 (trunk)
2006-08-24 19:19:15 +00:00
break;
case Polyobj_StartLine:
ld->id = ld->args[3];
break;
case Polyobj_ExplicitLine:
ld->id = ld->args[4];
break;
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
}
}
}
void P_SaveLineSpecial (line_t *ld)
{
if (*ld->sidenum == NO_SIDE)
return;
// killough 4/4/98: support special sidedef interpretation below
if ((ld->sidenum[0] != NO_SIDE) &&
// [RH] Save Static_Init only if it's interested in the textures
(ld->special != Static_Init || ld->args[1] == Init_Color))
{
sidetemp[*ld->sidenum].a.special = ld->special;
sidetemp[*ld->sidenum].a.tag = ld->args[0];
}
else
{
sidetemp[*ld->sidenum].a.special = 0;
}
}
// killough 4/4/98: delay using sidedefs until they are loaded
void P_FinishLoadingLineDefs ()
{
WORD len;
int i, linenum;
line_t *ld = lines;
for (i = numlines, linenum = 0; i--; ld++, linenum++)
{
ld->frontsector = ld->sidenum[0]!=NO_SIDE ? sides[ld->sidenum[0]].sector : 0;
ld->backsector = ld->sidenum[1]!=NO_SIDE ? sides[ld->sidenum[1]].sector : 0;
float dx = FIXED2FLOAT(ld->v2->x - ld->v1->x);
float dy = FIXED2FLOAT(ld->v2->y - ld->v1->y);
SBYTE light;
if (ld->frontsector == NULL)
{
Printf ("Line %d has no front sector\n", linemap[linenum]);
}
// [RH] Set some new sidedef properties
len = (int)(sqrtf (dx*dx + dy*dy) + 0.5f);
light = dy == 0 ? level.WallHorizLight :
dx == 0 ? level.WallVertLight : 0;
if (ld->sidenum[0] != NO_SIDE)
{
sides[ld->sidenum[0]].linenum = linenum;
sides[ld->sidenum[0]].TexelLength = len;
sides[ld->sidenum[0]].Light = light;
}
if (ld->sidenum[1] != NO_SIDE)
{
sides[ld->sidenum[1]].linenum = linenum;
sides[ld->sidenum[1]].TexelLength = len;
sides[ld->sidenum[1]].Light = light;
}
switch (ld->special)
{ // killough 4/11/98: handle special types
int j;
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
int alpha;
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
case TranslucentLine: // killough 4/11/98: translucent 2s textures
// [RH] Second arg controls how opaque it is.
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
alpha = sidetemp[ld->sidenum[0]].a.alpha;
if (alpha < 0)
{
alpha = ld->args[1];
}
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
if (!ld->args[0])
{
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
ld->alpha = (BYTE)alpha;
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
if (ld->args[2] == 1)
{
sides[ld->sidenum[0]].Flags |= WALLF_ADDTRANS;
if (ld->sidenum[1] != NO_SIDE)
{
sides[ld->sidenum[1]].Flags |= WALLF_ADDTRANS;
}
}
}
else
{
for (j = 0; j < numlines; j++)
{
if (lines[j].id == ld->args[0])
{
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
lines[j].alpha = (BYTE)alpha;
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
if (lines[j].args[2] == 1)
{
sides[lines[j].sidenum[0]].Flags |= WALLF_ADDTRANS;
if (lines[j].sidenum[1] != NO_SIDE)
{
sides[lines[j].sidenum[1]].Flags |= WALLF_ADDTRANS;
}
}
}
}
}
ld->special = 0;
break;
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadLineDefs (MapData * map)
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
{
int i, skipped;
line_t *ld;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->Size(ML_LINEDEFS);
char * mldf;
maplinedef_t *mld;
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
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numlines = lumplen / sizeof(maplinedef_t);
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
lines = new line_t[numlines];
linemap = new WORD[numlines];
memset (lines, 0, numlines*sizeof(line_t));
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mldf = new char[lumplen];
map->Read(ML_LINEDEFS, mldf);
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
// [RH] Count the number of sidedef references. This is the number of
// sidedefs we need. The actual number in the SIDEDEFS lump might be less.
// Lines with 0 length are also removed.
for (skipped = sidecount = i = 0; i < numlines; )
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mld = ((maplinedef_t*)mldf) + i;
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
int v1 = LittleShort(mld->v1);
int v2 = LittleShort(mld->v2);
if (v1 >= numvertexes || v2 >= numvertexes)
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete [] mldf;
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
I_Error ("Line %d has invalid vertices: %d and/or %d.\nThe map only contains %d vertices.", i+skipped, v1, v2, numvertexes);
}
else if (v1 == v2 ||
(vertexes[LittleShort(mld->v1)].x == vertexes[LittleShort(mld->v2)].x &&
vertexes[LittleShort(mld->v1)].y == vertexes[LittleShort(mld->v2)].y))
{
Printf ("Removing 0-length line %d\n", i+skipped);
memmove (mld, mld+1, sizeof(*mld)*(numlines-i-1));
ForceNodeBuild = true;
skipped++;
numlines--;
}
else
{
if (LittleShort(mld->sidenum[0]) != NO_INDEX)
sidecount++;
if (LittleShort(mld->sidenum[1]) != NO_INDEX)
sidecount++;
linemap[i] = i+skipped;
i++;
}
}
P_AllocateSideDefs (sidecount);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mld = (maplinedef_t *)mldf;
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
ld = lines;
for (i = numlines; i > 0; i--, mld++, ld++)
{
ld->alpha = 255; // [RH] Opaque by default
// [RH] Translate old linedef special and flags to be
// compatible with the new format.
P_TranslateLineDef (ld, mld);
ld->v1 = &vertexes[LittleShort(mld->v1)];
ld->v2 = &vertexes[LittleShort(mld->v2)];
//ld->id = -1; ID has been assigned in P_TranslateLineDef
P_SetSideNum (&ld->sidenum[0], LittleShort(mld->sidenum[0]));
P_SetSideNum (&ld->sidenum[1], LittleShort(mld->sidenum[1]));
P_AdjustLine (ld);
P_SaveLineSpecial (ld);
- Updated Jim's Makefile.linux. - Added support for wrapping midtextures vertically. - Since zdoom.wad is now zdoom.pk3, the default mapinfos can use full pathnames. So now they do. - Fixed: The DSimpleCanvas constructor used a pitch too narrow on screens wider than 640 pixels when using a non-AMD processor and the processor's L1 cache line size could not be determined. I think this should fix the issue of weirdly rendered 8 pixel wide borders on the left and right of the screen that some people experienced. - Fixed: The secnodes were never freed. SVN r93 (trunk)
2006-05-09 21:30:31 +00:00
if (level.flags & LEVEL_CLIPMIDTEX) ld->flags |= ML_CLIP_MIDTEX;
if (level.flags & LEVEL_WRAPMIDTEX) ld->flags |= ML_WRAP_MIDTEX;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mldf;
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
}
// [RH] Same as P_LoadLineDefs() except it uses Hexen-style LineDefs.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadLineDefs2 (MapData * map)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int i, skipped;
line_t *ld;
int lumplen = map->Size(ML_LINEDEFS);
char * mldf;
maplinedef2_t *mld;
numlines = lumplen / sizeof(maplinedef2_t);
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
lines = new line_t[numlines];
linemap = new WORD[numlines];
memset (lines, 0, numlines*sizeof(line_t));
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mldf = new char[lumplen];
map->Read(ML_LINEDEFS, mldf);
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
// [RH] Remove any lines that have 0 length and count sidedefs used
for (skipped = sidecount = i = 0; i < numlines; )
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mld = ((maplinedef2_t*)mldf) + i;
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
if (mld->v1 == mld->v2 ||
(vertexes[LittleShort(mld->v1)].x == vertexes[LittleShort(mld->v2)].x &&
vertexes[LittleShort(mld->v1)].y == vertexes[LittleShort(mld->v2)].y))
{
Printf ("Removing 0-length line %d\n", i+skipped);
memmove (mld, mld+1, sizeof(*mld)*(numlines-i-1));
skipped++;
numlines--;
}
else
{
if (LittleShort(mld->sidenum[0]) != NO_INDEX)
sidecount++;
if (LittleShort(mld->sidenum[1]) != NO_INDEX)
sidecount++;
linemap[i] = i+skipped;
i++;
}
}
if (skipped > 0)
{
ForceNodeBuild = true;
}
P_AllocateSideDefs (sidecount);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
mld = (maplinedef2_t *)mldf;
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
ld = lines;
for (i = numlines; i > 0; i--, mld++, ld++)
{
int j;
for (j = 0; j < 5; j++)
ld->args[j] = mld->args[j];
ld->flags = LittleShort(mld->flags);
ld->special = mld->special;
ld->v1 = &vertexes[LittleShort(mld->v1)];
ld->v2 = &vertexes[LittleShort(mld->v2)];
ld->alpha = 255; // [RH] Opaque by default
ld->id = -1;
P_SetSideNum (&ld->sidenum[0], LittleShort(mld->sidenum[0]));
P_SetSideNum (&ld->sidenum[1], LittleShort(mld->sidenum[1]));
P_AdjustLine (ld);
P_SaveLineSpecial (ld);
- Updated Jim's Makefile.linux. - Added support for wrapping midtextures vertically. - Since zdoom.wad is now zdoom.pk3, the default mapinfos can use full pathnames. So now they do. - Fixed: The DSimpleCanvas constructor used a pitch too narrow on screens wider than 640 pixels when using a non-AMD processor and the processor's L1 cache line size could not be determined. I think this should fix the issue of weirdly rendered 8 pixel wide borders on the left and right of the screen that some people experienced. - Fixed: The secnodes were never freed. SVN r93 (trunk)
2006-05-09 21:30:31 +00:00
if (level.flags & LEVEL_CLIPMIDTEX) ld->flags |= ML_CLIP_MIDTEX;
if (level.flags & LEVEL_WRAPMIDTEX) ld->flags |= ML_WRAP_MIDTEX;
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
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mldf;
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
}
//
// P_LoadSideDefs
//
// killough 4/4/98: split into two functions
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadSideDefs (MapData * map)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
numsides = map->Size(ML_SIDEDEFS) / sizeof(mapsidedef_t);
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
}
static void P_AllocateSideDefs (int count)
{
int i;
sides = new side_t[count];
memset (sides, 0, count*sizeof(side_t));
sidetemp = new sidei_t[MAX(count,numvertexes)];
for (i = 0; i < count; i++)
{
sidetemp[i].a.special = sidetemp[i].a.tag = 0;
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
sidetemp[i].a.alpha = -1;
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
sidetemp[i].a.map = NO_SIDE;
}
if (count < numsides)
{
Printf ("Map has %d unused sidedefs\n", numsides - count);
}
numsides = count;
sidecount = 0;
}
static void P_SetSideNum (DWORD *sidenum_p, WORD sidenum)
{
if (sidenum == NO_INDEX)
{
*sidenum_p = NO_SIDE;
}
else if (sidecount < numsides)
{
sidetemp[sidecount].a.map = sidenum;
*sidenum_p = sidecount++;
}
else
{
I_Error ("%d sidedefs is not enough\n", sidecount);
}
}
// [RH] Group sidedefs into loops so that we can easily determine
// what walls any particular wall neighbors.
static void P_LoopSidedefs ()
{
int i;
for (i = 0; i < numvertexes; ++i)
{
sidetemp[i].b.first = NO_SIDE;
sidetemp[i].b.next = NO_SIDE;
}
for (; i < numsides; ++i)
{
sidetemp[i].b.next = NO_SIDE;
}
for (i = 0; i < numsides; ++i)
{
// For each vertex, build a list of sidedefs that use that vertex
// as their left edge.
line_t *line = &lines[sides[i].linenum];
Fixed: Compiling with mingw once again works, although savegame loading problems are not yet fixed. SVN r31 (trunk)
2006-04-12 03:03:58 +00:00
int lineside = (line->sidenum[0] != (DWORD)i);
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
int vert = (lineside ? line->v2 : line->v1) - vertexes;
sidetemp[i].b.lineside = lineside;
sidetemp[i].b.next = sidetemp[vert].b.first;
sidetemp[vert].b.first = i;
// Set each side so that it is the only member of its loop
sides[i].LeftSide = NO_SIDE;
sides[i].RightSide = NO_SIDE;
}
// For each side, find the side that is to its right and set the
// loop pointers accordingly. If two sides share a left vertex, the
// one that forms the smallest angle is assumed to be the right one.
for (i = 0; i < numsides; ++i)
{
DWORD right;
line_t *line = &lines[sides[i].linenum];
// If the side's line only exists in a single sector,
// then consider that line to be a self-contained loop
// instead of as part of another loop
if (line->frontsector == line->backsector)
{
right = line->sidenum[!sidetemp[i].b.lineside];
}
else
{
if (sidetemp[i].b.lineside)
{
right = line->v1 - vertexes;
}
else
{
right = line->v2 - vertexes;
}
right = sidetemp[right].b.first;
if (right == NO_SIDE)
{ // There is no right side!
Printf ("Line %d's right edge is unconnected\n", linemap[line-lines]);
continue;
}
if (sidetemp[right].b.next != NO_SIDE)
{
int bestright = right; // Shut up, GCC
angle_t bestang = ANGLE_MAX;
line_t *leftline, *rightline;
angle_t ang1, ang2, ang;
leftline = &lines[sides[i].linenum];
ang1 = R_PointToAngle2 (0, 0, leftline->dx, leftline->dy);
if (!sidetemp[i].b.lineside)
{
ang1 += ANGLE_180;
}
while (right != NO_SIDE)
{
if (sides[right].LeftSide == NO_SIDE)
{
rightline = &lines[sides[right].linenum];
if (rightline->frontsector != rightline->backsector)
{
ang2 = R_PointToAngle2 (0, 0, rightline->dx, rightline->dy);
if (sidetemp[right].b.lineside)
{
ang2 += ANGLE_180;
}
ang = ang2 - ang1;
if (ang != 0 && ang <= bestang)
{
bestright = right;
bestang = ang;
}
}
}
right = sidetemp[right].b.next;
}
right = bestright;
}
}
sides[i].RightSide = right;
sides[right].LeftSide = i;
}
// Throw away sidedef init info now that we're done with it
delete[] sidetemp;
sidetemp = NULL;
}
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
int P_DetermineTranslucency (int lumpnum)
{
FWadLump tranmap = Wads.OpenLumpNum (lumpnum);
BYTE index;
PalEntry newcolor;
tranmap.Seek (GPalette.BlackIndex * 256 + GPalette.WhiteIndex, SEEK_SET);
tranmap.Read (&index, 1);
newcolor = GPalette.BaseColors[GPalette.Remap[index]];
if (developer)
{
char lumpname[9];
lumpname[8] = 0;
Wads.GetLumpName (lumpname, lumpnum);
Printf ("%s appears to be translucency %d (%d%%)\n", lumpname, newcolor.r,
newcolor.r*100/255);
}
return newcolor.r;
}
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
// killough 4/4/98: delay using texture names until
// after linedefs are loaded, to allow overloading.
// killough 5/3/98: reformatted, cleaned up
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadSideDefs2 (MapData * map)
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
{
int i;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
char name[9];
- Fixed: The sidedef loader could allocate insufficient memory if a map contained unused sidedefs. - Fixed: Color control sequences were written to the log file. Since any entered console command contains such a sequence it was quite noticable. SVN r208 (trunk)
2006-06-21 15:40:42 +00:00
char * msdf = new char[map->Size(ML_SIDEDEFS)];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Read(ML_SIDEDEFS, msdf);
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
name[8] = 0;
for (i = 0; i < numsides; i++)
{
- Fixed: The sidedef loader could allocate insufficient memory if a map contained unused sidedefs. - Fixed: Color control sequences were written to the log file. Since any entered console command contains such a sequence it was quite noticable. SVN r208 (trunk)
2006-06-21 15:40:42 +00:00
mapsidedef_t *msd = ((mapsidedef_t*)msdf) + sidetemp[i].a.map;
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
side_t *sd = sides + i;
sector_t *sec;
// [RH] The Doom renderer ignored the patch y locations when
// drawing mid textures. ZDoom does not, so fix the laser beams in Strife.
if (gameinfo.gametype == GAME_Strife &&
strncmp (msd->midtexture, "LASERB01", 8) == 0)
{
msd->rowoffset += 102;
}
sd->textureoffset = LittleShort(msd->textureoffset)<<FRACBITS;
sd->rowoffset = LittleShort(msd->rowoffset)<<FRACBITS;
sd->linenum = NO_INDEX;
// killough 4/4/98: allow sidedef texture names to be overloaded
// killough 4/11/98: refined to allow colormaps to work as wall
// textures if invalid as colormaps but valid as textures.
if ((unsigned)LittleShort(msd->sector)>=(unsigned)numsectors)
{
Printf (PRINT_HIGH, "Sidedef %d has a bad sector\n", i);
sd->sector = sec = NULL;
}
else
{
sd->sector = sec = &sectors[LittleShort(msd->sector)];
}
switch (sidetemp[i].a.special)
{
case Transfer_Heights: // variable colormap via 242 linedef
// [RH] The colormap num we get here isn't really a colormap,
// but a packed ARGB word for blending, so we also allow
// the blend to be specified directly by the texture names
// instead of figuring something out from the colormap.
if (sec != NULL)
{
SetTexture (&sd->bottomtexture, &sec->bottommap, msd->bottomtexture);
SetTexture (&sd->midtexture, &sec->midmap, msd->midtexture);
SetTexture (&sd->toptexture, &sec->topmap, msd->toptexture);
}
break;
case Static_Init:
// [RH] Set sector color and fog
// upper "texture" is light color
// lower "texture" is fog color
{
DWORD color, fog;
bool colorgood, foggood;
SetTextureNoErr (&sd->bottomtexture, &fog, msd->bottomtexture, &foggood);
SetTextureNoErr (&sd->toptexture, &color, msd->toptexture, &colorgood);
strncpy (name, msd->midtexture, 8);
sd->midtexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
if (colorgood | foggood)
{
int s;
FDynamicColormap *colormap = NULL;
for (s = 0; s < numsectors; s++)
{
if (sectors[s].tag == sidetemp[i].a.tag)
{
if (!colorgood) color = sectors[s].ColorMap->Color;
if (!foggood) fog = sectors[s].ColorMap->Fade;
if (colormap == NULL ||
colormap->Color != color ||
colormap->Fade != fog)
{
colormap = GetSpecialLights (color, fog, 0);
}
sectors[s].ColorMap = colormap;
}
}
}
}
break;
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
case TranslucentLine: // killough 4/11/98: apply translucency to 2s normal texture
if (!map->HasBehavior)
{
int lumpnum;
if (strnicmp ("TRANMAP", msd->midtexture, 8) == 0)
{
// The translator set the alpha argument already; no reason to do it again.
sd->midtexture = 0;
}
else if ((lumpnum = Wads.CheckNumForName (msd->midtexture)) > 0 &&
Wads.LumpLength (lumpnum) == 65536)
{
sidetemp[i].a.alpha = P_DetermineTranslucency (lumpnum);
sd->midtexture = 0;
}
else
{
strncpy (name, msd->midtexture, 8);
sd->midtexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
}
strncpy (name, msd->toptexture, 8);
sd->toptexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
strncpy (name, msd->bottomtexture, 8);
sd->bottomtexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
break;
}
// Fallthrough for Hexen maps is intentional
#if 0
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
sd->midtexture = strncasecmp("TRANMAP", msd->midtexture, 8) ?
(sd->special = W_CheckNumForName(msd->midtexture)) < 0 ||
W_LumpLength(sd->special) != 65536 ?
sd->special=0, R_TextureNumForName(msd->midtexture) :
(sd->special++, 0) : (sd->special=0);
sd->toptexture = R_TextureNumForName(msd->toptexture);
sd->bottomtexture = R_TextureNumForName(msd->bottomtexture);
- Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument. - Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality. - Fixed: A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player". SVN r268 (trunk)
2006-07-20 05:13:39 +00:00
#endif
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
default: // normal cases
strncpy (name, msd->midtexture, 8);
sd->midtexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
strncpy (name, msd->toptexture, 8);
sd->toptexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
strncpy (name, msd->bottomtexture, 8);
sd->bottomtexture = TexMan.GetTexture (name, FTexture::TEX_Wall, FTextureManager::TEXMAN_Overridable);
break;
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] msdf;
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
}
// [RH] Set slopes for sectors, based on line specials
//
// P_AlignPlane
//
// Aligns the floor or ceiling of a sector to the corresponding plane
// on the other side of the reference line. (By definition, line must be
// two-sided.)
//
// If (which & 1), sets floor.
// If (which & 2), sets ceiling.
//
static void P_AlignPlane (sector_t *sec, line_t *line, int which)
{
sector_t *refsec;
int bestdist;
vertex_t *refvert = (*sec->lines)->v1; // Shut up, GCC
int i;
line_t **probe;
if (line->backsector == NULL)
return;
// Find furthest vertex from the reference line. It, along with the two ends
// of the line will define the plane.
bestdist = 0;
for (i = sec->linecount*2, probe = sec->lines; i > 0; i--)
{
int dist;
vertex_t *vert;
// Do calculations with only the upper bits, because the lower ones
// are all zero, and we would overflow for a lot of distances if we
// kept them around.
if (i & 1)
vert = (*probe++)->v2;
else
vert = (*probe)->v1;
dist = abs (((line->v1->y - vert->y) >> FRACBITS) * (line->dx >> FRACBITS) -
((line->v1->x - vert->x) >> FRACBITS) * (line->dy >> FRACBITS));
if (dist > bestdist)
{
bestdist = dist;
refvert = vert;
}
}
refsec = line->frontsector == sec ? line->backsector : line->frontsector;
- 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
FVector3 p, v1, v2, cross;
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
const secplane_t *refplane;
secplane_t *srcplane;
fixed_t srcheight, destheight;
refplane = (which == 0) ? &refsec->floorplane : &refsec->ceilingplane;
srcplane = (which == 0) ? &sec->floorplane : &sec->ceilingplane;
srcheight = (which == 0) ? sec->floortexz : sec->ceilingtexz;
destheight = (which == 0) ? refsec->floortexz : refsec->ceilingtexz;
- 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
p[0] = FIXED2FLOAT (line->v1->x);
p[1] = FIXED2FLOAT (line->v1->y);
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
p[2] = FIXED2FLOAT (destheight);
- 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
v1[0] = FIXED2FLOAT (line->dx);
v1[1] = FIXED2FLOAT (line->dy);
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
v1[2] = 0;
- 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
v2[0] = FIXED2FLOAT (refvert->x - line->v1->x);
v2[1] = FIXED2FLOAT (refvert->y - line->v1->y);
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
v2[2] = FIXED2FLOAT (srcheight - destheight);
- 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
cross = (v1 ^ v2).Unit();
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
// Fix backward normals
- 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
if ((cross.Z < 0 && which == 0) || (cross.Z > 0 && which == 1))
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
{
- 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
cross = -cross;
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
}
srcplane->a = FLOAT2FIXED (cross[0]);
srcplane->b = FLOAT2FIXED (cross[1]);
srcplane->c = FLOAT2FIXED (cross[2]);
//srcplane->ic = FLOAT2FIXED (1.f/cross[2]);
srcplane->ic = DivScale32 (1, srcplane->c);
srcplane->d = -TMulScale16 (srcplane->a, line->v1->x,
srcplane->b, line->v1->y,
srcplane->c, destheight);
}
void P_SetSlopes ()
{
int i, s;
for (i = 0; i < numlines; i++)
{
if (lines[i].special == Plane_Align)
{
lines[i].special = 0;
lines[i].id = lines[i].args[2];
if (lines[i].backsector != NULL)
{
// args[0] is for floor, args[1] is for ceiling
//
// As a special case, if args[1] is 0,
// then args[0], bits 2-3 are for ceiling.
for (s = 0; s < 2; s++)
{
int bits = lines[i].args[s] & 3;
if (s == 1 && bits == 0)
bits = (lines[i].args[0] >> 2) & 3;
if (bits == 1) // align front side to back
P_AlignPlane (lines[i].frontsector, lines + i, s);
else if (bits == 2) // align back side to front
P_AlignPlane (lines[i].backsector, lines + i, s);
}
}
}
}
}
//
// [RH] My own blockmap builder, not Killough's or TeamTNT's.
//
// Killough's turned out not to be correct enough, and I had
// written this for ZDBSP before I discovered that, so
// replacing the one he wrote for MBF seemed like the easiest
// thing to do. (Doom E3M6, near vertex 0--the one furthest east
// on the map--had problems.)
//
// Using a hash table to get the minimum possible blockmap size
// seems like overkill, but I wanted to change the code as little
// as possible from its ZDBSP incarnation.
//
static unsigned int BlockHash (TArray<WORD> *block)
{
int hash = 0;
WORD *ar = &(*block)[0];
for (size_t i = 0; i < block->Size(); ++i)
{
hash = hash * 12235 + ar[i];
}
return hash & 0x7fffffff;
}
static bool BlockCompare (TArray<WORD> *block1, TArray<WORD> *block2)
{
size_t size = block1->Size();
if (size != block2->Size())
{
return false;
}
if (size == 0)
{
return true;
}
WORD *ar1 = &(*block1)[0];
WORD *ar2 = &(*block2)[0];
for (size_t i = 0; i < size; ++i)
{
if (ar1[i] != ar2[i])
{
return false;
}
}
return true;
}
static void CreatePackedBlockmap (TArray<int> &BlockMap, TArray<WORD> *blocks, int bmapwidth, int bmapheight)
{
int buckets[4096];
int *hashes, hashblock;
TArray<WORD> *block;
int zero = 0;
int terminator = -1;
WORD *array;
int i, hash;
int hashed = 0, nothashed = 0;
hashes = new int[bmapwidth * bmapheight];
memset (hashes, 0xff, sizeof(WORD)*bmapwidth*bmapheight);
memset (buckets, 0xff, sizeof(buckets));
for (i = 0; i < bmapwidth * bmapheight; ++i)
{
block = &blocks[i];
hash = BlockHash (block) % 4096;
hashblock = buckets[hash];
while (hashblock != -1)
{
if (BlockCompare (block, &blocks[hashblock]))
{
break;
}
hashblock = hashes[hashblock];
}
if (hashblock != -1)
{
BlockMap[4+i] = BlockMap[4+hashblock];
hashed++;
}
else
{
hashes[i] = buckets[hash];
buckets[hash] = i;
BlockMap[4+i] = BlockMap.Size ();
BlockMap.Push (zero);
array = &(*block)[0];
for (size_t j = 0; j < block->Size(); ++j)
{
BlockMap.Push (array[j]);
}
BlockMap.Push (terminator);
nothashed++;
}
}
delete[] hashes;
// printf ("%d blocks written, %d blocks saved\n", nothashed, hashed);
}
#define BLOCKBITS 7
#define BLOCKSIZE 128
static void P_CreateBlockMap ()
{
TArray<WORD> *BlockLists, *block, *endblock;
WORD adder;
int bmapwidth, bmapheight;
int minx, maxx, miny, maxy;
int i;
WORD line;
if (numvertexes <= 0)
return;
// Find map extents for the blockmap
minx = maxx = vertexes[0].x;
miny = maxy = vertexes[0].y;
for (i = 1; i < numvertexes; ++i)
{
if (vertexes[i].x < minx) minx = vertexes[i].x;
else if (vertexes[i].x > maxx) maxx = vertexes[i].x;
if (vertexes[i].y < miny) miny = vertexes[i].y;
else if (vertexes[i].y > maxy) maxy = vertexes[i].y;
}
maxx >>= FRACBITS;
minx >>= FRACBITS;
maxy >>= FRACBITS;
miny >>= FRACBITS;
bmapwidth = ((maxx - minx) >> BLOCKBITS) + 1;
bmapheight = ((maxy - miny) >> BLOCKBITS) + 1;
TArray<int> BlockMap (bmapwidth * bmapheight * 3 + 4);
adder = minx; BlockMap.Push (adder);
adder = miny; BlockMap.Push (adder);
adder = bmapwidth; BlockMap.Push (adder);
adder = bmapheight; BlockMap.Push (adder);
BlockLists = new TArray<WORD>[bmapwidth * bmapheight];
for (line = 0; line < numlines; ++line)
{
int x1 = lines[line].v1->x >> FRACBITS;
int y1 = lines[line].v1->y >> FRACBITS;
int x2 = lines[line].v2->x >> FRACBITS;
int y2 = lines[line].v2->y >> FRACBITS;
int dx = x2 - x1;
int dy = y2 - y1;
int bx = (x1 - minx) >> BLOCKBITS;
int by = (y1 - miny) >> BLOCKBITS;
int bx2 = (x2 - minx) >> BLOCKBITS;
int by2 = (y2 - miny) >> BLOCKBITS;
block = &BlockLists[bx + by * bmapwidth];
endblock = &BlockLists[bx2 + by2 * bmapwidth];
if (block == endblock) // Single block
{
block->Push (line);
}
else if (by == by2) // Horizontal line
{
if (bx > bx2)
{
swap (block, endblock);
}
do
{
block->Push (line);
block += 1;
} while (block <= endblock);
}
else if (bx == bx2) // Vertical line
{
if (by > by2)
{
swap (block, endblock);
}
do
{
block->Push (line);
block += bmapwidth;
} while (block <= endblock);
}
else // Diagonal line
{
int xchange = (dx < 0) ? -1 : 1;
int ychange = (dy < 0) ? -1 : 1;
int ymove = ychange * bmapwidth;
int adx = abs (dx);
int ady = abs (dy);
if (adx == ady) // 45 degrees
{
int xb = (x1 - minx) & (BLOCKSIZE-1);
int yb = (y1 - miny) & (BLOCKSIZE-1);
if (dx < 0)
{
xb = BLOCKSIZE-xb;
}
if (dy < 0)
{
yb = BLOCKSIZE-yb;
}
if (xb < yb)
adx--;
}
if (adx >= ady) // X-major
{
int yadd = dy < 0 ? -1 : BLOCKSIZE;
do
{
int stop = (Scale ((by << BLOCKBITS) + yadd - (y1 - miny), dx, dy) + (x1 - minx)) >> BLOCKBITS;
while (bx != stop)
{
block->Push (line);
block += xchange;
bx += xchange;
}
block->Push (line);
block += ymove;
by += ychange;
} while (by != by2);
while (block != endblock)
{
block->Push (line);
block += xchange;
}
block->Push (line);
}
else // Y-major
{
int xadd = dx < 0 ? -1 : BLOCKSIZE;
do
{
int stop = (Scale ((bx << BLOCKBITS) + xadd - (x1 - minx), dy, dx) + (y1 - miny)) >> BLOCKBITS;
while (by != stop)
{
block->Push (line);
block += ymove;
by += ychange;
}
block->Push (line);
block += xchange;
bx += xchange;
} while (bx != bx2);
while (block != endblock)
{
block->Push (line);
block += ymove;
}
block->Push (line);
}
}
}
BlockMap.Reserve (bmapwidth * bmapheight);
CreatePackedBlockmap (BlockMap, BlockLists, bmapwidth, bmapheight);
delete[] BlockLists;
blockmaplump = new int[BlockMap.Size()];
for (unsigned int ii = 0; ii < BlockMap.Size(); ++ii)
{
blockmaplump[ii] = BlockMap[ii];
}
}
//
// P_LoadBlockMap
//
// killough 3/1/98: substantially modified to work
// towards removing blockmap limit (a wad limitation)
//
// killough 3/30/98: Rewritten to remove blockmap limit
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadBlockMap (MapData * map)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int count = map->Size(ML_BLOCKMAP);
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
if (ForceNodeBuild || genblockmap ||
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
count/2 >= 0x10000 || count == 0 ||
Args.CheckParm("-blockmap")
)
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
{
DPrintf ("Generating BLOCKMAP\n");
P_CreateBlockMap ();
}
else
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
BYTE *data = new BYTE[count];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Read(ML_BLOCKMAP, data);
const short *wadblockmaplump = (short *)data;
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
int i;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
count/=2;
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
blockmaplump = new int[count];
// killough 3/1/98: Expand wad blockmap into larger internal one,
// by treating all offsets except -1 as unsigned and zero-extending
// them. This potentially doubles the size of blockmaps allowed,
// because Doom originally considered the offsets as always signed.
blockmaplump[0] = LittleShort(wadblockmaplump[0]);
blockmaplump[1] = LittleShort(wadblockmaplump[1]);
blockmaplump[2] = (DWORD)(LittleShort(wadblockmaplump[2])) & 0xffff;
blockmaplump[3] = (DWORD)(LittleShort(wadblockmaplump[3])) & 0xffff;
for (i = 4; i < count; i++)
{
short t = LittleShort(wadblockmaplump[i]); // killough 3/1/98
blockmaplump[i] = t == -1 ? (DWORD)0xffffffff : (DWORD) t & 0xffff;
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] data;
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
}
bmaporgx = blockmaplump[0]<<FRACBITS;
bmaporgy = blockmaplump[1]<<FRACBITS;
bmapwidth = blockmaplump[2];
bmapheight = blockmaplump[3];
// clear out mobj chains
count = bmapwidth*bmapheight;
blocklinks = new FBlockNode *[count];
memset (blocklinks, 0, count*sizeof(*blocklinks));
blockmap = blockmaplump+4;
}
//
// P_GroupLines
// Builds sector line lists and subsector sector numbers.
// Finds block bounding boxes for sectors.
// [RH] Handles extra lights
//
struct linf { short tag; WORD count; };
line_t** linebuffer;
static void P_GroupLines (bool buildmap)
{
cycle_t times[16] = { 0 };
TArray<linf> exLightTags;
int* linesDoneInEachSector;
int i;
int j;
int total;
int totallights;
line_t* li;
sector_t* sector;
DBoundingBox bbox;
bool flaggedNoFronts = false;
unsigned int ii, jj;
// look up sector number for each subsector
clock (times[0]);
for (i = 0; i < numsubsectors; i++)
{
subsectors[i].sector = segs[subsectors[i].firstline].sidedef->sector;
subsectors[i].validcount = validcount;
double accumx = 0.0, accumy = 0.0;
for (jj = 0; jj < subsectors[i].numlines; ++jj)
{
seg_t *seg = &segs[subsectors[i].firstline + jj];
seg->Subsector = &subsectors[i];
accumx += seg->v1->x + seg->v2->x;
accumy += seg->v1->y + seg->v2->y;
}
subsectors[i].CenterX = fixed_t(accumx * 0.5 / subsectors[i].numlines);
subsectors[i].CenterY = fixed_t(accumy * 0.5 / subsectors[i].numlines);
}
unclock (times[0]);
// count number of lines in each sector
clock (times[1]);
total = 0;
totallights = 0;
for (i = 0, li = lines; i < numlines; i++, li++)
{
if (li->frontsector == NULL)
{
if (!flaggedNoFronts)
{
flaggedNoFronts = true;
Printf ("The following lines do not have a front sidedef:\n");
}
Printf (" %d\n", i);
}
else
{
li->frontsector->linecount++;
total++;
}
if (li->backsector && li->backsector != li->frontsector)
{
li->backsector->linecount++;
total++;
}
// [RH] Count extra lights
if (li->special == ExtraFloor_LightOnly)
{
int adder = li->args[1] == 1 ? 2 : 1;
for (ii = 0; ii < exLightTags.Size(); ++ii)
{
if (exLightTags[ii].tag == li->args[0])
break;
}
if (ii == exLightTags.Size())
{
linf info = { li->args[0], adder };
exLightTags.Push (info);
totallights += adder;
}
else
{
totallights += adder;
exLightTags[ii].count += adder;
}
}
}
if (flaggedNoFronts)
{
I_Error ("You need to fix these lines to play this map.\n");
}
unclock (times[1]);
// collect extra light info
clock (times[2]);
LightStacks = new FLightStack[totallights];
ExtraLights = new FExtraLight[exLightTags.Size()];
memset (ExtraLights, 0, exLightTags.Size()*sizeof(FExtraLight));
for (ii = 0, jj = 0; ii < exLightTags.Size(); ++ii)
{
ExtraLights[ii].Tag = exLightTags[ii].tag;
ExtraLights[ii].NumLights = exLightTags[ii].count;
ExtraLights[ii].Lights = &LightStacks[jj];
jj += ExtraLights[ii].NumLights;
}
unclock (times[2]);
// build line tables for each sector
clock (times[3]);
linebuffer = new line_t *[total];
line_t **lineb_p = linebuffer;
linesDoneInEachSector = new int[numsectors];
memset (linesDoneInEachSector, 0, sizeof(int)*numsectors);
for (sector = sectors, i = 0; i < numsectors; i++, sector++)
{
if (sector->linecount == 0)
{
Printf ("Sector %i (tag %i) has no lines\n", i, sector->tag);
// 0 the sector's tag so that no specials can use it
sector->tag = 0;
}
else
{
sector->lines = lineb_p;
lineb_p += sector->linecount;
}
}
for (i = numlines, li = lines; i > 0; --i, ++li)
{
if (li->frontsector != NULL)
{
li->frontsector->lines[linesDoneInEachSector[li->frontsector - sectors]++] = li;
}
if (li->backsector != NULL && li->backsector != li->frontsector)
{
li->backsector->lines[linesDoneInEachSector[li->backsector - sectors]++] = li;
}
}
for (i = 0, sector = sectors; i < numsectors; ++i, ++sector)
{
if (linesDoneInEachSector[i] != sector->linecount)
{
I_Error ("P_GroupLines: miscounted");
}
if (sector->linecount != 0)
{
bbox.ClearBox ();
for (j = 0; j < sector->linecount; ++j)
{
li = sector->lines[j];
bbox.AddToBox (li->v1->x, li->v1->y);
bbox.AddToBox (li->v2->x, li->v2->y);
}
}
// set the soundorg to the middle of the bounding box
sector->soundorg[0] = bbox.Right()/2 + bbox.Left()/2;
sector->soundorg[1] = bbox.Top()/2 + bbox.Bottom()/2;
sector->soundorg[2] = sector->floorplane.ZatPoint (sector->soundorg[0], sector->soundorg[1]);
// Find a triangle in the sector for sorting extra lights
// The points must be in the sector, because intersecting
// planes are okay so long as they intersect beyond all
// sectors that use them.
if (sector->linecount == 0)
{ // If the sector has no lines, its tag is guaranteed to be 0, which
// means it cannot be used for extralights. So just use some dummy
// vertices for the triangle.
sector->Triangle[0] = vertexes;
sector->Triangle[1] = vertexes;
sector->Triangle[2] = vertexes;
}
else
{
sector->Triangle[0] = sector->lines[0]->v1;
sector->Triangle[1] = sector->lines[0]->v2;
sector->Triangle[2] = sector->Triangle[0]; // failsafe
if (sector->linecount > 1)
{
fixed_t dx = sector->Triangle[1]->x - sector->Triangle[0]->x;
fixed_t dy = sector->Triangle[1]->y - sector->Triangle[1]->y;
// Find another point in the sector that does not lie
// on the same line as the first two points.
for (j = 2; j < sector->linecount*2; ++j)
{
vertex_t *v;
v = (j & 1) ? sector->lines[j>>1]->v1 : sector->lines[j>>1]->v2;
if (DMulScale32 (v->y - sector->Triangle[0]->y, dx,
sector->Triangle[0]->x - v->x, dy) != 0)
{
sector->Triangle[2] = v;
}
}
}
}
#if 0
int block;
// adjust bounding box to map blocks
block = (bbox.Top()-bmaporgy+MAXRADIUS)>>MAPBLOCKSHIFT;
block = block >= bmapheight ? bmapheight-1 : block;
//sector->blockbox.Top()=block;
block = (bbox.Bottom()-bmaporgy-MAXRADIUS)>>MAPBLOCKSHIFT;
block = block < 0 ? 0 : block;
//sector->blockbox.Bottom()=block;
block = (bbox.Right()-bmaporgx+MAXRADIUS)>>MAPBLOCKSHIFT;
block = block >= bmapwidth ? bmapwidth-1 : block;
//sector->blockbox.Right()=block;
block = (bbox.Left()-bmaporgx-MAXRADIUS)>>MAPBLOCKSHIFT;
block = block < 0 ? 0 : block;
//sector->blockbox.Left()=block;
#endif
}
delete[] linesDoneInEachSector;
unclock (times[3]);
// [RH] Moved this here
clock (times[4]);
P_InitTagLists(); // killough 1/30/98: Create xref tables for tags
unclock (times[4]);
clock (times[5]);
if (!buildmap)
{
P_SetSlopes ();
}
unclock (times[5]);
clock (times[6]);
for (i = 0, li = lines; i < numlines; ++i, ++li)
{
if (li->special == ExtraFloor_LightOnly)
{
for (ii = 0; ii < exLightTags.Size(); ++ii)
{
if (ExtraLights[ii].Tag == li->args[0])
break;
}
if (ii < exLightTags.Size())
{
ExtraLights[ii].InsertLight (li->frontsector->ceilingplane, li, li->args[1] == 2);
if (li->args[1] == 1)
{
ExtraLights[ii].InsertLight (li->frontsector->floorplane, li, 2);
}
j = -1;
while ((j = P_FindSectorFromTag (li->args[0], j)) >= 0)
{
sectors[j].ExtraLights = &ExtraLights[ii];
}
}
}
}
unclock (times[6]);
if (showloadtimes)
{
Printf ("---Group Lines Times---\n");
for (i = 0; i < 7; ++i)
{
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
Printf (" time %d:%10llu\n", i, times[i]);
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
}
}
}
void FExtraLight::InsertLight (const secplane_t &inplane, line_t *line, int type)
{
// type 0 : !bottom, !flooder
// type 1 : !bottom, flooder
// type 2 : bottom, !flooder
vertex_t **triangle = line->frontsector->Triangle;
int i, j;
fixed_t diff = 0;
secplane_t plane = inplane;
if (type != 2)
{
plane.FlipVert ();
}
// Find the first plane this light is above and insert it there
for (i = 0; i < NumUsedLights; ++i)
{
for (j = 0; j < 3; ++j)
{
diff = plane.ZatPoint (triangle[j]) - Lights[i].Plane.ZatPoint (triangle[j]);
if (diff != 0)
{
break;
}
}
if (diff >= 0)
{
break;
}
}
if (i < NumLights)
{
for (j = MIN<int>(NumUsedLights, NumLights-1); j > i; --j)
{
Lights[j] = Lights[j-1];
}
Lights[i].Plane = plane;
Lights[i].Master = type == 2 ? NULL : line->frontsector;
Lights[i].bBottom = type == 2;
Lights[i].bFlooder = type == 1;
Lights[i].bOverlaps = diff == 0;
if (NumUsedLights < NumLights)
{
++NumUsedLights;
}
}
}
//
// P_LoadReject
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadReject (MapData * map, bool junk)
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
{
const int neededsize = (numsectors * numsectors + 7) >> 3;
int rejectsize;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (strnicmp (map->MapLumps[ML_REJECT].Name, "REJECT", 8) != 0)
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
{
rejectsize = 0;
}
else
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
rejectsize = junk ? 0 : map->Size(ML_REJECT);
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
}
if (rejectsize < neededsize)
{
if (rejectsize > 0)
{
Printf ("REJECT is %d byte%s too small.\n", neededsize - rejectsize,
neededsize-rejectsize==1?"":"s");
}
rejectmatrix = NULL;
}
else
{
// Check if the reject has some actual content. If not, free it.
rejectsize = MIN (rejectsize, neededsize);
rejectmatrix = new BYTE[rejectsize];
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_REJECT);
map->file->Read (rejectmatrix, rejectsize);
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
int qwords = rejectsize / 8;
int i;
if (qwords > 0)
{
const QWORD *qreject = (const QWORD *)rejectmatrix;
i = 0;
do
{
if (qreject[i] != 0)
return;
} while (++i < qwords);
}
rejectsize &= 7;
qwords *= 8;
for (i = 0; i < rejectsize; ++i)
{
if (rejectmatrix[qwords+rejectsize] != 0)
return;
}
// Reject has no data, so pretend it isn't there.
delete[] rejectmatrix;
rejectmatrix = NULL;
}
}
//
// [RH] P_LoadBehavior
//
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_LoadBehavior (MapData * map)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_BEHAVIOR);
FBehavior::StaticLoadModule (-1, map->file, map->Size(ML_BEHAVIOR));
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
if (!FBehavior::StaticCheckAllGood ())
{
Printf ("ACS scripts unloaded.\n");
FBehavior::StaticUnloadModules ();
}
}
// Hash the sector tags across the sectors and linedefs.
static void P_InitTagLists ()
{
int i;
for (i=numsectors; --i>=0; ) // Initially make all slots empty.
sectors[i].firsttag = -1;
for (i=numsectors; --i>=0; ) // Proceed from last to first sector
{ // so that lower sectors appear first
int j = (unsigned) sectors[i].tag % (unsigned) numsectors; // Hash func
sectors[i].nexttag = sectors[j].firsttag; // Prepend sector to chain
sectors[j].firsttag = i;
}
// killough 4/17/98: same thing, only for linedefs
for (i=numlines; --i>=0; ) // Initially make all slots empty.
lines[i].firstid = -1;
for (i=numlines; --i>=0; ) // Proceed from last to first linedef
{ // so that lower linedefs appear first
int j = (unsigned) lines[i].id % (unsigned) numlines; // Hash func
lines[i].nextid = lines[j].firstid; // Prepend linedef to chain
lines[j].firstid = i;
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
void P_GetPolySpots (MapData * map, TArray<FNodeBuilder::FPolyStart> &spots, TArray<FNodeBuilder::FPolyStart> &anchors)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (map->HasBehavior)
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
{
int spot1, spot2, spot3, anchor;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int lumplen = map->Size(ML_THINGS);
int num = lumplen / sizeof(mapthing2_t);
mapthing2_t *mt;
map->Seek(ML_THINGS);
mt = new mapthing2_t[num];
map->file->Read(mt, num * sizeof(mapthing2_t));
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
if (gameinfo.gametype == GAME_Hexen)
{
spot1 = LittleShort(PO_HEX_SPAWN_TYPE);
spot2 = LittleShort(PO_HEX_SPAWNCRUSH_TYPE);
anchor = LittleShort(PO_HEX_ANCHOR_TYPE);
}
else
{
spot1 = LittleShort(PO_SPAWN_TYPE);
spot2 = LittleShort(PO_SPAWNCRUSH_TYPE);
anchor = LittleShort(PO_ANCHOR_TYPE);
}
spot3 = LittleShort(PO_SPAWNHURT_TYPE);
for (int i = 0; i < num; ++i)
{
if (mt[i].type == spot1 || mt[i].type == spot2 || mt[i].type == spot3 || mt[i].type == anchor)
{
FNodeBuilder::FPolyStart newvert;
newvert.x = LittleShort(mt[i].x) << FRACBITS;
newvert.y = LittleShort(mt[i].y) << FRACBITS;
newvert.polynum = LittleShort(mt[i].angle);
if (mt[i].type == anchor)
{
anchors.Push (newvert);
}
else
{
spots.Push (newvert);
}
}
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete[] mt;
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
}
}
extern polyblock_t **PolyBlockMap;
void P_FreeLevelData ()
{
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
SN_StopAllSequences ();
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
DThinker::DestroyAllThinkers ();
level.total_monsters = level.total_items = level.total_secrets =
level.killed_monsters = level.found_items = level.found_secrets =
wminfo.maxfrags = 0;
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
FBehavior::StaticUnloadModules ();
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
if (vertexes != NULL)
{
delete[] vertexes;
vertexes = NULL;
}
if (segs != NULL)
{
delete[] segs;
segs = NULL;
}
if (sectors != NULL)
{
delete[] sectors;
sectors = NULL;
- Fixed: To prevent the pointer cleanup code from crashing numsectors has to be set to 0 when the sectors array is deleted. SVN r64 (trunk)
2006-04-23 00:03:32 +00:00
numsectors = 0; // needed for the pointer cleanup code
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
}
if (subsectors != NULL)
{
delete[] subsectors;
subsectors = NULL;
}
if (nodes != NULL)
{
delete[] nodes;
nodes = NULL;
}
if (lines != NULL)
{
delete[] lines;
lines = NULL;
}
if (sides != NULL)
{
delete[] sides;
sides = NULL;
}
if (blockmaplump != NULL)
{
delete[] blockmaplump;
blockmaplump = NULL;
}
if (blocklinks != NULL)
{
delete[] blocklinks;
blocklinks = NULL;
}
if (PolyBlockMap != NULL)
{
for (int i = bmapwidth*bmapheight-1; i >= 0; --i)
{
polyblock_t *link = PolyBlockMap[i];
while (link != NULL)
{
polyblock_t *next = link->next;
delete link;
link = next;
}
}
delete[] PolyBlockMap;
PolyBlockMap = NULL;
}
if (rejectmatrix != NULL)
{
delete[] rejectmatrix;
rejectmatrix = NULL;
}
if (LightStacks != NULL)
{
delete[] LightStacks;
LightStacks = NULL;
}
if (ExtraLights != NULL)
{
delete[] ExtraLights;
ExtraLights = NULL;
}
if (linebuffer != NULL)
{
delete[] linebuffer;
linebuffer = NULL;
}
if (polyobjs != NULL)
{
for (int i = 0; i < po_NumPolyobjs; ++i)
{
if (polyobjs[i].segs != NULL)
{
delete[] polyobjs[i].segs;
}
if (polyobjs[i].originalPts != NULL)
{
delete[] polyobjs[i].originalPts;
}
if (polyobjs[i].prevPts != NULL)
{
delete[] polyobjs[i].prevPts;
}
}
delete[] polyobjs;
polyobjs = NULL;
}
- Fixed: M_NotifyNewSave() needlessly created a copy of the filename. - Fixed: Any touching_sectorlists for actors unlinked in G_StartTravel() were lost forever. - Fixed: DLightningThinker::Serialize() did not delete the old LightningLightLevels array when loading from an archive. - Fixed: Although I moved the correct polyobject freeing code into P_FreeLevelData(), I left the old wrong code there too, which just deleted the array without deleting anything hanging off of it. SVN r127 (trunk)
2006-05-18 04:25:26 +00:00
po_NumPolyobjs = 0;
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
if (zones != NULL)
{
delete[] zones;
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
zones = NULL;
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
}
P_FreeStrifeConversations ();
- Removed my "backwards compatibility fix" for APROP_Speed. It turns out that in all the public versions where monster speed is not fixed point, you couldn't modify the monster's speed due to a bug in P_Move() anyway. So there's nothing to be backward compatible with. SVN r190 (trunk)
2006-06-14 23:22:14 +00:00
if (level.Scrolls != NULL)
{
delete[] level.Scrolls;
level.Scrolls = NULL;
}
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
}
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
extern msecnode_t *headsecnode;
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
void P_FreeExtraLevelData()
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
{
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
// Free all blocknodes and msecnodes.
// *NEVER* call this function without calling
// P_FreeLevelData() first, or they might not all be freed.
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
{
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
FBlockNode *node = FBlockNode::FreeBlocks;
while (node != NULL)
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
{
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
FBlockNode *next = node->NextBlock;
delete node;
node = next;
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
}
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
}
{
msecnode_t *node = headsecnode;
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
while (node != NULL)
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
{
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
msecnode_t *next = node->m_snext;
- Fixed AInventory::PickupFlash setting with GCC. - Fixed: The MusicVolumes list was allocated with M_Malloc but freed with delete. - Fixed: demobuffer was inconsistantly handled with new[]/delete[] and malloc/free. - Added used memory tracking to M_Malloc() and M_Realloc(). This necessitated the addition of an M_Free() call to track frees. - Removed M_Calloc since it was only used in one place, and can just as well be done with an M_Malloc/memset pair. - Bumped DEMOGAMEVERSION for the new net controller codes. SVN r751 (trunk)
2008-02-17 02:40:03 +00:00
M_Free (node);
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
node = next;
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
}
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
headsecnode = NULL;
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
}
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
}
- Yay! We now seem to be free of memory leaks! The next step will be to merge a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. (Interestingly, the amount of memory used when repeatedly executing the same map command at the console varies up and down, but it now stays relatively stable rather than increasing unbounded.) - Fixed: The list of resolutions in the video modes menu was not freed at exit. - Fixed: mus_playing.name was not freed at exit. - Fixed: SN_StopAllSequences() should be called at the start of P_FreeLevelData(), not just before the call to P_SetupLevel() in G_DoLoadLevel(), so it can run even at exit. And C_FullConsole() can call P_FreeLevelData() to free more memory too. - Fixed: StatusBar was not freed at exit. - Fixed: spritesorter was not freed at exit. - Fixed: Bad things happened if FString's data pool was destroyed before all C_RemoveTabCommand() calls were made. - Added an overload for FArchive << FString. - Fixed: The players' log text was not freed at exit. - Fixed: Bot information was not freed at exit. - Fixed: doomcom was not freed at exit. But since it's always created, there's no reason why it needs to be allocated from the heap. My guess is that in the DOS days, the external packet driver was responsible for allocating doomcom and passed its location with the -net parameter. - Fixed: FBlockNodes were not freed at exit. - Fixed: Openings were not freed at exit. - Fixed: Drawsegs were not freed at exit. - Fixed: Vissprites were not freed at exit. - Fixed: Console command history was not freed at exit. - Fixed: Visplanes were not freed at exit. - Fixed: Call P_FreeLevelData() at exit. - Fixed: Channel, SoundCurve, and PlayList in s_sound.cpp were not freed at exit. - Fixed: Sound sequences were not freed at exit. - Fixed: DSeqNode::Serialize() did not resize the m_SequenceChoices array when loading. SVN r106 (trunk)
2006-05-11 04:00:58 +00:00
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
//
// P_SetupLevel
//
// [RH] position indicates the start spot to spawn at
void P_SetupLevel (char *lumpname, int position)
{
cycle_t times[20] = { 0 };
mapthing2_t *buildthings;
int numbuildthings;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
int i;
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
bool buildmap;
wminfo.partime = 180;
clearinterpolations(); // [RH] Nothing to interpolate on a fresh level.
FCanvasTextureInfo::EmptyList ();
R_FreePastViewers ();
if (!savegamerestore)
{
for (i = 0; i < MAXPLAYERS; ++i)
{
players[i].killcount = players[i].secretcount
= players[i].itemcount = 0;
}
}
for (i = 0; i < MAXPLAYERS; ++i)
{
players[i].mo = NULL;
}
- Discovered that Shader Model 1.4 clamps my constants, so I can't use palettes smaller than 256 entries with the shader I wrote for it. Is there a list of gotchas like this listed some where? I'd really like to see it. Well, when compiled with SM2.0, the PalTex shader seems to be every-so- slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a minor win for cards that support it. - Fixed: ST_Endoom() failed to free the bitmap it used. - Added the DTA_ColorOverlay attribute to blend a color with the texture being drawn. For software, this (currently) only works with black. For hardware, it works with any color. The motiviation for this was so I could rewrite the status bar calls that passed DIM_MAP to DTA_Translation to draw darker icons into something that didn't require making a whole new remap table. - After having an "OMG! How could I have been so stupid?" moment, I have removed the off-by-one check from D3DFB. I had thought the off-by-one error was caused by rounding errors by the shader hardware. Not so. Rather, I wasn't sampling what I thought I was sampling. A texture that uses palette index 255 passes the value 1.0 to the shader. The shader needs to adjust the range of its palette indexes, or it will end up trying to read color 256 from the palette texture when it should be reading color 255. Doh! - The TranslationToTable() function has been added to map from translation numbers used by actors to the tables those numbers represent. This function performs validation for the input and returns NULL if the input value is invalid. - Major changes to the way translation tables work: No longer are they each a 256-byte array. Instead, the FRemapTable structure is used to represent each one. It includes a remap array for the software renderer, a palette array for a hardware renderer, and a native texture pointer for D3DFB. The translationtables array itself is now an array of TArrays that point to the real tables. The DTA_Translation attribute must also be passed a pointer to a FRemapTable, not a byte array as previously. - Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly for D3DFB's 2D mode. Before, any fullscreen graphics (like help images) covered it up. SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
// [RH] Clear any scripted translation colors the previous level may have set.
- Removed a few new warnings spewed by GCC. SVN r641 (trunk)
2007-12-26 05:03:14 +00:00
for (i = 0; i < int(translationtables[TRANSLATION_LevelScripted].Size()); ++i)
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
{
- Discovered that Shader Model 1.4 clamps my constants, so I can't use palettes smaller than 256 entries with the shader I wrote for it. Is there a list of gotchas like this listed some where? I'd really like to see it. Well, when compiled with SM2.0, the PalTex shader seems to be every-so- slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a minor win for cards that support it. - Fixed: ST_Endoom() failed to free the bitmap it used. - Added the DTA_ColorOverlay attribute to blend a color with the texture being drawn. For software, this (currently) only works with black. For hardware, it works with any color. The motiviation for this was so I could rewrite the status bar calls that passed DIM_MAP to DTA_Translation to draw darker icons into something that didn't require making a whole new remap table. - After having an "OMG! How could I have been so stupid?" moment, I have removed the off-by-one check from D3DFB. I had thought the off-by-one error was caused by rounding errors by the shader hardware. Not so. Rather, I wasn't sampling what I thought I was sampling. A texture that uses palette index 255 passes the value 1.0 to the shader. The shader needs to adjust the range of its palette indexes, or it will end up trying to read color 256 from the palette texture when it should be reading color 255. Doh! - The TranslationToTable() function has been added to map from translation numbers used by actors to the tables those numbers represent. This function performs validation for the input and returns NULL if the input value is invalid. - Major changes to the way translation tables work: No longer are they each a 256-byte array. Instead, the FRemapTable structure is used to represent each one. It includes a remap array for the software renderer, a palette array for a hardware renderer, and a native texture pointer for D3DFB. The translationtables array itself is now an array of TArrays that point to the real tables. The DTA_Translation attribute must also be passed a pointer to a FRemapTable, not a byte array as previously. - Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly for D3DFB's 2D mode. Before, any fullscreen graphics (like help images) covered it up. SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
FRemapTable *table = translationtables[TRANSLATION_LevelScripted][i];
if (table != NULL)
{
delete table;
translationtables[TRANSLATION_LevelScripted][i] = NULL;
}
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
}
- Discovered that Shader Model 1.4 clamps my constants, so I can't use palettes smaller than 256 entries with the shader I wrote for it. Is there a list of gotchas like this listed some where? I'd really like to see it. Well, when compiled with SM2.0, the PalTex shader seems to be every-so- slightly faster on my GF7950GT than the SM1.4 version, so I guess it's a minor win for cards that support it. - Fixed: ST_Endoom() failed to free the bitmap it used. - Added the DTA_ColorOverlay attribute to blend a color with the texture being drawn. For software, this (currently) only works with black. For hardware, it works with any color. The motiviation for this was so I could rewrite the status bar calls that passed DIM_MAP to DTA_Translation to draw darker icons into something that didn't require making a whole new remap table. - After having an "OMG! How could I have been so stupid?" moment, I have removed the off-by-one check from D3DFB. I had thought the off-by-one error was caused by rounding errors by the shader hardware. Not so. Rather, I wasn't sampling what I thought I was sampling. A texture that uses palette index 255 passes the value 1.0 to the shader. The shader needs to adjust the range of its palette indexes, or it will end up trying to read color 256 from the palette texture when it should be reading color 255. Doh! - The TranslationToTable() function has been added to map from translation numbers used by actors to the tables those numbers represent. This function performs validation for the input and returns NULL if the input value is invalid. - Major changes to the way translation tables work: No longer are they each a 256-byte array. Instead, the FRemapTable structure is used to represent each one. It includes a remap array for the software renderer, a palette array for a hardware renderer, and a native texture pointer for D3DFB. The translationtables array itself is now an array of TArrays that point to the real tables. The DTA_Translation attribute must also be passed a pointer to a FRemapTable, not a byte array as previously. - Modified DFrameBuffer::DrawRateStuff() so that it can do its thing properly for D3DFB's 2D mode. Before, any fullscreen graphics (like help images) covered it up. SVN r640 (trunk)
2007-12-26 04:42:15 +00:00
translationtables[TRANSLATION_LevelScripted].Clear();
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
// Initial height of PointOfView will be set by player think.
players[consoleplayer].viewz = 1;
// Make sure all sounds are stopped before Z_FreeTags.
S_Start ();
// [RH] Clear all ThingID hash chains.
AActor::ClearTIDHashes ();
// [RH] clear out the mid-screen message
C_MidPrint (NULL);
// Free all level data from the previous map
P_FreeLevelData ();
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
MapData * map = P_OpenMapData(lumpname);
if (map == NULL)
{
I_Error("Unable to open map '%s'\n", lumpname);
}
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
// find map num
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
level.lumpnum = map->lumpnum;
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
// [RH] Support loading Build maps (because I felt like it. :-)
buildmap = false;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (map->MapLumps[0].Size > 0)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
BYTE *mapdata = new BYTE[map->MapLumps[0].Size];
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
map->Seek(0);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->file->Read(mapdata, map->MapLumps[0].Size);
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
if (map->Encrypted)
{
More map loader fixes. SVN r194 (trunk)
2006-06-15 17:26:27 +00:00
BloodCrypt (mapdata, 0, MIN<int> (map->MapLumps[0].Size, 256));
SVN r191 (trunk)
2006-06-15 03:31:19 +00:00
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
buildmap = P_LoadBuildMap (mapdata, map->MapLumps[0].Size, &buildthings, &numbuildthings);
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
delete[] mapdata;
}
if (!buildmap)
{
// note: most of this ordering is important
ForceNodeBuild = gennodes;
// [RH] Load in the BEHAVIOR lump
FBehavior::StaticUnloadModules ();
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (map->HasBehavior)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadBehavior (map);
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
level.flags |= LEVEL_HEXENFORMAT;
}
else
{
// Doom format maps get strict monster activation unless the mapinfo
// specifies differently.
if (!(level.flags & LEVEL_LAXACTIVATIONMAPINFO))
{
level.flags &= ~LEVEL_LAXMONSTERACTIVATION;
}
}
- Added support for automatically loading ACS objects (even for Doom-format maps). To use it, compile the ACS files as ordinary libraries placed between A_START/A_END markers. Then outside the markers, create a lump called LOADACS. This is just a plain text lump that lists all the libraries you want to autoload with every map. You can do this with as many libraries as you want, and LOADACS lumps are also cummulative. SVN r123 (trunk)
2006-05-17 01:38:07 +00:00
FBehavior::StaticLoadDefaultModules ();
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
P_LoadStrifeConversations (lumpname);
clock (times[0]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadVertexes (map);
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
unclock (times[0]);
// Check for maps without any BSP data at all (e.g. SLIGE)
clock (times[1]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadSectors (map);
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
unclock (times[1]);
clock (times[2]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadSideDefs (map);
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
unclock (times[2]);
clock (times[3]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!map->HasBehavior)
P_LoadLineDefs (map);
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
else
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadLineDefs2 (map); // [RH] Load Hexen-style linedefs
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
unclock (times[3]);
clock (times[4]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadSideDefs2 (map);
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
unclock (times[4]);
clock (times[5]);
P_FinishLoadingLineDefs ();
unclock (times[5]);
clock (times[6]);
P_LoopSidedefs ();
unclock (times[6]);
delete[] linemap;
linemap = NULL;
}
else
{
ForceNodeBuild = true;
}
UsingGLNodes = false;
if (!ForceNodeBuild)
{
// Check for compressed nodes first, then uncompressed nodes
FWadLump test;
More map loader fixes. SVN r194 (trunk)
2006-06-15 17:26:27 +00:00
DWORD id = MAKE_ID('X','x','X','x'), idcheck=0;
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
For some unknown reason the HasBehavior check in P_OpenMapData was gone. SVN r193 (trunk)
2006-06-15 16:23:41 +00:00
if (map->MapLumps[ML_ZNODES].Size != 0 && !UsingGLNodes)
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
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_ZNODES);
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
idcheck = MAKE_ID('Z','N','O','D');
}
More map loader fixes. SVN r194 (trunk)
2006-06-15 17:26:27 +00:00
else if (map->MapLumps[ML_GLZNODES].Size != 0)
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
{
// If normal nodes are not present but GL nodes are, use them.
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->Seek(ML_GLZNODES);
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
idcheck = MAKE_ID('Z','G','L','N');
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
map->file->Read (&id, 4);
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
if (id == idcheck)
{
try
{
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadZNodes (*map->file, id);
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
}
catch (CRecoverableError &error)
{
Printf ("Error loading nodes: %s\n", error.GetMessage());
ForceNodeBuild = true;
if (subsectors != NULL)
{
delete[] subsectors;
subsectors = NULL;
}
if (segs != NULL)
{
delete[] segs;
segs = NULL;
}
if (nodes != NULL)
{
delete[] nodes;
nodes = NULL;
}
}
}
else
{
clock (times[7]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadSubsectors (map);
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
unclock (times[7]);
clock (times[8]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!ForceNodeBuild) P_LoadNodes (map);
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
unclock (times[8]);
clock (times[9]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!ForceNodeBuild) P_LoadSegs (map);
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
unclock (times[9]);
}
}
if (ForceNodeBuild)
{
unsigned int startTime, endTime;
startTime = I_MSTime ();
TArray<FNodeBuilder::FPolyStart> polyspots, anchors;
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_GetPolySpots (map, polyspots, anchors);
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
FNodeBuilder::FLevel leveldata =
{
vertexes, numvertexes,
sides, numsides,
lines, numlines
};
- ClassifyLine now chooses either SSE2 or regular x87 math depending on whether or not SSE2 is available at runtime. Since most of the time is spent in ClassifyLine, using SSE2 in just this one function helps the most. - Nodebuilding is a little faster if we inline PointOnSide. - Changed FEventTree into a regular binary tree, since there just aren't enough nodes inserted into it to make a red-black tree worthwhile. - Added more checks at the start of ClassifyLine so that it has a better chance of avoiding the more complicated checking, and it seems to have paid off with a reasonably modest performance boost. - Added a "vertex map" for ZDBSP's vertex selection. (Think BLOCKMAP for vertices instead of lines.) On large maps, this can result in a very significant speed up. (In one particular map, ZDBSP had previously spent 40% of its time just scanning through all the vertices in the map. Now the time it spends finding vertices is immeasurable.) On small maps, this won't make much of a difference, because the number of vertices to search was so small to begin with. SVN r173 (trunk)
2006-06-06 21:39:08 +00:00
leveldata.FindMapBounds ();
For some unknown reason the HasBehavior check in P_OpenMapData was gone. SVN r193 (trunk)
2006-06-15 16:23:41 +00:00
UsingGLNodes |= genglnodes;
FNodeBuilder builder (leveldata, polyspots, anchors, UsingGLNodes, CPU.bSSE2);
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
delete[] vertexes;
builder.Extract (nodes, numnodes,
segs, numsegs,
subsectors, numsubsectors,
vertexes, numvertexes);
endTime = I_MSTime ();
Printf ("BSP generation took %.3f sec (%d segs)\n", (endTime - startTime) * 0.001, numsegs);
}
clock (times[10]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadBlockMap (map);
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
unclock (times[10]);
clock (times[11]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadReject (map, buildmap);
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
unclock (times[11]);
clock (times[12]);
P_GroupLines (buildmap);
unclock (times[12]);
clock (times[13]);
P_FloodZones ();
unclock (times[13]);
bodyqueslot = 0;
// phares 8/10/98: Clear body queue so the corpses from previous games are
// not assumed to be from this one.
for (i = 0; i < BODYQUESIZE; i++)
bodyque[i] = NULL;
deathmatchstarts.Clear ();
if (!buildmap)
{
clock (times[14]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!map->HasBehavior)
P_LoadThings (map, position);
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
else
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
P_LoadThings2 (map, position); // [RH] Load Hexen-style things
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
for (i = 0; i < MAXPLAYERS; ++i)
{
if (playeringame[i] && players[i].mo != NULL)
players[i].health = players[i].mo->health;
}
unclock (times[14]);
clock (times[15]);
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
if (!map->HasBehavior)
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
P_TranslateTeleportThings (); // [RH] Assign teleport destination TIDs
unclock (times[15]);
}
else
{
for (i = 0; i < numbuildthings; ++i)
{
P_SpawnMapThing (&buildthings[i], 0);
}
delete[] buildthings;
}
- Fixed: Saving on maps that don't contain a MAPINFO definition didn't work. - Fixed: The Zip loader loaded all WADs inside a Zip into the lump directory. This is only supposed to be done for WADs in the root directory. - Complete restructuring of the map loading code. Previously the only way to put maps into Zips was to load them as embedded WADs which caused some problems, most importantly that the map's file name was irrelevant and the internal map label was used instead. With the new code there is now a properly defined way to add maps to Zips: * Maps are placed in a subdirectory called 'maps'. * Maps are stored as WADs that contain all map related lumps. * The first lump in the map's WAD directory must be the map label. * All lumps not belonging to the first map are ignored. * The map's file name determines the name the map is identified with. For maps stored this way the internal map label is ignored so with this method renaming maps is as easy as renaming a file and it is no longer necessary to manipulate the map label. With the new code it is also possible to load external maps without adding them to the WAD list. Type 'open mapfile.wad' in the console to start such a map. The new code also performs stricter lump name checks to prevent accidental loading of non-map data. SVN r188 (trunk)
2006-06-14 15:56:56 +00:00
delete map;
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
clock (times[16]);
PO_Init (); // Initialize the polyobjs
unclock (times[16]);
// if deathmatch, randomly spawn the active players
if (deathmatch)
{
for (i=0 ; i<MAXPLAYERS ; i++)
{
if (playeringame[i])
{
players[i].mo = NULL;
G_DeathMatchSpawnPlayer (i);
}
}
}
// set up world state
P_SpawnSpecials ();
// build subsector connect matrix
// UNUSED P_ConnectSubsectors ();
R_OldBlend = 0xffffffff;
// [RH] Remove all particles
R_ClearParticles ();
clock (times[17]);
// preload graphics and sounds
if (precache)
{
R_PrecacheLevel ();
S_PrecacheLevel ();
}
unclock (times[17]);
if (deathmatch)
{
AnnounceGameStart ();
}
P_ResetSightCounters (true);
//Printf ("free memory: 0x%x\n", Z_FreeMemory());
if (showloadtimes)
{
Printf ("---Total load times---\n");
for (i = 0; i < 18; ++i)
{
static const char *timenames[] =
{
"load vertexes",
"load sectors",
"load sides",
"load lines",
"load sides 2",
"load lines 2",
"loop sides",
"load subsectors",
"load nodes",
"load segs",
"load blockmap",
"load reject",
"group lines",
"flood zones",
"load things",
"translate teleports",
"init polys",
"precache"
};
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
Printf ("Time%3d:%10llu cycles (%s)\n", i, times[i], timenames[i]);
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
}
}
}
//
// P_Init
//
void P_Init ()
{
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
atterm (P_Shutdown);
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
P_InitEffects (); // [RH]
- Texture animation improvements: * Animations are now millisecond-accurate, so delays in ANIMDEFS can have fractional parts. * Cleaned up the animation code and moved it into r_anim.cpp. * Blood's oscillating texture animations are now available for use by actual supported games by adding the word "oscillate" after a "range" definition in ANIMDEFS. * Not exactly texture animation, but it's handled in the same function as texture animations: Scrolling skies also have millisecond precision. SVN r125 (trunk)
2006-05-18 01:42:50 +00:00
R_InitPicAnims ();
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
P_InitSwitchList ();
P_InitTerrainTypes ();
P_InitKeyMessages ();
R_InitSprites ();
}
- Merged a lot of these static destructor-only structs into regular functions added to the exit chain with atterm so that they can be called in a deterministic order and not whatever order the linker decides to put them in. - Fixed: DCajunMaster did not free its getspawned. - Fixed: P_FreeLevelData() did not free ACS scripts. - Fixed: Level snapshots were not freed at exit. - Fixed: The save/load menu list was not freed at exit. - Fixed: FCompressedMemFile needs a destructor to free the m_ImplodedBuffer. - Fixed: G_DoLoadGame() did not free the engine string. - Fixed: M_ReadSaveStrings() did not free the engine string. - Fixed: Processing DEM_SAVEGAME did not free the pathname string. - Added a check for truncated flats to FFlatTexture::MakeTexture() because Heretic's F_SKY1 is only four bytes long. - Added a dump of the offending state to the "Cannot find state..." diagnostic. - Fixed: FCompressedFile did not initialize m_Mode in its default constructor. - Fixed: Heretic and Hexen status bars did not initialize ArtiRefresh. - Fixed: PNGHandle destructor should use delete[] to free TextChunks. SVN r111 (trunk)
2006-05-12 03:14:40 +00:00
static void P_Shutdown ()
{
R_DeinitSprites ();
P_DeinitKeyMessages ();
P_FreeLevelData ();
P_FreeExtraLevelData ();
if (StatusBar != NULL)
{
delete StatusBar;
StatusBar = NULL;
}
}
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
#if 0
#include "c_dispatch.h"
CCMD (lineloc)
{
if (argv.argc() != 2)
{
return;
}
int linenum = atoi (argv[1]);
if (linenum < 0 || linenum >= numlines)
{
Printf ("No such line\n");
}
- Fixed: cycle_t was still a DWORD and not a QWORD under GCC. - The stat meters now return an FString instead of sprintfing into a fixed output buffer. - NOASM is now automatically defined when compiling for a non-x86 target. - Some changes have been made to the integral types in doomtype.h: - For consistancy with the other integral types, byte is no longer a synonym for BYTE. - Most uses of BOOL have been change to the standard C++ bool type. Those that weren't were changed to INTBOOL to indicate they may contain values other than 0 or 1 but are still used as a boolean. - Compiler-provided types with explicit bit sizes are now used. In particular, DWORD is no longer a long so it will work with both 64-bit Windows and Linux. - Since some files need to include Windows headers, uint32 is a synonym for the non-Windows version of DWORD. - Removed d_textur.h. The pic_t struct it defined was used nowhere, and that was all it contained. SVN r326 (trunk)
2006-09-14 00:02:31 +00:00
Printf ("(%d,%d) -> (%d,%d)\n", lines[linenum].v1->x >> FRACBITS,
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
lines[linenum].v1->y >> FRACBITS,
lines[linenum].v2->x >> FRACBITS,
lines[linenum].v2->y >> FRACBITS);
}
#endif
Reference in a new issue Copy permalink