[ASM & Hex] Table Reading Delay

[Lance Koijer 2.0]

Hello huys, just a quick question.

What is more convenient to use when reading a massive table of entries? ASM or Battle Script(I am using a jumpifbyte command which I think makes the reading too long)

My idea is just to create a table of an 8-byte-long entry and make a table checking using ASM... Would it give long delays just like the byte-reading in battle script? 'cuz the table I will be creating is more or less 64 (in hex).

 

[Blah]

Hello huys, just a quick question.

What is more convenient to use when reading a massive table of entries? ASM or Battle Script(I am using a jumpifbyte command which I think makes the reading too long)

My idea is just to create a table of an 8-byte-long entry and make a table checking using ASM... Would it give long delays just like the byte-reading in battle script? 'cuz the table I will be creating is more or less 64 (in hex).

rethink your algorithm to allow constant time. Tables are arrays, think of searching like:
moves[pokemon][level]

 

[Lance Koijer 2.0]

rethink your algorithm to allow constant time. Tables are arrays, think of searching like:
moves[pokemon][level]

I know now what each entry would look like...

It's
[2 bytes for Move ID] [2 reserved bytes 0x00] [Pointer to script] terminated by 0xFFFFFFFF of course
I mean in my question is, is doing this in ASM will not induce long delays because the table that I will be making is massive? (it will, more or less, occupy half an MB.)
Because when I tried jumpifbyte in battle script and there are actually hundreds of jumps, the byte-checking causes a long delay.

 

[Blah]

I know now what each entry would look like...

It's
[2 bytes for Move ID] [2 reserved bytes 0x00] [Pointer to script] terminated by 0xFFFFFFFF of course
I mean in my question is, is doing this in ASM will not induce long delays because the table that I will be making is massive? (it will, more or less, occupy half an MB.)
Because when I tried jumpifbyte in battle script and there are actually hundreds of jumps, the byte-checking causes a long delay.

ASM would be faster, yes. But it'll still be relatively slow to loop through the entire table in comparison to just a look up. Can you elaborate more on what it is this table is for, and what you're trying to implement?

 

[Lance Koijer 2.0]

ASM would be faster, yes. But it'll still be relatively slow to loop through the entire table in comparison to just a look up. Can you elaborate more on what it is this table is for, and what you're trying to implement?

I've used the unused byte of Move Data and used it for checking.... once that byte is found and matches to the byte required for the process... it will go to another table of Battle Script (Which I found out now how to execute Battle Script in a routine)

 

[Blah]

I've used the unused byte of Move Data and used it for checking.... once that byte is found and matches to the byte required for the process... it will go to another table of Battle Script (Which I found out now how to execute Battle Script in a routine)

Are you trying to make Z moves?

Regardless, if your table is indexed in move id order, you can try to just do move_table[id] and zmove_behaviours[id] kind of thing.

 

[Lance Koijer 2.0]

Are you trying to make Z moves?

Regardless, if your table is indexed in move id order, you can try to just do move_table[id] and zmove_behaviours[id] kind of thing.

Yes I am.. and I managed to make a Z-move-ish implementation... however, it's kind of not satisfyig me because it just uses a massive jumpifhalword commands which makes the execution a bit of delayed so what I explained before is kind of stupid.. I realized I just have to use the unused byte in Move Data and use it as a Battle Script ID to a table that contains the battle script of all moves and then execute it... I sent you a PM already. I've created an ASM and it makes something odd.