- reordered a few things in the startup procedure
Mainly done to isolate the calls that actually manipulate the global frame buffer. V_Init alsoi initialized some palette data, which was moved to V_InitPalette and did something entirely different when running a restart as opposed to an initial start.
This commit is contained in:
parent
a2883cdf39
commit
2a3205200f
4 changed files with 113 additions and 101 deletions
|
|
@ -2453,8 +2453,26 @@ void D_DoomMain (void)
|
|||
I_Init ();
|
||||
}
|
||||
|
||||
// [RH] Initialize palette management
|
||||
InitPalette ();
|
||||
|
||||
if (!batchrun) Printf ("V_Init: allocate screen.\n");
|
||||
V_Init (!!restart);
|
||||
if (!restart)
|
||||
{
|
||||
V_InitScreenSize();
|
||||
}
|
||||
|
||||
if (!restart)
|
||||
{
|
||||
// This allocates a dummy framebuffer as a stand-in until V_Init2 is called.
|
||||
V_InitScreen ();
|
||||
}
|
||||
|
||||
if (restart)
|
||||
{
|
||||
// Update screen palette when restarting
|
||||
screen->UpdatePalette();
|
||||
}
|
||||
|
||||
// Base systems have been inited; enable cvar callbacks
|
||||
FBaseCVar::EnableCallbacks ();
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue