From what I found here:

http://www.zetaprints.com/help/coreldra ... perations/

The "lightness" blend keeps the hue and saturation of the back and keeps the lightness of the front.

The "luminosity" effect in c2 matches that description, but doesn't seem to give the same results. Perhaps it's a bug in it somehow since a fair of math is involved.

The basic logic is to convert the back and front from rgb to hsl, then take the hue and saturation from the back and the lightness from the front to make a new hsl, finally that is converted back into rgb.

That's the logic needed to make an effect, or the info needed to debug the luminosity effect if someone is curious and has the time.

Well... so there is no way to achieve what I want in C2? :\</p>

Try blend mode additive.

Probably there is no blend mode in C2 to achieve the effect.. in coreldraw there is the lightness blend mode, that do exactly what I need.

So.. I'm looking for, maybe, some workaround.

This might be possible with one of the effects, like Multiply or Overlay. It's the same stuff Photoshop uses, so this list can be handy: http://www.myphotocentral.com/wp-conten ... -modes.jpg

Hehe thank you for the help, but, as I said "with the "overlay" effect it got close, but is invisible in black backgrounds". <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad">

the effect must work like the image that I attached.

I would think that you could just set the z order of the white box to a lower number than the gradient box, then set the opacity of the gradient box to lower than 100 (say, 70). I'm not sure a blend mode is required.

I can't do this, 'cause the gradient is the background of the level. It need to be as colorful as it can be.

I really need that effetct in my game:

https://onedrive.live.com/redir?resid=3 ... hoto%2cjpg

But I couldn't achieve this.. with the "overlay" effect it got close, but is invisible in black backgrounds...

Can someone help me? <img src="{SMILIES_PATH}/icon_e_confused.gif" alt=":?" title="Confused">

Hehe thank you for the answer!

But I would prefer something more "dynamic".. like an effect or something like this.

There is a way to achieve something like that?

The light in the background isn't just with some glow.. it surpass the sprites in front of it and make a nice lighting effect.

The relevant manual entry is Memory usage, which covers layout-by-layout loading and how objects placed in the layout vs. created at runtime are handled. In short, you should have any objects the layout ever uses placed somewhere offscreen and destroyed on startup if need be - this causes their images to be preloaded when the layout starts. Otherwise, 'create object' can "jank" as it loads images on-demand.

Hehe thank you, Ashley!

And, of course, thank you very much guys!

Thank you very much guys! That's a very interesting discution. But... well, now I have more doubts that before haha

Sorry, but I'll have to call boss... Hey, Ashley , we need you here!!

What do you think about it?

Hm... Well, I like the organization of making a layout for these objects, but if it isn't the best practice here, I will not do this hehe

Thank you!

> I would like to know what is more interesting...

> Put the objects that will appear only with the 'create object' action in a separated layout, or just put outside the layout that it will appear?

> Thanks.

>

The best practice would be is to put everything that the Layout needs including the objects that will be created using "System ->Create Object(X,Y)". And on start of layout, if the object is not needed yet , destroy it.

Because if you don't have the object in the layout and create it using "System ->Create Object(X,Y)" it will make a laggy pause because the object isn't preloaded.

Only the objects present in the layout during editing will be preloaded. It is still okay if you put it outside the Layout White Paper as long it is on the Layout Page.

Note: Do not put your objects in a separate layout that isn't run during gameplay.

(Example of a bad practice!!! is to make a Layout where the game happens and make a separate layout for storage of the objects that will be created by "System ->Create Object(X,Y)" for the reason of not making the Main Game Layout look messy. ) - Wrong! The objects will not be preloaded and plus a Layout that is not used and made a storage for objects makes it worse.

For more info, read Ashley's Optimization tips below:

Ashley's posts:

https://www.scirra.com/blog/83/optimisa ... -your-time

https://www.scirra.com/tutorials/298/pe ... bile-games

Wow, are you sure that the objects stored in a separated layout are not preloaded? I was almost sure that they are... and it would be much more organized.

How do you know that they aren't?

I would like to know what is more interesting...

Put the objects that will appear only with the 'create object' action in a separated layout, or just put outside the layout that it will appear?

Thanks.