DieHard Wolfers Forum Index DieHard Wolfers
A Wolfenstein 3d Fan Community


  Hosted by: MCS & Areyep.com - Designed by: BrotherTank

Original Yahoo Forum - Die Hard Archives

AReyeP HomepageAreyep Homepage DieHard Wolfenstein BunkerDieHard Wolfenstein Bunker Log inLog in RegisterRegister Banlist FAQFAQ Search ForumsSearch

  Username:    Password:      Remember me       

[Code] 64+ Wall Tiles - The original fix
Page 1 of 1
DieHard Wolfers Forum Index -> Code Tutorials View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page BottomView Next Topic
Post new topicReply to topic
Author Message
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Thu Aug 26, 2004 12:48 pm
   Subject: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Next PostGoto Bottom of Posts

Using More than 64 Wall tiles in the Vswap

Way back when SOD2 was being developed, MCS challenged me to find a solution to the 64 wall tiles limitation with the game. The problem is how the game detects doors, door sides (jams as I call them), and pushwalls, when scanning/drawing the wall surfaces within the game using the HitVertWall, HitHorzWall, as well as the pushwall routines. The game checks for these using 'bit' or binary arithmatic.

Each wall map value is converted to a binary value when it is checked. The engine converts the wall values to an 8 bit binary equivalent. As an example, the maximum wall value in the original code would be 64 or binary '00111111" <- the first 2 zero's are what creates the problem. Those two positions are where the door and pushwall is defined. If bit 7 is set then it is a door and bits 1 to 6 define the door number (int) in the map - thus the limit of 64 doors max on a level. If the next wall is a pushwall, then the 8th bit is triggered as well as the 7th.

ie: the first 6 bits define the graphic wall value to display unless it is a door, in which case the first 6 bits define the door number. if it is a door the bits would be '01111111" for a door (maxed out door limit of 64) or for a pushwall it toggles both bits 7 & 8 and the first 6 bits refer to the wall value to be displayed.

The problem is without access to the 7th bit, you couldn't define greater wall tiles than 64. For those binary challenged each bit can be 1 or 0.... starting from the right and moving left you add the value to your total if the bit value is 1. Bit 1 is 0 or 1. Bit 2 is 2 or 0, Bit 3 is 4 or 0, Bit 4 is 8 or 0, Bit 5 is 16 or 0, Bit 6 is 32 or 0. given the binary value '00111111' we add the values together and get 63... (wall values defined bit value + 1) so it would display wall graphic 64 in this case.

I took him up on the challenge and after many a long night I reached a solution. I made a routine that would check the adjacent tiles when drawing to see if they were a pushwall or a door, draw them properly if they were, and if not then just use the defined wall tile. This solution added 26 additional wall tiles to the 64 tile limit within the game itself based on the fact that we could now have access to the 7th bit (partially).

My solution is not pefect, but does work with the following limitations:

1) the 64+ walls can't be immediately beside a door or pushwall...
2) the 64+ walls can't be used to define a pushwall graphic.

Many people have asked for my routine... and I've been holding out until I released something using it. Over the last 2 years, I've talked to a few people and given them some information to chew on on where the problem is in the engine. I even challenged a number of people to try and figure it out as well (in 25 lines or less Smile ). It's not easy... but WSJ is the only one who has even come close (he two has the above limitations on where these new graphics can be located as well as not being able to use the graphics on the outer edge of the map) and his routine still doesn't fix the door display error that is created when you place two doors in a corner, next to one another. The door error is caused by the way in which the engine draws the walls because when you open one door, the bits change for the walls located immediately beside each door. Want to see the error... create a room on your map with 2 doors in 1 of the corners of the room... one going north/south, the other going east/west.. start your game... open one of the doors and one of the doors sides will change graphics from the "doorside" or jam, to a wall graphic.

Well, my Wolfenstein Plus engine is almost complete... EoD is nearing completion as well and will soon be in Beta. SOD2 used my routines successfully, and it was also installed into the source for Brian/TVP's ROM (they had it installed by MCS but didn't get the source to it Smile ), which we would still like to see released.

So, With all that in mind and the spirit of sharing, I'm keeping my promise and releasing the tutorial for the original solution to the 64+ wall tile problem. Enjoy and here it is:

Open wl_def.h and change the MAXWALLTILES from 64 to 90. Save the file.

Open wl_draw.c and search for the void HitVertWall function. Before that routine add the following red lines of code:

::: CODE :::


//
//  BrotherTank's 64 Plus Wall values Routine
//
int CheckHighBits (int value)       // Check For Door Bit 7 only
{
   if ((value & 0x40) && (value & 0x80)) // If Pushwall Return False Bit7&6
      { return 0; }
   else
      {
   if (value & 0x80)        // Is Door Return True
     { return 1; }
   else
     { return 0; }                  // Not Door Return False
      }
}

int CheckAdjacentTile (int x, int y)
{  // Part of 64+ Wall Tiles - Make sure within Map Boundaries
   // to fix bug of not allowing 64+ in outer edge of map
   // Checks Adjacent Tile for Bit 7 Set - Door or Pushwall
   if ((y-1 >= 0) && (tilemap[x][y-1] & 0x80)
   || (y+1 <= 63) && (tilemap[x][y+1] & 0x80)
   || (x-1 >= 0) && (tilemap[x-1][y] & 0x80)
   || (x+1 <= 63) && (tilemap[x+1][y] & 0x80))
    return 1;
   else
    return 0;
}



That is the basic code to my 64+.... Now to activate the routines within your code.... Modify the HitVertWall and HitHorzWall routines as follows: Replace the BLUE lines of code with the Red Lines of code (3 small changes in each routine) :
::: CODE :::
IN THE HitVertWall FUNCTION:

if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit)

REPLACE WITH:

// Fix for door graphic problem with 2 doors in a corner
if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))



