BGLOAD failure?

[[][][][]]

In relation to EREDAR-ENTRY, I've already constructed a shell-Try around it.
Unfortunately, something seems to prevent BGLOAD from working properly.

Whenever I start the TRY, the background doesn't load at all - it instead shows a broken, blurry section of either the original background or the new one, or maybe both.
Which is static, posing problems for the BGSCROLL command.

Here's the codes that I used, lifted out of various TRYs.

Code: Select all

"BUFFER", 32768, 32
"BGLOAD","cloud.bmp",1,1,1000,4,0,255,240
"BGCHANGE",1
"BGFADE", 8,8,8
"BGSCROLL",4000,0,2048,0
"BGSCROLL",8000,200,2048,0

For those who are wondering what's the two BGSCROLL commands for, the first one is the initial speed, the second is triggered right after EREDAR-ENTRY activates afterburners and jets off the screen to simulate you chasing it down (the timer is a WAIT command synced with the exact frame of take-off).

So... anything wrong with the code?

[AlexMdle]

It's gotta be the value 4. Setting that one wrong with a black background results in it quickly fading out in a poof of blur motion.
Try one of the other values and see which sticks.

int5 Draw blend mode (3~6)
3 Translucent
4 Translucent with black(r=0,g=0,b=0) disregard
5 Addition
6 Subtraction

[[][][][]]

Tried that, changed the only 4 in the value to 3, 5, and 6, and even 0...
Nothing worked.

Setting BGCHANGE to 0 set it to the wireframe bg.
Any others had no effect.

>>Nevermind, found the real non-problem.
Nope, still having trouble. Check back for updates.

EDIT: Okay, comparing the (okay) previous update with the (bugged) current update's code.
Current: "BGLOAD","cloud.bmp",1,1,1000,4,0,255,240
Previous: "BGLOAD","data/cloud.bmp",1,1,1000,4,255

Seems the fifth value is different. Unless there's a loading error that forces TRYs to put data in a separate folder, I'm guessing the 5th value is the opaqueness setting, and setting it to 0 essentially renders it transparent.

Gonna test it by setting said 5th value to 255, and/or removing the additionals (they're x and y coordinates, pretty much non-essential).

THE LAST FRIGGIN' EDIT:
Yep, guessed right. Turns out the 5th value covers opaqueness, so in essence I was using a transparent background while the previous background bled away, so there.

Please lock this, and keep this for future TRYs that may have trouble with BGs.
Also, put the info somewhere here oh wait that's in the Fraxy Wiki, right?
Anyways, make the link more easily accessed, please...

[AlexMdle]

Try setting the third value (1) to 0.

The bg priority is 0>1>2. It's possible that it gets overlapped by the bg in the layer 0.

[[][][][]]

Fair enough, but that was only one background...

...but anyways, noted, and thank you. Will be useful for multi-layered BGs, and now I can probably have a more realistic cloud BG.