Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unintended transparency
#1
After a couple of years, I've fallen back into a coding error that I don't know where it is, and at the time it was resolved in a way that I don't remember...

Suddenly, when I write something in a certain position, if I overwrite something in that position, the new phrase does NOT cover the old one, which somehow 'survives' producing a very annoying transparency effect.

Obviously, there are no COLOR instructions with RGB that set various transparencies, so the effect is not intended. I always use - at the beginning of my code - SCREEN _NEWIMAGE([...], [...], 32).

If I don't solve it, I'm stuck indefinitely... sine die...

I'm sure it's something minor... I mean, exactly the type of errors that are the hardest to find...

Any suggestions regarding this?
Reply
#2
Without any code to go by, it's hard to diagnose this type of issue.  From past experiences, I'd think it would probably be:

1) Variable type.   Are you using a variable to store a color value?  Is that variable a SINGLE type (or undefined so it defaults to SINGLE)?  Those variable types can lose precision and end up returning values that hold 0 alpha (or reduced alpha levels), leading to this type of transparency problem.

2) Is there a _PRINTMODE statement in the code?  Those can change behavior and you may need to toggle them back to normal.

3) By chance is there a COLOR statement with a variable which is somehow cleared and becoming 0?  COLOR fg, 0 , for example, would give you a transparent background.  So would any variable which might be reset or cleared to 0 there.

Without seeing the actual code, I'm inclined to think it's probably one of the above issues at play.  Share the source (or a stripped down example of the code with the problem, if you can), and it shouldn't be too difficult to narrow the issue down and give you a definitive answer.
Reply
#3
(08-25-2025, 12:52 AM)SMcNeill Wrote: Without any code to go by, it's hard to diagnose this type of issue.  From past experiences, I'd think it would probably be:

1) Variable type.   Are you using a variable to store a color value?  Is that variable a SINGLE type (or undefined so it defaults to SINGLE)?  Those variable types can lose precision and end up returning values that hold 0 alpha (or reduced alpha levels), leading to this type of transparency problem.

2) Is there a _PRINTMODE statement in the code?  Those can change behavior and you may need to toggle them back to normal.

3) By chance is there a COLOR statement with a variable which is somehow cleared and becoming 0?  COLOR fg, 0 , for example, would give you a transparent background.  So would any variable which might be reset or cleared to 0 there.

Without seeing the actual code, I'm inclined to think it's probably one of the above issues at play.  Share the source (or a stripped down example of the code with the problem, if you can), and it shouldn't be too difficult to narrow the issue down and give you a definitive answer.
Thank you !! You gave me the right address.
The error was number 3, a sneaky and very hidden case where the background color became 0.
I could have spent weeks figuring out where the problem was...
Reply
#4
Quote:Thank you !! You gave me the right address.
The error was number 3, a sneaky and very hidden case where the background color became 0.
I could have spent weeks figuring out where the problem was...
Lol thats Steve for ya! Like Clippy (meant as compliment here) he will (unless your question is out the box) provide the answer! Gotta love that GUY! 

Glad you got your answer!

Unseen
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Transparency with Hardware Images NakedApe 8 1,017 07-10-2025, 09:47 AM
Last Post: Pete
  Another way to use Hardware Images and Transparency (alpha channel) for a PopUp Menu TempodiBasic 1 500 03-30-2025, 05:10 PM
Last Post: Pete

Forum Jump:


Users browsing this thread: 1 Guest(s)