Enemy white blink withouth extra texture

BigDave

Is there a way to create the typical enemy white blink when he takes damage withouth needing to import an extra frame?

ForumNinja

@BigDave You may be able to get that kind of effect through changing the actor's alpha for a fraction of a second. Here's a quick demo project.

Hopscotch

@BigDave

An alternative to @ForumNinja 's suggestion of playing with the alpha, you can also change the color values. E.g. to let the enemy flash with a reddish hue. Since the actor color needs to be white when using a texture, you will not be able to flash it white, but you can tint it with any other color.

Socks

@Hopscotch said:
you will not be able to flash it white . . .

You can get pretty close if you stack the actor's colour values . . . click anywhere on the screen to launch a bomb.

Toque

I was playing with it but Socks example is great.

Now Im asking "why does replicating the image make it look white????"

jamie_c

@Toque, he has the blending mode of the actor set to Screen so it interacts with the colors of the image(s) that are below it.

ForumNinja

@Socks Very neat!

Hopscotch

Clever use of the blend mode @Socks. Nice one for the box of tricks.

The blend mode can also be changed while the game is running, so you could do the trick without an extra spawn.

Socks

@Hopscotch said:
The blend mode can also be changed while the game is running . . .

Are you sure about that ?

Toque

@jamie_c said:

Thanks,
Ok I see blending. I will have to play with it to see what the "screen" setting does.

Thanks @Guru for the helpful video on the blending topic.

Socks

@Toque said:
I will have to play with it to see what the "screen" setting does.

The luminance of both layers is inverted (made negative) and then multiplied by each other (values of layer 1 x values of the layer 2) - and then the result of this calculation is inverted.

Hopscotch

@Socks said:
Are you sure about that ?

Unless I am wrong ... and I am never wrong ... (blatantly got used in a movie)

yes, it works

Rule:on collide
- - Timer for duration of blink
- - - - Change Attribute self.Graphics.Blendmode = 3
- - - - Replicate blabla
- - - - Change Attribute self.Graphics.Blendmode = 0 (back to normal)
-- End timer
End rule

Socks

@Hopscotch said:
Unless I am wrong ...

Unfortunately you cannot change blend modes at run time (although it would be useful if you could).

Hopscotch

@Hopscotch said:
... and I am never wrong ...

Here you go @Socks :* (dang, there is no suitably smug smiley)

Socks

@Hopscotch said:
Here you go @Socks :* (dang, there is no suitably smug smiley)

It seems you are right, sort of, well right enough, ok, you're right . . . .

Well it works, but it's certainly very hit and miss in normal use, I'd never actually tried a combination of change.blend.mode + Replicate, and it seems you need the have Replicate in place for it to work for some reason ? When you switch Replicate off the change attribute won't work, which means it doesn't work ! Which means I was right ! (Ok, ok, I wasn't right).

Anyhow, great discovery, you could implement a useable change-blend-mode-at-runtime by simply adding a Replicate after the change attribute and set it to 1 copy / 0 spacing !

I wonder why we simply can't use change attribute to change the mode, they clearly can be changed at run time (using your workaround), this reminds me of other things in GameSalad that are clearly achievable but not implemented - for example if you want to scale your actor to, for example, x = -300 . . . . you can't . . . . but the engine can clearly do it, for example use Interpolate to scale an actor to x = -300 and it will do exactly that, you will get a reversed actor, but it then disappears after the target value is reached.

Anyhow, enough complaining, yes you were right, I'm going to now drink myself into an early grave . . . . and it'll all be your fault.

Socks

@Hopscotch said:

Here's an example of what I was referring to above (file attached), Interpolate can pull actor sizes into negative values, but annoyingly you can't set an actor to a negative value any other way !

BigDave

wow guys! thank you very much!

Thats epic I now save an extra image per enemy type + It can now blink on any current frame so it doesn't has to get constraint and deactivate other animations

perfect!

RossmanBrothersGames

Nice, I may have to test this in Get Me Outta Here

kianziack

cool! thanks lad. >:)

Hopscotch

@Socks said:
I wonder why we simply can't use change attribute to change the mode, they clearly can be changed at run time (using your workaround), this reminds me of other things in GameSalad that are clearly achievable but not implemented - for example if you want to scale your actor to, for example, x = -300 . . . . you can't . . . . but the engine can clearly do it, for example use Interpolate to scale an actor to x = -300 and it will do exactly that, you will get a reversed actor, but it then disappears after the target value is reached.

• I wonder why we can't set the tiling offset, since we can already set tile width. This would immediately give us sprite-sheets. This would even allow running animations straight from a sprite-sheet. The staple of any 2D tool.

