Go Back   The PokéCommunity Forums > ROM Hacking > Research & Development
Reload this Page Development [FR] Triple Layer Tiles using Block References

Notices
For all updates, view the main page.

Research & Development Got a well-founded knack with ROM hacking? Love reverse-engineering the Pokémon games? Or perhaps you love your assembly language. This is the spot for polling and gathering your ideas, and then implementing them! Share your hypothesis, get ideas from others, and collaborate to create!
Research & Development programs in this forum are subject to moderator approval before they are displayed.



Reply
 
Thread Tools
  #1    
Old June 2nd, 2014 (09:45 PM).
Shiny Quagsire's Avatar
Shiny Quagsire Shiny Quagsire is offline
Double Agent for Team Johto
 
Join Date: May 2009
Location: Hoenn Safari Zone
Age: 17
Gender: Male
Nature: Jolly
Posts: 691
So for a long time there has been a bit of an underground-ish ASM routine (made by diegoisawesome) that's gone around which enabled a hacker to have a triple layered blocks, which is done by using the bottom layer of the next block as the third layer of the tripled block. To demonstrate graphically, imagine this is your average block:

[bottom layer (4 bytes)] [top layer (4 bytes)]

Depending on the background byte, these two layers will be loaded with either both underneath the player or the top layer above the player. With the triple layer tiles, it will load like this:

[bottom layer (4 bytes)] [middle layer layer (4 bytes)] {player} [top layer (4 bytes)]

However, I found this system to be slightly inefficient, and given all the extra bits that Fire Red has been blessed with by GameFreak due to the fact that Fire Red has 4 bytes for block behaviors instead of 2, we can utilise these extra bits available to us to create a reference-based triple-layer tile. That is, a tile which will tell the game which block to pull it's top layer from.

To start, I wrote out the original block rendering routine, which can be compiled and inserted at 0805A9B4. In it's current state, it is very inefficient and has a lot of repeating code:
Code:
.thumb
.thumb_func

main:
push {r4,lr}
mov r4, r1
lsl r2, r2, #0x10
lsr r2, r2, #0x10
cmp r0, #0x1
beq underplayer
cmp r0, #0x1
bgt triple
cmp r0, #0x0
beq overplayer
b render

triple:
cmp r0, #0x2
bne render

