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.

This time I tried something different. I saved the 256 color image as a 16 color image, then re-saved it as a 256 color image again. This is the result in the game map:



Still an almost, but closer to the mark by far.

.

I wasn't sure if I should specify the palette option for this, so I left it off to see what I would get. All of the images are the wrong color except for the tile16s. So, obviously there is something amiss. Somehow the tile16 is using a different palette. I'm going to try using the export command again, this time using the palette option to see if the colors are corrected.

Edit: I tried again with the palette option and all of the images are correct except for the tile16. It shows the same colors I see in the game, so it is obvious that somehow the palette is different from the game palette. I will have to try to recreate the image and see if I can correct for this.

I started by making a copy of a wall sprite that I believe was saved with the game palette (I used WDC to export the wall images). I changed it's size to 288x48 and then started adding the 16x16 sprites I made by changing the size of each wall to 16x16 and copying it so that it would preserve the palette. I put the new tile16 image in the BMPS folder and imported with ModId. The map still shows different colors. I am wondering if ModId is somehow converting the image as it imports it.

I can try making it an 8-bit image again, but I still have to re-save it as a 256 color image before ModId wll accept it, and I'm not sure if saving in 8-bit color will change the palette or not.

It's also possible that WDC didn't preserve the palette when it exported the wall images. I wonder if there's a way to tell paint to use a specific palette...

.

I started a topic on DHW. I found I can export the game palette using ChaosEdit, but it saves it in SDL format as a .c file. I can see it using my text editor, but I don't know how to use it in Paint to create an accurate palette.

.

I did that. It is saved as a .pal file now. But I need to know what to do with it so far as the image is concerned. I need to change the palette the images was saved with or it won't correct for it when I recompile the VGAGRAPH file. I also have the .c file, which is text, so I can use that if I can find a way to convert it to a .gpl (gimp palette) file. Then I can import it to gimp and see if I can color correct the image there.

I am on the path to getting it right. I was able to import the wolf3d palette into gimp using the .pal file that ChaosEdit created, and when I color corrected the image to the Wolf3D palette all of the colors I am seeing in the game became the colors of the image.

This means that WDC did not preserve the palette when it exported the wall images. I am going to see if ChaosEdit will preserve the palette if I use it to export the wall images and try again. I'll post my results here.

Cool thread!

Not sure if you knew Asa, but there's an alpha version of wolf3d where the vga Tile16s work:
http://www.wolfenstein3d.co.uk/WOLF1V.ZIP

Just press F10-O to see the overhead map in it.

NY00123 even added a def for it to modid (wolf3d_wl1_alpha.def):
https://github.com/owenmpierce/modId/tree/master/def/others

NY00123 also restored the source code for the alpha so you can compile it (by opening WL920312.PRJ):
https://bitbucket.org/gamesrc-ver-recreation/wolf3d/src/master/

I also had to use GIMP to modify pictures with modid because Windows Paint always changed it's format. I like using the classic Deluxe Paint II for Dos too though.

Princess Peach wrote:Cool thread!

Not sure if you knew Asa, but there's an alpha version of wolf3d where the vga Tile16s work:
http://www.wolfenstein3d.co.uk/WOLF1V.ZIP

Just press F10-O to see the overhead map in it.

NY00123 even added a def for it to modid (wolf3d_wl1_alpha.def):
https://github.com/owenmpierce/modId/tree/master/def/others

NY00123 also restored the source code for the alpha so you can compile it (by opening WL920312.PRJ):
https://bitbucket.org/gamesrc-ver-recreation/wolf3d/src/master/

I also had to use GIMP to modify pictures with modid because Windows Paint always changed it's format. I like using the classic Deluxe Paint II for Dos too though.

I knew there was an alpha, but didn't know where to find it. Thanks for the link. I have found a possible solution using ChaosEdit to export the walls and gimp to create a new tile16 image. Hopefully it works. If it doesn't, I'll be looking for Deluxe paint II. Thanks for that link as well.

OK, this may be a clue to the problem. I opened the alpha version with WDC and it acknowledges the tile16s's and tile16m's that exist in the demo. So, if the file is built properly, WDC should be able to read it. That tells me it's ModId that's the problem. It's doing something funny with the tile16s image.