if (tilehit & 0x40)

REPLACE WITH:

if (CheckAdjacentTile(xtile,ytile))  // 64+ Wall Graphics



if ( tilemap[xtile-xtilestep][ytile]&0x80 )

REPLACE WITH:

if (CheckHighBits(tilemap[xtile-xtilestep][ytile]))


IN THE HitHorzWall FUNCTION:


if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit)

REPLACE WITH:

// Fix for door graphic problem with 2 doors in a corner
if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))



if (tilehit & 0x40)

REPLACE WITH:

if (CheckAdjacentTile(xtile,ytile))  // 64+ Wall Graphics



if ( tilemap[xtile][ytile-ytilestep]&0x80 )

REPLACE WITH:

if (CheckHighBits(tilemap[xtile][ytile-ytilestep]))



That's all there is to it. Now insert your wall graphics into your vswap to a maximum of 90 walls total and just define them as you would any wall in your mapeditor (mapedit, Floedit, Wdc, or Chaosedit). Remember the limitations listed above in the tutorial and enjoy your access to 26 more wall definitions as well as now being able to put two doors in a corner without the graphics changing when a player opens 1 of the doors.

Greg
BrotherTank


Last edited by BrotherTank on Sat Sep 04, 2004 1:49 pm; edited 2 times in total
Ringman
DieHard Wolfer
DieHard Wolfer


Joined: 31 Jul 2003
Last Visit: 14 Dec 2016

Topics: 54
Posts: 1165
Location: up my nose
usa.gif

PostPosted: Thu Aug 26, 2004 8:05 pm
   Subject: Re: 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thanks Brothertank! Quick question though, when you mean that the 64+ walls can't be immediately beside a door do you mean this: (ascii art representation)

KEY

--=door

W=64+wall

WWWWWWW--WWWWWW

How about if you do this?

W=64+Wall

N=Normal wall

--=door

WWWWWW WWWWWWW
NNNNNNNN--NNNNNNNNN
WWWWWW WWWWWWW

Will that display correctly?

_________________
One day I saw upon a stair a little man who wasn't there. He wasn't there again today. My gosh I'd wish he'd go away.
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Thu Aug 26, 2004 10:58 pm
   Subject: Re: 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

My meaning of not beside a pushwall or door means just that... Nothing 1 tile either side (in any direction) of the door or pushwall can be of 64+. Those must be of 1 to 64... If you don't follow the rules, the graphics will switch...

Using your text example... W = 64+ Wall N = Wall 1 to 64... P = Pushwall D = Door... the following are fine:

1) WWWWNWNWNW <- any combination as there is no door or pushwall

2) WWNPNWW

3) WWNDNWW

NOT acceptable are things like:

WWWWDWWWW or WWWWPWWWW

In both cases above, the W on either side of the door will revert back to the corresponding tile within the 1 to 64 range. ie... Pushwall or door strips off the 7th and 8th bits... thus the value of the remaining bits is limited to 1 to 64. Say we used graphic 65 for the W's beside the door/pushwall... when the game displays those walls as you play it, it will show graphic 1.

It's not that by placing a 64+ wall beside a door or pushwall will break the game, but rather that it will not show the correct graphic that you have placed in that position. In all cases the graphic will switch and change depending on the state of the pushwall/door. Hence it's a limitation... and is the same limitation that anyone will get unless they re-write the raycaster routines and how it handles wall definitions. Truthfully, you can do anything with it... it will not break the game... it will however have some people asking you why the walls are changing graphics when you open a door or push a pushwall.. Smile

And for the door bug check... using the legends defined above... creating a room as follows, without using my fix, will cause the door jams to disapear on one side of an opened door. Try it with the original and then add my routines and try it again... you will see this problem disappear.
That example is:

NDNNNNNN
D
N
N
N

If you've played the original game you will very rarely see doors used in this combination as it was a bug in the original code that they never fixed. It was easier for them to move the door so there is at a minimum of 1 wall tile between any two doors in any corner type situation.

Hope that helps...

Greg
BrotherTank
Ringman
DieHard Wolfer
DieHard Wolfer


Joined: 31 Jul 2003
Last Visit: 14 Dec 2016

Topics: 54
Posts: 1165
Location: up my nose
usa.gif

PostPosted: Fri Aug 27, 2004 5:13 am
   Subject: Re: 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Well, I understood what you meant about the graphic changing and not the game crashing, but what I'm asking is if you set it up like this:


wwww wwwww
nnnnndnnnnnn
wwww wwwww

Will the graphic on the w wall change when you open the door? Since it is not directly up against the door, I would assume no, but I'm not sure, Here's another example:

ndnnnnnnn
w<---
w
w


Will the graphic on the wall that the arrow points to display correctly this way? I'm just trying to figure a work around so you can use a new wall NEAR a door but not directly on top of it.

_________________
One day I saw upon a stair a little man who wasn't there. He wasn't there again today. My gosh I'd wish he'd go away.
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Fri Aug 27, 2004 9:42 am
   Subject: Re: 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

@Ringman

No... It doesn't check diagonals, so that shouldn't be a problem.

@All: Basically what the code does is this:

In the original code - As the raycaster drawing, it is calling HitVertWall and HitHorzWall functions and it is checking to see if the graphic to be drawn is a door or pushwall. If it is then it strips off the upper bits 7&8 and grabs the appropriate graphic based on the remaining bits (if it's a pushwall then it just uses the bits for the graphics, if it's a door then it used the lower bits to get the door number, 1 to 64, and looks up the door graphic based on the door array created when the game is setting up, and that tells it which door graphic to use based on the type of door.).

My code adds an additional check. It adds the check to make sure that graphics to be drawn in any of the four carnal directions (North, South, East, West), that would be directly touching the graphic currently being drawn isn't a pushwall or a door. If it's not, then the code says to allow the 7th bit to be used to define the graphic number. Thus, giving you access to 26 more graphics.

