Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#26 1970-01-01 00:33:30

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 286/3,578

Re: RGBY Map Headers

To help anyone who is confused about the correct way to work these formulas, who keep coming up with the wrong answers, I've provided a link explaining the order of operations.  This will come in handy for those of us who did not pay attention in Algebra or who are young enough that they have not yet taken a course that explains this.

http://www.purplemath.com/modules/orderops.htm

Offline

#27 1970-01-01 00:33:30

~Red
Member
Registered: 2010-10-16
Post 51/276

Re: RGBY Map Headers


To help anyone who is confused about the correct way to work these formulas, who keep coming up with the wrong answers, I've provided a link explaining the order of operations.  This will come in handy for those of us who did not pay attention in Algebra or who are young enough that they have not yet taken a course that explains this.

http://www.purplemath.com/modules/orderops.htm

I know the order of operations I just was too lazy to do my BIDMAS.

Brackets
Indices
Division
Multiplication
Addition
Subtraction

BIDMAS.

Offline

#28 1970-01-01 00:33:30

~Red
Member
Registered: 2010-10-16
Post 58/276

Re: RGBY Map Headers

Ugh. I can't seem to get the connection from Route 5 to Cinnabar to work either. Here's what I've got:

08 47 1C EB C6 0A 0A 00 00 79 C7

Offline

#29 1970-01-01 00:33:30

~Red
Member
Registered: 2010-10-16
Post 64/276

Re: RGBY Map Headers

So....what am I doing wrong?

Offline

#30 1970-01-01 00:33:30

Miksy91
Member
Registered: 2010-10-16
Post 152/2,339

Re: RGBY Map Headers

I'm also having some problems with this.
I'm trying to make a downwards connection from New Bark to Route 41 (sea route).

The Width & Height of Route 41 are 25, 27 (19, 1B).
I used the pattern for South-connection (C6EB + (Height of Map + 3) * (Width of Map + 6) + X_Movement_of_Connection Strip) and got this.

C6EB + (19 + 6) * (1B + 3) + x = CA8D + x

Of course x must be some digit as well but I can't figure out which one.
I tried with 4 (making it CA91) but it didn't work.

Other map connection bytes should be right, do you know what's the problem ?

Offline

#31 1970-01-01 00:33:30

Sawakita
Administrator
Registered: 2010-10-16
Post 35/365

Re: RGBY Map Headers

the last variable (x) represents how many blocks the connected map is shifted horizontally.
So if you put:
x = 4
then your connected map's top left corner should be moved to the right of four blocks, rather than aligned with the map above.

Exactly what problem are you experiencing?
(also a screenshot would be helpful to understand the trouble)

Offline

#32 1970-01-01 00:33:30

Miksy91
Member
Registered: 2010-10-16
Post 153/2,339

Re: RGBY Map Headers

The connection doesn't seem to exist   :-/
It just shows trees as border blocks.

EDIT:
I made a quick test by using the map connection bytes of Route 40 (Down), and ended up with the same result.
The connection isn't appearing.

Also, now I only have 2 connections for New Bark although it used to have 3. Might that cause the problem ?
*The connection to right (to Route 27) is working however...

Offline

#33 1970-01-01 00:33:30

Sawakita
Administrator
Registered: 2010-10-16
Post 36/365

Re: RGBY Map Headers

Did you edit the connection byte?
Did you insert the connection data in the right order?


Quote:

=============================================================
    10) Connection Byte
==================================================================

Note:
~~~~~
If this value is 00h it is immediately followed by the Object Data
Pointer, no gap. Repeated list:

Connection Byte:
    00 = No Connections
    01 = East
    02 = West
    03 = West + East
    04 = South
    05 = South + East
    06 = South + West
    07 = South + West + East
    08 = North
    09 = North + East
    0A = North + West
    0B = North + West + East
    0C = North + South
    0D = North + South + East
    0E = North + South + West
    0F = North + South + West + East

Connections can be obtained with binary masks:

    1. connect_byte & (1 << 3) -> North
    2. connect_byte & (1 << 2) -> South
    3. connect_byte & (1 << 1) -> West
    4. connect_byte & (1 << 0) -> East

You have to respect this order to get the correct list.


@Red

Quote:

Ugh. I can't seem to get the connection from Route 5 to Cinnabar to work either. Here's what I've got:

08 47 1C EB C6 0A 0A 00 00 79 C7

This should be connection of cinnabar in route 5's header, right?

Unless you repointed Cinnabar data, connection data should be:

08 69 40 ab c7 0a 0a 00 00 69 cf

08: ok
69 40: connection strip pointer (no idea where you got 471c)
ab c7: it seems that you applied north formula instead of south formula
0a 0a: ok
00 00: ok
69 cf:it seems that you applied north formula instead of south formula

Offline

#34 1970-01-01 00:33:30

Miksy91
Member
Registered: 2010-10-16
Post 154/2,339

Re: RGBY Map Headers

Actually, I tried editing the connections with JohtoMap, therefore they may be in wrong order.
I'll check what hex editor shows in the connection data.

Offline

#35 1970-01-01 00:33:30

Sawakita
Administrator
Registered: 2010-10-16
Post 37/365

Re: RGBY Map Headers

I built a program (in VB 6.0), that checks if your connections are correct. I tested it on a clean ROM of Blue: it works perfectly when the coefficient of shift is >=0; but when shift is <0, formula seems to be different.
For example it seems (although I'm not sure) that "BIGNESS" is not actual connected map's width (N/S connection) or height(W/E connection), but the visible width (or height), depending on the current map's width (or height). Also "current map position (RAM)" seems to be calculated differently.

Is there anyone that can confirm it?

==================================

EDIT: In the end of the first post, Event Displacement formula should be fixed. If I'm not wrong the correct formula is:

C6EF + (Map width) + (Map width + 6) * (rows above) + (X movement)

==================================

EDIT2: After doing some research, I found out that Tileset Headers aren't 0x0C bytes long, but rather 0x0B bytes long.
In fact when calculating the tileset_header's offset the program multiplies Tileset_ID by twelve (decimal), but when loading Tileset_header into RAM it only loads 0x0B bytes.

That byte was probably originally planned to indicate another grass-tile (like second-last byte), or some other feature for the tiles, but then removed during game development.

Last edited by Sawakita (2011-06-05 20:09:45)

Offline

#36 2010-12-14 13:34:36

Sawakita
Administrator
Registered: 2010-10-16
Post 60/365

Re: RGBY Map Headers

Did you know that in warp data you can put 'FF' instead of the warp-to-Map's ID, and the program finds the corresponding map, by itself?
For example, map "Red's house F1":
- warp to Pallet Town (there are 2 of these since the door is 2 tiles wide):
        07 02 00 FF
        07 03 00 FF

As usual, the warp structure is [Y-coord][X-coord][warped Map's Warp_ID][Map_ID (or in this case FF)]

If you put the actual Map_ID instead of FF it still works fine.

Offline

#37 2010-12-14 22:22:58

64/703

Re: RGBY Map Headers

Sawakita wrote:

Did you know that in warp data you can put 'FF' instead of the warp-to-Map's ID, and the program finds the corresponding map, by itself?
For example, map "Red's house F1":
- warp to Pallet Town (there are 2 of these since the door is 2 tiles wide):
        07 02 00 FF
        07 03 00 FF

As usual, the warp structure is [Y-coord][X-coord][warped Map's Warp_ID][Map_ID (or in this case FF)]

If you put the actual Map_ID instead of FF it still works fine.

In Gold, this means that the warp can be edited through a script (e.g., elevators). The usage in Red is probably similar. I don't see why they would do it in this case, but it might be worth checking for a nearby script that loads the Pallet Town map number.

#38 2010-12-15 14:32:21

Sawakita
Administrator
Registered: 2010-10-16
Post 61/365

Re: RGBY Map Headers

IIMarckus wrote:

In Gold, this means that the warp can be edited through a script (e.g., elevators). The usage in Red is probably similar. I don't see why they would do it in this case, but it might be worth checking for a nearby script that loads the Pallet Town map number.

It seems that the 'FF'-method is used only when cities (maps $00-$0a) are involved. There's a controller that checks it when warping FROM city (it checks if Map_ID is < 0x0B): it saves [warped map's ID] in [$D365].
Then, when you enter a warp, if Map_ID (fourth byte in warp data) is 'FF' then the program loads Map_ID from [$D365] to [C35E], which is Current_Map (so it loads the new map, and warps the player to it).
Obviously this whole system is based on the bijection of warps.

Side Note: it seems that a data table is involved: this table starts at $7219e. I didn't bother finding more about it, for the moment. I just stumbled in it and ignored it, so I don't really have info about it.


Now, about elevators, since you mentioned them, I went checking them in Red/Blue, to see if they actually work like GSC ones do.
It seems that they don't, since their warp data specifies, instead of 'FF', an actual map, just one.

This implies that there's a script about them, in fact in Text-Scripts there's a specific method (both the elevators I checked have it): it pops up that "which floor menu", and it also loads some data in RAM, that is possibly used, after you choose the floor, to point to a maps' table (groups of 4-bytes data, the only byte I'm sure of is the last, which is FloorMap_ID, odds are that those 4-bytes groups are overwritten on the default's warp-data in RAM).

I didn't finish disassembling that elevators' stuff too, so.. that's all I could find for now.

Offline

#39 2010-12-15 20:28:34

Tauwasser
Member
Registered: 2010-10-16
Post 53/452

Re: RGBY Map Headers

It sounds like it is using the default return maps/fly destinations. You return to cities when you faint, don't you?

cYa,

Tauwasser

Offline

#40 2010-12-16 13:37:53

Sawakita
Administrator
Registered: 2010-10-16
Post 62/365

Re: RGBY Map Headers

Tauwasser wrote:

It sounds like it is using the default return maps/fly destinations. You return to cities when you faint, don't you?

cYa,

Tauwasser

I'm not sure if I read your post correctly but: it's not axiomatic that you return to cities, generally speaking you return to the last Healing Center (or your home): in the table at $647c dying warps are listed, but they're not exclusively cities (for example, map $0F and map $15 are those routes with a PokeCenter in them).

Also, flying/dying warp system has one warp per map at most, while the FF-thingy is used for every "InsideMap to OutsideMap warp". In fact my last post needs a correction, not only houses-to-cities use the FF-method for warp, apparently every Inside-to-Outside warp use it.

So, now I' not sure what that "Map < $0B" was for. It turns out that the table at $7219e, that I previously ignored, can be relevant...


----------------------------------------------



EDIT1:
Ok, I think I found it!! OldMap's warp_ID and OldMap are stored respectively in $D73B and $D73C. So it just read from there the location, if warp data  has FF-method.


----------------------------------------------



EDIT2:
This is insane. Here is how it works, when you enter a warp:

Saving Aspect:
It checks if map's Tileset is $00 (used exclusively for external maps), or $17 (Indigo Plateau's, i.e. the only external map, that doesn't use Tileset 00 (*)).
If true, saves Map_ID in [$D365], and in [$D73C] (as I said in EDIT1, this is the normal OldMap backup).
If false just saves Map_ID in [$D73C].

Loading Aspect:
Checks if warp is FF.
If true loads Map from [$D365];
If false loads Map from [$D73C].


(*): S.S.Anne's Dock works like an internal map, in this aspect: it warps to Vermilion city by means of a FF-warp. S.S.Anne's Inside, in fact, doesn't warp to external dock using a FF-warp, but a regular warp.

Last edited by Sawakita (2010-12-16 22:34:39)

Offline

#41 2011-03-20 13:58:30

Sawakita
Administrator
Registered: 2010-10-16
Post 95/365

Re: RGBY Map Headers

via PM Iron Nidow wrote:

well, I don't understand which is the correctly formula of warp to points the formulas in topic of map editing are not right explained you can tell me?

[*2 Bytes*: Event Displacement][Y position][X position]

First 2 bytes are event displacement (little-endian):

Event Displacement Formula:
~~~~~~~~~~~~~~~~~~~~~~~~~~
C6EF + (Map width) + (Map width + 6) * (rows above) + (X movement)

"Map width" is map's width in blocks (3rd byte in map header)
"rows above" = ("Y position" - 1) \ 2             ;basically it's the number of blocks above the warp
"X movement" = ("X position" - 1) \ 2           ;basically it's the number of blocks on the left of the warp

Last edited by Sawakita (2011-03-20 13:58:47)

Offline

#42 2011-03-20 14:40:27

Iron Nidow
Member
Registered: 2010-10-16
Post 7/10

Re: RGBY Map Headers

oh thanks...

and I have another doubt. the animations of event displacement(for exemple: the silph co portals, and the seafoan islands hole)

this is only changeable in asm?

Offline

#43 2011-03-21 13:55:47

Sawakita
Administrator
Registered: 2010-10-16
Post 96/365

Re: RGBY Map Headers

Could you explain better what you mean when you say "animations of event displacement"?

Offline

#44 2011-03-21 20:50:20

Iron Nidow
Member
Registered: 2010-10-16
Post 8/10

Re: RGBY Map Headers

Well

when you enter in a portal in silph co, no are a normal warp(you fly up and place in other portal)
when you enter in a hole in seafoan islands, no are a normal warp ( you enter in hole and down of the top screen of displaced location )

Offline

#45 2011-04-08 16:23:12

Sawakita
Administrator
Registered: 2010-10-16
Post 99/365

Re: RGBY Map Headers

Iron Nidow wrote:

Well

when you enter in a portal in silph co, no are a normal warp(you fly up and place in other portal)
when you enter in a hole in seafoan islands, no are a normal warp ( you enter in hole and down of the top screen of displaced location )

I guess it would probably require some ASM hacking (or at least some reverse engineering to find if it's simply hex-editable or not); I really never made any research about special warps, so I don't know.

Offline

#46 2011-04-09 07:35:57

Miksy91
Member
Registered: 2010-10-16
Post 319/2,339

Re: RGBY Map Headers

I noticed something quite useful according to the G/S map connection editing today :D

I first thought "I don't get it. Whatever I do, I always mess up because I never come up with the right values".
Well, I took a look at it and noticed that the connection ram values are slightly different from the ones in 1st gen games.
For example, the minimum "Window" value for the for "West" connection is C706, not C6EE.
Other than that, you can count it exactly the same way.

I'll be checking out the others as well and post a tutorial about map connection editing later ;)

Offline

#47 2011-06-05 20:16:22

Sawakita
Administrator
Registered: 2010-10-16
Post 124/365

Re: RGBY Map Headers

Sawakita wrote:

EDIT2: After doing some research, I found out that Tileset Headers aren't 0x0C bytes long, but rather 0x0B bytes long.
In fact when calculating the tileset_header's offset the program multiplies Tileset_ID by twelve (decimal), but when loading Tileset_header into RAM it only loads 0x0B bytes.
That byte was probably originally planned to indicate another grass-tile (like second-last byte), or some other feature for the tiles, but then removed during game development.

As usual what I wrote was wrong. It's true that only 11 of 12 bytes of Tileset's Header are loaded in WRAM ($D52B-$D535), but the last (12th) byte is used indeed. It's just that it's loaded in HRAM ($FFD7). It's the flag for animation tiles.

@IIMarckus: I've updated the Notes at datacrystal, in case you're interested in updating our mirror too.

Offline

#48 2011-06-27 21:54:45

Sawakita
Administrator
Registered: 2010-10-16
Post 148/365

Re: RGBY Map Headers

@IIMarckus: it would probably be a good thing if you could update the first post with the latest version of the document. Maybe not everyone will go to http://hax.iimarck.us/files/rbheaders.txt; they rather go looking at this thread's first post instead. Don't you agree?

Offline

#49 2011-06-28 01:11:03

228/703

Re: RGBY Map Headers

Sawakita wrote:

@IIMarckus: it would probably be a good thing if you could update the first post with the latest version of the document. Maybe not everyone will go to http://hax.iimarck.us/files/rbheaders.txt; they rather go looking at this thread's first post instead. Don't you agree?

You’re right, of course. But rather than forever update two documents with the same information, I’ve replaced the post with just a link. It didn’t work well in the message board format anyway (assumed fixed‐width font, code tags would have forced left‐right scrolling…).

#50 2011-08-28 15:37:37

~Red
Member
Registered: 2010-10-16
Post 134/276

Re: RGBY Map Headers

After picking up Wisteria again after some time to see if I could figure out I still was not able to get the connections right. I don't usually ask for handouts but I'm getting desperate, can someone tell me what data I need to input into connection data and explain how you got to that? I just cannot seem to connect route 5 to cinnabar, I managed to get cinnabar to connect to route 5, but not route 5 to cinnabar!

Offline

Board footer

Powered by FluxBB