AGIXP sprite curruption glitchy problem

folaip · 2012-12-13 07:22:40

Hey, I've been using agixp to insert some sprites... I mean A LOT of sprites into pokemon silver, for my pokemon b/w devamp.
I've gotten a fair way, and have made backups. But now there's a problem, every now and then, I will reach a point where I can't insert any more sprites, for it will end up becoming glitched and warped in battle, like so

http://img145.imageshack.us/img145/7703/helpplease.png

is there something I've done wrong along the way? I've reached up to galvantula with out a problem. does anyone know how to fix this? I f so I will happily provide a rom download link.

delpo · 2012-12-13 07:35:39

Are you sure that particular pokemon's graphic is the right size and not too big? If the dimensions are not perfect, the graphic will not display correctly.

folaip · 2012-12-13 07:41:01

delpo wrote:

Are you sure that particular pokemon's graphic is the right size and not too big? If the dimensions are not perfect, the graphic will not display correctly.

yep, I know to make them the right size. this seemed to happen after I inserted quite a few sprites...... this problem makes it so, I can't insert anymore sprites without this glitchyness happening.

folaip · 2012-12-13 07:52:37

folaip wrote:

delpo wrote:
Are you sure that particular pokemon's graphic is the right size and not too big? If the dimensions are not perfect, the graphic will not display correctly.
yep, I know to make them the right size. this seemed to happen after I inserted quite a few sprites...... this problem makes it so, I can't insert anymore sprites without this glitchyness happening.

also, on an additional not, when I re-open the corrupt sprite in agixp, the size is all wrong, being sizes lin 64x64 or 80x80, even though the file I inserted was, lets say, 48x48

GeminiRage · 2012-12-13 10:01:00

AgiXP's auto-pointer seems to break after a certain number of insertions (It was one of the first major issues I ran into when developing Touhoumon). It usually doesn't bother too many hackers who usually just change few species or sprites, but for hacks that replace more than half a pokedex like you're doing, this bug creeps it way up.

My advice, start doing manual repointing from now on. Look for some blocks of freespace in your ROM (any large space of 00 bytes in your hex editor), or overwrite some of the original image locations to save space. Whatever you do, make sure you are manually designating the hex addresses for your sprites insertions by typing &H______ (fill in the blank with the hex address) in that field when it shows up.

folaip · 2012-12-13 18:40:25

GeminiRage wrote:

AgiXP's auto-pointer seems to break after a certain number of insertions (It was one of the first major issues I ran into when developing Touhoumon). It usually doesn't bother too many hackers who usually just change few species or sprites, but for hacks that replace more than half a pokedex like you're doing, this bug creeps it way up.
My advice, start doing manual repointing from now on. Look for some blocks of freespace in your ROM (any large space of 00 bytes in your hex editor), or overwrite some of the original image locations to save space. Whatever you do, make sure you are manually designating the hex addresses for your sprites insertions by typing &H______ (fill in the blank with the hex address) in that field when it shows up.

Ok, it's great someone know the direct problem. so, I've not done very much hex editing. in fact none at all, I'm more the art director of this project. so I've pretty much been using tools, except for people that have helped with map connecting. So that overriding tip you gave. does that mean to go delete unnecessary pokemon image information? if so, I do have a hex editor that I really barely know how to use, so if I'm giving the offset, and what to exactly to delete I would do so.

GeminiRage · 2012-12-13 19:33:06

folaip wrote:

GeminiRage wrote:
AgiXP's auto-pointer seems to break after a certain number of insertions (It was one of the first major issues I ran into when developing Touhoumon). It usually doesn't bother too many hackers who usually just change few species or sprites, but for hacks that replace more than half a pokedex like you're doing, this bug creeps it way up.
My advice, start doing manual repointing from now on. Look for some blocks of freespace in your ROM (any large space of 00 bytes in your hex editor), or overwrite some of the original image locations to save space. Whatever you do, make sure you are manually designating the hex addresses for your sprites insertions by typing &H______ (fill in the blank with the hex address) in that field when it shows up.
Ok, it's great someone know the direct problem. so, I've not done very much hex editing. in fact none at all, I'm more the art director of this project. so I've pretty much been using tools, except for people that have helped with map connecting. So that overriding tip you gave. does that mean to go delete unnecessary pokemon image information? if so, I do have a hex editor that I really barely know how to use, so if I'm giving the offset, and what to exactly to delete I would do so.

