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.

Here's what the even numbers shows:
(90 for normal door, 92 for locked door, 100 for lift/elevator door)



Here's what the odd numbers shows:
(91 for normal door, 93 for locked door, 101 for lift/elevator door)

.

Looking at the elevators in the overhead map you see this:



I have always wondered why it doesn't show the elevator control where it should be instead of the elevator wall. Well, Adam Biser gave me a code segment that he says will deal with this, but because of the way it's written, I'm not sure where to put it.

Code:

if ((x > 0 && (unsigned)actorat[x - 1][y] < MAXWALLTILES) || (x < 63 && (unsigned)actorat[x + 1][y] < MAXWALLTILES))
{
    // When there's a wall to the left or right, draw the elevator side.
} else {
    // Draw the elevator switch
}

I'm sure it uses the LatchDrawTile(sx,sy,tile); statement where the comments are, but I'm not certain how to identify the tile16's. I know that the wall is 21 and the control is supposed to be 22, but (even though the images suggest it's the down control) the control inserted into the game when 22 is used is the up control, not the down control. I replaced the down control tile16 with a up control one, and now when I look at the controls in the game and then go to the overhead map, the tile16 for the up control wall is correct. I don't know if any of this is making sense.

Let me start again. There are two elevator control textures, one for the control you see when you first enter the elevator, and one for what you see after you press the spacebar. The first one has the down arrow lit and the up arrow dim. The second one has the down arrow dim and the up arrow lit. Also, the switch between them is down in the first and up in the second. I call these the down and up controls, respectively. In the textures, the elevator wall occurs at #40, the down elevator at #41, the dark blank side of the up control at #42 and the up control at #43.

In the tile16's, the side wall is at position #21, the down control at #22 and there is no tile16 for the dark blank sidewall or the up control. In the game map, a code of 21 places an elevator down control with an elevator side wall on either side of it in that position in the map. The overhead map will show a side wall, not an elevator control. a code of 22 placed in the game map places an up elevator control with the dark blank sidewall in that position in the map. The overhead map shows the elevator down control in that position.

The code Adam gave me is supposed to detect if the elevator control is facing a wall on either side or both sides. If on one side, then place the elevator down control tile16 in the overhead map there. If walls are on both sides, place the elevator wall tile16 in that position in the overhead map. I like this, as it is more along the lines of what the overhead map should be displaying, rather than what it does display. The problem, for me, is that because he coded the if statement the way he did, I'm not sure where it goes in the code as it exists now. and then, I think the latchdrawtile statement will state 21 if a wall or 22 of a control, but I'm again not sure.

.

Yeah, it just keeps putting the side wall tile there. The fog in my brain lifted enough for me to grok what the code is doing, and it seems like it would be right, since the location in my extra room that has the up elevator set shows the same tile we're trying to get here. I just don't get why it's not working. The code says it should be.

Edit: Success!!!




How, you ask? The fog lifting from my brain enabled me to see what was going on. The code in the if statement was almost right. It just needed a little tweaking.

The original statement:

Code:

if ((x > 0 && (unsigned)actorat[x - 1][y] < MAXWALLTILES) || (x < 63 && (unsigned)actorat[x + 1][y] < MAXWALLTILES))

The modified statement that works:

Code:

if ((x > 0 && ((unsigned)actorat[x - 1][y] > 0 && (unsigned)actorat[x - 1][y] < MAXWALLTILES)) && (x < 63 && ((unsigned)actorat[x + 1][y] > 0 && (unsigned)actorat[x + 1][y] < MAXWALLTILES)))

You'll notice that what the new one is doing is making sure that the tile on either side is or is not a wall. If either one is not a wall, then it is a floor space. If it's a floor space, then the tile is the elevator control, not a side wall. Also, I changed the or (||) to and (&&) because it was going to decide it was a wall with the or. The code was saying if either one is a wall then make it a wall. It needed to be saying, if both are walls then make it a wall, otherwise one is a floor space, so make it the elevator control.

.

