Jump to content

Photo

Zscript: Alpha Opacity


  • Please log in to reply
7 replies to this topic

#1 OmegaX

OmegaX

    Leader of Omega GamingHunters101

  • Members
  • Real Name:Matthew
  • Location:Rochester, NY

Posted 11 July 2020 - 01:32 PM

There are only two opacity options when using draw commands in Zscript, OP_TRANS and OP_OPAQUE (50%, 100%, or 0% if you want it completely invisible) and you can't set it too anything else like 25%, etc. Why not use Alpha transparency instead? where we can set the value anywhere between 0 to 1 (so .25 for 25% transparency). This could be useful for transferring between room if the quest creator wanted to script it or fading in a string slowly instead of it appearing instantly.



#2 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 11 July 2020 - 05:38 PM

It's because ZC doesn't actually have transparency, just an approximation of it. It has a 256 color palette of which only those colors can be displayed to the screen. If the average of two colors doesn't exist in the palette, it'll go with the next closest approximation, which is why you sometimes get really janky transparent layers if your quest doesn't have a good color distribution. So long as ZC uses Allegro this can't be changed.

 

Now in ZScript you can still have some fading by overlaying transparent draws over each other. It'll do the color math two times, three times, and eventually just become solid. It's not very flexible, but for quick fade-ins it works fine. For more complex effects we'd need the ability to write to or override the palette itself and that's apparently a pretty big undertaking.


Edited by Moosh, 11 July 2020 - 09:10 PM.

  • Mani Kanina likes this

#3 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 11 July 2020 - 07:48 PM

To have proper alpha transparency, we'd need to entirely rewrite the color system. It's in my plans to do, but, not any time REMOTELY soon, as it's extremely difficult to do without breaking things.

#4 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 11 July 2020 - 09:06 PM

To have proper alpha transparency, we'd need to entirely rewrite the color system. It's in my plans to do, but, not any time REMOTELY soon, as it's extremely difficult to do without breaking things.

So that's not actually tied to allegro like I thought? And could be done without completely breaking the existing qst format? Apologies for the misinformation there. I didn't even notice this was posted in feature requests.  :doh:



#5 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 11 July 2020 - 10:43 PM

So that's not actually tied to allegro like I thought? And could be done without completely breaking the existing qst format? Apologies for the misinformation there. I didn't even notice this was posted in feature requests.  :doh:

Oh, it is 100% tied to allegro. We just need to rewrite how it's tied to allegro and write multiple new systems for handling it from scratch.



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 14 July 2020 - 12:36 AM

So that's not actually tied to allegro like I thought? And could be done without completely breaking the existing qst format? Apologies for the misinformation there. I didn't even notice this was posted in feature requests.  :doh:

 

It's tied to using 8bbp indexed colour palettes. Allegro 4 supports 24bbp and 32bbp with alpha.

 

That said, ...no. 8bbp cannot support alpha levels. In the future, you will be able to create, save and load palettes by script, and manually rebuild translucent colour tables, but actual alpha is not only a long way off, but it will occur no sooner than 3.1. The first task is to start using OpenGL. After that, Rob can have his fun. I fully expect this to be impossible to provide properly (without compatibility issues), as the palette rewrite is too vast and would literally be its own version with no other features.

 

 

Note: If you bitch that 2.55 (or 2.5.x) is slow (compared to version n), 3.0 will likely be slower (due to OpenGL), and 3.1 with a palette rewrite will be much slower, still. Every layer of conversion and abstraction is an efficiency deficit.While I will work on 3.0, to get AL with OpenGL working, I have no interest in working on a colour system rewrite,and will not be taking any substantial part in that. I understand indexed palettes. I do not know much about shaders or other OpenGL facets.

 

I will instead, if still alive,wait for it to be done, or wait for it to be abandoned; an then resume work on new engine features, or begin the future 3.x or 4.x process. 


  • Moosh likes this

#7 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 29 July 2020 - 02:18 PM

I fully expect this to be impossible to provide properly (without compatibility issues), as the palette rewrite is too vast and would literally be its own version with no other features.

By that, do you mean that Graphics->GetPixel() will just not work the same way anymore? And maybe others? I've been wondering about that function in particular, since you clearly can't keep it working the same way without reimplementing the current pseudo-alpha behavior.



#8 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 30 July 2020 - 07:04 AM

By that, do you mean that Graphics->GetPixel() will just not work the same way anymore? And maybe others? I've been wondering about that function in particular, since you clearly can't keep it working the same way without reimplementing the current pseudo-alpha behavior.

The pseudo-alpha would need to be maintained via compatibility QR. Creating true alpha will be hell^666.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users