Seamless levels and Wolf4sdl

Using MCS's tutorial on enabling seamless level progression renders some compilation errors. The errors basically stop me dead in my tracks at WL_MENU.CPP. I get the following

Code:


c:\documents and settings\nickolas\desktop\my ****\project\blackwolf\source\wl_menu.cpp(3913) : error C2065: 'f' : undeclared identifier
c:\documents and settings\nickolas\desktop\my ****\project\blackwolf\source\wl_menu.cpp(3913) : error C2065: 'FA_ARCH' : undeclared identifier
c:\documents and settings\nickolas\desktop\my ****\project\blackwolf\source\wl_menu.cpp(3913) : error C3861: 'findfirst': identifier not found
c:\documents and settings\nickolas\desktop\my ****\project\blackwolf\source\wl_menu.cpp(3922) : error C2065: 'gfilename' : undeclared identifier
c:\documents and settings\nickolas\desktop\my ****\project\blackwolf\source\wl_menu.cpp(3923) : error C2065: 'aheadname' : undeclared identifier


Its all centered in the block:

Code:


void
CheckForEpisodes (void)
{
    struct stat statbuf;

   if (!findfirst("*.WL6",&f,FA_ARCH))
   {
      strcpy(extension,"WL6");
   }
   else
   Quit("NO WOLFENSTEIN DATA FILES TO BE FOUND!");

   strcat(configname,extension);
   strcat(SaveName,extension);
   strcat(gfilename,extension);
   strcat(aheadname,extension);
   strcat(demoname,extension);
   strcat(helpfilename,extension);
   strcat(endfilename,extension);
}


I am not sure what the problem is and I highly doubt he would post code that doesn't work, so I am assuming it is a thin with SDL because of some changed code somewhere. Doing a search (with the whole msvc solution as the scope) for any the missing vars renders no results, including the findfirst function. So I am assuming something has seriously changed.


Thanks,
Dr.Zin

I take it the solution either doesn't exist or the forum's are seriously inactive right now =P

Yes I have looked over at the DieHard forums, however, searching and viewing topics is broken, as it returns an SQL querry error. So those forums are effectively useless.

Dr.Zin wrote:I take it the solution either doesn't exist or the forum's are seriously inactive right now =P

Yes I have looked over at the DieHard forums, however, searching and viewing topics is broken, as it returns an SQL querry error. So those forums are effectively useless.

I found one thread 'Seamless in SDL' on Die Hard Wolfers which may help http://diehardwolfers.areyep.com/viewtopic.php?t=5412&start=0 .

Ah thanks for that. I browsed it in Firefox (on my laptop). Andy's post pointed me in the right direction. I still had to modify his code somewhat, but in the end I have seamless levels. In SDL, achieving seamless levels is completely different than the original code. I think that his tutorial should be put up here somewhere for future reference. HOWEVER, the one modification that is needed is to remove any reference to the integer variable 'episode', and just change NewGame(which, episode) to NewGame(which, 0), so that you'll start out in episode 1 levels (all episodes are ep. number - 1).

I would go with Chris' code towards the end of that DHW thread. If you read to the end, you'll see that there were some problems with my code. Hopefully you won't get bitten by it.

Actually your code was quite functional up to a point in CP_NewGame. It appears that you forgot to get rid of some very last bits of the episode selection. Particularly the parts about what level to begin on. As is, it'll cause you to bomb out after selecting the difficulty. So I did a little experimenting and came up with the following -

(My specifics in red)

