﻿ Collision on far right of map (Last 2 pixels)

# Thread: Collision on far right of map (Last 2 pixels)

1. ## Collision on far right of map (Last 2 pixels)

This isn't really a bug but maybe something that perhaps got omitted and overlooked maybe to save a few data bits of space..
I've been trying and trying to figure out if there is something wrong with my code that would make this "bug" happen but I have not successfully figured out a way to fix it without patching the glitch with an offset of where it reads the data from in the last two pixels of the map.
Using this Code:
void F()
{
int B=Floor(N/256);
int A=Floor(N/176);
CURRENTSCREEN=B+A*16;
//These fors and formula prevent the need to draw all screens and all layers all at once,
//which would cause massive slowdown.
//This math eliminates the calling of all screens except for the one Link would be
//on in relation to N, N, and the 8 screens around it, for a 9x9 grid of screens.
//if(LOOP==true)
//{
for(int X=B-1;X<=B+1;X++)
{
for(int Y=A-1;Y<=A+1;Y++)
{
int a;int b;int modx;int mody;
//int modpixelx;int modpixely;
//if(X==-1){b=15;modx=-9;}
//if(X>-1&&X<16){b=X;modx=0;}
//if(X==16){b=0;modx=9;}
//if(Y==-1){a=7;mody=-27;}
//if(Y>-1&&Y<8){a=Y;mody=0;}
//if(Y==8){a=0;mody=27;}
if(X==-1){b=15;modx=-9;if(MAPMODIFIER%27==0){modx=18;}}
if(X>-1&&X<16){b=X;modx=0;}
if(X==16){b=0;modx=9;if(MAPMODIFIER%27==18){modx=-18;}}
if(Y==-1){a=7;mody=-27;if(MAPMODIFIER-18<=0){mody=135;}}
if(Y>-1&&Y<8){a=Y;mody=0;}
if(Y==8){a=0;mody=27;if(MAPMODIFIER+18>=153){mody=-135;}}

int S=b+a*16;int LARGEMAP=modx+mody+MAPMODIFIER;//
//if(Screen->Flags[SF_ROOMTYPE]&4){D(Game->GetCurMap()+1,S);return;}
SCR(Game->GetCurMap()+2+LARGEMAP,S);
//if(Screen->State[ST_SECRET]==true){SeC(Game->GetCurMap()+1+LARGEMAP,S);}
if(Screen->NumNPCs()>0){NPCF(Game->GetCurMap()+2+LARGEMAP,S);}
if(Screen->NumItems()>0){ITEMF(Game->GetCurMap()+2+LARGEMAP,S);}
//if(EPOCH<=0)BC(Game->GetCurMap()+1+LARGEMAP);
}

//}
}
}
bool isSolidScreen(int m,int s,int c,int d)//checks for solid at current (map,screen,x,y) in ZC scrolling down to the quarters.
{
int x=c-((s%16)*256)-(N-N);
int y=d-(Floor(s/16)*176)-(N-N);
//Screen->DrawInteger(7,c,d,2,1,0,32,16,x,0,128);
//Screen->DrawInteger(7,c,d+8,2,1,0,32,16,y,0,128);

if(H()==false){x=c;}if(I()==false){y=d;}
if(x<0 || x>255 || y<0 || y>175) return false;

if(x % 16 < 8)
else

if(y % 16 < 8)
else

int ret = Game->GetComboSolid(m,s,ComboAt(x,y)) & mask;
return (ret!=0);
}
void DRAW(int x,int a,int b,int y)
{
if(b<0){b=0;}
if(LOOP==false&&x<N){x=N;}if(LOOP==false&&y<N){y=N;}
if(LOOP==false&&x>N){x=N;}if(LOOP==false&&y>N){y=N;}
int C;int D;
C=N;D=N;
int X=x-C;int Y=y-D;if(LOOP==false&&H()==false){X=0;}if(LOOP==false& &I()==false){Y=0;}
int z;
if(BackgroundShift<360){z=5;}
if(BackgroundShift<240){z=4;}
if(BackgroundShift<120){z=3;}

Screen->DrawScreen(1,a,b,X,Y,0);
Screen->DrawScreen(1,a+1,b,X,Y,0);
Screen->DrawScreen(2,a+2,b,X,Y-4,0);
Screen->DrawScreen(2,a+3,b,X,Y,0);
if(z==3){Screen->DrawScreen(2,a+4,b,X,Y,0);}
if(z==4){Screen->DrawScreen(2,a+5,b,X,Y,0);}
if(z==5){Screen->DrawScreen(2,a+6,b,X,Y,0);}
}
plugging the current X and Y coordinate on the screen in variables C and D, moving the character by whichever means of input by a variable that determines overall coordinate on the map, a "scrolling" functionality can determine and detect solid combos for collision, and a flag and type code of similar nature I use for other things in the scrolling game.
I posted an example of this years ago on the forums here.

In my game, I connect several maps together to form a much larger map, and loop the map so when the player hits the edge of the map it just draws and loops back around to the other side like many RPG games with a world map.

The movement part is a simple if(InputRight)N++ moving his overall coordinate and so on. Then another function called after that detects if the player collided with a solid with isSolidScreen and moves the player back the other direction if so before the screen is drawn so it looks like no movement occured while the game is running.
In this case when using an overhead view and this style of code the player can walk right through the last few pixels on the far right and south, or in a sideview style view with gravity falls through the floor on the last few pixels after N>4094.
What I'm saying is that in a normal ZQuest game, the last two pixels out of the 4096 (256 per map x 16 screens) on the X axis are never actually used to detect collision because Link would never go there and would be stopped from going out that far by hitting the edge of the world map. I believe the Y Axis solid bits have the same problem at the southmost couple pixels.
Is it true that because of this those data bits aren't even in the code to check for isSolid there?

This isSolidScreen function checks for solid in chunks of 4 pixels so when I use it in conjunction (I wrote a code snippet that if I hover the mouse coordinates over a combo while the game is running it will return a string that says "true" or not to detect for solid combo if isSolidScreen is true on that combo) so it always returns true when I hover over the last combo on the last screen on the easternmost edge of the map and I wrote that function just to see if it would return true there or not, yet my character still falls through the floor without the additional patch to offset the detection if N (the main X overall coordinate) > 4094.

The function SCR( just has to do with where the player is on the screen, his current screen being pre-determined by the F() function indice, and from there coordinates in relation to combos and other objects are determined and plugged into isSolidScreen and other functions for type and flag.
the Draw( function draws the screens inside of a function similar to F() that determines the screen and map in relation to N and N
In a future release could you guys check to see if what I'm saying here is right and write in the databits for collision for the last two easternmost pixels please?

If you (specifically the ZC devs mainly though) want an example quest of this if you message me I'll upload it somewhere and send you link via message PM here because although I'm planning on publishing the game probably unpassworded (I read that there are ways around passwords now anyway) eventually I don't want to do that until it is done so people can play it without looking at the code for spoilers first later on.  Reply With Quote

2. I think bugs are a normal part of every game, it's great that users like you try to help!  Reply With Quote

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•