EXT_AUTO_BRIGHT does not function at all.

[frozenLake]

Do note that this also is the original palette, and it goes back to the default GB tiles when not on that palette, aka what you would typically want EXT_AUTO_BRIGHT for.

I have provided two screen shots, one where the tiles have EXT_AUTO_BRIGHT enabled, and one where it isn't.

[frozenLake]

If you examine what happens, the colors of the graphics all all forced to a single brightness value. My suggestion would be using the brightest and darkest colors in a palette in order to determine a range to shift brightness into, without setting everything to a singular brightness... unless the palette is all the same color.

[shonumi]

EXT_AUTO_BRIGHT only works for GBC games. This is Pokemon Gold/Silver/Crystal, right? Make sure it's not in DMG mode. On that note, EXT_AUTO_BRIGHT is messed up in certain situations on GBC games, so it's a valid issue I've been meaning to look into either way.

I'll take a look at improving the factor by which it adjusts the brightness. Please be aware that the EXT_AUTO_BRIGHT option is not intended for the kinds of fade-in/fade-out effects in the in DMG games, that's something that the future EXT_AUTO_PAL option would handle. EXT_AUTO_BRIGHT should be use for something like the "CAPCOM" logo during the intro to Mega Man Extreme or Shantae (gradual fade in/out to white, that kind of stuff) I should probably disable EXT_AUTO_BRIGHT from even processing when doing DMG CGFX since the results are completely unexpected/unpredictable.

I'll dig into this soon though, should have some progress + a new dev build in a day or two.

[shonumi]

BTW, if you are using GBC graphics with CGFX + EXT_AUTO_BRIGHT, send me the stuff you're working on if you don't mind, for testing purposes. Thanks.

[frozenLake]

This uses Pokemon Yellow, and given the default yellow pikachu on the front title, I can tell its not in DMG mode.

Plus, the manifest is using 2 and 20, not 1 and 10, so that also is a sign to it not being in DMG mode.

[shonumi]

Okay. Be sure to post your source materials when you get the chance.

[frozenLake]

PKYellow.zip

[shonumi]

This was fixed last month, but you can test the latest builds to verify. Two things to note:

1) When using EXT_AUTO_BRIGHT, you may notice that some tiles (like Pikachu's all-yellow tiles on the title screen) have their brightness level changed even though you haven't dumped them and turned on this option for them. Obviously this is not the desired effect you'd want, but EXT_AUTO_BRIGHT works on matching the raw VRAM dot-data (basically the pixel data before a palette gets applied) so some tiles (typically tiles of a solid color) get matched up anyway.

The solution is to dump any affected tiles and turn them into CGFX. Here, you would just dump the yellow sections, and just scale them up (note that the title screen here actually uses the BG and WINDOW layers, so you have to dump 2 yellow tiles).

2) EXT_AUTO_BRIGHT isn't perfect when it comes to DMG style fades vs GBC style fades (e.g. basically changing 4 colors and few shades vs changing many colors and many shades). As you can see below, the bookcases don't fade all the way, not until the very, very last frame. Until then, they get stuck like this:

It's a problem related to this issue, and I'm working on it.

[JappaWakka]

Some of my dumped backgrounds get affected by the auto bright function. In Pokémon TCG 2, some of the dumped and edited cgfx background tiles get swapped around too. Like the shoulder tile of one cgfx tile appears as the fading tile of another, even with vram address active.

[JappaWakka]

Also when there are many auto bright enabled graphics on screen (like when you transition from one room to another), the game slows down a lot to the point of audio crackling and graphics glitching...

[shonumi]

Files please

[JappaWakka]

PokemonTCG2.zip You may find that my manifest file has a lot of comments, that is to make my custom syntaxis work when using Notepad++ (so I can collapse sections and such)

[JappaWakka]

like so

[JappaWakka]

this is one of the things that happen for example the red tiles are probably from the male player and his shoulder is flipped

[shonumi]

Alright, a couple of comments about what's going on:

1 - About the broken Aaron portrait. There are two possible ways to fix this. The first is to dump all of the transitions that happen in-between (there are only 7), and replace them with the same CGFX (Portrait_Researcher_Aaron_Neutral.bmp). EXT_AUTO_BRIGHT will automatically handle the brightness levels and adjust them accordingly so that the fade-in effect matches the game. You'd need to dump these 7 variations of Aaron's portrait:

And the manifest entries would look something like this (adjusting the paths/files for your project, of course):

https://pastebin.com/raw/7rXWQXr7

The other is to enable both EXT_AUTO_BRIGHT and EXT_VRAM_ADDR. In theory, this combo should work, and you'd only need to dump 1 copy of Aaron's portrait. But this is currently broken in GBE+. It should be working later this week (or sometime this weekend). So if you can wait, this is the better method. If not, the method above is verified to work (but I'd use that only temporarily, if absolutely necessary, otherwise give it a few days).

2 - About performance. Automatically adjusting the brightness is simply a demanding task. Doing it correctly involves converting RGB to HSL, adjusting the lightness, then converting it back to RGB, so it's a pretty expensive operation per-pixel. Most computers do just fine at 1x-2x CGFX, but 3x and above is pretty challenging as more and more CGFX use the EXT_AUTO_BRIGHT option. I could experiment with cheaper ways to adjust the RGB values, but there's no guarantee it'll look accurate. I'll look into it, but no promises that such slowdowns will be completely eliminated. After a certain point, CGFX can become too demanding for some computers (e.g. even without EXT_AUTO_BRIGHT, 6x-7x CGFX would bring any system to its knees).

[JappaWakka]

I tried resizing my images to 2x instead of 4x the internal resolution, but it was just as slow :( also I don't mind it being accurate or not :)

[shonumi]

Well, quantity also matters (quantity as in how many CGFX appear on-screen at a given moment, and how many need brightness changes). If it's just a handful, you can use EXT_AUTO_BRIGHT on most CPUs with 4x, but even 2x will slowdown based on what's going on at any given moment.

I'm going to have to use a cache of some sort since the quicker, inaccurate brightness adjustment method turned out to be garbage (unusable basically) and only marginally faster.

[JappaWakka]

On the latest dev update, the auto brightness function suddenly stopped working on every game.

[JappaWakka]

Nevermind, I was using DMG mode.

[shonumi]

Fwiw, I haven't forgotten about the performance issues with EXT_AUTO_BRIGHT. I'm just caught up in other things atm, so sorry for the lack of communication. I recently made a plan for a cache, so once certain graphics have their brightness adjusted, that calculation (which is expensive per-pixel) wouldn't have to be done for a while. No code yet, but I have the idea formed and written out.

[JappaWakka]

I'm glad to hear you're still working on it :) I was scared that you might've already started to get annoyed by my reminders XD Don't forget that I really love your work and I'll be patiently waiting for you to fix the issue :)

[JappaWakka]

Quick question though... Would that cache be transferable? As in that you can add it to the cgfx pack so someone else wouldn't need to have performance issues either?

[shonumi]

The cache doesn't cover the entire CGFX pack. It's just GBE+ keeping internal copies for itself, and the cache gets updated when new entries come in and old ones get kicked out. The trick is making it just the right size so that it doesn't consume too much memory and the entries in the cache are still relevant long enough. That's just a matter of how many cache entries max should I use, and to find that out I'll just have to experiment.

So to answer your question, no, it's not transferable, not like shader caches for CEMU (I think?) or other emulators. The initial performance cost of making a cache entry for EXT_AUTO_BRIGHT graphics should be relatively small in comparison to the performance boost that comes when repeatedly accessing the cache.