You can do that, OR just find some freespace blocks in the ROM. I just did the former because I didn't want to insert my pics all over the place in the ROM (I would still recommend recording the locations you saved them to either way.)

Also just noticed you're using a Silver ROM, which makes it very convenient for me to link the original sprite locations stag019 generated (he has a gold version list too, but I only copied the silver version link)

http://www.romendo.net/stag019/pokedex/test2.php

Miksy91 · 2012-12-13 19:45:06

folaip wrote:

Ok, it's great someone know the direct problem. so, I've not done very much hex editing. in fact none at all, I'm more the art director of this project. so I've pretty much been using tools, except for people that have helped with map connecting. So that overriding tip you gave. does that mean to go delete unnecessary pokemon image information? if so, I do have a hex editor that I really barely know how to use, so if I'm giving the offset, and what to exactly to delete I would do so.

You should be repointing data from now on. Everything has its own "place" inside the rom. For example, if you wanted to change the front sprite of Sentret to that of Zigzagoon for instance and used AgiXp to do it, this is what would happen inside the rom:

The program (AgiXp) would locate the pointer that determines where Sentret's image (front sprite) is stored ("one way or another" (well, I do know this could work but it's not important so I won't confuse you more with it), the programmer of AgiXp has made the program to do that). This pointer consists of 3 bytes which tell where the sprite of Sentret's front sprite is located (you can find tutorials about repointing in Gameboy/Cross gen section, they will explain how these pointers work).

While inserting the image of Zigzagoon with AgiXp, you can either choose the address where you want to insert that image or you can let AgiXp manually choose an address where there is free space for inserting that new image. Let's assume you let AgiXp to choose the offset itself. Now, AgiXp checks for free space to insert the new image in, once it finds a "good place" for it, it picks up the offset of this free space, and calculates a pointer leading to this offset. Finally, it simply replaces the original pointer (which lead to image of Sentret) with this new pointer (leading to the rom area where the program decided to insert Zigzagoon's image in).

Last edited by Miksy91 (2012-12-13 19:49:28)

folaip · 2012-12-13 19:58:02

Miksy91 wrote:

folaip wrote:
Ok, it's great someone know the direct problem. so, I've not done very much hex editing. in fact none at all, I'm more the art director of this project. so I've pretty much been using tools, except for people that have helped with map connecting. So that overriding tip you gave. does that mean to go delete unnecessary pokemon image information? if so, I do have a hex editor that I really barely know how to use, so if I'm giving the offset, and what to exactly to delete I would do so.
You should be repointing data from now on. Everything has its own "place" inside the rom. For example, if you wanted to change the front sprite of Sentret to that of Zigzagoon for instance and used AgiXp to do it, this is what would happen inside the rom:
The program (AgiXp) would locate the pointer that determines where Sentret's image (front sprite) is stored ("one way or another" (well, I do know this could work but it's not important so I won't confuse you more with it), the programmer of AgiXp has made the program to do that). This pointer consists of 3 bytes which tell where the sprite of Sentret's front sprite is located (you can find tutorials about repointing in Gameboy/Cross gen section, they will explain how these pointers work).
While inserting the image of Zigzagoon with AgiXp, you can either choose the address where you want to insert that image or you can let AgiXp manually choose an address where there is free space for inserting that new image. Let's assume you let AgiXp to choose the offset itself. Now, AgiXp checks for free space to insert the new image in, once it finds a "good place" for it, it picks up the offset of this free space, and calculates a pointer leading to this offset. Finally, it simply replaces the original pointer (which lead to image of Sentret) with this new pointer (leading to the rom area where the program decided to insert Zigzagoon's image in).

ok, seeing I know nothing about hex editing, I tell agixp to save the image at an offset that has free space. Then... I really don't know how to repoint it to make, let's say slowbrow use the stunfisk image I just inserted.