• I wonder why we can't change the order of actors in a layer, since we can already spawn dozens of actors in-front/behind/top/bottom within one draw cycle. This would immediately give us depth-sorting/z-order. The staple of any 2D tool.

Anyhow, enough complaining, yes you were right, I'm going to now drink myself into an early grave . . . . and it'll all be your fault.

Hold on, I'm joining you...

By the way, it is @adent42 's fault

Toque

@Hopscotch said:

• I wonder why we can't set the tiling offset, since we can already set tile width. This would immediately give us sprite-sheets. This would even allow running animations straight from a sprite-sheet. The staple of any 2D tool.

• I wonder why we can't change the order of actors in a layer, since we can already spawn dozens of actors in-front/behind/top/bottom within one draw cycle. This would immediately give us depth-sorting/z-order. The staple of any 2D tool.

+1

I really hate cutting up sprite sheets. Complicated ones with obscure boundaries are hard to get right. Everything has to be centered and equal sized.

BigDave

@Hopscotch @Socks
what you guys think will this replicate trick be a hard pill for the perfomance in cases of 4-6(maximum) enemies beeing hit at once (blinking)?

i assume not too bad as I never really had perfomance Issues with gamesalad games so far just asking

just wanna get sure to know things I have to watch out for with this solution, which i love btw ( that extra shaky effect very nice)

Hopscotch

@BigDave no, I am sure it will be fine. Replicate does not actually spawn any actors, only adds some draw calls. I have had projects with over a thousand replicate copies with no noticeable performance problems. @Socks has probably used even more in some of his simulated 3D projects.

Hopscotch

@BigDave so I double checked.

My table project from here

http://forums.gamesalad.com/discussion/comment/590800/#Comment_590800

has 20 actors, each replicated 300 times (that is 6000 replicates)

and runs at a steady 60 FPS on an iPad4, even though it does a lot of other things at the same time.

Socks

@Hopscotch said:
@BigDave no, I am sure it will be fine. Replicate does not actually spawn any actors, only adds some draw calls. I have had projects with over a thousand replicate copies with no noticeable performance problems. @Socks has probably used even more in some of his simulated 3D projects.

Yeah, I'll often used dozens, even hundreds.

AlchimiaStudios

@Hopscotch @Socks I'll probably end up doing some testing/profiling of mine own, but does replicate performance seem to be heavily effected by the amount of logic within the actor being replicated?

I know I've used it on one scene where it would start to drop frames with about 200-300 replications (3 diff actor types with 50-100 replicates each) all using a fairly complex equation for rotation. But other factors on the scene may have been affecting it.

jamie_c

@AlchimiaStudios, Replicate only replicates the actors image and none of their behaviors so I don't think the amount of logic used in the actor would have any effect at all.

Hopscotch

@AlchimiaStudios

As @jamie_c says, it only draws a copy of the image to the replicated positions. 200-300 replications is nothing.

See my table project I referred to above, with 6000 replications, on top of 20 constrains to table values, complex calculations, etc. while still maintaining 60FPS.

AlchimiaStudios

@jamie_c said:
@AlchimiaStudios, Replicate only replicates the actors image and non of their behaviors so I don't think the amount of logic used in the actor would have any effect at all.

@Hopscotch said:
@AlchimiaStudios

As @jamie_c says, it only draws a copy of the image to the replicated positions. 200-300 replications is nothing.

See my table project I referred to above, with 6000 replications, on top of 20 constrains to table values, complex calculations, etc. while still maintaining 60FPS.

Thanks you two! Love the clever workaround for real-time blending modes.

Socks

@jamie_c said:
@AlchimiaStudios, Replicate only replicates the actors image and none of their behaviors so I don't think the amount of logic used in the actor would have any effect at all.

One thing you should watch out for though is that Replicate replicates Replicate !

That is to say if you had an actor and you replicated 10 copies upwards (90°), you would end up with - of course - 10 copies.

If you then added a second Replicate behaviour below the first one, set to replicate another 10 copies to the right (0°), you would end up not with 20 copies, but with 100 copies.

Of course it would be obvious enough to see with the above example, as you'd see a 10 x 10 grid of copies, but with other non-grid replicate tasks it's good to remember that the second Replicate behaviour replicates all the copies of the first Replicate, not just the original actor.

Socks

@Hopscotch said:
By the way, it is @adent42 's fault

Agreed. Sprite sheets are just within reach, but like so many things they are so cruely kept from us poor GS developers. Being able to alter the horizontal and vertical anchor (the tiling offset) would open up a whole world of cool options like sprite sheets and easy to implement parallaxing and all sorts of great special effects.