Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2012-03-02 14:24:37

Miksy91
Member
Registered: 2010-10-16
Post 799/2,305

"Collision data" assembly

Does anyone have any idea where the assembly of collision data is located in GSC ?
What I mean by collision data is how the game reacts when trying to walk in some direction that uses one.

Some collision data -bytes

00 = Land
01 = Grass
07 = Wall
10 = Bushy Effect (No Wild Pokemon)
12 = Cutable Tree
14 = Slightly odd Bush effect W/ Wild Pokemon
15 = Headbutt Tree
18 = Bushes w/ Wild Pokemon
1A = Cutable Tree?
20 = Surfable Water With Bushy Effect
23 = Slip N Slide!
24 = Whirlpool

What I want to do is to make a "collision" data of my own for North Star (check whether player has protective equipment against cold and if not, do something...). I'd rather use one of the "unused" bytes like 02.

(I guess I just try to find it out later myself if no one knows by now but just felt like asking first)

Offline

#2 2012-03-02 14:28:20

Aicy
Member
Registered: 2012-02-20
Post 19/76

Re: "Collision data" assembly

Maybe just use events? If, player have like silph scope, then the area will not let the player in. Thats the easiest way I can think of.

Last edited by Aicy (2012-03-02 14:33:35)


Email!

Offline

#3 2012-03-02 14:32:02

Miksy91
Member
Registered: 2010-10-16
Post 800/2,305

Re: "Collision data" assembly

Aicy wrote:

Maybe just use events? If, player have like silph scope, then the area will not let the player in. Thats the easiest way I can think of.

There are already loads of trigger events here and there so that so that if you walk somewhere where there is a trigger, you may get cold without protection against it. However, there are also spots where there are no triggers (which doesn't work the way I want) and besides, it's quite easy to figure out that there are some spots out there where you can only get cold. And I want it to look as professional as possible ;)

Offline

#4 2012-03-02 14:36:41

Aicy
Member
Registered: 2012-02-20
Post 21/76

Re: "Collision data" assembly

Then I don't have any idea. XD


Email!

Offline

#5 2012-03-02 16:42:44

Melash
Member
Registered: 2010-10-16
Post 102/132

Re: "Collision data" assembly

I'm very interested in this too. I've looked into this myself to try and create new tile effects for my game, but I haven't been successful yet.

Offline

#6 2012-03-02 17:18:05

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 1,252/3,455

Re: "Collision data" assembly

I'm also interested in this. It would make recreating the spinner tiles from RBY handy, plus I've noticed that with a bit of tweaking the collision byte for tall grass with no pokemon would make walking behind roofs possible. By minimal tweaking, I mean this: Make it not load the bushy graphic over the player, and have it load either just the bottom row or all of both rows over the player using the first colour as transparency (instead of the bottom row and half of the top row like it does now). As it is, if you deleted the graphics for bushy effect over player, and made your graphics so they would work with the 1 and a half rows of tiles over the player, you can already make it walk behind roof and treetops, but with tweaking it could be better.

Offline

#7 2012-03-02 23:54:42

Tauwasser
Member
Registered: 2010-10-16
Post 268/447

Re: "Collision data" assembly

The checks are all over the place:

1713 = Check if Hero's current collision is water type
       z = is water type; nz = is other type
171E = Get lower 4 bits of collision type for collision a
        a <= ret
215A = WarpEnter?
        Del all Sprites,
        Hide window and turn screen update off,
        Update Hero Collisions
        Check for Warp-On-Contact and if so change Hero's viewing direction to down
        Special check bit5[D182]: Change Hero's viewing direction
        Set After-Warp Walking Mode [D682] according to collision
        if !(bit6[D182]) { 
            set0[CFE5]
            call 2F1E    update engine sprites and update screen once
        }
        
        clear [D182]
2A32 = Update Hero Collision
       Update [CEA3-CEA6] und bit3[CEA7] (bug!!).
       Update Collision under Hero [D20B],
       Update [CEA7] to reflect prohibited walking directions
2AA9 = Check whether a is BX/CX collision; ([CEA3] should == a)
       if it is, check for Oben-Impossible Collisions
       and set3[CEA7] if so
       !buggy, should set according direction bit!
2AC3 = Check whether a is BX/CX collision; ([CEA4] should == a)
       if it is, check for Down-Impossible Collisions
       and set3[CEA7] if so
       !buggy, should set according direction bit!
2ADD = Check whether a is BX/CX collision; ([CEA6] should == a)
       if it is, check for Left-Impossible Collisions
       and set3[CEA7] if so
       !buggy, should set according direction bit!
2AF7 = Check whether a is BX/CX collision; ([CEA5] should == a)
       if it is, check for Right-Impossible Collisions
       and set3[CEA7] if so
       !buggy, should set according direction bit!
2B11 = Check whether a is BX/CX collision
       z = true; nz = false
2B19 = Get Collision Data (=a) and X/Y (= de) of block quarter hero is facing
2B4E = Get collision byte for block quarter at de = XY (in People coords). Block 00 will always give FF
       Tilesetheader has to be loaded ([D0C8-D0CA] = PNT to collData)
04:402D - Movement routine Collision Data when arriving on block quarter
05:4A44 : Check for Warp-On-Contact Collision under Hero [D20B]

        check for 
                    71 
                    79 
                    7A 
                    73 
                    7B 
                    74 
                    7C 
                    75 
                    7D

So if you check for calls to those, you should find stuff. There are some lists of other often-used collision indexes early in the rom. Also, all offsets might or might not match with the English version...

Finally:

00 - no obstacle
01 - no obstacle
07 - obstacle
    talking collision