int CP_NewGame (int)
{
int which; //No need for episodes variable. Dont even keep it around or MSVC debug
//will bomb it out

#ifdef SPEAR
UnCacheLump (OPTIONS_LUMP_START, OPTIONS_LUMP_END);
#endif


#ifndef SPEAR
firstpart:

/* DrawNewEpisode ();
do
{
which = HandleMenu (&NewEitems, &NewEmenu[0], NULL);
switch (which)
{
case -1:
MenuFadeOut ();
return 0;

default:
if (!EpisodeSelect[which / 2])
{
SD_PlaySound (NOWAYSND);
Message ("Please select "Read This!"\n"
"from the Options menu to\n"
"find out how to order this\n" "episode from Apogee.");
IN_ClearKeysDown ();
IN_Ack ();
DrawNewEpisode ();
which = 0;
}
else
{*/
//episode = which / 2; //We need to comment it out as it wants to select an episode
which = 1;
/*}
break;
}

}
while (!which);

ShootSnd ();
*/
//
// ALREADY IN A GAME?
//
if (ingame)
#ifdef JAPAN
if (!GetYorN (7, 8, C_JAPNEWGAMEPIC))
#else
if (!Confirm (CURGAME))
#endif
{
MenuFadeOut ();
return 0;
}

MenuFadeOut ();

#else
//episode = 0; //This is dead code as far as I know compiling Wolf3D, so drop it anyway

//
// ALREADY IN A GAME?
//
CacheLump (NEWGAME_LUMP_START, NEWGAME_LUMP_END);
DrawNewGame ();
if (ingame)
if (!Confirm (CURGAME))
{
MenuFadeOut ();
UnCacheLump (NEWGAME_LUMP_START, NEWGAME_LUMP_END);
CacheLump (OPTIONS_LUMP_START, OPTIONS_LUMP_END);
return 0;
}

#endif

DrawNewGame ();
which = HandleMenu (&NewItems, &NewMenu[0], DrawNewGameDiff);
if (which < 0)
{
MenuFadeOut ();
#ifndef SPEAR
//goto firstpart;
return 0;
#else
UnCacheLump (NEWGAME_LUMP_START, NEWGAME_LUMP_END);
CacheLump (OPTIONS_LUMP_START, OPTIONS_LUMP_END);
return 0;
#endif
}

ShootSnd ();
NewGame (which, 0); // This part is extremely important, the second parameter
// of NewGame is which episode to start in. By setting it to 0
// rather than keeping around an obsolete variable, we start
// in Episode 1, and you can progress from there seamlessly!
StartGame = 1;
MenuFadeOut ();

//
// CHANGE "READ THIS!" TO NORMAL COLOR
//
#ifndef SPEAR
#ifndef GOODTIMES
MainMenu[readthis].active = 1;
#endif
#endif

pickquick = 0;

#ifdef SPEAR
UnCacheLump (NEWGAME_LUMP_START, NEWGAME_LUMP_END);
CacheLump (OPTIONS_LUMP_START, OPTIONS_LUMP_END);
#endif

return 0;
}


The above along with your other changes works quite well for me, and I hope this helps anyone seeking the same information as myself. Basically my method centers around brute forcing the game to start a new game on Ep1 Map 1, while the rest of your code allows it to progress seamlessly. The only time it bombs now is if i go into a 64x64 map, as I am using 128x128 now.

I like the idea of seamless maps. Now how difficult would a persistent level be? A HUB system would be very awesome and allow for more dynamic maps not to mention less linear game play.

You would need to implement some manner of cache or buffer to store level data when it is entered and exited. This can be quite a bit of data and has the potential to be a very serious memory eater as you read and write data multiple times. The more levels you have the more data you would need to store. You would need to store the position and type of every object, door and wall in the level as it is when the level is exited. If you keep with 16 bits per tile that is 8 kilobytes per level on a 64x64 level. It goes to 32 kilobytes per level when you move to 128x128 sized levels. Obviously, the memory adds up pretty fast, especially if you have large hubs. A 10 level hub with 128x128 levels is 320 kilobytes of data you'd need to store.

So, say level 1 through 10 are part of hub 1. When you enter level 1 you will need to store a "photocopy" of it in the hub cache. When it is completed you will need to store another photocopy of it over the previous one. When you enter level 2 this has to be repeated. Now, if you go back to level 1 you will need to load the latest photocopy of level 1 which will serve as the playable level. You will need to implement some form of memory manager to keep this operation efficient and performance conscious. So, let's say you have 32 playable levels in your game, that is nearly a megabyte in level data you need to manage. The best way to avoid this memory and performance pitfall is to divide your game into smaller hubs where the player cannot move between then. I.e. non-linear play is restricted to a single hub. So, once you've moved to hub 2, the cache is cleared and moving to levels in hub 1 is not possible.

In short, this would require writing new routines for managing, loading and saving level data as well as a hub cache which will become very expensive the more levels you have in a single hub. While it may seem nothing to manage a 32 kilobyte cache when a system has gigabytes of available memory, it is actually extremely cumbersome and performance hungry. You can do it one of two ways, using a cache file or a cache array. File I/O can be costly and an array with massive subscript numbers can be very hard to manage leading to corruption so you would need very, very clean and efficient code that knows exactly what it is doing using only fixed numbers. All of your hubs should have a fixed number of levels like an episode or some such, it will become too much to deal with if you start getting silly with hubs having an arbitrary number of levels.

Frankly, I would advice against it. If you want hub-style gameplay, just use a modern Doom port. You're not taking into account the relative age of the code, even with SDL enhancements. It would require some rather serious rewrites of a lot of core systems.

I wonder if the solution is equally complex if this same logic is applied to the ROTT engine.

If I recall, ROTT is still DOS and therefor still bound to 64 kilobytes of memory. So, unless there is a Win32 port for it, no, it would take up too much memory.

EDIT: If it was written using any kind of DOS Extender, then then 64kb limit doesn't apply, the limits of whatever DOS extender the authors used applies.

I have some ideas, non of which involve the use of a DOS extender thankfully. Looking over the WinRott code best the best option available.

It likes to randomly crash on me. Anyone else have this problem?

Start a different thread on that issue.