VGMaps
November 18, 2017, 06:00:55 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1] 2   Go Down
  Print  
Author Topic: Degree of transparency.  (Read 6643 times)
0 Members and 1 Guest are viewing this topic.
Troy Lundin
Full Member
***
Offline Offline

Posts: 145


« on: March 01, 2012, 08:24:07 PM »

Is there a way to tell how much transparency a game uses for any of it's layers with VBA?
Logged

TerraEsperZ
Hero Member
*****
Offline Offline

Posts: 2225



« Reply #1 on: March 01, 2012, 09:51:44 PM »

If there is, it must be buried pretty deep. I know that the Gameboy Advance apparently uses Alpha Blending and there's some technical information on this page about the GBA's graphic effects, but I don't think there's any easy way aside from looking around VBA's various tools like the IO Viewer for example.

And even then, it never seems to be a simple transparency effect that's being used, which might have to do with the GBA's 15-bit color palette? I've long given up trying to reproduce the GBA's transparency effects perfectly and I just try to get it as reasonably close as I can without having access to Photoshop.
Logged

Current project that I really should try to finish:
-Drill Dozer (GBA)
-Sonic 3D Blast (Genesis)
-Naya's Quest (PC)
-Lilly Looking Through (PC)

Pending project:
-A ton of stuff that will never be finished
Troy Lundin
Full Member
***
Offline Offline

Posts: 145


« Reply #2 on: March 02, 2012, 12:49:07 AM »

Good read.

So, using the calculation they gave: C = wA·A + wB·B.

wA = 0.625
wB = 0.5625

as shown in the IO Viewer. Blend mode is 01 or Alpha blend mode. How would I use this information to create a good transparency in a program like GIMP?
Logged

Peardian
Hero Member
*****
Offline Offline

Posts: 627


Busy busy


« Reply #3 on: March 02, 2012, 02:08:15 AM »

It's certainly not easy,that's all I know. In fact, for all my GBA maps that involve blending, I either took screenshots of the blends (MLSS) or did my best guess.

Of course, seeing how you're handy with programming, you could try creating a script that takes two images and outputs the results in the way the GBA would do. In fact, something like that would be great for GBA mappers to have. If you do decide to attempt this, I recommend working with BMP format, so you don't have to bother with compression.
Logged

MM (10%) - SMA3 (33%) - DNS (0%)

Come check out the Nintendo 64 Mapping Workshop!
DarkWolf
Hero Member
*****
Offline Offline

Posts: 621



« Reply #4 on: March 02, 2012, 08:13:57 AM »

If you do decide to attempt this, I recommend working with BMP format, so you don't have to bother with compression.

Just FYI, dealing with PNG in any higher-level language/environment like Java or .NET is pretty easy.  You don't have to write any decompression code yourself to read the files.  Even with lower-level languages like C there are libraries already written.  Several years back I still used BMP because I used MS Paint for a lot of things, but these days there really isn't much reason to use BMP unless you're dealing with some sort of legacy software or system.

Logged
Troy Lundin
Full Member
***
Offline Offline

Posts: 145


« Reply #5 on: March 02, 2012, 10:56:39 AM »

A few years ago I figured out how GBA stores it's colors. It's values go from 0 to 31. So, to get to the actual RGB value you must multiply by 8. I grabbed the RGB values of the two layers. Layer A is the transparent layer while Layer B is the underlying layer. I took a screenshot of the blend in action. This is C.

A = 224, 224, 224
B =   0,  64, 120
C = 136, 176, 200

Converted into GBA colors gives the following:

A =  28, 28, 28
B =   0,  8, 15
C =  17, 22, 25

Now, if we use the formula given in the first post (C = (wA * A) + (wB * B)) where wA = 0.625 and wB = 0.5625 (these value are given via the IO Viewer) with the GBA colors then we get the following:

C = (wA * A) + (wB * B)

R = (0.625  * 28) + (0.5625 *  0)
G = (0.625  * 28) + (0.5625 *  8)
B = (0.625  * 28) + (0.5625 * 15)

R = 17.5 + 0
G = 17.5 + 4.5
B = 17.5 + 8.4375

R = 17.5
G = 22
B = 25.9375

As you can see, the results have to be floored to match up with the in-game results. But, the math works. This tells me how the formula works but I still don't know how to apply it. In GIMP, there is a simple slider for the percent of transparency to add to a layer. I'll fiddle around with it some more.
Logged

Troy Lundin
Full Member
***
Offline Offline

Posts: 145


« Reply #6 on: March 02, 2012, 12:22:16 PM »

Ok, Peardian, you got me. Because you said I was handy with programming I had to see if I could do this. Looks like I could. I got it to blend perfectly. Thank you. Cheesy

Here it is: GBA Alpha Blender.zip

It's very basic right now and only supports one mode of blending (alpha). You will have to get the evA and evB values from the VBA IO Viewer as they are bound to be different per game or even per area. I included three images for testing purposes.

_clouds3.png is the blended image. It goes in Box A.
_darkClouds.png is the background image. It goes in Box B.
The last image is a screenshot from the game. I used it to compare the blending.

Also, the evA value is 0.625 and the evB value is 0.5625 for this game. Let me know if it doesn't work. Thanks again, Peardian. Cheesy