triplestuffing:
@ Commented out due to space restrictions. This code block is unused anyhow.
@ Write bottom blocks
@ldr r0, overworld_bg3_tilemap
@ldr r0, [r0]
@lsl r3,r2,#0x1
@add r0, r3, r0
ldrh r1, [r4]
strh r1, [r0] @ Write top left bg tile
ldrh r1, [r4,#0x2]
strh r1, [r0,#0x2]
mov r2, r0
add r2, #0x40
ldrh r1, [r4, #0x4]
strh r1, [r2]
add r0, #0x42
ldrh r1, [r4, #0x6]
strh r1, [r0]

@ Write top blocks
ldr r0, overworld_bg2_tilemap
ldr r0, [r0]
add r0, r3, r0
mov r2, #0x0
strh r2, [r0]
strh r2, [r0,#0x2]
mov r1, r0
add r1, #0x40
strh r2, [r1]
add r0, #0x42
strh r2, [r0]
b overplayer_bg1

underplayer:
@ Write bottom blocks
ldr r0, overworld_bg3_tilemap
ldr r0, [r0]
lsl r3,r2,#0x1
add r0, r3, r0
ldrh r1, [r4]
strh r1, [r0] @ Write top left bg tile
ldrh r1, [r4,#0x2]
strh r1, [r0,#0x2]
mov r2, r0
add r2, #0x40
ldrh r1, [r4, #0x4]
strh r1, [r2]
add r0, #0x42
ldrh r1, [r4, #0x6]
strh r1, [r0]

@ Write top blocks
ldr r0, overworld_bg2_tilemap
ldr r0, [r0]
add r0, r3, r0
ldrh r1, [r4,#0x8]
strh r1, [r0]
ldrh r1, [r4, #0xA]
strh r1, [r0,#0x2]
mov r2, r0
add r2, #0x40
ldrh r1, [r4,#0xC]
strh r1, [r2]
add r0, #0x42
ldrh r1, [r4,#0xE]
strh r1, [r0]

@ Clear other existing blocks
ldr r0, overworld_bg1_tilemap
ldr r0, [r0]
add r3, r3, r0
mov r1, #0x0
strh r1, [r3]
strh r1, [r3,#0x2]
mov r0, r3
add r0, #0x40
strh r1, [r0]
add r3, #0x42
str r1, [r3]
b render

overplayer:
@ Write nothing to bottom (not sure why they use 0x3014 :/)
ldr r0, overworld_bg3_tilemap
ldr r0, [r0]
lsl r3,r2, #1
add r0, r3, r0
ldr r1, _3014
mov r2, r1
strh r2, [r0]
strh r2, [r0,#0x2]
mov r1, r0
add r1, #0x40
strh r2, [r1]
add r0, #0x42
strh r2, [r0]

ldr r0, overworld_bg2_tilemap
ldr r0, [r0]
add r0, r3, r0
ldrh r1, [r4]
strh r1, [r0]
ldrh r1, [r4,#0x2]
strh r1, [r0,#0x2]
mov r2, r0
add r2, #0x40
ldrh r1, [r4,#0x4]
strh r1, [r2]
add r0, #0x42
ldrh r1, [r4,#0x6]
strh r1, [r0]

overplayer_bg1:
ldr r0, overworld_bg1_tilemap
ldr r0, [r0]
add r3, r3, r0
ldrh r0, [r4,#0x8]
strh r0, [r3]
ldrh r0, [r4,#0xA]
strh r0, [r3,#0x2]
mov r1, r3
add r1, #0x40
ldrh r0, [r4,#0xC]
strh r0, [r1]
add r3, #0x42
ldrh r0, [r4,#0xE]
strh r0, [r3]

render:
mov r0, #0x1
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x2
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x3
ldr r1, render_bgmap
bl bx_r1
pop {r4}
pop {r0}
bx r0

bx_r1:
bx r1

.align 2
overworld_bg1_tilemap: .long 0x03005018
overworld_bg2_tilemap: .long 0x03005014
overworld_bg3_tilemap: .long 0x0300501C
_3014: .long 0x3014
render_bgmap: .long 0x080F67A4+1
I should probably note that this version was actually slightly larger due to the bl's at the end, and as such part of the unused part of the routine was cut out. But, after some optimisations we can come out with a much cleaner version of this renderer which is a lot more efficient:
Code:
.thumb
.thumb_func

main:
push {r4,lr}
mov r4, r1
lsl r2, r2, #0x10
lsr r2, r2, #0x10
cmp r0, #0x1
beq underplayer
cmp r0, #0x1
bgt triple
cmp r0, #0x0
beq overplayer
b render

triple:
b render

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ All blocks are underneath the player  @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
underplayer:
@ Write bottom blocks
ldr r0, overworld_bg3_tilemap
bl write_bottom_blocks

@ Write top blocks
ldr r0, overworld_bg2_tilemap
bl write_top_blocks

@ Clear other existing blocks
ldr r0, overworld_bg1_tilemap
bl write_nothing
b render


@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ The top layer of blocks is rendered over the player @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
overplayer:
@ Write bottom blocks
ldr r0, overworld_bg2_tilemap
bl write_bottom_blocks

@ Write top blocks
ldr r0, overworld_bg1_tilemap
bl write_top_blocks

@ Write nothing to bottom 
ldr r0, overworld_bg3_tilemap
bl write_nothing
b render

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write first 4 blocks to bottom-most layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_bottom_blocks:
ldr r0, [r0]
lsl r3,r2,#0x1
add r0, r3, r0
ldrh r1, [r4]
strh r1, [r0] @ Write top left bg tile
ldrh r1, [r4,#0x2]
strh r1, [r0,#0x2]
add r0, #0x40
ldrh r1, [r4, #0x4]
strh r1, [r0]
ldrh r1, [r4, #0x6]
strh r1, [r0, #0x2]
bx lr

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write last 4 blocks to top-most layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_top_blocks:
ldr r0, [r0]
add r0, r3, r0
ldrh r1, [r4,#0x8]
strh r1, [r0]
ldrh r1, [r4, #0xA]
strh r1, [r0,#0x2]
add r0, #0x40
ldrh r1, [r4,#0xC]
strh r1, [r0]
ldrh r1, [r4,#0xE]
strh r1, [r0, #0x2]
bx lr

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write out 0's in the unused layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_nothing:
ldr r0, [r0]
lsl r3, r2, #1
add r0, r3, r0
mov r2, #0x0
strh r2, [r0]
strh r2, [r0,#0x2]
add r0, #0x40
strh r2, [r0]
strh r2, [r0, #0x2]
bx lr

render:
mov r0, #0x1
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x2
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x3
ldr r1, render_bgmap
bl bx_r1
pop {r4}
pop {r0}
bx r0

bx_r1:
bx r1

bx_r2:
bx r2

.align 2
overworld_bg1_tilemap: .long 0x03005018
overworld_bg2_tilemap: .long 0x03005014
overworld_bg3_tilemap: .long 0x0300501C
render_bgmap: .long 0x080F67A4+1
In this version we cut out a lot of the repetition and junk, bringing our routine down to a slim 188 bytes, 100 bytes smaller than the original 288. With some modification, I added my triple layer tile hack:
Code:
.thumb
.thumb_func

main:
push {r4,lr}
mov r4, r1
lsl r2, r2, #0x10
lsr r2, r2, #0x10
cmp r0, #0x1
beq underplayer
cmp r0, #0x1
bgt triple
cmp r0, #0x0
beq overplayer
b render

triple:
@ Write bottom blocks
ldr r0, overworld_bg3_tilemap
bl write_bottom_blocks

@ Write top blocks
ldr r0, overworld_bg2_tilemap
bl write_top_blocks

push {r2}
mov r0, r6
mov r1, r7
ldr r2, getBlockIDAt
bl bx_r2
mov r2, r0

ldr r1, =0x27F
cmp r2, r1
ble blockset_1
add r1, #0x1
sub r2, r2, r1
mov r1, #0x4
blockset_1:
add r1, #0x10
ldr r0, cur_mapheader
ldr r0, [r0] @ Get mapdata header
ldr r3, [r0, #0x10] @ Store blockset 1 pointer for later
ldr r5, [r0, #0x14] @ Store blockset 2 pointer for later
ldr r0, [r0, r1] @ Get blockset pointer
ldr r0, [r0, #0x14] @ Get blockset background bytes
lsl r1, r2, #0x2
ldr r0, [r0, r1] @ Get background byte
lsl r1, r0, #0x8
lsr r1, r1, #0x16 @Isolate bits we want
ldr r0, =0x27F
cmp r1, r0
bgt blockset2_tiles

@sub r1, r1, #0x8 @Get top layer
b write_third_layer

blockset2_tiles:
add r0, #0x1
sub r1, r1, r0
mov r3, r5
@sub r1, r1, #0x8 @Get top layer

write_third_layer:
ldr r4, [r3, #0xC] @ Get blockset pointer
lsl r1, r1, #0x4
add r4, r1, r4
pop {r2}

@ Write third layer
ldr r0, overworld_bg1_tilemap
lsl r3, r2, #0x1
bl write_top_blocks
b render

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ All blocks are underneath the player  @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
underplayer:
@ Write bottom blocks
ldr r0, overworld_bg3_tilemap
bl write_bottom_blocks

@ Write top blocks
ldr r0, overworld_bg2_tilemap
bl write_top_blocks

@ Clear other existing blocks
ldr r0, overworld_bg1_tilemap
bl write_nothing
b render


@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ The top layer of blocks is rendered over the player @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
overplayer:
@ Write bottom blocks
ldr r0, overworld_bg2_tilemap
bl write_bottom_blocks

@ Write top blocks
ldr r0, overworld_bg1_tilemap
bl write_top_blocks

@ Write nothing to bottom 
ldr r0, overworld_bg3_tilemap
bl write_nothing
b render

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write first 4 blocks to bottom-most layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_bottom_blocks:
ldr r0, [r0]
lsl r3,r2,#0x1
add r0, r3, r0
ldrh r1, [r4]
strh r1, [r0] @ Write top left bg tile
ldrh r1, [r4,#0x2]
strh r1, [r0,#0x2]
add r0, #0x40
ldrh r1, [r4, #0x4]
strh r1, [r0]
ldrh r1, [r4, #0x6]
strh r1, [r0, #0x2]
bx lr

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write last 4 blocks to top-most layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_top_blocks:
ldr r0, [r0]
add r0, r3, r0
ldrh r1, [r4,#0x8]
strh r1, [r0]
ldrh r1, [r4, #0xA]
strh r1, [r0,#0x2]
add r0, #0x40
ldrh r1, [r4,#0xC]
strh r1, [r0]
ldrh r1, [r4,#0xE]
strh r1, [r0, #0x2]
bx lr

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ Write out 0's in the unused layer @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
write_nothing:
ldr r0, [r0]
lsl r3, r2, #1
add r0, r3, r0
mov r2, #0x0
strh r2, [r0]
strh r2, [r0,#0x2]
add r0, #0x40
strh r2, [r0]
strh r2, [r0, #0x2]
bx lr

render:
mov r0, #0x1
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x2
ldr r1, render_bgmap
bl bx_r1
mov r0, #0x3
ldr r1, render_bgmap
bl bx_r1
pop {r4}
pop {r0}
bx r0

bx_r1:
bx r1

bx_r2:
bx r2

.align 2
overworld_bg1_tilemap: .long 0x03005018
overworld_bg2_tilemap: .long 0x03005014
overworld_bg3_tilemap: .long 0x0300501C
render_bgmap: .long 0x080F67A4+1
getBlockIDAt: .long 0x08058E48+1
cur_mapheader: .long 0x02036DFC
(To insert this, compile the routine and overwrite the bytes at 0x05A9B4. The compiled size should be 288 (0x120) bytes long. Any larger will overwrite part of the next routine.)

So how does it work? There are a few parts to this. First, the background byte must be set to 0x60, which will trigger the triple layer tile code. Next, we need to select our block which will be the top layer donor. In vanilla Fire Red, block 0xF contains a top layer for trees. Now since we're using only unused bits, we are required to use the following mask for identifying our block:
Code:
00FFC000
Which is basically just 10 bits bitshifted left by 14.

So how can I use this in A-Map? Well, it's a bit complicated. First you need to take your block number (in our case 0xF) and bit shift it left by 14. For us, we get 38000, or if we pad it with 0's to get a full dword, 00038000. Now the trick here is inserting it into A-Map's behavior byte editor properly. As of now, A-Map's byte editor literally just takes the four bytes and gives them textboxes. The problem is, we need to split up our value into the right boxes. This is the current byte order it uses for Fire Red:
Code:
[0][1]
[2][3]
So if we split up our dword by bytes (00 03 80 00), we'll get something like this:
Code:
[00][80]
[03][60]
Now the reason why I put a 60 in there, is because that is what triggers the triple tile. Now obviously your tile might have additional bits set for block behaviors and wild encounters, and the solution to that is to only modify boxes 1 and 2, and the upper half of box 3 (which we replace with a 6).

With that set, you can go ahead and test it in VBA. Here's a sample screen of what you can do using this system:

As you can see, you have the ground underneath the fence, the fence itself, and a tree above both. This system is especially useful for trees in particular because it allows you to have more dynamic environments with better looking trees without having to sacrifice additional tiles in your tileset.

Comments, questions, and concerns are welcome. Also, it should be noted that this system will be implemented in MEH along with a proper inserter. This is just a thread explaining how it works. Also, (before someone asks), this system will not be ported to RSE due to the fact that RSE only has two bytes available for behaviors/backgrounds, which only gives us 4 out of the 10 needed bits for this system. So it's not a hate/time issue, but in fact an incapability without severely breaking existing tools. If there's enough support however, I *might* be able to implement something which expands the behavior bytes and is compatible with MEH. But it's very unlikely.
__________________



Reply With Quote
  #2    
Old June 3rd, 2014 (05:58 AM).
Kenny1's Avatar
Kenny1 Kenny1 is offline
On a break from Rom hacking, to improve other skills.
 
Join Date: Nov 2013
Gender: Male
Posts: 85
Great work Shiny Quagsire, I have seen a video about it, but with no tutorial or anything like research, so I am glad you posted this, it is a relly nice feature, that will help with those pesky tiles that need too many layers, so I believe it will help many people, also the implementation of it into MEH is a great thing.

I only have one question though:
Are there any bugs related to this?
__________________
Currently working on ASM. Thank you to Almarto, for teaching me the basics of ASM, and everyone else who posts ASM routines and tutorials.
Reply With Quote
  #3    
Old June 3rd, 2014 (06:22 AM).
Cheve_X's Avatar
Cheve_X Cheve_X is offline
 
Join Date: Dec 2010
Location: Argentina
Gender: Male
Posts: 18
Haha! You did it again xD

Nice piece of ASM... Another great step forward :3
Congratulations!
__________________
Free Your Spirit!






Reply With Quote
  #4    
Old June 3rd, 2014 (09:02 AM).
Jaizu's Avatar
Jaizu Jaizu is offline
Spanish Rom Hacker
 
Join Date: Jan 2010
Location: Spain
Gender: Male
Posts: 48
Realy awesome, I hope that can be a common "tool" to use on hacks soon :D
__________________
Reply With Quote
  #5    
Old June 3rd, 2014 (09:35 AM).
Lost Heart's Avatar
Lost Heart Lost Heart is online now
the better journalist
Crystal Tier
 
Join Date: Mar 2010
Age: 18
Gender: Other
Nature: Impish
Posts: 2,112
This is great! I really like what you did here.
I've always wanted something like this to be released.

It'd pretty cool of you if you implemented an RSE version, too.
__________________
Reply With Quote
  #6    
Old June 3rd, 2014 (10:18 AM).
Shiny Quagsire's Avatar
Shiny Quagsire Shiny Quagsire is offline
Double Agent for Team Johto
 
Join Date: May 2009
Location: Hoenn Safari Zone
Age: 17
Gender: Male
Nature: Jolly
Posts: 691
Quote originally posted by Kenny1:
Great work Shiny Quagsire, I have seen a video about it, but with no tutorial or anything like research, so I am glad you posted this, it is a relly nice feature, that will help with those pesky tiles that need too many layers, so I believe it will help many people, also the implementation of it into MEH is a great thing.

I only have one question though:
Are there any bugs related to this?
As of now, there are no bugs known. You might get some weirdness going on if you try to reference a block outside of the scope of the second tileset though, but that's to be expected. Although I nearly released this earlier before realizing that if you referenced a tile in the secondary blockset it would be pulling from the wrong source, but I fixed it just in time.

Quote originally posted by Cheve_X:
Haha! You did it again xD

Nice piece of ASM... Another great step forward :3
Congratulations!
Thanks!

Quote originally posted by jaizu:
Realy awesome, I hope that can be a common "tool" to use on hacks soon :D
I myself hope to see triple tiles used more, they really add a lot to a hack in terms of aesthetics.

Quote originally posted by itari:
This is great! I really like what you did here.
I've always wanted something like this to be released.

It'd pretty cool of you if you implemented an RSE version, too.
Thanks. In terms of an RSE version, I'm still unsure of how to go about implementing something properly. One option might be to replace the first block's behavior with a pointer to another table which will give us as much space as we need. Of course this is assuming that the hack applied to leaves the first block untouched (ie just black), otherwise it would cause a few issues. I definitely want to have some sort of implementation in Emerald though, because it would be a shame for this to be Fire Red only.
__________________



Reply With Quote
  #7    
Old June 3rd, 2014 (10:23 AM).
Lost Heart's Avatar
Lost Heart Lost Heart is online now
the better journalist
Crystal Tier
 
Join Date: Mar 2010
Age: 18
Gender: Other
Nature: Impish
Posts: 2,112
Well, one way you could do it would be your table idea. Like, you set the behavior byte to a specific value, doesn't matter what, and then it checks a table. If the table contains a matching entry (block id, third tile?) then it would know to substitute. If not in the table, it is treated like a normal block.
__________________
Reply With Quote
  #8    
Old January 12th, 2015 (02:51 AM).
Lance32497's Avatar
Lance32497 Lance32497 is offline
LanceKoijer of Pokemon_Addicts
 
Join Date: Aug 2014
Location: Criscanto town-Ginoa Region xD
Gender: Male
Nature: Adamant
Posts: 579
I hope Lu-Ho will add this in his A-Map
nice research (y)
__________________
My Threads

Reply With Quote
  #9    
Old January 12th, 2015 (04:05 AM).
Bill Cipher's Avatar
Bill Cipher Bill Cipher is offline
Call me Fuxydia~!
 
Join Date: Aug 2014
Gender: Female
Posts: 167
Quote originally posted by Lance32497:
I hope Lu-Ho will add this in his A-Map
nice research (y)
I doubt Advance Map will ever be updated again, but I'm pretty sure this is coming to (MEH).
__________________

いいえエンディングまで泣くん...
Reply With Quote
  #10    
Old January 12th, 2015 (04:15 AM).
Lance32497's Avatar
Lance32497 Lance32497 is offline
LanceKoijer of Pokemon_Addicts
 
Join Date: Aug 2014
Location: Criscanto town-Ginoa Region xD
Gender: Male
Nature: Adamant
Posts: 579
Quote originally posted by .//HackZoroark//.:
I doubt Advance Map will ever be updated again, but I'm pretty sure this is coming to (MEH).
ahhh, it would be great if Lu-Ho'll apply that in his newest A-Map Version
__________________
My Threads

Reply With Quote
  #11    
Old January 12th, 2015 (04:19 AM).
Bill Cipher's Avatar
Bill Cipher Bill Cipher is offline
Call me Fuxydia~!
 
Join Date: Aug 2014
Gender: Female
Posts: 167
Quote originally posted by Lance32497:
ahhh, it would be great if Lu-Ho'll apply that in his newest A-Map Version
Lu-Ho hasn't been on PC in almost a year, and he also states in his sig, that he's "no longer active in ROM Hacking".
Which is why I have my doubts of a Advance Map 1.93/2.0
__________________

いいえエンディングまで泣くん...
Reply With Quote
  #12    
Old January 12th, 2015 (04:24 AM).
Lance32497's Avatar
Lance32497 Lance32497 is offline
LanceKoijer of Pokemon_Addicts
 
Join Date: Aug 2014
Location: Criscanto town-Ginoa Region xD
Gender: Male
Nature: Adamant
Posts: 579
Quote originally posted by .//HackZoroark//.:
Lu-Ho hasn't been on PC in almost a year, and he also states in his sig, that he's "no longer active in ROM Hacking".
Which is why I have my doubts of a Advance Map 1.93/2.0
awww, since theres no assurance of A-Map new version, I am forced to apply this hack manually, but its ok, the harder the better
__________________
My Threads

Reply With Quote
  #13    
Old January 12th, 2015 (04:25 AM).
Bill Cipher's Avatar
Bill Cipher Bill Cipher is offline
Call me Fuxydia~!
 
Join Date: Aug 2014
Gender: Female
Posts: 167
Quote originally posted by Lance32497:
awww, since theres no assurance of A-Map new version, I am forced to apply this hack manually, but its ok, the harder the better
Look at it this way, you might learn a thing or two, doing it the hard way. Instead of having a tool do it for you.
__________________

いいえエンディングまで泣くん...
Reply With Quote
  #14    
Old January 12th, 2015 (03:34 PM).
Shiny Quagsire's Avatar
Shiny Quagsire Shiny Quagsire is offline
Double Agent for Team Johto
 
Join Date: May 2009
Location: Hoenn Safari Zone
Age: 17
Gender: Male
Nature: Jolly
Posts: 691
Quote originally posted by .//HackZoroark//.:
Look at it this way, you might learn a thing or two, doing it the hard way. Instead of having a tool do it for you.
Eh, on the bright side this is one of the few things integrated into MEH. The tool can actually patch it in (although I believe you don't have as much choice in how it's inserted iirc), and the block editor handles previews and editing just fine.
__________________



Reply With Quote
  #15    
Old June 28th, 2015 (07:45 PM).
Lance32497's Avatar
Lance32497 Lance32497 is offline
LanceKoijer of Pokemon_Addicts
 
Join Date: Aug 2014
Location: Criscanto town-Ginoa Region xD
Gender: Male
Nature: Adamant
Posts: 579
Quote originally posted by Shiny Quagsire:
Eh, on the bright side this is one of the few things integrated into MEH. The tool can actually patch it in (although I believe you don't have as much choice in how it's inserted iirc), and the block editor handles previews and editing just fine.
Hey, what if I want to make it "Block is covered by hero"?
__________________
My Threads

Reply With Quote
  #16    
Old July 4th, 2015 (09:07 PM).
Shiny Quagsire's Avatar
Shiny Quagsire Shiny Quagsire is offline
Double Agent for Team Johto
 
Join Date: May 2009
Location: Hoenn Safari Zone
Age: 17
Gender: Male
Nature: Jolly
Posts: 691
Quote originally posted by Lance32497:
Hey, what if I want to make it "Block is covered by hero"?
Er, that kinda defeats the point. Two layers will always be under the player, one will always be on top. That's how the BGs are sorted by default.
__________________



Reply With Quote
  #17    
Old July 5th, 2015 (12:59 AM).
kearnseyboy6's Avatar
kearnseyboy6 kearnseyboy6 is offline
Aussie's Toughest Mudder
 
Join Date: Dec 2008
Posts: 294
Quote originally posted by Lance32497:
Hey, what if I want to make it "Block is covered by hero"?
That doesn't make sense. You either have it set as 0x20 block covered by hero, or 0x60 which activates the hack.
__________________
HOLIDAYING CURRENTLY!!
Reply With Quote
  #18    
Old July 5th, 2015 (01:17 AM).
Lance32497's Avatar
Lance32497 Lance32497 is offline
LanceKoijer of Pokemon_Addicts
 
Join Date: Aug 2014
Location: Criscanto town-Ginoa Region xD
Gender: Male
Nature: Adamant
Posts: 579
Quote originally posted by kearnseyboy6:
That doesn't make sense. You either have it set as 0x20 block covered by hero, or 0x60 which activates the hack.
Yah, I know that, I just want to confirm it is possible or not
__________________
My Threads

Reply With Quote
Reply
Quick Reply

Sponsored Links

You may also like.. (Beta)
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are UTC -8. The time now is 07:24 PM.