folaip · 2012-12-13 20:22:20

folaip wrote:

Miksy91 wrote:
folaip wrote:
Ok, it's great someone know the direct problem. so, I've not done very much hex editing. in fact none at all, I'm more the art director of this project. so I've pretty much been using tools, except for people that have helped with map connecting. So that overriding tip you gave. does that mean to go delete unnecessary pokemon image information? if so, I do have a hex editor that I really barely know how to use, so if I'm giving the offset, and what to exactly to delete I would do so.
You should be repointing data from now on. Everything has its own "place" inside the rom. For example, if you wanted to change the front sprite of Sentret to that of Zigzagoon for instance and used AgiXp to do it, this is what would happen inside the rom:
The program (AgiXp) would locate the pointer that determines where Sentret's image (front sprite) is stored ("one way or another" (well, I do know this could work but it's not important so I won't confuse you more with it), the programmer of AgiXp has made the program to do that). This pointer consists of 3 bytes which tell where the sprite of Sentret's front sprite is located (you can find tutorials about repointing in Gameboy/Cross gen section, they will explain how these pointers work).
While inserting the image of Zigzagoon with AgiXp, you can either choose the address where you want to insert that image or you can let AgiXp manually choose an address where there is free space for inserting that new image. Let's assume you let AgiXp to choose the offset itself. Now, AgiXp checks for free space to insert the new image in, once it finds a "good place" for it, it picks up the offset of this free space, and calculates a pointer leading to this offset. Finally, it simply replaces the original pointer (which lead to image of Sentret) with this new pointer (leading to the rom area where the program decided to insert Zigzagoon's image in).
ok, seeing I know nothing about hex editing, I tell agixp to save the image at an offset that has free space. Then... I really don't know how to repoint it to make, let's say slowbrow use the stunfisk image I just inserted.

It really help if someone who knows how could do this. I am no hex editor, specialty for this hack is the artistic side of it. There's about 30-something sprites that need to be still added.

comet · 2012-12-13 20:24:56

so how pokemon looks up things is using a table with an entry for each graphic. each entry has 3 bytes:

the first is the bank the data is in. the game boy can only have a couple chunks of the rom open at a time. these chunks are called banks. they're $4000 bytes long so to get to the right bank you multiply the bank # by $4000

the next 2 are the address the data is at in ram. there are only 2 banks open at a time, bank 0 and another of your choice. this means only the switchable bank is going to contain the graphics data. this bank is accessed from $4000-7fff ($4000 bytes long, the entire bank), so the address is going to be somewhere between those values

the address is typically stored in reverse. since it uses 2 bytes, they can be swapped around so the lower byte is read first. so an address $4075 would look like 75 40 in a hex editor

these conventions are not inherent to the hardware or even the game, multiple arrangements are used depending on how the programmer felt like doing it at the time

so what this means is if you have an address it just has to be converted to this format:

get out windows calculator (win key -> type 'calc.exe') and switch to programmer mode (under view, or alt+3). you can switch between hex and decimal at will and there's a nice view of the binary representation too

so for the hero backsprite from http://www.romendo.net/stag019/pokedex/test2.php the address is $3f9cb

to get the bank we divide by $4000. $3f9cb / $4000 = $f, so the sprite is in bank f (15)

the ram address is trickier at a glance. you can subtract $f*$4000 (=$3c000) from the address (=$39cb) and add another $4000 (=$79cb)

or you can type in the address, '&' then 7fff. the result is the same

so the resulting entry would look like 0f cb 79

to convert back, you add the ram address & 3fff (39cb) to the bank * 4000 (bank f -> 3c000) -> 3f9cb

Last edited by comet (2012-12-13 20:27:23)

folaip · 2012-12-13 20:40:56

comet wrote:

