Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#76 2013-07-02 18:28:25

Danny-E 33
Administrator
Registered: 2012-06-09
Post 602/1,119

Re: RGBY Map Headers

pokeglitch, there are a few cases where I have to edit the dimensions of a map because I have changed the dimensions in my hack but the dimensions are hard-coded in your tool based on the map name. I've noticed that when I edit the variables, close the tool and reopen it, it has reverted to the original code, so there's no harm if I edit some things that I need to edit, yes?
By the way, it is working great so far, thank you.

Offline

#77 2013-07-02 20:42:59

80C
Banned
Registered: 2013-03-16
Post 967/1,257

Re: RGBY Map Headers

I didn't encountered glitched Tiles errors, it hasn't to do with connection problems.

About the OverWorld Glitch that occours between new routes, I've found the truth:

An undiscovered glitch of the main series of Generation I.

I guess this could be called "The OW Glitch", and even Nintendo noticed it, that's why sometimes they buildt route gates "with no reason".

The most noticeable case regard Route 13.

In Route 13 infact, the Lavender Spriteset is different from Route 13, this means that the game glitches up with the OW assignment unless the player is spawned in the map by warp, so to avoid this glitch a warp connection is needed.
The fastest way to do this was build those Route Buildings.
So Game Freak staff created the Route Building in Route 13 to avoid this bug (infact there isn't any person before the Route Building).

I think its related with spritesets of R\B, and we didn't investigated enough about that IN THE FIRST GENERATION GAMES.

Last edited by 80C (2013-07-02 22:08:41)


I left this forum.

Offline

#78 2013-07-02 20:56:09

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

Re: RGBY Map Headers

No, not really. It's just that there is so little space in Video Ram that only some sprites can be displayed at once.
Everytime you enter a warp, these sprites are loaded with the sprites that are present in the spritesheet of that Map Bank (or so it goes in G/S/C anyway).

The reason they programmed it like that though? I'd say, convenience really!

Last edited by Miksy91 (2013-07-02 20:56:36)

Offline

#79 2013-07-02 21:12:10

80C
Banned
Registered: 2013-03-16
Post 970/1,257

Re: RGBY Map Headers

Hmm... the bank spriteset thing works only for G\S\C, infact in GenI Games there's only 1 "Bank" for maps because all the maps, unlike GSC, are listed by index number from 0 to FF, but not every index is used, like the eliminated maps - such as $0B aka Erased City or $FE, completely empty.


I left this forum.

Offline

#80 2013-07-02 21:36:10

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

Re: RGBY Map Headers

So basically you willfully ignored all tutorials on spritesets just to claim you found a bug? Wow.

cYa,

Tauwasser

Offline

#81 2013-07-02 22:04:43

80C
Banned
Registered: 2013-03-16
Post 971/1,257

Re: RGBY Map Headers

Tauwasser wrote:

So basically you willfully ignored all tutorials on spritesets just to claim you found a bug? Wow.

So basically I've looked to all tutorials of R\B exept this one because I don't think there's a tutorial like that for Generation I, maybe for Generation II, I'm talking about Gen.I.

Ok, I've took 2 screenshot of the Gen1 games Tutorial section, where you saw the thread of the Tutorial for spritesets in maps in Red\Blue?

uak1.png

mwdf.png

There's something like that thing you suggested in the Gen2 section - i.e. G\S\C, not in Gen1.

So you basically ignored all the previous posts just to claim willfully I'm stupid? wow, but I've been expecting a better statement about an error that shows up in new connected routes under not-really known circumstances, expecially from an asm genious.

Knowing advanced asm doesn't mean then you could answer anything un-related to the argument and mock everyone.
Anyway, It's surprising encounter how many people think GenI is the same thing of GenII.

I know only that there are maps in which the OW will be correct, if you try change an OW using an OW that doesn't look like the other ones used in the same map, sometimes they could glitch.

Last edited by 80C (2013-07-02 22:25:49)


I left this forum.

Offline

#82 2013-07-03 15:24:49

tekcoR
Member
From: Celadon City
Registered: 2010-10-16
Post 154/165

Re: RGBY Map Headers

You may not know Tauwasser and his harsh responses that well but this is one of the nicer things he could have said. It was really a bit hasty to make a fuzz about a 'bug' when there isn't one. Miksy explained it. It's more handling limited memory than a bug.
I don't know if you have looked into the disassembly for your problem or understanding the spritesets in RBY but you can find some neat information about it.

(off-topic)
Speaking of you, Tauwasser, is there any chance of fixing RHWiki? (or some mirror?) I saved most pages and can look them up on the hard drive and Google Cache is yet working but it would be nice to see the site back up again.


Cya

Offline

#83 2014-01-03 17:17:04

pokeglitch
Member
Registered: 2013-02-20
Post 15/95

Re: RGBY Map Headers

Well, I've solved the mystery of the "bigness" byte in the connection headers.  It's actually refers to the number of blocks that you want to appear in a column/row of the connection strip [i.e. the width or height of the connection strip].  It has a maximum of 0x0F (15), anything greater will great drawn incorrectly.

I'll try to explain it in the simplest way possible:
Let's say we are trying to connect a map to the North of another map.  Bytes 2 and 3 refer to the position of the top left corner of the connection script in the North map.  This will ALWAYS be in the 3rd row from the bottom.  The "bigness" byte refers to the width of this connection strip, as the height will always be 3.  Anything outside of this box that is defined by the top left corner and the "bigness"/width will be drawn as the maps border tile.

So now you have a 3 by X window of tiles, all you have to do now is place it in the correct position in RAM (bytes 4 and 5).  No other formulas have changed, but just remember that the X offset is the difference between the left edge of the south map and the left edge of the connection strip.

There you go.  For example, instead of using an X offset of 0x14 and a bigness of 0x20, you can add 0x12 to the top left corner of the connection strip and subtract 0x12 from the X offset and Bigness.  This shifts the left edge of the window over by 0x12, but decreases the width of the window and the relative position of the current map by the same amount, so the right edge of the window is exactly the same. (the 12 blocks that you removed were pointless anyway because they will never be visible)

The normal method works for maps where the "bigness" byte is under 10.  If the bigness byte is larger, this glitch still may not be noticible depending on what the X/Y offset is.

Let me know if this makes sense and works for you.

Here is an example:  I want Rt 13 to be north of Lavender Town, but I want the right edges to line up.  The width of Rt. 13 is 0x1E and the width of Lavender town is 0x0A.  So my original code (in the Lavender Town header) had the X Offset be 20 (0x14), the bigness was 0x1E, and the top left corner of the connection strip was the first block in the 3rd row from the bottom.
In my new code, I set the X offset to be 0 and had the bigness be 0x0A, and have the top left of the connection be the 20th block in the 3rd row from the bottom.

Old:
18 3f 49 d6 c6 1e 1e 11 2a 2d c8

New:
18 54 49 eb c6 0A 1e 11 2a 2d c8

Offline

Board footer

Powered by FluxBB