The tile16s and tile16m images in the alpha are obviously not 256 color, 8-bit images. They seem more like 16 color 8-bit images. I can save them out using the export multiple chunks option, but many of the tile16s and tile16m items are, what WDC calls, sparse. Looking at them, this means no image (or mask in terms of the 16m's) are in the file for those entries. I'm not sure how this will play out in terms of trying to create a set of images I can use for the map. I can say that the 16m's in the file are obviously for displaying the various items throughout the level map. I haven't looked closely to see if they are actually displayed or not.

Edit: Apparently, the tile16m's are not used. Perhaps that code was removed before that particular copy was given out to someone (not the copy Chris made available, the one he got that from). Anyway, I can at least get an idea of how well developed the map was originally, and maybe see if WDC can give me some hints in v1.0. I have a sneaking suspicion that the v1.0 we have now is not the one originally released. I remember when the game first came out, my friend downloaded it. We found out about the map and looked at it, and it resembled the map in the alpha very closely. So, somewhere along the way the tile16s's (and possibly the tile16m's) got lost.

Just to document a few things.

Sparse tile16m's: 406,407
Sparse tile16's: 87-137, 141-155, 168-209

tile16s are not tile16s's, they are tile16's. WDC shows them as tile16s and the m's as tile16m, so I think the s is supposed to be 's but you couldn't put that there for some reason.

tile16's 83-86 are identical (red brick wall). Many walls are not there, so I'm guessing that at least some of the sparse chunks would be the other walls.

All four of the locked door types are included in the tile16's (158-165).
All four key types are included in the tile16m's (253-256).

It will take some time to compare all the tile16m's to all of the objects in the game.

Edit: I looked at ted5. What appears to be the other two locked door keys in the tile16m's is the bed and some other thing I can't readily identify.

It's interesting how things can come back to you. I decided to go to the WDC site to see if I could find out what the author knows about tile16's, and lo and behold in the forums for WinWolf/WDC I find a thread from years ago that I started. I not only had the alpha and the wolf3d source, I was actively working on unraveling the contents of the data files. I also found the name of my old Wolf3D website. It was called The Wolfenstein 3-D Mall. The site is long gone, but the waybackmachine still has the homepage catalogued. The thread is here. It seems I used to know more than I know now, even though I have now learned a few things I didn't know then.

.

AryanWolf3D wrote:Try using this image.



It's a .bmp file using the Wolfenstein 3D palette. Let me know if it works.

Well, I already fixed it, but thanks. Here's the image of the map in the game:



How I did it is this. Someone made a statement about "insisting on using a 64-bit machine", and that got me to thinking. I have a 32-bit XP-Pro SP3 machine that I don't really use anymore. So, I dug it out and copied the files to that computer and started working on it there. I still had gimp and dosbox installed there, so working on the image was easy enough. I found that if I saved without including color information, the images came out looking right in the game. So, I came back to this computer and started again. I found that the image I had saved before was not set to the wolfenstein 3d palette as I thought it was, so I started all over again. This time, when I set the new image to use the wolf3d palette, the background changed to black, as it is supposed to. I finished coping all the images to the new image and ran modid again. It worked! I am stoked!

BTW, the image you supplied doesn't have a background image in the first position (top-left). I found out the hard way that will screw up the order of the images. Here's the image I made:



While WDC is showing the tile16's being there, it still isn't using them on the maps, even though I have the checkbox for using them if they exist checked. I wonder if it has anything to do with the fact that tile16m's don't exist, but I have to check the checkbox that says they start at map code 0 anyway ...

.

Also, I found an issue with the number and order of images in the tile16 image. I left out one elevator control wall because I thought it wasn't necessary. In the game, I find that every image after that is off by one. I am repairing the image, and I will post the repaired image here and on DHW when it's done.

Edit: Well, the previous image in this thread is replaced with the new one, but here's the new one anyway.



Notice that the doors aren't used in the overhead map. It still uses numbers. I am wondering if this is due to the door images being in the wrong position in the file. If you look at the alpha, you can see gaps in the tile16's with chunks that are sparse according to WDC. I take it to mean it's an empty chunk. I am thinking about trying to use the alpha as a guide and see if I can figure out where the gaps belong and see if I can't make the door images be used in the map.

.

I will definitely look into this. Having the doors drawn as doors would be great. I'm also thinking about tile16m's. I don't know if it would be too much for the program, but if I could put in all those, I might be able to have it draw the guards and dogs instead of numbers as well.

Did you see the new topic I started on tile16's?

Interesting doors... lol
I think we're getting closer though.

.

OK. I am going to try that and see where it leads.

As far as my point in the tile16 thread goes, it is that I don't think adding in sparse tiles will make any difference given the differences. I think much of the sparse tiles is because they didn't know (at that time) how many more walls would be added, or how many doors would be in the final version. Also, I'm pretty sure the tile16m's were going through changes too, since what were the last 2 keys (blue and yellow) became the bed and the water bowl, and the first 2 (red and green) became the gold and silver keys.

I am not going to worry so much about the tile16m's at this point. The fact that I have a working overhead map is the major point at this time, since that was the goal to begin with. Well, that and the god-mode sprites, which have both been accomplished now. Getting the doors to be displayed is the icing on the cake at this point.

Code:


    if (door->type >= dr_lock1 && door->type <= dr_lock4)
        LatchDrawTile(sx,sy,51);
    else if (door->type == dr_elevator)
        LatchDrawTile(sx,sy,50);



3 errors, 1 warning

lines 674 and 676 Undefined symbol 'type'
line 694 'door' is assigned a value that is never used

I have no idea what is going on here.

I've been looking through the code, and I find that DOORWALL is assigned the value of the first sprite minus 8. Looking at the data using WDC, I find that the walls and doors textures ends at 105, and the sprites begin at 106, so the DOOWALL is set to 106-8=98, which is the number of the first door texture. From this, I can determine that the number of wall textures includes the door textures, with the door textures being at the end of the walls. So, it doesn't seem to matter if I have less than 64 walls (128 textures, 2 per wall). What does appear to matter is that the first door texture is 8 chunks before the first sprite chunk. This makes it easier to think about how to deal with the problem.

Also, I looked at the WL_DEF.H file for more insights on doorobj_t and door_t. doorobj_t doesn't have a type element (not sure what to call ->type), and neither does door_t. This might explain why the compiler gives an error saying that type is undefined. I am only guessing, given that I don't know enough about C to know for sure.

I found the code for drawing the doors and noticed that the second textures for each door are never used. In other words, DOORWALL +1, +5 and +7 are never used. Only DOORWALL, +4 and +6 are used. +2 and +3 are both used (being the door jambs (or door excavations as ID called them) are both used, though I don't fully grasp the context of when each is used.

I don't know if any of this helps, but I am trying to see if I can help nail this down in some small way.

Doing some research, I think I see the issue. doorobj_t does not contain a member 'type'. Because of this, there is no way to know what type of door is being pointed to, unless something else does it. door_t contains the door types, but I don't know how that is used in the game, since it is an enum (which means it's just creating a list of numbered items). The numbering (if it was the first thing being numbered) would be normal=0, locked1=1, locked2=2, locked3=3, locked4=4 and elevator=5. But doorobj_t does not contain any field for holding the type number of any of those, so the compiler is saying that doorobj_t.type does not exist. And even if it did, my guess is there's nothing in the code to tell it which door is being looked at. That's all I can do right now, given my lack of knowledge of C programming.

More digging produced this. The lock element of the doorobj_t typedef struct does hold the number specified by door_t in the game code. I changed ->type to ->lock and compiled. No errors. I built the program and tested it.



As you can see, all of the doors (and some of the static objects) are now elevator doors, so this is a step closer to what I'm trying to achieve.

Edit: Looking even more at the code, I am wondering if the fact that MAXWALLTILES being 64 and the number of wall and door tiles being 53 has anything to do with the problem.

I suppose I can try adding in some sparse tiles between the last wall and the first door to see what happens. I would need to add 14 to equal 64 before the doors begin.

Edit2: I made that change and tried the game again. Now there are no doors, just openings, and most objects are not there, except a few which still show up as grey stone (brick) 1 walls. also, when I quit the game, the screen turned red and I got a god-awful scratchy sound that told me things didn't end so well, so maybe I added too many sparse tiles.

.

.

@AryanWolf3D On my last attempt I added 14 blank wall sprites to the tile16's. The game played well enough, but when I quit the game the screen turned red and it played a sound that sounded like something was broken. I will check the code again and see if I remembered to renumber the code you supplied.

@Wolf3DGuy It's been a long time since I even looked at the textures in Spear. Maybe I should put them in instead of sparse tiles.

OK. I'm running into a problem trying to get the extra tile16's added to the VGAGRAPH and VGAHEAD files. ModId says it's successfully modifying the files, but then the game says otherwise and WDC shows the old order (139-192) instead of the new order (139-206). I don't understand what's happening here, so I will post the relevant information here.

First, the import file for ModId:

Code:

#ModId definition file for Wolfenstein 3D, GT + Id + Activision releases, v1.4
GALAXY
 GAMEEXT wl6
 GRAPHICSFORMAT VGA
 GRSTARTS 3
 CHUNKS 220
 FONT 2 1 #num, start
 FONTM 0 3
 PICS 135 3 0      #num, start, tablestart
 PICM 0 138 0  
 SPRITES 0 138 0
 TILE8 35 138 # The EXE has a count of 72 defined
 TILE8M 0 139
 TILE16 68 139
 TILE16M 0 207
 TILE32 0 207
 TILE32M 0 207
 B800TEXT 207 orderscreen
 B800TEXT 208 errorscreen
 TEXT 209 helpart
 DEMO 210 0
 DEMO 211 1
 DEMO 212 2
 DEMO 213 3
 TEXT 214 endart1
 TEXT 215 endart2
 TEXT 216 endart3
 TEXT 217 endart4
 TEXT 218 endart5
 TEXT 219 endart6


Second, the image that includes all the walls from Spear (except the sparse tiles because Gimp says 1-byte files are not valid bmp files and I didn't know how to add them, so I just made them the same as the background). Also, the second "door" image is the door jamb (door excavation, as ID called it), so I left it out since it wouldn't be used in the overhead map anyway:



Third, the command I'm using for ModId:

Code:

modid -import -gamedef=wolf3d_wl6_14_import.def -bmpdir=bmps -palette=wolf3d_palette.bmp

I am cd'd to the folder the game files are in, so all paths are local. It worked before, so I don't know why it would not work now.

Fourth, the code in WL_DEBUG.C:

Code:

/*
===================
=
= OverheadRefresh
=
===================
*/

void OverheadRefresh (void)
{
 unsigned x,y,endx,endy,sx,sy;
 unsigned tile,i,temp;

 doorobj_t *thisDoor;

 endx = maporgx+VIEWTILEX;
 endy = maporgy+VIEWTILEY;
 temp = bufferofs;

 for (y=maporgy;y<endy;y++)
 {
 for (x=maporgx;x<endx;x++)
 {
 sx = (x-maporgx)*16;
 sy = (y-maporgy)*16;

 tile = (unsigned)actorat[x][y];

 for (i = 0; i < 3; i++)
 {
 bufferofs = screenloc[i] + screenofs;

 if (tile<MAXWALLTILES)
 LatchDrawTile(sx,sy,tile);
 else if (tile & 0x80)
 //LatchDrawTile(sx,sy,tile & ~0x80);
 {
 thisDoor = &doorobjlist[tile & ~0x80];

 if (thisDoor->lock >= dr_lock1 && thisDoor->lock <= dr_lock4)
 LatchDrawTile(sx,sy,67);
 else if (thisDoor->lock == dr_elevator)
 LatchDrawTile(sx,sy,66);
 else
 LatchDrawTile(sx,sy,64);
 }
 else
 {
 LatchDrawChar(sx,sy,NUMBERCHARS+((tile&0xf000)>>12));
 LatchDrawChar(sx+8,sy,NUMBERCHARS+((tile&0x0f00)>>8));
 LatchDrawChar(sx,sy+8,NUMBERCHARS+((tile&0x00f0)>>4));
 LatchDrawChar(sx+8,sy+8,NUMBERCHARS+(tile&0x000f));
 }
 }
 }
 }

 bufferofs = temp;

}


This part doesn't really have anything to do with building the VGAGRAPH and VGAHEAD files, but I thought you might want to see what the code looks like after all the other changes.

I rebuilt the exe just to make sure it wasn't me forgetting that, and I apparently did not forget. However, I found out the reason WDC wasn't showing me the updated tile16's. I had copied a project file from another directory and it was showing me an older build. Correcting that made it where the new tile16's were there in WDC. However, none of this changed anything. The program still turns the screen red and makes a horrendous noise when I quit the game, and the doors (and some game objects) are showing up as something other than doors. And the elevator doors show up as something else altogether, also not a door or a wall. I will take a screenshot and post it here.

I made one correction, but it didn't make any difference, other than the screeching sound when I quit the game isn't there, but the screen still turns red and I can't exit normally. I have to just close the window. Anyway, I keep looking for reasons, and it seems the only reason that makes sense is that 64 walls is too many for the overhead map. I'm going to try removing the sparse walls and have just the walls that exist as walls and see what happens then.

.

According to WDC, both error screens, all four demos and all of the endscreens have the correct chunk numbers and are in the correct order. I will have to play an episode to the end to see what they look like in the game.

I revamped the tile16 image so that it only contains 62 walls (including all 3 doors and the door jamb), and recompiled the VGAGRAPH and VGAHEAD files with ModId (checking to make sure I used the correct numbers in the import file), and according to WDC, all the tile16's are in the correct order with the correct chunk number, giving a total of 62 chunks. I am wondering if I am using the correct numbers in the WL_DEBUG.C file though. The chunk numbers for the doors are 197-200 (including the door jamb), but in the debug file I am specifying 58, 60 and 61 (normal, elevator and locked). I am wondering if I shouldn't specify the chunk numbers instead.

Edit: OK, there is a problem with the demos. I let the game play on through the title screen, through the credits, through the high scores, and when the first demo was supposed to start the game froze, never leaving the high scores screen.

.

I'll give that a try.

Yours did a better job (once I corrected the numbers in debug again), but that first tile filling all the floor space with grey stone 1 wasn't going to work, plus I was still getting other walls for doors. So I went back to my image that was almost identical to yours, except it included the elevator control tile that I had left out originally, and it had a black tile first for floor space. When I did that, and got the numbers in the debug file corrected, I got this:



As you can see, some objects and guards are being displayed as doors, but otherwise everything is fine. The doors are being placed correctly, so I'm pretty happy with this. But, this time when I quit the game, I got this:



I guess I'm pushing the memory limit again.

So, it's apparent to me that some static objects are being seen as walls, and some guards/dogs are being seen as doors in the map code. I am trying to determine how this is, and what can be done about it, but at the same time, I don't really see a need to have objects and guards displayed in the map. My primary interest is in seeing where there may be secret rooms (shown as rooms without doors or openings). In the Mac version, you had the option of showing push walls, but the way they did it was to garble the sprite that was the wall that could be pushed. I never liked this, and would have preferred a super-imposed P on the wall you could push. But, I didn't have the source code, so I couldn't try to figure it out.

When it comes to the guards and static objects in this map, I have already commented out the last else clause to see what would happen, and all that does is remove the ones that would show up as a number anyway. The ones being identified as walls or doors are still showing up as walls or doors, so it's apparent to me that the codes for those items are somehow not being seen properly.

.

AryanWolf3D wrote:I meant using the image I put in the zip, not the one I uploaded here... But nevermind, it looks like you mostly got it to work.

I think you can fix guards being drawn as doors by changing "if (tile & 0x80)" to "if ((tile & 0x80) && tile < 256)".

OK, somehow I never saw the zip. I will make that change to the code and see what happens.

Edit: I made that change and it fixed the guards being seen as doors, but it didn't do anything about the static sprites being seen as walls. It's a good start though. Also, I ran ModId on a fresh copy of the game files and it got rid of the memory error when quitting the game.

I modified E1L1 to include 2 secret rooms so I could put each wall texture in as a separate item and walk through to see them so I could compare the walls with the tile16's the map displayed. I ran into an anomaly that I can't explain. When you first enter the room it appears normal with all four sides having the same texture, but within a few seconds the east-west sides change to grey stone 1. I took a screenshot so you could see it.

.

Wolf3DGuy wrote:I'd help you making the exe draw the map names and the stats on the map, but I am not in that mood these days. I mean I don't have any inspiration or motivation to do anything modding related, I'm experienced at drawing sprites, textures and such and making maps and I kinda like doing these. Everything I have made just came naturally, but these days I am kinda forcing myself to do anything and I am not satisfied with the outcomes so I end up deleting everything that I made because I know they're awful. I'm not feeling it these days so my modding spirit is just as dead as this community, I kinda lost everything that was important for me in modding and I'm not sure if I'll ever get them back after a while. I would like to help, but I just can't, sorry.

I can understand losing your impetus. It has happened to me before too. It's ok. If you suddenly decide you want to show me how to do it, I'm all eyes. LOL Otherwise, don't sweat it.

Edit: I mean, I can draw something that looks similar to what you showed in that image, but I'd need help with getting it into the game, and with writing the code to make it where the numbers get updated each time I open the map after getting more treasures, killing more enemies and discovering more secrets.

.

I made that change, but the static objects still show up in the map as grey stone 1 walls. I briefly read through the fix for the grey stone 1 bug, so I'll have to go through it again and take notes. Izt seems like a complex fix, but that may just be me being unfamiliar.

Edit: Scratch that. It did work. I loaded a saved game and that's why it seemed like it didn't work. OK, now to move on to the grey stone bug.

Edit2: Grey Stone bug squashed. I need to go back to that list of bugs that have been found and see if I can find the fixes to the other bugs I haven't run into yet.

So, today I will begin to create a web page detailing the things I've done to make Wolf3D the game I want it to be. There are a few things I haven't done, but that is primarily because I want to see how well the game plays as it is.

The fix that made the static objects not appear as walls had an unexpected result, but unless you know a fix for that I'm not worried about it. It is, after all, minor. The fake elevator wall shows up in the map as 0050 instead of a tile16. Before the change, it showed up in the map as a elevator. Apart from that, the map is completely correct. I don't know if ID ever used that wall texture anyway. I think the levels with elevators that were blocked with barrels and such were active elevators, though I haven't checked to be sure.


I do have one question. What did I sacrifice by removing that code that gave me more memory? The sounds and music still play just fine, so I'm not sure what that code was even for.

As to what else I want to do with the game, well, I want to add the Apogee sprite back in. That room in the maze just doesn't look right with that pile of bones, even if they did add an extra life. I also would like to put the Read this! section back in. I like reading it. There may be other things I have yet to discover, but I am not sure there's enough memory left to even do those two things.

Edit: I just checked and they are indeed elevators, not fake elevators.

I added the Apogee sprite back in. It was easier than I thought it would be.

I can't (for the life of me) figure out where the config screen is drawn (the first screen you see when you start the game). I have found the part that draws the memory and hardware configuration, but not the part that draws the title (the ID logo, the title banner and the other logo). I know it's different with different versions, like the earlier apogee versions all have Apogee on the left and ID on the right, but the later ones have ID on the left and either Activision or GT on the right. But I can't find where the routine is that draws that screen.

.

.

Wolf3DGuy wrote:There's lots of stuff you can delete from the code to gain more memory and they're mostily unused or there's another way to pull it out that is more benefiting, sometimes changing a single value or changing a type of a variable can free up some memory as well!

For instance, there's this line in wl_agent:

Code:

struct atkinf
{
 char tics,attack,frame; // attack is 1 for gun, 2 for knife
} attackinfo[4][14] =

Notice at attackinfo, the first value is how many guns are there in the game, that's fine, but the second one means how many frames each gun has, it is kinda misleading because that value should be 4 as well (funfact: ID software originally wanted to have 15 frames for each gun, I believe they forgot to change this value later on) changing this one value can free up a few extra memory.

The first screen is located in a file called signon.c, but it's just a file filled with a bunch of color datas.

Now that is a good piece of information. I will make that change. I know that signon.obj is a headerless bitmap without col,or data, so I was expecting there to be a routine that supplied the data missing from the file. I found the routine that draws the memory and hardware configuration, but couldn't find the routine that drew or loaded the signon.obj file. I will look for signon.c. Thanks

AryanWolf3D wrote:

Asa wrote:I can't (for the life of me) figure out where the config screen is drawn (the first screen you see when you start the game). I have found the part that draws the memory and hardware configuration, but not the part that draws the title (the ID logo, the title banner and the other logo). I know it's different with different versions, like the earlier apogee versions all have Apogee on the left and ID on the right, but the later ones have ID on the left and either Activision or GT on the right. But I can't find where the routine is that draws that screen.

That's because it's not drawn via the code; it's an image that was pre-compiled into an .obj file which gets linked as part of wolf3d.exe. I'm guessing the reason it was done that way is because the game needs to test that all is well before the video and image handlers are started up, as you can see in InitGame:

Code:

 MM_Startup ();                  // so the signon screen can be freed

 SignonScreen ();

 VW_Startup ();
 IN_Startup ();
 PM_Startup ();
 PM_UnlockMainMem ();
 SD_Startup ();
 CA_Startup ();
 US_Startup ();

You should be able to create your own "signon" screen using IGRAB, I believe.

I was looking for code that loaded the image from the signon.obj file, but thinking that this is a headerless bitmap with no color information, I figured there had to be code for supplying all that. Wolf3DGuy pointed me to signon.c (don't know why I never saw that file yet, cuz I still haven't found it). I will look for IGRAB. I know ID used it, so if must be around somewhere.

.