Just FYI, dealing with PNG in any higher-level language/environment like Java or .NET is pretty easy.  You don't have to write any decompression code yourself to read the files.  Even with lower-level languages like C there are libraries already written.  Several years back I still used BMP because I used MS Paint for a lot of things, but these days there really isn't much reason to use BMP unless you're dealing with some sort of legacy software or system.

.NET handles PNG natively. Reading and writing is automatic without extra code.
« Last Edit: March 02, 2012, 12:24:57 PM by Troy Lundin » Logged

Maxim
Hero Member
*****
Offline Offline

Posts: 972



« Reply #7 on: March 02, 2012, 12:38:12 PM »

To convert 5-bit-per-channel colour to 8-bit-per-channel colour (aka true colour) you should not multiply by 8, as that makes pure white a bit grey. You should use bit operations to repeat the value until it fills 8 bits:
Code:
r = (r5 << 3) | (r5 >> 2)
and repeat for g, b and a. But a lot of emulators do this wrong.
« Last Edit: March 02, 2012, 12:38:54 PM by Maxim » Logged
Troy Lundin
Full Member
***
Offline Offline

Posts: 145


« Reply #8 on: March 02, 2012, 01:09:01 PM »

To convert 5-bit-per-channel colour to 8-bit-per-channel colour (aka true colour) you should not multiply by 8, as that makes pure white a bit grey. You should use bit operations to repeat the value until it fills 8 bits:
Code:
r = (r5 << 3) | (r5 >> 2)
and repeat for g, b and a. But a lot of emulators do this wrong.

Not sure what you mean here. As far as I know, the GBA doesn't have a pure white color, as it can only get up to {248,248,248}.
Logged

Peardian
Hero Member
*****
Offline Offline

Posts: 627


Busy busy


« Reply #9 on: March 02, 2012, 01:32:33 PM »

I knew you could do it! Cheesy

And that's good to know about PNG. Shows you how much experience I have with making programs. Tongue


Also, yeah, SNES is the same way. That's the brightest color you'll ever see in Yoshi's Island, too. (It became very apparent in the snow levels.)
Logged

MM (10%) - SMA3 (33%) - DNS (0%)

Come check out the Nintendo 64 Mapping Workshop!
DarkWolf
Hero Member
*****
Offline Offline

Posts: 621



« Reply #10 on: March 02, 2012, 02:25:39 PM »

To convert 5-bit-per-channel colour to 8-bit-per-channel colour (aka true colour) you should not multiply by 8, as that makes pure white a bit grey. You should use bit operations to repeat the value until it fills 8 bits:
Code:
r = (r5 << 3) | (r5 >> 2)
and repeat for g, b and a. But a lot of emulators do this wrong.

Not sure what you mean here. As far as I know, the GBA doesn't have a pure white color, as it can only get up to {248,248,248}.

Generally speaking when talking about video hardware the largest value per color channel should represent the most intense value.  So when you translate that over from 5-bit to 8-bit, 31 should translate into 255.  Like Maxim said, the emulator itself probably does the color conversion wrong.
Logged
TerraEsperZ
Hero Member
*****
Offline Offline

Posts: 2225



« Reply #11 on: March 02, 2012, 03:27:09 PM »


Generally speaking when talking about video hardware the largest value per color channel should represent the most intense value.  So when you translate that over from 5-bit to 8-bit, 31 should translate into 255.  Like Maxim said, the emulator itself probably does the color conversion wrong.

I'm pretty sure DarkWolf has it right. Pure white (RGB 255, 255, 255) is basically the brightest color any standard display can output, but the actual bit value of all three channel will change depending on the bit/color depth. I think I once read that most emulators end up with 248, 248, 248 as the brightest white simply because it requires a simpler bit operation (something like simply shifting the bits to the left?) than to adjust the value so that the minimum value is 0 but the maximum is 255 instead pf 248.
Logged

Current project that I really should try to finish:
-Drill Dozer (GBA)
-Sonic 3D Blast (Genesis)
-Naya's Quest (PC)
-Lilly Looking Through (PC)

Pending project:
-A ton of stuff that will never be finished
Maxim
Hero Member
*****
Offline Offline

Posts: 972



« Reply #12 on: March 03, 2012, 11:15:42 AM »

It's a common error in emulators. The algorithm I posted (value extension rather than zero extension) is only marginally slower than simple left-shifting, as it's two shifts and an OR which are all incredibly fast operations, but the naive approach is to use a multiply and divide, which emulator authors immediately discount as too slow. Actually, on modern (and not so modern) CPUs even that is fast enough...
Logged
Peardian
Hero Member
*****
Offline Offline

Posts: 627


Busy busy


« Reply #13 on: March 03, 2012, 12:00:22 PM »

Considering most of the emulators do it that way, and all of the graphics used with and around the program are from an emulator, is it really that much of an issue?
Logged

MM (10%) - SMA3 (33%) - DNS (0%)

Come check out the Nintendo 64 Mapping Workshop!
Revned
Hero Member
*****
Offline Offline

Posts: 1091



« Reply #14 on: March 03, 2012, 12:43:11 PM »

If you care about perfection it is. I wrote a script to pull the icons out of Gamecube disc images at one point and I was confused as to why they didn't ever come out with true white. Eventually I realized why, and the fix made them look noticeably better to me.
Logged

Pages: [1] 2   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!