Why only 26... Doesn't giving you access to the 7th bit give you an additional 64 walls. In theory, yes, it should. But, because of the floor codes and other defines being held in the same map-plane as the walls, it limits the number of graphics one has access to.

Hope that helps.

Greg
BrotherTank
WSJ
DieHard Officer
DieHard Officer


Joined: 17 Apr 2004
Last Visit: 08 May 2017

Topics: 24
Posts: 521

blank.gif

PostPosted: Fri Aug 27, 2004 2:30 pm
   Subject: Re: 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thanks for sharing this with us, BrotherTank. Smile

BrotherTank wrote:
It's not easy... but WSJ is the only one who has even come close (he two has the above limitations on where these new graphics can be located as well as not being able to use the graphics on the outer edge of the map)


Just to clear a few things up, my code was written so that you could have the 64+ walls next to doors, and I haven't had any problems using them on the outer edge of the map either. And though I hadn't included it in my tutorial, I later discovered that you can create a pushwall modifier which works the same way as the 64+ modifier... so you can use 64+ graphics on secret walls as well, provided that the path of the pushwall has 64+ modifiers on it.

But as you said, my code doesn't fix the door bug, and there's another display bug which sometimes occurs if you use the 64+ modifier in a row of walls of the same type but don't use it on all the walls in that row. This doesn't happen with different wall types, though.
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 04 Dec 2017

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sat Sep 04, 2004 8:59 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I'm having a slight problem adding this:

The code: if ( tilemap[xtile-xtilestep][ytile]&0x80 )

I cann't seem to find it, the only code that I found closest to it was

::: CODE :::
               tile = tilemap[xtile][ytile-ytilestep];
               if(tile & 0x80)

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Sat Sep 04, 2004 9:23 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Haasboy wrote:
I'm having a slight problem adding this:

The code: if ( tilemap[xtile-xtilestep][ytile]&0x80 )

I cann't seem to find it, the only code that I found closest to it was

::: CODE :::
               tile = tilemap[xtile][ytile-ytilestep];
               if(tile & 0x80)


Look at the original code uneditied... and the three lines will stand out like a sore thumb.. lol...
If you have installed another 64+ (WSJ) then this one will not work for you.

Greg
BrotherTank
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 04 Dec 2017

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sat Sep 04, 2004 9:37 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

BrotherTank wrote:
Haasboy wrote:
I'm having a slight problem adding this:

The code: if ( tilemap[xtile-xtilestep][ytile]&0x80 )

I cann't seem to find it, the only code that I found closest to it was

::: CODE :::
               tile = tilemap[xtile][ytile-ytilestep];
               if(tile & 0x80)


Look at the original code uneditied... and the three lines will stand out like a sore thumb.. lol...
If you have installed another 64+ (WSJ) then this one will not work for you.

Greg
BrotherTank

I haven't even used WSJ code, here's my code for the "HitHorizWall" code

