Yvtq8K3n

I will probably have a few ideas, but like I said I haven't had time to look at it

Ok. Well I do think there are many updates to come as there are still minimal features

What about advanced tile ripper?
This tool allows you to extract tiles with ease, as oppose to doing it by hand. Still in beta mode with many updates to come.

It's all up to you, I dont have any suggestions

Sorry that I haven't had time to look at the tool. I would say to just examine it once more and look for any bugs, and then go ahead and release it. From what I did see though, it looks like an awesome tool and im sure people will love it. Thanks for making it!

yes, it should be bigger in case they only want some of the tiles from the image they upload

Sorry, I've been super busy with school so I haven't had any time to look at it.. One thing I did notice was that it didn't support .PNG files which was a bit of an inconvenience.. It'd be good to add support for that if you can. Other than that it looks good for now, but as I said I havent really tested it haha. I'll test it soon though and will let you know :)

I remenber everything now.

What is happening xd.

Hmm, I mentioned a possibility of using a bit field and lookup table in conjunction. Basically if we have this list:
[1, 3, 4, 6, 10]

we will make this bitfield:

[1, 0, 1, 1, 0, 1, 0, 0, 0, 1]. This bitfield, "1011010001" = 721. In the look up table, you'd have n! entries, where each entry is a possible value for the bit field. As you can guess this is growing very large very fast, so it's not very good either. Anyways, from the look up table, we'll have an entry like this:

struct table_entry {
u32 value;
int x[];
};

then we do something like

list = []
for (int n : x) {
for (int i = 0; i < original_list[n's position]; i++) {
list.append(n);
}
}
return list;

---

I don't think even this is a very good idea. It's speed is linear and depending on the length of the list, BUT, it's requiring a lookup table. Look up tables take space and this look up table would grow fast.

Yooo

So i checked it and i think that i understand it
Every map has a different amount of blocks?
So u can only change the blocks to the map that u have

Oke will try it first thanks!

Hey, I added your tool to my website(the link redirects to your thread)
Hope you don't mind about it. You can find your tool in my website right here!
Thanks and good luck with future versions of your tool <3

oooh, I see what you mean, I can help you with that!

The general concept here is that you want to insert your image pixel by pixel inside the rom.

Before I continue here are two things to note:

1) The gba works with indexed images (16 colors with a transparent one). That means that each image has a 16-color palette and each pixel is represented by a number from 0-15 witch tells the game the color of that pixel, based on the palette. For ex. if the top left pixel is the pixel (0,0) and has the value 3, it means that this pixels color is the 4th in the palette.

2) In one byte you can put the color information of 2 pixels. A pixel consists of two nibbles and each nibble can take a value from 0-F. So for ex. byte 0x2A has the color information of two pixels. The first one's color is the 3rd and the second pixels the 11th color of the palette.

3) The roms generally work with 8x8 tiles. That means that a 64x64 image has 8x8 tiles. So if you want to insert a 64x64 image you'd have to first import the first 8x8 tile, then the second 8x8 to the right etc and when you import the first 8 tiles you'd import the second row of 8x8 tiles etc until you import all the tiles. Also note that when importing an 8x8 tile you first import the first 8 pixels of the first row of the tile, then the next 8 pixels of the second row etc until the 8th row.

Thats in a nutshell how it works. On what language did you write your tool?

What do you mean by "change the offset in order to load a new sprite"? Is the offset in the rom?