Reinstating the overhead map function in Wolf3D

First topic message reminder :

Well, I added the code from that thread on DHW to WL_DEBUG.C and the compiler is choking on about 16 errors. I really don't know what to do to fix it, so I thought maybe I should start a new thread and ask about getting help to fix it. I know the code in that thread on DHW was for SDL, so I was expecting problems. I just don't have enough knowledge or experience to fix the errors.

There was a piece of the thread that talked about changing unsigned in some places to uint8_t so it would work in MacOSX. There were 2 occurrences of uint8_t in the code, so I changed both of them to unsigned and that got rid of two of the errors. I will see if I can post the errors and the lines they apply to here, but being in DOSBox, I don't know if there's an easy way to save out the messages and the code they relate to. I will edit this post when I have something.

Code:

void TileMWall(unsigned sx, unsigned sy, unsigned pagenum)
{
    unsigned *start;
    start = PM_GetPage(pagenum); // line 633 WARNING: Suspicious pointer conversion

    for (int x=0;x<TileMSize;x++) // line 635 ERRORs: Expression syntax, Undefined symbol 'x', Statement missing ;
    {
        for (int y=0;y<TileMSize;y++) // line 637 This line previously had the same errors as line 635, but after changing uint8_t to unsigned these errors went away
        {
            VWB_BarScaledCoord((sx+x*pixelSize),(sy+y*pixelSize),pixelSize,pixelSize,(int)*start);
            start = start + TileMWallRatio;
        }

        start = start + TEXTURESIZE*(TileMWallRatio-1);
    }
}

void TileMDoor(unsigned sx, unsigned sy, byte doornum) // line 647 ERROR: Declaration is not allowed here
{ // line 648 ERROR: Declaration syntax error

.
.
.

    VW_UpdateScreen();

    if (Keyboard[sc_P])
        PictureGrabber();

} // line 871 WARNINGs: 'start' is assigned a value that is never used, Parameter 'sx' is never used, Parameter 'sy' is never used
// #endif

// #if 0
/*
===================
=
= ViewMap
=
===================
*/



OK, I'm finishing up this post. I read your responses and intend to utilize them, but I wanted to finish this post so you can see what I see. Apparently, changing the uint8_t occurrences to unsigned got rid of most of the errors, leaving just the 6 errors and 4 warnings above.

If you need a new signon screen you could also try
https://wl6.fandom.com/wiki/BMP2C
or
WolfSignon

Thanks, Nexion. I will be checking these out. Already downloaded both of them.

@AryanWolf3D Now all I have to do is find the file that is in. Shouldn't be too hard.

@Wolf3DGuy You're right. I searched for it and it's not out there. I did find an article that says that (I think it was) John Romero who wrote it. My guess is they never made it public.

.

I was looking at those earlier. When I tried to find the actual functions they were in none of the files I looked at. Anyway, I am continuing to try and figure out how the game loads the files it uses so that I can better understand the file i/o the game has. So far, it's a no go, but I will continue to try.

I looked at signon.obj in XVI32 and found that it was created with a program called makeobj. I found links, but the file size is always 0, so I'm assuming the files have disappeared long ago and they just never took the links down. I would really like to modify the contents of signon.obj, but creating a new signon in a .c file will suffice for now.