::: CODE :::
void HitHorizWall (void)
{
   int         wallpic;
   unsigned   texture/*,doorsidetype*/;
   byte tile;

   texture = (xintercept>>4)&0xfc0;
   if (ytilestep == -1)
      yintercept += TILEGLOBAL;
   else
      texture = 0xfc0-texture;
   wallheight[pixx] = CalcHeight();

   if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit)
   {
      // in the same wall type as last time, so check for optimized draw
      if (texture == (unsigned)postsource)
      {
      // wide scale
         postwidth++;
         wallheight[pixx] = wallheight[pixx-1];
         return;
      }
      else
      {
         ScalePost ();
         (unsigned)postsource = texture;
         postwidth = 1;
         postx = pixx;
      }
   }
   else
   {
   // new wall
      if (lastside != -1)            // if not the first scaled post
         ScalePost ();

      lastside = 0;
      lastintercept = ytile;

      lasttilehit = tilehit;
      postx = pixx;
      postwidth = 1;

      if (tilehit & 0x40)
            {                        // check for adjacent doors
               xtile = xintercept>>TILESHIFT;
               tile = tilemap[xtile][ytile-ytilestep];
               if(tile & 0x80)
               {
                     switch(doorobjlist[tile & 0x7f].lock)
                     {
               case dr_test01:
                  wallpic = DOORWALL+2;
                  break;

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Sat Sep 04, 2004 9:51 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Ah...

You are using Rippers Different Door sides.

Yes, replace the appropriate "if (tile & 0x80)" lines with their lines from my tutorial... Don't change the line above it (tile = tilemap[xtile-xtilestep][ytile]; ). Or you can modify my code so that each of the "if (tile & 0x80)" in both routines are changed to:

if (CheckHighBits(tile))

That will solve the problem... And make it work...

Greg
BrotherTank
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 04 Dec 2017

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sat Sep 04, 2004 9:55 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thanks alot "Brother".

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 04 Dec 2017

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sat Sep 04, 2004 11:22 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Ok the code works but I've got one problem. The tile that I would use would have the first wall image in the VSWAP N/S and what ever number tile, used for E/W (Meaning; N/S would have the grey stone tile and E/W would have Blue brick).

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Sat Sep 04, 2004 12:17 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Haasboy wrote:
Ok the code works but I've got one problem. The tile that I would use would have the first wall image in the VSWAP N/S and what ever number tile, used for E/W (Meaning; N/S would have the grey stone tile and E/W would have Blue brick).


Sounds like you've made an error in the code somewhere... The 64+ does not change the tile numbers, but rather changes the conditions met to use one of the upper tiles. You may want to increase the "MAXWALLTILES" in the wl_def.h file.. to 90... but I don't think that will be the problem.

Greg
BrotherTank
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 04 Dec 2017

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sat Sep 04, 2004 12:56 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Changing the MAXWALLTILES worked, I don't think I did any error with the code cos I followed it exactly, it was just that one part that I was having trouble.

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 30 Oct 2017

Topics: 55
Posts: 2115
Location: Canada
blank.gif

PostPosted: Wed Feb 23, 2005 7:18 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Pretty cool Greg. I've been looking through this a little lately too. I guess another way of saying it (perhaps easier), is that the tilemap is split up into 4 sections:

1. 1-63 walls
2. 64-127 Door Sides
3. 128-191 Doors
4. 192-255 Pushwalls


The limitations you mention wouldn't be that hard to get rid of. To fix your "can't be a pushwall" limitation, you could add a variable to keep track of the graphic while any given tile has become a pushwall; so you'd only need to use one tilemap number. Here's what I did, for anyone that's curious... Think

First off, add this to WL_DEF.H:

::: CODE :::
extern   int      horizwall[],vertwall[];

extern   unsigned   pwallpos;
extern  byte      pwallcount, pwalltile;


fixed   FixedByFrac (fixed a, fixed b);

Then just erase the end of WL_ACT1.C, and replace that whole section with this:

::: CODE :::
/*
============================================

         PUSHABLE WALLS

============================================
*/

unsigned   pwallstate;
unsigned   pwallpos;
byte      pwallcount, pwalltile;
unsigned   pwallx,pwally;
int      pwalldir;

/*
===============
=
= PushWall
=
===============
*/

void PushWall (int checkx, int checky, int dir)
{
   int  oldtile;

   if (pwallstate)
     return;

   pwalltile = oldtile = tilemap[checkx][checky];

   if (!oldtile)
      return;

   pwallx = checkx; pwally = checky;

   switch (dir)
   {
   case di_north: checky--; break;
   case di_east: checkx++; break;
   case di_south: checky++; break;
   case di_west: checkx--; break;
   }

   if (actorat[checkx][checky])
   {
      SD_PlaySound (NOWAYSND);
      return;
   }
   tilemap[checkx][checky] = (unsigned)actorat[checkx][checky] = oldtile;

   gamestate.secretcount++;
   pwalldir = dir; pwallstate = 1; pwallpos = 0;
   tilemap[pwallx][pwally] = 255;
   *(mapsegs[1]+farmapylookup[pwally]+pwallx) = 0;   // remove P tile info

   SD_PlaySound (PUSHWALLSND);
}



/*
=================
=
= MovePWalls
=
=================
*/

void MovePWalls (void)
{
   int   oldblock, oldtile;
   int   checkx, checky;

   if (!pwallstate)
      return;

   checkx = checky = 0;
   oldblock = pwallstate/128;

   pwallstate += tics;

   if (pwallstate/128 != oldblock)
   {
   // block crossed into a new block
      oldtile = pwalltile;

      //
      // the tile can now be walked into
      //
      tilemap[pwallx][pwally] = (unsigned)actorat[pwallx][pwally] = 0;
      *(mapsegs[0]+farmapylookup[pwally]+pwallx) = player->areanumber+AREATILE;
      pwallcount++;

      //
      // see if it should be pushed farther
      //
      if (pwallcount >= 2)
      {
      //
      // the block has been pushed two tiles
      //
         pwallstate = pwallcount = 0;
         return;
      }
      else
      {
         switch (pwalldir)
         {
         case di_north: pwally--; checky--; break;
         case di_east: pwallx++; checkx++; break;
         case di_south:    pwally++; checky++; break;
         case di_west:   pwallx--; checkx--; break;
         }

         if (actorat[pwallx+checkx][pwally+checky])
         {
            pwallstate = pwallcount = 0;
            return;
         }
         tilemap[pwallx+checkx][pwally+checky] =
         (unsigned)actorat[pwallx+checkx][pwally+checky] = oldtile;

         tilemap[pwallx][pwally] = 255;
      }
   }


   pwallpos = (pwallstate/2)&63;

}

Now open up WL_DRAW.C, and change the lines that have "tilehit&63" to this (one is in HitHorizPWall, the other is in HitVertPWall):

::: CODE :::
      lasttilehit = tilehit;
      postx = pixx;
      postwidth = 1;

      if (pwalltile > 191)
         wallpic = horizwall[pwalltile-64];
      else
         wallpic = horizwall[pwalltile];


      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;

::: CODE :::
      lasttilehit = tilehit;
      postx = pixx;
      postwidth = 1;

      if (pwalltile > 191)
         wallpic = vertwall[pwalltile-64];
      else
         wallpic = vertwall[pwalltile];


      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;

If you want to make sure it shows the correct moving tile if someone "saves while the passage is moving and then exits the game", you might want to also add these lines to WL_MAIN.C (in SaveTheGame, SaveTheGame, and LoadTheGame):

::: CODE :::
   size += sizeof(gamestate) +
   #ifndef SPEAR
         sizeof(LRstruct)*8 +
   #else
         sizeof(LRstruct)*20 +
   #endif
         sizeof(tilemap) +
         sizeof(actorat) +
         sizeof(laststatobj) +
         sizeof(statobjlist) +
         sizeof(doorposition) +
         sizeof(pwallstate) +
         sizeof(pwallcount) +
         sizeof(pwalltile) +

         sizeof(pwallx) +

::: CODE :::
   DiskFlopAnim(x,y);
   CA_FarWrite (file,(void far *)&pwallstate,sizeof(pwallstate));
   checksum = DoChecksum((byte far *)&pwallstate,sizeof(pwallstate),checksum);
   CA_FarWrite (file,(void far *)&pwallcount,sizeof(pwallcount));
   checksum = DoChecksum((byte far *)&pwallcount,sizeof(pwallcount),checksum);
   CA_FarWrite (file,(void far *)&pwalltile,sizeof(pwalltile));
   checksum = DoChecksum((byte far *)&pwalltile,sizeof(pwalltile),checksum);

   CA_FarWrite (file,(void far *)&pwallx,sizeof(pwallx));

::: CODE :::
   DiskFlopAnim(x,y);
   CA_FarRead (file,(void far *)&pwallstate,sizeof(pwallstate));
   checksum = DoChecksum((byte far *)&pwallstate,sizeof(pwallstate),checksum);
   CA_FarRead (file,(void far *)&pwallcount,sizeof(pwallcount));
   checksum = DoChecksum((byte far *)&pwallcount,sizeof(pwallcount),checksum);
   CA_FarRead (file,(void far *)&pwalltile,sizeof(pwalltile));
   checksum = DoChecksum((byte far *)&pwalltile,sizeof(pwalltile),checksum);

   CA_FarRead (file,(void far *)&pwallx,sizeof(pwallx));

Watch out when copying, though, as the second and third are different; one is CA_FarWrite and the other is CA_FarRead. Wink

To avoid the "can't be beside a door" limitation, and get rid of some drawing bugs (optimized door slots on walls, vertical slots placed near horizontal walls), replace Brothertank's CheckAdjacentTile() function in WL_DRAW.C with these:

::: CODE :::
boolean CheckVertTile (int x, int y)
{
   if ((x > 0) && (tilemap[x-1][y]/64 == 2)
      && (!doorobjlist[tilemap[x-1][y]-128].vertical)) return 1;
   if ((x+1 < MAPSIZE) && (tilemap[x+1][y]/64 == 2)
      && (!doorobjlist[tilemap[x+1][y]-128].vertical)) return 1;
   return 0;
}

boolean CheckHorizTile (int x, int y)
{
   if ((y > 0) && (tilemap[x][y-1]/64 == 2)
      && (doorobjlist[tilemap[x][y-1]-128].vertical)) return 1;
   if ((y+1 < MAPSIZE) && (tilemap[x][y+1]/64 == 2)
      && (doorobjlist[tilemap[x][y+1]-128].vertical)) return 1;
   return 0;
}

Then make the following changes, first in the HitVertWall() function:

::: CODE :::
   if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && !CheckVertTile(xtile,ytile))

::: CODE :::
      postx = pixx;
      postwidth = 1;

      if (tilehit > MAXWALLTILES)
         tilehit -= 64;


      if (CheckVertTile(xtile,ytile))
      {                        // check for adjacent doors
         ytile = yintercept>>TILESHIFT;
         if ( CheckHighBits(tilemap[xtile-xtilestep][ytile]) )
         {
            wallpic = DOORWALL+3;
            lasttilehit = 0;
         }

         else
            wallpic = vertwall[tilehit];
      }
      else
         wallpic = vertwall[tilehit];

      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;

Next with a similar idea in the HitHorizWall() function:

::: CODE :::
   if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit && !CheckHorizTile(xtile,ytile))

::: CODE :::
      postx = pixx;
      postwidth = 1;

      if (tilehit > MAXWALLTILES)
         tilehit -= 64;


      if (CheckHorizTile(xtile,ytile))
      {                        // check for adjacent doors
         xtile = xintercept>>TILESHIFT;
         if ( CheckHighBits(tilemap[xtile][ytile-ytilestep]) )
         {
            wallpic = DOORWALL+2;
            lasttilehit = 0;
         }

         else
            wallpic = horizwall[tilehit];
      }
      else
         wallpic = horizwall[tilehit];

      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;

Now the old style of drawing bit 6 walls for door sides is useless, so you can open up WL_ACT1.C and erase (or comment out) the lines in red from the SpawnDoors() function:

::: CODE :::
//
// make the door tile a special tile, and mark the adjacent tiles
// for door sides
//
   tilemap[tilex][tiley] = doornum | 0x80;
   map = mapsegs[0] + farmapylookup[tiley]+tilex;
   if (vertical)
   {
      *map = *(map-1);                        // set area number
//      tilemap[tilex][tiley-1] |= 0x40;
//      tilemap[tilex][tiley+1] |= 0x40;

   }
   else
   {
      *map = *(map-mapwidth);               // set area number
//      tilemap[tilex-1][tiley] |= 0x40;
//      tilemap[tilex+1][tiley] |= 0x40;

   }

   doornum++;
   lastdoorobj++;
}

Since we've cleared up some room in the tilemap, we can gain access to some new tiles, as well as having no pushwall placement and door side limitations:

0 Blank Space
1-63 Walls
64-89 Walls
90-127 Walls
128-191 Doors
192-254 Walls
255 Pushwall

If you only need 127 walls, just change your MAXWALLTILES define in WL_DEF.H to 128 (as block 1 is nothing), then crack open your WL_GAME.C and change the wall section of SetupGameLevel() to this:

::: CODE :::
//
// copy the wall data to a data segment array
//
   memset (tilemap,0,sizeof(tilemap));
   memset (actorat,0,sizeof(actorat));
   map = mapsegs[0];
   for (y=0;y<mapheight;y++)
      for (x=0;x<mapwidth;x++)
      {
         tile = *map++;
         if (tile >= 144 && tile <= (MAXWALLTILES+54))
         // walls 90 and above
            tilemap[x][y] = (unsigned)actorat[x][y] = tile-54;
         else if (tile<AREATILE)
         // solid wall
            tilemap[x][y] = (unsigned)actorat[x][y] = tile;
         else
         // area floor
            tilemap[x][y] = (unsigned)actorat[x][y] = 0;
      }

Now just throw some new definitions into your mapeditor. For example (using Mapedit's MAPDATA.WL6 file):

003f e010 Wall 63
0059 a010 Wall 89
...
0090 c010 Wall 90
0091 c010 Wall 91
0092 c010 Wall 92
...
009a c010 Wall 100
...
00b5 c010 Wall 127


If you want to have 190 walls, using tiles 192-254 as walls, there's a little more stuff you have to play with; but it's pretty fun to try out. The most organized way would probably be to switch the walls and doors around, so that you have 190 walls in a row in the tilemap, with 191 being the pushwall and 192-255 being the doors. But the easiest way would just be to skip 64 tiles when drawing them on the screen.

To do it the easy way, first go into WL_DEF.H and change you MAXWALLTILES define to 191. After that, alter the WL_GAME.C code (that was displayed above) to this:

::: CODE :::
         if (tile >= 144 && tile <= (MAXWALLTILES+54))
         // walls 90 and above
         {
            if (tile > 181) tile+=64;

            tilemap[x][y] = (unsigned)actorat[x][y] = tile-54;
         }
         else if (tile<AREATILE)

Now replace/add this red stuff into WL_DR_A.ASM, so that the walls don't get directed to pushwalls anymore:

::: CODE :::
hithoriz:
   mov   al,[BYTE tilemap+di]      ; tilehit = *((byte *)tilemap+yspot);
   mov   [BYTE tilehit],al
   or   al,al                  ; set flags
   js   horizdoor
horizxtra:
   mov   [WORD xintercept+2],cx
   mov   [xtile],cx

::: CODE :::
horizdoor:
   mov   [xtile],bx               ; save off live register variables
   mov   [WORD yintercept+2],dx

   cmp   al,255
   je   horizpushwall

   test   al,040h
   jnz   horizxtra


   mov   bx,ax

::: CODE :::
vertxtra:
   jmp   notvertdoor

hithmid:
   cmp   ax,[doorposition+bx]      ; position of leading edge of door
   jb   continuehoriz

::: CODE :::
vertdoor:
   mov   [xtile],bx               ; save off live register variables
   mov   [WORD yintercept+2],dx

   cmp   al,255
   je   vertpushwall

   test   al,040h
   jnz   vertxtra


   mov   bx,ax

The walls will display correctly now, but you might want to check out this thread to avoid ever seeing the "walls randomly appear as Grey Stone" bug. The enemies will still assume that blocks 192-255 are doors, and try to walk through them... so to avoid this, just open up WL_STATE.C and change the CheckSide() define to this:

::: CODE :::
#define CHECKSIDE(x,y)               \
{                                                   \
   temp=(unsigned)actorat[x][y];                   \
   if (temp)                                       \
   {                                               \
      if (temp<128 || temp/64 == 3)                \
         return false;                           \
      if (temp<256)                               \
         doornum = temp&63;                      \
      else if (((objtype *)temp)->flags&FL_SHOOTABLE)\
         return false;                           \
   }                                               \
}

Also, though these don't seem to cause any noticable problems, you might want to scroll down to the CheckLine() function and change those two "if (value<128 || value>256)" lines to "if (value<128 || value>191)"; then open up WL_AGENT.C and replace the "doornum & 80" line in Cmd_Use() with something like this:

::: CODE :::
   else if (!buttonheld[bt_use] && doornum/64 == 2)
   {
      buttonheld[bt_use] = true;
      OperateDoor (doornum & ~0x80);
   }

Yeah, alot of interesting stuff to fool around with. At this point, you can have 190 different walls on each level instead of 89; without any restrictions. I never noticed any decrease in speed on my computer, but if there is, one idea could be to use a different vswap file for walls. If anyone wants to do a little experimenting, here's the files I've tested with (using E1L1 as a test map):

http://www.canadianphilatelics.com/choksta/wall_add.zip

Not sure if anyone actually wanted more than 89 walls, or wanted some kind of alternative to WSJ's offset idea, but there's alot of data in the tilemap (and even more in the actorat, for that matter) that don't need to be there, so I just thought it'd be fun to post a way to give those blocks a better purpose. You can also use those 192+ blocks for 63 more doors, if you only need 128 walls - or something. I don't know, just some random ideas. Razz Very Happy


Last edited by Chris on Wed Feb 23, 2005 11:09 am; edited 1 time in total
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Wed Feb 23, 2005 7:57 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Very Interesting Chris.... Hat's off to you!

Back when I was originally challenged by MCS with this, I didn't have the knowledge that I do now, and re-writing many parts of the code seemed a little beyond what I was capable of. It's good to see that someone has stepped up and really broken down the barrier.

I have sort of moved past this solution as I'm using the Darkone's NewWolf Classic Raycastor now, and it used a similar yet different approach to the original game. Darkone still had a problem with the bits from 64 to 90 in his code, but with a little studying I was able to remove that block and now have 90 walls that can be used anywhere for anything. Strangely enough, changing his code was a lot easier than I had immagined.

Honestly, I can't see needing more than 89 wall types (as 0 or the 90th type is really a blank)... lol... But if I do, I'm sure that your solution will be key in helping me change even Darkone's source.

Thanks again...

Greg
BrotherTank
Latzhosenjunge
Can I Play Daddy
Can I Play Daddy


Joined: 20 Aug 2006
Last Visit: 17 Jun 2017

Topics: 1
Posts: 41
Location: Saarbrücken, Germany
germany.gif

PostPosted: Sun Aug 20, 2006 6:45 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Hi there!

I am new here and hope you can help me. I have already added new walls using FloEdit 2 and changed the code as in dir 1st posting. Compiling works fine but every time I execute the WOLF3D.EXE nothing happens except an "Abnormal program termination".

Could you please give me an information what I should do to fix?
Thanks a lot!
ronwolf1705
Moderator
<B>Moderator</B>


Joined: 31 Jul 2006
Last Visit: 9:43 ago.

Topics: 69
Posts: 3673

blank.gif

PostPosted: Sun Aug 20, 2006 7:59 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

http://diehardwolfers.areyep.com/viewtopic.php?t=2798

Maybe this link can help you.
Latzhosenjunge
Can I Play Daddy
Can I Play Daddy


Joined: 20 Aug 2006
Last Visit: 17 Jun 2017

Topics: 1
Posts: 41
Location: Saarbrücken, Germany
germany.gif

PostPosted: Mon Aug 21, 2006 1:18 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

TNX a lot. Meanwhile, I found out that it's a memory problem. I removed some useless GOOBERS-commands (such as "Extra VBLs") to get some free mem - and it works.
ronwolf1705
Moderator
<B>Moderator</B>


Joined: 31 Jul 2006
Last Visit: 9:43 ago.

Topics: 69
Posts: 3673

blank.gif

PostPosted: Thu May 24, 2007 12:06 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

I still don't understand how to combine different door sides with 64+ walls, can anyone help me with this?
WSJ
DieHard Officer
DieHard Officer


Joined: 17 Apr 2004
Last Visit: 08 May 2017

Topics: 24
Posts: 521

blank.gif

PostPosted: Fri May 25, 2007 6:06 am
   Subject: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

@ronwolf1705...

Replace your HitVertWall function with:

::: CODE :::

void HitVertWall (void)
{
   int         wallpic;
   unsigned   texture;
   byte      tile;

   texture = (yintercept>>4)&0xfc0;
   if (xtilestep == -1)
   {
      texture = 0xfc0-texture;
      xintercept += TILEGLOBAL;
   }
   wallheight[pixx] = CalcHeight();

   // Fix for door graphic problem with 2 doors in a corner
   if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))
   {
      // in the same wall type as last time, so check for optimized draw
      if (texture == (unsigned)postsource)
      {
      // wide scale
         postwidth++;
         wallheight[pixx] = wallheight[pixx-1];
         return;
      }
      else
      {
         ScalePost ();
         (unsigned)postsource = texture;
         postwidth = 1;
         postx = pixx;
      }
   }
   else
   {
   // new wall
      if (lastside != -1)            // if not the first scaled post
         ScalePost ();

      lastside = true;
      lastintercept = xtile;

      lasttilehit = tilehit;
      postx = pixx;
      postwidth = 1;

      if (CheckAdjacentTile(xtile,ytile))  // 64+ Wall Graphics
      {                        // check for adjacent doors
         ytile = yintercept>>TILESHIFT;
         tile = tilemap[xtile-xtilestep][ytile];
         if (CheckHighBits(tile))
         {   // select a door side
            switch(doorobjlist[tile & 0x7f].lock)
            {
            case dr_lock1:
            case dr_lock2:
            case dr_lock3:
            case dr_lock4:
            case dr_elevator:
               wallpic = DOORWALL+9;
               break;
            case dr_normal:
            default:
               wallpic = DOORWALL+3;
               break;
            }
         }
         else
            wallpic = vertwall[tilehit & ~0x40];
      }
      else
         wallpic = vertwall[tilehit];

      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;

   }
}