AryanWolf3D wrote:Ah, I think that's because it doesn't confirm that there's an actorat value in those places... For example, "(unsigned)actorat[x - 1][y]" will be 0 if it's an empty spot to the left of the elevator switch... Which is still less than MAXWALLTILES. So try changing that line to this:

Code:

if (((unsigned)actorat[x - 1][y] && (unsigned)actorat[x - 1][y] < MAXWALLTILES) || ((unsigned)actorat[x + 1][y] && (unsigned)actorat[x + 1][y] < MAXWALLTILES))

I removed the map edge check for clarity, but you can add it back in if you want it.

I edited my last post before I saw this post. at any rate, compare yours with what ended up working. The or is going to always ensure it gets made a wall side and not a control side. Why? Because to be a wall side only one side of it has to be a wall. The way the exits are laid out in this game, the control has a wall on one side and a floor space on the other. The side wall always has walls on both sides. so, the only way it is going to work correctly is to check to see if both sides are walls or not. If only one side is a wall, then it's the control, otherwise it the wall.

Also, until I get the door thing figured out I changed it back to use the tiles at 50, 52 and 53. I will be changing it though, because at some point I'm going to add the Spear walls, and those tiles will no longer be the doors and door jamb.

I figured it out. The doors don't start at 90 because not all of the 102 tile16's are being loaded into memory. The doors (right now) actually start at 60. 60-61 for the normal doors, 62-63 for the locked doors, and 64-65 for the lift/elevator doors. I say right now because now that I've figured this out, I know how to get all of the images I want into the tile16's without having any unused ones. and being able to access a door image at 64 means I am not limited to the 0-63 on the walls. all I have to do is make a special case for the walls that don't fit in that range (as far as the overhead map goes, the wall textures will still be limited to 64).  I will post images when I have it done, but for tonight I'm going to bed.

.

Here's a little video showing what everything looks like now.




The video ended before I was through talking. What I said was, "So, I'm not sure how the game would react to having more walls, and I believe it would mean I can't use the editors anymore until/unless I can find a way to get them to recognize more than 64 walls."

.

.

To both of you: It's nice to know that things are not beyond the realm of possibility. However, I have yet to know exactly what to change using AryanWolf3D's list, so the notion of making the kinds of changes necessary to achieve even adding 5 more walls (and freeing up as much memory in all areas as possible) would require me to have a sheet listing exactly what code to change, where and what to change it to (similar to the way I did my modding page). I'm just not at the stage of being able to go and find these things and know what I'm changing.

Anyway, now it's time to get my modding page caught up with all of the changes I've made that aren't documented there.

.

AryanWolf3D wrote:Well, I'll be willing to help you out with that; just make another thread detailing exactly what you need.

I will do that. I need to go through the file you gave me and describe what I need from each item you list. They all sound like good memory savers, and knowing how much memory (and where) I will save is great, but without knowing what it is to change it doesn't really help. I will be starting a new topic a little later today.

And, thanks for all your help!

.

Thought you guys might want to see what I have accomplished. It's not entirely finished yet, but that's a good start, I think.

Here's the finished product.





The magenta numbers are how many of those items are left on the level. The cyan percentages are how much you've achieved so far. When the number of items reaches 0, you have achieved 100% of those items.

.

.

Wolf3DGuy wrote:I am curious about one thing tho, something I just realized just now, can you still change the viewsize? If so how does it affect the automap stats?

I looked at each different size viewport. There are 16 in total. The largest is the only one with the gap at the bottom, so it is the only size that displays the bar. I wrote it that way because any time the bar was on top of the map, it would flicker, so it wasn't going to work that way, plus I didn't want to obscure any part of the map, and the bottom half of the bottom row of the map would have been obscured by it at any other size than the largest.

I have updated my site to include the new mods. For those who haven't been there, The Wolfenstein 3D Mall

It's still under construction, so there are some links that don't work yet. I had this site years ago and lost it, and I found a snapshot of the main page on webarchive.com. I have been rebuilding the site from this snapshot and have not recreated the pages that got lost yet.