I have run into an interesting wall. The size of the image is supposed to be 320x200, but every screenshot I take is 642x427. Even if you account for the window title bar and whatever side and bottom there may be (which I don't see in the screenshots), this in no way is a 320x200 image, and the DOSBox window is much bigger than that. In fact, it's bigger than 640x400, so I don't know how I am supposed to work with an image that big. I have to be able to reduce it to 320x200, and scaling in gimp is causing much blurriness. My idea is that I want to use the original screen as much as possible, keeping the ID logo and Wolf3D title intact. I was going to take the Apogee, Activision and GT logos and reduce them until I can fit all three of them in the right-side box. The box is, after all, the same size for each one separately. I was going to try to put Apogee and GT above ActiVision. Now I'm not so sure this is a feasible idea. After all, I'm not a graphic artist. I dabble in "pixel art" here and there, but really fancy stuff is out of my league.

.

I have been looking at the files. I can see there's a limit to what I can understand. I have never learned assembly, so reading that code is like reading hieroglyphics to me. It's OK though. I have also looked at the signon code in main. I've looked at it a few times, actually. It's calling functions that I can't find anywhere. There are so many files in the source code that I don't know which files do what. With no easy way to search all of the files, it's like trying to find a needle in a haystack. Anyway, I am going to stop trying to add or change anything else for abit so I can get what I've already done documented. It sortof already is, in these threads, but I want to make a concise record of exactly what I changed and why so others who may want to make these changes will know what I did.

Oh, and @AryanWolf3D, you never did tell me what it is that I sacrificed by removing the code:

Code:

#ifdef AUDIOHEADERLINKED
huffnode *audiohuffman;
#else
huffnode audiohuffman[255];
#endif

As I said previously, the game has suffered no ill effects from it, but I'm wondering what changed by removing this. The explanation will also be good to include in my documenting what I changed and why, as I can include what effect the change did have (in this case, freeing up memory and at what cost).

.

Wolf3DGuy wrote:I believe there's no cost in this case, they used something else instead, this was left unused and they kept it for no reason.

Thanks, Wolf3DGuy! That's perfect! Unnecessary and unused is always a candidate for removal.

Nexion wrote:You might want to change Dosbox's resolution to 320x200 in the dosbox.conf. I think by default CTRL+F5 should be the screenshot function which keeps the game palette intact.
Alternatively use printscreen and load the palette after though it could lose some colors this way. The WolfSignon tool also has a template but without logos in case.

I am using WolfSignon, but because the images don't contain the ID logo or any of the other logos or the title, I have to grab them from a screenshot of the signon screen from the game. I will look at DOSBox's config file to see about setting the resolution to 320x200. That should solve the problem, as everything will be properly scaled then. Thanks for the tip.

.

AryanWolf3D wrote:Yeah, there's a ton of unused stuff in the code. That array alone takes up 1k of the data segment, which is a terrible waste.

I don't get what's so complicated about the signon screen routines? Every function name in them is prefixed by the ID manager that contains it:

MML -> ID_MM.C
US -> ID_US_1.C
IN -> ID_IN.C
VL -> ID_VL.C

The VW/VWB/VH/VL stuff can seem a little confusing. Originally, in the catacomb source, there was only ID_VW.C, but that later got split up into two files, ID_VH.C and ID_VL.C. The VW routines are macros for compatibility with the old code. VWB is a wrapper that first checks stuff to do with the block updating (I admit I don't understand that stuff very well at all...)

For me, the confusion is in the fact that it is not necessarily a easy transition from, say, MML to ID_MM.C when you don't know what MM stands for, or what any of the files do. The text at the top of each file does not say what that file is, or what it's for, and the assumption is you know the language and coding well enough to make educated guesses. If you don't know the language that well, or the coding for it, those assumptions are incorrect. The language I have proficiency in is called Basic09, and runs on a Tandy Color Computer using the OS-9 operating system. That's a far cry from the PC, DOS and C. I have learned enough C to be able to understand what most instructions are saying. Do I understand what they are doing? Not by a long shot. Thanks for the info, as now maybe I can start making sense of the code.

Oh, is there a list anywhere that will tell me the unused things that I can comment out to free up more memory?

.

.

.

Oh boy! I'm like a kid in a candy store with that list! LOL

I'll be going through it with a fine-toothed comb, for sure.

I have made a web page to document the changes I have made so far (with space for the ones I haven't done yet). I thought you guys might want to check it out. I wrote it in a how-to style with an eye on people who know less than I do. It's not finished yet, and I plan to add more information about getting Borland installed and setup for editing the source, getting the source ready, and more on the utilities I am using. If any of you see anything I missed, give me a shout out.

Edit: Might help if I include the link!

.

Wolf3DGuy wrote:Nice link! Note that Chris and Princess Peach is the same person!

LMAO! I didn't know that. Well, he gets double billing then!

I have been conversing with Adam Bizer concerning the way WDC has been dealing with the tile16's being in the VGAGRAPH.WL6 file. In the discussion, I realized the error I had made choosing to go for hard-coded door numbers in the code. I worked out what I thought the proper arrangement should be and created this document to show Adam and get his idea of whether or not I am correct. Anyway, I created a new tile16 image based on these numbers, and this is what it looks like:



The white space are all of the sparse tiles (they aren't really sparse, they're just blank because I don't know how to make them sparse yet). The doors and door jamb on the 3rd row are there to keep the game displaying doors in the map, but if I wanted to add the SoD walls that Wolf3D doesn't have, they'd have to go. For this reason, I need to figure out how to modify the code to look for the doors where they're supposed to be instead of where they are. The doors at the bottom of the image are correct according to where the Alpha has them. I recompiled the game after changing the numbers in GFXV_WL6.H and ran the game. There are two problems, but otherwise the game runs fine. The problems occur on the signon screen and the loading screen when you start a new game.





I think these problems are just related to banging the edge of memory again, but I haven't figured out what to change yet in that list I got from AryanWolf3D. Since the game is running and not crashing, I figure I can still try to work out what to change in the code so that the overhead map function looks for the correct tiles in the correct locations. I am still studying the code, but I am making very little progress.

.

.

That makes a whole lot of sense. I will try doing that as well, but I was also thinking that if I knew how to identify the tile16's in the VGAGRAPH file, and how to make sure the VGAHEAD file was updated accordingly, I might be able to save some space by removing the unused tile16's the same way they did in the Alpha. If you look at it, the unused tile16 chunks don't even exist in that file. I think that allowed them to have all of the ones the Alpha used in without having to worry about running out of space.

Also, if you look at SoD, there are images in that game that do not exist in the Wolf3D game (and some of them don't use the same palette). I think if you start mucking with removing images from the file it will have an adverse affect on SoD (I do want to eventually get to adding these mods to SoD, but I have a long way to go before I will be comfortable trying to compile for SoD).

I am going to try reducing the tile8 number from 72 to 35, and I am still trying to sort out how to remove the unused tile16's to see if that makes a difference. The Tile16M's are something I'm thinking about also because when I play in Death Incarnate mode the map shows me objects in the rooms, and I'd like to see the actual object instead of a number. But that is for another day. Let me get the Tile16's figured out first.

BTW, where did you define TILETEST3?


Edit: I just found in the WL_DEF.H file:

#define NUMLATCHPICS    100

Aren't there more than 100 images in the VGAGRAPH file, not including the tile8 and tile16's? (I believe the count was 134). Should I change this number to correspond with that?

Edit2: I see why you said 25 instead of 35. If I change the number to 25, should I also alter the tile8 image to not include the 10 blank images?

.

I tried removing the unused part of the tile8 image. WDC still shows the bottom 2 rows of the original images, sans the lines that made borders around each one. I'm guessing that means it worked.

I see. Well, I guess I can leave that alone for now, until I figure something out. I really would like to know how to remove chunks that aren't needed, since that reduces file size as well as making it faster to load the chunks that do matter.

OK, that makes sense. I did change the one, not knowing there was another until the compiler choked. Thing is, it didn't tell me which file the other one was in. It was compiling WOLFHACK.C when it happened, and I couldn't understand why it errored there when latchpics and numlatchpics don't occur in that file at all. Thanks for telling where to find it. LOL

I won't worry about that then. I was going to try your code, but if it doesn't work properly in 1.4 then it won't help.

.

AryanWolf3D wrote:

Code:

for (i=0;i<NUMTILE16;i++)
{
    if ((i >= 56 && i <= 71) || (i >= 75 && i <= 89) || (i >= 94 && i <= 99) || (i >= 102 && i <= 107))
        continue;

    CA_CacheGrChunk (STARTTILE16+i);
    src = (byte _seg *)grsegs[STARTTILE16+i];
    VL_MemToLatch (src,16,16,destoff);
    destoff+=64;
    if (src)
        UNCACHEGRCHUNK (STARTTILE16+i);
}

It's ugly, but it might work.

First, the blanks from 102 through 107 don't exist. By specifying 102 chunks, they were not imported. Second, the chunk numbers are 139-240, so would I change the numbers you show to the chunk numbers, or does this routine start at 0?

Edit: NVM. I just saw the answer in the for statement. LOL

I tried changing NUMLATCHPICS to 47 ( the actual number of images between and including KNIFEPIC (91) and GETPSYCHEDPIC (137)). The game showed the signon screen for about a second, then the top 5 or 6 lines of the screen became garbled and the game crashed. I changed it back to 100. I haven't gotten good enough to know what's going on with that, so I think I'll leave it alone for now.

I'm about to recompile the EXE to see what happens with this change.

Edit: Just not loading the unused tile16 images worked. The game functions normally again. Now I can get back to how to use the doors where they are at the bottom of the image rather than the ones immediately following the last wall image. That may help with getting the map to recognize the elevator wall (code 85). In the game, it looks identical to the elevator control (code 21), but it isn't functional. To me, that one should be called the fake elevator and the one called fake elevator (code 22) should be called up elevator control since it's the one that displays when you enter the elevator and press the space bar. Anyway, in the map it shows up as 0055 (not 0085?) instead of using a tile16.

Nice thing about the code you provided is that I can modify it to include the tile16's for the walls in SoD if I decide to add those in. I know they aren't used by Wolf3D, but I can always see if I can make maps using them just to see what I can do.

.

AryanWolf3D wrote:47 must have been too few then. You could try increasing it by 1 each time until it no longer bombs.

Out of curiosity, could you show me how much latch memory you have remaining now? Just do the sprintf and Quit thing that I mentioned earlier and the error screen will print the number.

I'm about to recompile with the sprintf code added. I'll let you know what the answer is.

it says 64464.

.

LOL yeah. I changed the NUMLATCHPICS to 50 and it worked, so I changed it to 49. Still worked. I'm going to try 48 and if that works, then I'm going to try 47 one more time. When I figure out what number breaks it, then I'm going to set it back to the lowest number that works and run the sprintf thing again to see what number I get then.

Edit: 48 broke it with a map not 64x64 error. 49 is the lowest number that works. The sprintf thing still reports 64464 as the memory used, so I guess changing the NUMLATCHPICS value didn't really do much for the tile16's.

.

That makes sense. So, is there anything you can tell me about the elevator door thing so that the map will display the elevator wall image instead of the 0055 number? I have the feeling that the code 0085 is partly the issue, since that's the code the map editors say it is, and using it in the editor does seem to put it in the map as far as the game displaying it normally. It just doesn't show up as an elevator control or side wall in the overhead map.

Also, I know that the original overhead map didn't display the doors as doors, but as numbers, so I'm guessing the only way to get the overhead map to display them as doors is to look for them in specific locations in the tile16's. This would mean hard-coding them the way it is now, except for using the numbers for the doors more at the end of the tile16's than where it's looking now. am I correct?

Edit: Well, either I am incorrect or there's something else going on. The doors are located at 90-91 for the normal doors, 92-93 for the locked doors and 100-101 for the elevator doors. It doesn't matter which I specify for any of them, the doors in the overhead map are not doors. I will post a pic here.



Edit: I thought, maybe if I subtracted the number of unused tile16's that weren't being loaded...



Improvement! We're back to where we were when it wasn't showing doors or numbers. I think that's a good place to start, don't you?

.

.

AryanWolf3D wrote:I'm not sure what you mean by the dummy elevator being tile 85... That's not even within the range of walls in tilemap.

That one is listed in the map editors as 85, Elevator wall. In the game it is the same thing as the elevator (down control on east-west face, side wall on north-south face), but it doesn't work. The Fake elevator (22) is actually the up elevator control on the east-west face and a dark gray nothing wall on the north-south face. I discovered this when I went to use the fake elevator in a level I was playing around with to see if it would let me put a fake elevator facing north-south instead of east-west. Of course, it didn't because all elevator control images face east-west. Anyway, in my test area of the first floor map, where I have these things set so I can see what the map displays as opposed to what's actually there in the game, the elevator wall shows up in the map as 0055 instead of the elevator-wall image that I was expecting to see. The Fake elevator shows up as the up control because I made sure that image was in the tile16's at that location. Originally, the down control image was there, so both the elevator control and "fake elevator" showed the same graphic. However, I think that the "fake elevator" should be renamed "up elevator control", and the "elevator wall" should be renamed "fake elevator". Now, I do not know why it has the code in the editor of 85. All I know is, in the game it shows up as an elevator control that isn't functional.

Oh, in the map editor, the doors have the codes 90,91,92,93,94,95,100 and 101. (94 and 95 are the silver key doors, but there is no separate graphic for them, so I didn't put one in for them. I figured they could use the same one as the gold-key doors.)

AryanWolf3D wrote:And didn't we already get the doors to display properly?

As I said before, that was with the doors being located where walls from SoD would be if I included them, so if I wanted to include them, the door images would have to be moved. Also, Adam stated that it would be better to look for them where they are supposed to be, which is in positions 90,91,92,93,100 and 101 (chunks 229,230,231,232,239 and 240). I am agreeing with that, so I am trying to figure out how to make the map code look for the doors where they are supposed to be.

As I am reading this, I realize that maybe all I need do is put the image I want in position 85. I don't know why I didn't think of that before.

Wolf3DGuy wrote:ChaosEdit also shows a dummy elevator on the map symbols, I believe WDC does too!

That is the one I am referring to, and yes, ChaosEdit, Havoc's Wolf3D Editor and WDC have it. The code is 85.

.

Well, that didn't fix it. My guess at this point is that the doors are looked at as separate from the walls, and the elevator wall (being 85) is somehow being seen as part of the doors. The fake doors and door jamb (door excavation the editors call it) are 50-53 and occur at the end of the walls. The doors begin at 90, and the elevator wall being 85 falls between them, so I'm not sure how the game sees this. I just know that the overhead map doesn't have a clue what it is. and the doors are not showing up as doors now because I changed the locations to look for them. I am guessing that, in the game, the doors have a different kind of code or something.

@Wolf3DGuy: you just clued me in. That's the reason these things aren't working as expected. I keep forgetting about the 64 wall image limit. SoD pushes this to the limit, as it has 63 walls, and the overhead map, adding a floor image, makes that 64. so anything above 63 is going to be trashed since there is no valid wall code there. I have been trying to use the workaround AryanWolf3D gave me where we looked at specific locations, but I didn't think about the fact that 50-53 is less than 64. Adam did tell me that the overhead map originally didn't display the doors, but numbers instead, and I remember that was why AryanWolf3D and I worked out that workaround. I guess it's back to the drawing board.

.

I made a little video so you guys can see what I see. It's going to be about a half-hour before it's done uploading. I will edit this post when it's ready and embed the video here.

@Wolf3DGuy: This is good info. I am checking it out while I wait for the video to upload. I will be studying it to figure out where the game is loading the elevator wall from, because it does (as the video I made will show).

.

.

AryanWolf3D wrote:Alright, after some quick testing, the "ran out of latch space!" comment is definitely correct. Let me explain a couple things...

Neat stuff. Wonder if that's why they ended up removing the vga TILE16s. Funny and cool idea to shove the chunks into the end of video ram instead of near or far memory, I remember Fabian saying they used that trick for something else too maybe for speed. I guess if you did it with the egagraph and took the TILE16 loading code from TED5 it could use half the memory? haha, might take a shot at this later when I'm back from my parent's camp. It might require temporarily switching wolf3d to a different video mode though or some EGA->VGA drawing hackery.

Speaking of which, Asa, did you know that Les Bird (one of the creators/programmers of Corridor 7) recently found his WL6 egagraph, it was dated 1993-02-04 so it has the Spear walls in it too. I'll upload it here in case anyone else wants to look at incorporating it into the overhead.

.

.

.

AryanWolf3D wrote:OK, I didn't know about the fake elevator wall at 85, but I know what's going on. The walls are stored on the actorat table, and the overhead code draws Tile16s for them as long as the actorat value is BELOW 64, otherwise it will draw Tile8s. The reason for the fake elevator having a tile number of 85 is because after 63, the walls will repeat. The regular elevator is 21, so 64 + 21 = 85 for the fake elevator. The reason why you can't flip the switch is because the code checks specifically for tile 21.

Now I get what the point of 85 is. Now, if I can just figure out how to use that to my advantage.

AryanWolf3D wrote:By the way, don't be confused by it showing 55 on the overhead... That's hexadecimal for 85. ;-)

I don't know why I still haven't gotten hex down. I use it, I know it, but I never make the connection. LOL

AryanWolf3D wrote:As for the doors, you should be able to use the same code I showed you for them, just change the numbers to match the new tile locations (starting at 90, I guess.)

I did that initially. Using 91, 93 and 101 got me the result shown in notdoors.png, which I posted an image a few posts up. Using 90, 92 and 100 got me almost the same result, except for where there are normal doors, I get the white numbers on blue background in the same 8x8 format as the tile8's. I'll grab a screen shot of that.

AryanWolf3D wrote:About your comment in the video about the game "already pushing the limit on memory"... Well yes, it kind of does, but with a bit of work and a lot of creativity, you can get access to stuff you would never have thought possible. I mean, that basically sums up the game itself.

That gives me hope. Maybe I can do the things I want to do, given enough time to learn the coding.