And replace your HitHorizWall function with:

::: CODE :::

void HitHorizWall (void)
{
   int         wallpic;
   unsigned   texture;
   byte      tile;

   texture = (xintercept>>4)&0xfc0;
   if (ytilestep == -1)
      yintercept += TILEGLOBAL;
   else
      texture = 0xfc0-texture;
   wallheight[pixx] = CalcHeight();

   // Fix for door graphic problem with 2 doors in a corner
   if (lastside==0 && lastintercept == ytile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))
   {
      // in the same wall type as last time, so check for optimized draw
      if (texture == (unsigned)postsource)
      {
      // wide scale
         postwidth++;
         wallheight[pixx] = wallheight[pixx-1];
         return;
      }
      else
      {
         ScalePost ();
         (unsigned)postsource = texture;
         postwidth = 1;
         postx = pixx;
      }
   }
   else
   {
   // new wall
      if (lastside != -1)            // if not the first scaled post
         ScalePost ();

      lastside = 0;
      lastintercept = ytile;

      lasttilehit = tilehit;
      postx = pixx;
      postwidth = 1;

      if (CheckAdjacentTile(xtile,ytile))  // 64+ Wall Graphics
      {                        // check for adjacent doors
         xtile = xintercept>>TILESHIFT;
         tile = tilemap[xtile][ytile-ytilestep];
         if (CheckHighBits(tile))
         {   // select a door side
            switch(doorobjlist[tile & 0x7f].lock)
            {
            case dr_lock1:
            case dr_lock2:
            case dr_lock3:
            case dr_lock4:
            case dr_elevator:
               wallpic = DOORWALL+8;
               break;
            case dr_normal:
            default:
               wallpic = DOORWALL+2;
               break;
            }
         }
         else
            wallpic = horizwall[tilehit & ~0x40];
      }
      else
         wallpic = horizwall[tilehit];

      *( ((unsigned *)&postsource)+1) = (unsigned)PM_GetPage(wallpic);
      (unsigned)postsource = texture;
   }

}