10 - 
12 - Tree (Cut)
14 - Warp on grass
15 - Tree (Headbutt)
18 - High Grass (Pokémon Fight + Grass Animation)
1A - Tree (Cut)
1C - Warp on Grass
1D - Tree (Headbutt)
20 - 
23 - Slide (on ice)
24 - Whirlpool (Whirlpool) 
27 - Obstacle 
28 - 
29 - Water (Surfer)
2B - Slide (on ice)
2C - Whirlpool (Whirlpool)
    30ies
30 - Waterfall right
31 - Waterfall left
32 - Waterfall up
33 - Waterfall down
3B - Waterfall down (can be used when talked to)
    40ies
40 - 
41 - right
42 - left
43 - up
44 - down
45 - 
46 - 
47 - 
    50ies
50 - right
51 - left
52 - up
53 - down
5F - 
60 - Falling down in Caves
61 - Not finished. Possibly Formula One Simulator.
68 - Falling down in Caves (different sound than 0x60)
    70ies
70 - Warp when trying to move down
71 - Door (if warp is present, warp; if no warp is present, move down one block quater)
72 - Warp when moving onto block quarter
73 - 
74 - 
75 - 
76 - Warp when trying to move left
78 - Warp when trying to move right
79 - 
7A - Warp; When warped to, move down one block quarter
7B - Warp on moving onto block quarter
7C - Teleporter warp
7D - 
7E - Warp when trying to move right
90 - People event in line with hero's facing and talked-to block quarter is talked to
91 - Dialog "PokéMon Friend PokéMon Magazine ..."
93 - PC in PokéMonCenter
94 - Radio "OAKs Pokémon Talk"
95 - Town Map
96 - Dialog "Much Pokémon Merchandising!"
97 - Dialog "This is a television!"
98 - People event in line with hero/s facing and talked-to block quarter is talked to
9D - Dialog "My mirror image! Looking good!"
9F - Dialog "What is this? Oh, it's incense!"
    A0ies
A0 - Hero can jump right
A1 - Hero can jump left
A2 - Hero can jump up
A3 - Hero can jump down
A4 - Hero can jump down and right
A5 - Hero can jump down and left
A6 - Hero can jump up and right
A7 - Hero can jump up and left
    B0ies
B0 - right side blocked
B1 - left side blocked
B2 - top side blocked
B3 - bottom side blocked
B4 - bottom and right sides blocked
B5 - bottom and left sides blocked
B6 - top and right sides blocked
B7 - top and left sides blocked
    C0ies
B0-codes in water!

3E:74BE table with attributes for every collision type:

X0 - walkable
X1 - only walkable using surfer
XF - not walkable
1X - talk event

Very rough translations, it's 1 AM, sue me.

cYa,

Tauwasser

Offline

#8 2012-12-19 22:08:44

SRL8
Member
From: United States
Registered: 2012-12-17
Post 15/27

Re: "Collision data" assembly

How did you find which calls trigger the checks, Tauwasser? I've been trying to figure out ASM call functions by looking at the disassembly of Crystal, but that code listing is difficult for me to navigate.


"The more you know, the more you know you don't know."  -Aristotle
"Now remember, kids, the Internet is serious business." - Unknown

Offline

#9 2012-12-20 01:47:45

Tauwasser
Member
Registered: 2010-10-16
Post 329/447

Re: "Collision data" assembly

I looked at the code? There's nothing more to it. Go through the collision routine step by step and you'll find most of them used. Others are hidden in LUTs and pointer arithmetic.

cYa,

Tauwasser

Offline

#10 2012-12-20 02:18:44

SRL8
Member
From: United States
Registered: 2012-12-17
Post 16/27

Re: "Collision data" assembly

I see. I guess I'll just have to deduce ASM call functions by looking more closely at the disassembly and nopping out calls in order to test their effects. It seems that's how IIMarckus did it in the Naming Screen ASM analysis he posted back in 2011.


"The more you know, the more you know you don't know."  -Aristotle
"Now remember, kids, the Internet is serious business." - Unknown

Offline

#11 2012-12-20 02:54:39

koolboyman
Member
Registered: 2010-10-16
Post 123/203

Re: "Collision data" assembly

Some of the colliders actually read from scripts when you" talk" to them.  One that comes to mind is the "my reflection looking good" script.

Offline

#12 2012-12-21 00:26:00

Tauwasser
Member
Registered: 2010-10-16
Post 330/447

Re: "Collision data" assembly

SRL8 wrote:

I see. I guess I'll just have to deduce ASM call functions by looking more closely at the disassembly and nopping out calls in order to test their effects. It seems that's how IIMarckus did it in the Naming Screen ASM analysis he posted back in 2011.

Don't nop calls out, just jump into them and see what they're actually doing! Nopping stuff out is guesswork, really.

cYa,

Tauwasser

Offline

#13 2012-12-21 01:18:26

SRL8
Member
From: United States
Registered: 2012-12-17
Post 19/27

Re: "Collision data" assembly

Thanks for the advice, Tauwasser, I'll do that.


"The more you know, the more you know you don't know."  -Aristotle
"Now remember, kids, the Internet is serious business." - Unknown

Offline

#14 2012-12-21 07:07:00

Miksy91
Member
Registered: 2010-10-16
Post 1,363/2,305

Re: "Collision data" assembly

One thing I like to do when following code is having two or three asm editors opened up at the time.
I use one for following the main code and two other ones for its subscripts. That way, you can keep up with what's going on better.
And bgb's debugging option is helpful sometimes too.

Last edited by Miksy91 (2012-12-21 07:07:16)

Offline

Board footer

Powered by FluxBB