so how pokemon looks up things is using a table with an entry for each graphic. each entry has 3 bytes:
the first is the bank the data is in. the game boy can only have a couple chunks of the rom open at a time. these chunks are called banks. they're $4000 bytes long so to get to the right bank you multiply the bank # by $4000
the next 2 are the address the data is at in ram. there are only 2 banks open at a time, bank 0 and another of your choice. this means only the switchable bank is going to contain the graphics data. this bank is accessed from $4000-7fff ($4000 bytes long, the entire bank), so the address is going to be somewhere between those values
the address is typically stored in reverse. since it uses 2 bytes, they can be swapped around so the lower byte is read first. so an address $4075 would look like 75 40 in a hex editor
these conventions are not inherent to the hardware or even the game, multiple arrangements are used depending on how the programmer felt like doing it at the time

so what this means is if you have an address it just has to be converted to this format:
get out windows calculator (win key -> type 'calc.exe') and switch to programmer mode (under view, or alt+3). you can switch between hex and decimal at will and there's a nice view of the binary representation too
so for the hero backsprite from http://www.romendo.net/stag019/pokedex/test2.php the address is $3f9cb
to get the bank we divide by $4000. $3f9cb / $4000 = $f, so the sprite is in bank f (15)
the ram address is trickier at a glance. you can subtract $f*$4000 (=$3c000) from the address (=$39cb) and add another $4000 (=$79cb)
or you can type in the address, '&' then 7fff. the result is the same
so the resulting entry would look like 0f cb 79

to convert back, you add the ram address & 3fff (39cb) to the bank * 4000 (bank f -> 3c000) -> 3f9cb

.............................................I have no idea what you are talking about there. As I said, I have no knowledge of hex editing. what I really need is for someone now to help by manually inserting and re-pointing the sprites for us. I can upload the rom with all the front sprites up to chandelure, and all the the sprite.bmp and what pokemon number they replace.

comet · 2012-12-13 20:44:38

what is it that you're confused about? ask away

folaip · 2012-12-13 20:47:07

comet wrote:

what is it that you're confused about? ask away

I'm confused by the fact I don't know anything to do with hex editing, so these words are foreign to me. I am the director/art director, I don't have anything to do with hex editing, which is why I would be grateful if someone were to do this for me.

comet · 2012-12-13 20:50:07

what words are you stuck on? don't worry about supposed-tos.

Miksy91 · 2012-12-13 21:01:53

folaip wrote:

comet wrote:
what is it that you're confused about? ask away
I'm confused by the fact I don't know anything to do with hex editing, so these words are foreign to me. I am the director/art director, I don't have anything to do with hex editing, which is why I would be grateful if someone were to do this for me.

None of us knew anything about hex editing, programming, ...
when we started. Everyone must start from zero.

Whether you will make this or not depends pretty much only on whether you want to learn to do so or not. Also don't be afraid of seeing digits like A8. Writing digits in hexadecimal is just another way to of presenting numbers.

Read through again what comet wrote there, it shouldn't be that difficult to understand. What you can't pick up of it, ask. That's no way impossible to overcome, even if you aren't good at maths.

Edit:
Those three bytes comet was talking about there are the pointer to (in this case) the image. A byte there "consists of two digits". For example 17 25 62 could be one pointer there, having three bytes in it. The first byte is the "bank" and 25 62 the "address in this bank".
Now these three bytes determine the offset of an image because they point to it.

The offset in this case is (everything in hexadecimal):

17 * 4000 + 6225 - 4000 = 5E225 (check how this works with Windows Calculator).

And that there is how pointers work; first byte is multiplied by 4000 and the next two bytes are switched around 25 62 --> 6225. This 6225 is added to that multiply and decreased by 4000. In this case, the result is 5E225.

Every image that's pointer is set to 17 25 62 looks for the data of that image in offset 5E225.

This explanation is actually very inaccurate but I wanted to try to explain everything as simply as possible.
Hopefully you'll make use of it!

Last edited by Miksy91 (2012-12-13 21:04:04)

folaip · 2012-12-13 21:04:58

comet wrote:

what words are you stuck on? don't worry about supposed-tos.

well, I don't no what byte means, I don't know what bank means. And I'm really quite distant on how and where to even start on manually inserting sprites. would it help if I livestreamed my screen and you walk me through one or 2 sprite insertions, that way I can learn the process. That's the only way I ever got maths at school, by following a set of steps and instructions. when it came to world problems, I failed horribly because it required you to not go by a proccess, but rather use self mathematical thinking.

