You are not logged in.
Pages: 1
I see an tutorial in PC talking about how to make the hero walk in 8 directions.
I want to ask if there a way to do it in pokemon GSC.
If someone know, post please, it will make the game seen like Zelda.
BTW thnx.
Last edited by RaltVus (2013-10-31 00:17:27)
RaltVus is back.
I'm not hacking in the moment, but i always had ideas to give. Just ask me if you want.
Offline
Doesn't the hero already walks in 4 directions? Or do you mean to let the hero walk in any direction without the tile system?
Hacks Gameboy 8-bit music in Pokémon Gen I & II, composes 8-bit music in LSDJ and FamiTracker.
“God created the Earth, but the Dutch created the Netherlands.”
Offline
Doesn't the hero already walks in 4 directions? Or do you mean to let the hero walk in any direction without the tile system?
oh sorry for the mistake TMOTW, i edit i mean 8 direction.
RaltVus is back.
I'm not hacking in the moment, but i always had ideas to give. Just ask me if you want.
Offline
You mean like diagonally, too? I'm sure if Nintendo could implement moving diagonally, they would have in the first 5 gens. You would need some sort of magic ASM skills to accomplish this.
Offline
Thnx for the diagonally i forgot to mention that.
And, you think it is hard to do jastolze?
RaltVus is back.
I'm not hacking in the moment, but i always had ideas to give. Just ask me if you want.
Offline
I believe it's not even possible. And what I mean by this is that hardware wouldn't support such a hack.
If it's so that only one button can be pressed down at a time, not a chance.
Offline
I thought multiple buttons could be pressed down to call another code than if you press ONE of these two buttons. And as seen this is also done in Zelda for the Game Boy, it should be possible with nearly impossible skills of ASM hacking.
Hacks Gameboy 8-bit music in Pokémon Gen I & II, composes 8-bit music in LSDJ and FamiTracker.
“God created the Earth, but the Dutch created the Netherlands.”
Offline
Hmmm Miksy91 and TMOTW, i'll search more to see what i can find.
RaltVus is back.
I'm not hacking in the moment, but i always had ideas to give. Just ask me if you want.
Offline
It's of course possible and not that hard to do from scratch -- but hacking it into the existing system is going to be a pain, because collision is based on block quarters and not on absolute pixel values, so there will have to be a lot more statefulness in collision detection, because right now events just occupy two block quarters at the same time all the time. Usually, these two point to the same block quarter. However, while moving, they occupy neighboring block quarters. You would obviously have to redo this so it's pixel precise.
Even more will be involved if event positions are to be placed at pixel resolution... Also, you will have to edit all scripts that involve movement, because obviously you would need to move events pixel-wise now or compromise that scripts can only move events quarter block wise.
So it's IMHO a lot more trouble than it's worth, but it can definitely be done.
cYa,
Tauwasser
Offline
@tauwasser
thnx for the answer, i can tell that i'm not a master like you in script but may i try!!!
And, i ask this to see if someone already try and could (or not) do that.
RaltVus is back.
I'm not hacking in the moment, but i always had ideas to give. Just ask me if you want.
Offline
It's of course possible and not that hard to do from scratch -- but hacking it into the existing system is going to be a pain, because collision is based on block quarters and not on absolute pixel values, so there will have to be a lot more statefulness in collision detection, because right now events just occupy two block quarters at the same time all the time. Usually, these two point to the same block quarter. However, while moving, they occupy neighboring block quarters. You would obviously have to redo this so it's pixel precise.
Even more will be involved if event positions are to be placed at pixel resolution... Also, you will have to edit all scripts that involve movement, because obviously you would need to move events pixel-wise now or compromise that scripts can only move events quarter block wise.So it's IMHO a lot more trouble than it's worth, but it can definitely be done.
cYa,
Tauwasser
Do games like Zelda GB really have pixel precise collisions? I thought more likely about tile maps existing out of 1/8-block triangles..
Hacks Gameboy 8-bit music in Pokémon Gen I & II, composes 8-bit music in LSDJ and FamiTracker.
“God created the Earth, but the Dutch created the Netherlands.”
Offline
Do games like Zelda GB really have pixel precise collisions? I thought more likely about tile maps existing out of 1/8-block triangles..
I actually don't know, I just assumed that to be the case, because that's the way it seems when fighting or entering holes, doors etc.
cYa,
Tauwasser
Offline
I agree that this whole idea would be more trouble than it's worth, but I have some thoughts about implementing diagonal movement. First of all, non-grid-like movement in Pokemon is heresy! :P More seriously though, it would be much simpler to extend the current "tile-based" collision system. It seems logical to me that a player would only be able to move diagonally if the two horizontally-adjacent tiles were also open. Here's a quick diagram of the current map state around the player: (# is player; 0 is open tile; 1 is solid tile)
100
1#0
010
In this case, the player would only be able to move up, up-right, right, and down-right.
Here's another case to demonstrate my proposal:
010
0#0
010
The player would NOT be able to move diagonally in any direction be there is a solid adjacent tile to every corner.
Of course, you would also need to create some diagonal-movement overworld sprites!
Anyway, those were some of my thoughts, and I think that using tile-based collision would be much more feasible and appropriate if someone were to ever do something like this.
Definitely doable, though, like Tauwasser mentioned.
My hacks: Pokémon Maize, Pokémon Red: Battle Factory
Offline
Pages: 1