Note: I'm using the door sides given in Ripper's example, so you'll have to change the "case dr_" lines to suit your needs.
ronwolf1705
Moderator
<B>Moderator</B>


Joined: 31 Jul 2006
Last Visit: 9:43 ago.

Topics: 69
Posts: 3673

blank.gif

PostPosted: Sat May 26, 2007 7:00 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Thanks a lot, it works now! Smile
Anonymous
Guest



Last Visit:





PostPosted: Fri Jul 06, 2007 2:19 pm
   Subject: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Hi, i know i haven't been around for the last year probably.
I wrote some code that should make you use about 16000 types of walls and with a few other tweaks could get past the 64+ door limitation.
If someone wants i`ll post. I don't have it with me now.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 15:21 ago.

Topics: 160
Posts: 8007
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Fri Jul 06, 2007 6:17 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

How does it work with WOLF4GW?
Dean
Moderator
<B>Moderator</B>


Joined: 10 Jan 2006
Last Visit: 23 Oct 2016

Topics: 52
Posts: 2187
Location: Australia
australia.gif

PostPosted: Fri Jul 06, 2007 11:01 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Flamer46 wrote:
Hi, i know i haven't been around for the last year probably.
I wrote some code that should make you use about 16000 types of walls and with a few other tweaks could get past the 64+ door limitation.
If someone wants i`ll post. I don't have it with me now.
Wow, if it gets past some of the limitations in placing certain textureas adjacent to doors then this would be a nice improvement. Post the code for everyone, I'm sure if it does what you say then it will be used a lot.