That's how I've even reached this far in the hack, by watching tutorials and following that process shown.

Miksy91 · 2012-12-13 21:07:32

I've uploaded several video tutorials in youtube. They're linked to the Global FAQ and resource thread.
Once you understands most stuff explained in parts from 1 to (5 ?), you can check what I've explained about pointers in the parts following them.

folaip · 2012-12-13 21:33:32

Miksy91 wrote:

I've uploaded several video tutorials in youtube. They're linked to the Global FAQ and resource thread.
Once you understands most stuff explained in parts from 1 to (5 ?), you can check what I've explained about pointers in the parts following them.

ok, I have a much better Idea, so I coverted a hex location that was free, changed it to decimal and saved stunfisks sprite at that location
on agixp, now when I go to that offset, there's a whole bunch of data. now, what offset does pokemon data start and how do I re-point slowbro to use that stunfisk image I inserted?

folaip · 2012-12-13 21:34:45

folaip wrote:

Miksy91 wrote:
I've uploaded several video tutorials in youtube. They're linked to the Global FAQ and resource thread.
Once you understands most stuff explained in parts from 1 to (5 ?), you can check what I've explained about pointers in the parts following them.
ok, I have a much better Idea, so I coverted a hex location that was free, changed it to decimal and saved stunfisks sprite at that location
on agixp, now when I go to that offset, there's a whole bunch of data. now, what offset does pokemon data start and how do I re-point slowbro to use that stunfisk image I inserted?

I meant to say I have a much better idea of what I'm doing -_-

comet · 2012-12-13 21:42:17

folaip wrote:

well, I don't no what byte means

think of a rom as a stream of data. this is like any other file on your computer. but a computer can't read human numbers

computers function by turning transistors on and off in different combinations. these transistors are represented by digits with 2 values, called bits. we call the off state 0 and the on state 1. so a single bit can be 0 or 1

these bits can be combined to make bigger numbers. this is what's called base 2 (binary).

the counting system we use is base 10 (decimal). this means that every time we move up a place value we count by a factor of 10:

base 10:
   1 ones 10^0
  10 tens 10^1
 100 hundreds 10^2
1000 thousands 10^3
and so on

base 2 is the same way, except we count by a factor of 2. you can think of it like doubling:

base 2:
   1 ones 2^0
  10 twos 2^1
 100 fours 2^2
1000 eights 2^3
and so on

but binary is hard to read even if you're familiar with it. we could use something shorter and more meaningful.

you know how old consoles were called 8-bit? this is because bits were grouped in sets of 8. we call these sets bytes.

with base 10, the max number you can have in a digit is 9, like 99999999. it's the same way with base 2, but the max number is 1, so the most you can have in a byte would look like 11111111.

now think about the purpose of a digit. we need a new one when we run out of numbers. this means the value of 1 in a digit is worth one more than the max value you can have below it. it's also the number of values you can make using the digits below it.

you know 99999999 + 1 is 100000000. with base 2, 11111111 + 1 is 100000000. since there are 8 zeros this value means 2^8 (2*2*2*2*2*2*2*2), 256 in base 10.

so if we can have 256 values, what's the best way to represent it easily? base 10 obviously isn't very useful since it's not how computers read data.

say we want to keep it down to 2 digits. in base 10, if we want to represent 100 values in 2 digits, both of them can be from 0-9 (10 numbers). 10 is the square root of 100, so let's do the same with 256.

the square root of 256 is 16. if we want to keep it down to 2 digits each digit has to be able to use 16 numbers. since we don't have any characters for numbers higher than 9, we use a b c d e f (10 11 12 13 14 15). when we hit 16, we would move to the next digit (10). this is called base 16 (hexadecimal).

so hex is a way to make base 2 readable for us. a byte is just a number viewed differently. you can use 2 bytes together for a 16-bit value (4 digits).

folaip wrote:

I don't know what bank means.

a bank is just how the game boy separates chunks of data in the rom. they're $4000 bytes long.

folaip · 2012-12-13 21:43:17

folaip wrote:

folaip wrote:
Miksy91 wrote:
I've uploaded several video tutorials in youtube. They're linked to the Global FAQ and resource thread.
Once you understands most stuff explained in parts from 1 to (5 ?), you can check what I've explained about pointers in the parts following them.
ok, I have a much better Idea, so I coverted a hex location that was free, changed it to decimal and saved stunfisks sprite at that location
on agixp, now when I go to that offset, there's a whole bunch of data. now, what offset does pokemon data start and how do I re-point slowbro to use that stunfisk image I inserted?
I meant to say I have a much better idea of what I'm doing -_-

HOLY SHIT NIPPLES *sorry for that outburst, but anyway, I manually chose epty offsets for agixp to use, and now everything seems to be working fine..... I hope it will last, but till then, thanks guys!

folaip · 2012-12-13 22:26:30

folaip wrote:

folaip wrote:
folaip wrote:
ok, I have a much better Idea, so I coverted a hex location that was free, changed it to decimal and saved stunfisks sprite at that location
on agixp, now when I go to that offset, there's a whole bunch of data. now, what offset does pokemon data start and how do I re-point slowbro to use that stunfisk image I inserted?
I meant to say I have a much better idea of what I'm doing -_-
HOLY SHIT NIPPLES *sorry for that outburst, but anyway, I manually chose epty offsets for agixp to use, and now everything seems to be working fine..... I hope it will last, but till then, thanks guys!

Question. will I have the same problems when doing the backsprites?

Mateo · 2012-12-13 23:08:34

Backsprites work the same way. If you've figured out front sprites, it will work for backsprites as well.

folaip · 2012-12-13 23:11:58

Mateo wrote:

Backsprites work the same way. If you've figured out front sprites, it will work for backsprites as well.

wait, so I will reach the point again were I must manually insert?

Skeetendo

#1 2012-12-13 07:22:40

AGIXP sprite curruption glitchy problem

#2 2012-12-13 07:35:39

Re: AGIXP sprite curruption glitchy problem

#3 2012-12-13 07:41:01

Re: AGIXP sprite curruption glitchy problem

#4 2012-12-13 07:52:37

Re: AGIXP sprite curruption glitchy problem

#5 2012-12-13 10:01:00

Re: AGIXP sprite curruption glitchy problem

#6 2012-12-13 18:40:25

Re: AGIXP sprite curruption glitchy problem

#7 2012-12-13 19:33:06

Re: AGIXP sprite curruption glitchy problem

#8 2012-12-13 19:45:06

Re: AGIXP sprite curruption glitchy problem

#9 2012-12-13 19:58:02

Re: AGIXP sprite curruption glitchy problem

#10 2012-12-13 20:22:20

Re: AGIXP sprite curruption glitchy problem

#11 2012-12-13 20:24:56

Re: AGIXP sprite curruption glitchy problem

#12 2012-12-13 20:40:56

Re: AGIXP sprite curruption glitchy problem

#13 2012-12-13 20:44:38

Re: AGIXP sprite curruption glitchy problem

#14 2012-12-13 20:47:07

Re: AGIXP sprite curruption glitchy problem

#15 2012-12-13 20:50:07

Re: AGIXP sprite curruption glitchy problem

#16 2012-12-13 21:01:53

Re: AGIXP sprite curruption glitchy problem

#17 2012-12-13 21:04:58

Re: AGIXP sprite curruption glitchy problem

#18 2012-12-13 21:07:32

Re: AGIXP sprite curruption glitchy problem

#19 2012-12-13 21:33:32

Re: AGIXP sprite curruption glitchy problem

#20 2012-12-13 21:34:45

Re: AGIXP sprite curruption glitchy problem

#21 2012-12-13 21:42:17

Re: AGIXP sprite curruption glitchy problem

#22 2012-12-13 21:43:17

Re: AGIXP sprite curruption glitchy problem

#23 2012-12-13 22:26:30

Re: AGIXP sprite curruption glitchy problem

#24 2012-12-13 23:08:34

Re: AGIXP sprite curruption glitchy problem

#25 2012-12-13 23:11:58

Re: AGIXP sprite curruption glitchy problem

Board footer