Don't know why this is happening, EXT_VRAM_ADDR doesn't make a difference

[JappaWakka]

This is the metatile entry:

['Load\PokemonTCG2\BG\CardArt_Header_Pokemon.bmp':CardArt_Header_Pokemon:0] [00lo_f--820b+-a2-a2Ua2Ua2Va2V:CardArt_Header_Pokemon_0:20:0x8E00:0] [00lo_f--000f--03-00Y00o02p02p:CardArt_Header_Pokemon_1:20:0x8E10:0] [00lo_f--000f--03-00V00p02o02o:CardArt_Header_Pokemon_2:20:0x8E20:0] [00lo_f--000f--03-02o00o00V01U:CardArt_Header_Pokemon_3:20:0x8E30:0] [00lo_f--000f--03-00P00N03M00M:CardArt_Header_Pokemon_4:20:0x8E40:0] [00lo_f--000f--03-02s00o00p00p:CardArt_Header_Pokemon_5:20:0x8E50:0] [00lo_f--000f--03-00V00p02o02o:CardArt_Header_Pokemon_6:20:0x8E60:0] [00lo_f--041fTZ0nZ0mt0mt0mt0kt:CardArt_Header_Pokemon_7:20:0x8E70:0] [00lo_a2Ua2Ua2Va2Va2-b+-820f--:CardArt_Header_Pokemon_8:20:0x8E80:0] [00lo_00p00V03U03Y03-f--000f--:CardArt_Header_Pokemon_9:20:0x8E90:0] [00lo_02o02p00p00V03-f--000f--:CardArt_Header_Pokemon_10:20:0x8EA0:0] [00lo_00U00p02o02o03-f--000f--:CardArt_Header_Pokemon_11:20:0x8EB0:0] [00lo_00O03P00P00P03-f--000f--:CardArt_Header_Pokemon_12:20:0x8EC0:0] [00lo_02p02p02o02s03-f--000f--:CardArt_Header_Pokemon_13:20:0x8ED0:0] [00lo_02o02p00p00V03-f--000f--:CardArt_Header_Pokemon_14:20:0x8EE0:0] [00lo_0kt0kt0mt0mt0nZfTZ041f--:CardArt_Header_Pokemon_15:20:0x8EF0:0]

[shonumi]

2 questions I have to ask:

1) What do you expect EXT_VRAM_ADDR to do in this situation?

2) Do you understand how EXT_VRAM_ADDR works on a technical level?

So far, literally everyone that's used EXT_VRAM_ADDR has misused it due to not fully understanding what its purpose is and how it goes about doing its job. I don't know if the manual explained it poorly or if I need to add a visual example in the future or something, but so far no one has used it correctly even though I made it a long time ago at someone's request.

EXT_VRAM_ADDR is only supposed to be used in very limited scenarios, mainly for tiles that are solid colors, and mainly for DMG games with limited palettes. Essentially, if two tiles share the exact same hash (same data in VRAM and same color palette) but that tile exists at multiple VRAM addresses, you can make unique CGFX for each different address.

The reason EXT_VRAM_ADDR does nothing here is due to the fact that there's nothing it can do in this situation. Unless these tiles appear at another VRAM address and you want to give them different CGFX EXT_VRAM_ADDR is not what you want. It really shouldn't be used 99% of the time; it's for an edge case that largely affected DMG games.

[JappaWakka]

It already had the graphical error before I tried ext vram adrr, it seemed to copy a tile from a different location but mirrored in some way.

[shonumi]

Well, the problem is completely unrelated to EXT_VRAM_ADDR, and that option isn't designed to help with the incorrectly rendered tile.

Send me the files you're working on (manifest + bitmaps), so I can take a look.

[JappaWakka]

PokemonTCG2.zip

[shonumi]

Ok, after taking a closer look at what the graphics for the Pokemon card header is doing, this actually is an edge case where EXT_VRAM_ADDR is required for what you want to do. Some of the tiles in the Pokemon card header are the same. Depending on the art style people use, the edited graphics may not match up with the original text, and the original reuses tiles to save on memory. If the edited graphics match up nicely, EXT_VRAM_ADDR isn't necessary, but for your 4x versions it is.

Only a couple of entries needed the EXT_VRAM_ADDR option enabled, but I don't expect people to manually pick-and-choose which entries are necessary (since the GUI for meta-tiles turns it on for every tile anyway). Just be careful in the future since it can lead to unintended results if EXT_VRAM_ADDR is not narrowly applied (e.g. not a good idea to use it everywhere).

Anyway, the issue was that GBE+ wasn't fully parsing the specified VRAM address. Currently fixed, but I'm going to do some minor code clean-up before updated the dev builds

[JappaWakka]

Thank you for looking at the problem and fixing it. Just a question: where can I find the latest dev builds when they get released?

[shonumi]

I've got a folder on MEGA that I've been meaning to publish. I haven't updated it with the most current devs builds but will try to soon. You can bookmark the folder and check it periodically for new builds. In the future, I'll hopefully automate the process.

Off-topic, but I'd love to keep an eye on this project your working on. Looks really good!

[JappaWakka]

You haven't seen half of it ;)

[JappaWakka]

How far are you with the cleanup? the bug is occuring at more places. even in objects and other character portraits...

[shonumi]

It's completely fixed, I just haven't uploaded a dev build. I'm a bit behind in closing a bunch of issue even though they're no longer valid with the most recent code changes.

[JappaWakka]

Alright good to hear. The object misbehaving appeared to be my fault though, forgot to use ext_vram_addr

[shonumi]

This should be fixed now. A basic build-bot is up and running, and the latest builds should be available on mega.nz from now on -> https://mega.nz/#F!GhcQ1QYB!L5_8qN_S0gqYE-oCCa9mJQ