_________________
The Wolfenstein 3d Blog
The Wolfenstein 3d Blog is now on Facebook!

"Strong minds discuss ideas, average minds discuss events, weak minds discuss people" - Socrates
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2256
Location: Ontario
canada.gif

PostPosted: Fri Jul 06, 2007 11:48 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Personally...

I think I'm going to stick with the 90 walls... because with unlimited patches (using Adam's Patchwall tutorials) you backsically have 90 walls x the number of patches you have installed. I have about 50... so that gives me 4550 different wall combinations...

So, to be honest... If I can't build a level with that... lol... or even a whole game... lol..

Basically... take say the basic stone wall... I have 51 combinations - original + 50 patches... (which can also be pushwalls if you add the second part of Adam's mod to it)... So unless it's something really special that can't be patched... I just need 1 set of graphics (1 light - 1 dark) for each of the 90 positions and I'm in graphics heaven... Smile

Greg
BrotherTank

PS: But yes... Post the code... It is always something to see how other people have achived different results. At the time, my code was the best that I could come up with and it was something that MCS & AreYeP could use for SR... as they could live with the limitations... When Chris came up with his code (taking my code idea to the next level) it opened even more options (and I now use a variation of Chris's and mine). Sometimes all it takes is seeing any solution to make you open your mind to further mods and programming ideas...
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 15:21 ago.

Topics: 160
Posts: 8007
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat Jul 07, 2007 6:27 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Heck, I'm sure *I* could use all 90 wall images in a few levels pretty easily. That's just the way I map. Smile
Raziel
DieHard SS
DieHard SS


Joined: 03 Dec 2005
Last Visit: 03 Dec 2009

Topics: 49
Posts: 485
Location: Israhell
israel.gif

PostPosted: Thu Jul 03, 2008 8:29 am
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Can I use this code in Wolf4SDL? or I need to change some parameters?

_________________
Raziel A.
Adam Biser
Utility Developer
Utility Developer


Joined: 06 Jun 2003
Last Visit: 10 Dec 2017

Topics: 46
Posts: 2291
Location: USA
usa.gif

PostPosted: Tue Sep 02, 2008 1:09 pm
   Subject: Re: [Code] 64+ Wall Tiles - The original fix
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

Havoc has pointed out a bug to me and the bug seems to be in this code. He was experiencing a slowdown when this code was combined with the wall patch tutorial. When looking at the wall beside a door, the FPS would drop considerably.

Solution:
1) Add the following line right above "int CheckAdjacentTile (int x, int y)"
::: CODE :::
int lastAdjacentTileCheck = -1;

2) Now, go to HitVertWall and change
::: CODE :::
if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && !CheckAdjacentTile(xtile,ytile))
to
::: CODE :::
if (lastside==1 && lastintercept == xtile && lasttilehit == tilehit && lastAdjacentTileCheck == CheckAdjacentTile(xtile,ytile))

