zdoom/qzdoom
0
0
Fork 0
mirror of https://github.com/ZDoom/qzdoom.git synced 2024-11-11 23:32:04 +00:00
Code Issues Projects Releases Packages Wiki Activity
qzdoom/src/p_setup.h

97 lines
2.2 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.
//
// DESCRIPTION:
// Setup a game, startup stuff.
//
//-----------------------------------------------------------------------------
#ifndef __P_SETUP__
#define __P_SETUP__
- 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 "w_wad.h"
#include "files.h"
#include "doomdata.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
- 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
struct MapData
{
wadlump_t MapLumps[ML_BEHAVIOR+1];
bool HasBehavior;
bool CloseOnDestruct;
int lumpnum;
FileReader * file;
MapData()
{
memset(MapLumps, 0, sizeof(MapLumps));
file = NULL;
lumpnum=-1;
HasBehavior=false;
CloseOnDestruct=true;
}
~MapData()
{
if (CloseOnDestruct && file != NULL) delete file;
file = NULL;
}
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
void Seek(unsigned int lumpindex)
- 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
{
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
if (lumpindex<countof(MapLumps))
- 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
{
file->Seek(MapLumps[lumpindex].FilePos, SEEK_SET);
}
}
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
void Read(unsigned int lumpindex, void * buffer)
- 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
{
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
if (lumpindex<countof(MapLumps))
- 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
{
file->Seek(MapLumps[lumpindex].FilePos, SEEK_SET);
file->Read(buffer, MapLumps[lumpindex].Size);
}
}
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
DWORD Size(unsigned int lumpindex)
- 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
{
GCC compile fixes. SVN r189 (trunk)
2006-06-14 20:24:43 +00:00
if (lumpindex<countof(MapLumps))
- 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 MapLumps[lumpindex].Size;
}
return 0;
}
};
MapData * P_OpenMapData(const char * mapname);
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
// NOT called by W_Ticker. Fixme. [RH] Is that bad?
//
// [RH] The only parameter used is mapname, so I removed playermask and skill.
// On September 1, 1998, I added the position to indicate which set
// of single-player start spots should be spawned in the level.
void P_SetupLevel (char *mapname, int position);
- 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
void P_FreeLevelData();
- 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
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
// Called by startup code.
void P_Init (void);
#endif
Reference in a new issue Copy permalink