3) Go down to
::: CODE :::
if (CheckAdjacentTile(xtile,ytile))  // 64+ Wall Graphics
and change it to
::: CODE :::
lastAdjacentTileCheck = CheckAdjacentTile(xtile,ytile);  // 64+ Wall Graphics
if (lastAdjacentTileCheck)

4) Repeat #2 and 3 for HitHorizWall .

The problem was that simply checking !CheckAdjacentTile(xtile,ytile) (changed in #2) would cause the wall patch to be rebuilt repeatedly during the drawing of walls beside doors. So it's best to just remember the old value and compare the current value to the 'last' value likst all the other checks do.

This bug is not noticed without adding the wall patch code. Things fly by too quickly, but rebuilding a wall patch takes some time and makes this problem show up.

_________________
Orb of Dilaaria now has a Facebook page
Star Wars: Bloodlines now has a Facebook page
Display posts from previous:   
Post new topicReply to topic Time synchronized with the forum server time
DieHard Wolfers Forum Index -> Code Tutorials View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page TopView Next Topic
Page 1 of 1
Jump to:  

Related topics
 Topics   Replies   Views   Last Post 
No new posts [Code] Blood Splatz Tutorial - Blood Splatters
Author: Dugtrio17
45 11219 Tue Mar 11, 2008 12:02 am
AlumiuN View latest post
No new posts [Code] Display Different Ammo Types on Statusbar-BrotherTank
Author: BrotherTank
1 2381 Fri Feb 11, 2005 9:18 pm
Zombie_Plan View latest post
No new posts [Code] Adding a Frames per Second Counter - Darkone
Author: BrotherTank
0 1703 Sat Mar 13, 2004 2:07 pm
BrotherTank View latest post
No new posts [Code] Changing an Enemies Attack Strength - BrotherTank
Author: BrotherTank
0 1969 Tue Jan 27, 2004 10:29 am
BrotherTank View latest post
No new posts [Code] Changing Weapons -CheckWeaponChange- BrotherTank
Author: BrotherTank
2 2700 Sun Oct 26, 2003 1:21 am
Guest View latest post
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
   You cannot delete your posts in this forum
You cannot vote in polls in this forum


Copyright ©2003-2008 DieHard Wolfers
A Modified subBunker Theme by BrotherTank
Powered by phpBB © 2001, 2005 phpBB Group