I'll keep everything 128x128 for now -- and see where that gets me. I have a feeling that v-ram won't be the bottleneck for this project. (famous last words)

It does help in planning to note that a 70x70 uses the same memory as a 100x100. Never knew that.

Did you stretch it across the whole layout or the just the display? If you set it to the size of the displayed area, and have it on a layer that is set to 0,0 for the scroll x/y rate, then it should be quite efficient.

The display area and layout are the same on this project. 1920x1080.

I'll check the scroll x/y rate and see if that helps. Thanks.

The gradient object has a built in timer.

I'll try it that way... Didn't know that!

You don't have to, but yes editing the images to the least amount of empty space is a good idea.

Saves memory, and you can use bounding box collisions when needed.

Making them in power of two dimensions is even better.

Got it. I'll look into making all this stuff 128x128 or 256x256.

Thanks again Newt!

Make a little white sprite, with a private variable for its opacity time.

Now with a start of layout event set the sprite to 0,0, set its width and height to the screen.(not necessary, just tidier for your layout.)

private variable being 0 set the opacity to 0.

If the pv is greater than 0

-set opacity to 100

-set pv to clamp(whitesprite.value('privatevariable') - 100 * timedelta, 0, 100)

Now, when you want to trigger the flash set the pv to 10 or so.

Cool thanks!

I did this exactly, except I kept using the all-white-layer-visibility for the flash itself. I tried the sprite stretched across the screen and then set to 0 opacity -- but it seemed to drop the frames per second more than using the layer version.

Either way, thanks for the timer code. That'll be really useful in a bunch of places!

Should all sprites be trimmed to their smallest possible size -- removing any border of transparent pixels?

I ask because I make the main sprites (i.e. player ship) and all the addional sprites (i.e. flames for boost, shield images, etc) on one sprite sheet like so:

<img src="http://i232.photobucket.com/albums/ee215/JDoejoe/SpriteSheet.png">

That way when I reassemble them in construct using image points they all line up perfectly.

But that also means that the center "ship" image has a bunch of empty space all around it. Should I be trimming each of these individually, then fiddling with them in construct to make it all line up?

Another way of looking at it is: Does construct use up resources storing and moving all those transparent pixels? Enough so that it's better practice to cut out the excess?

I know the physics behavior takes them all into account unless you make a custom collision mask.

These sprites were made at 400x400, but in game they'll probably end up closer to 100x100. Once they're that small, am I just splitting hairs worrying about transparent pixel trimming?

I'm trying to do a quick flash of white that covers the entire screen...

My solution so far has been to make a layer that is all white and turn it to invisible by default.

Then, when I need it to flash I turn it on...

Turning it back off is the problem.

I want it to stay on for just a moment -- 25 or 50 milliseconds. The way I have it now (totally lame) is I have an Always event running every 25 milliseconds that just turns the layer invisible. This sort of works, but sometime the flash doesn't show up (clearly a timing issue).

I realize this is clearly not the correct way to do this -- and my guess is the answer to this is really simple and obvious -- but for the life of me, I can't figure out how it's supposed to work... Is there the equivalent of a "turn on/wait 25 milliseconds/then turn off." command?

Also, if this runs at 60 frames a second, aren't I going to get different length flashes than if I'm running at 85 frames a second?

Well I got a version of this working. Had a lot of confusion with the turret behavior. I kept trying to switch targets while using the "follow first in range" parameter -- but it would always just lock on to the first created instance of an object, even if it wasn't actually the closest.

I took "first in range" to mean find the closest, and lock on ignoring all others. But it appears to be, find the first created of a particular object and ignore all others regardless of distance.

Switching to the "always nearest" targeting method -- and always clearing all targets before adding new target finally did the trick.

I know have some basic, extremely dumb, but working a.i.!!!!!!!

Thanks CrudeMik and Newt

Yeah the turret behavior was designed to either be attached to something that moves, or stationary, so basically all its good for is attacking.

Quite honestly you'd be better off dropping physics, and using the custom movement behavior, and either using the line of sight behavior, or distance(), with you own attacking/ retreating events.

For the black hole there's even a command that would work well for that "restrain distance from position" If you use a lerp on the distance to restrain, and set it to "distance lower".

Course you would have to have to include a escape velocity condition in there.

Just when I got it all dialed in with physics and turret behaviors!

If I were to stick with physics, I was thinking that I might create several "escape points" and arrange them around the black hole. And then assign them the attribute "escape point." That way, if the ship strayed too far into the "black hole zone", I could tell it to aquire the nearest escape point, target that and add thrust.

<img src="http://i232.photobucket.com/albums/ee215/JDoejoe/SW-Escape.jpg">

Unfortunately, when I try to do this, either with the "follow first in range" or even the "always the nearest" properties it refuses to work. It will only target one of the "escape points" and always the same one. If I then delete that escape point. It'll pick another one and target only that. Regardless of which one is closer.

I even tried dropping attributes in favor makeing the escape points out of families instead. Still the same response.

I must be doing something wrong.

Right now it is:

If Ships Distance to Black Hole lower than 350 > Aquire target "escape point." Add thrust.

If Ships Distance to Black Hole greater than 350 > Go back to hunt and shoot behaviors.

I've tried clearing the targets first, then acquiring the "escape points." Nothing works.

Should I be using the "add object to target" action instead? What's the difference between "add object to target" and "acquire target"? I've tried using both at the same time to no avail.

I wanted to see if something like this could work before I scrapped all the physics stuff I'm doing (there is alot of stuff that right now requires the physics behavior.)

Any thoughts appreciated. Thanks!

Okay, so I got the turret behavior going. And it works great for the "hunt" and "shoot" a.i. -- but I need to do an "Escape Black Hole" a.i. and I'm not sure how.

It might just be something simple.

Like if ship gets within a certain range of the Black Hole, turn 45 degrees away from black hole and thrust. Unfortunately, I have no idea how to turn away from something with turret behavior (and things like "rotate towards" don't look right at all) -- is there a math thing I'm missing?

Do I need to control the ship without turret behavior? I found a "Physics Turret" in another thread:

http://www.scirra.com/forum/viewtopic.php?f=3&t=6611&start=10#p52361

I in no way understand it -- but should I be looking at something like that?

Any other thoughts for a.i. avoidance with physics behavior?

Thanks!

Why not just roll your own wrap code?

I did exactly that. Set up a compare:

ship x greater than 1024 > set ship x to 0.

ship x less than 0 > set ship x to 1024.

Did the same for the y coordinates....

And I ended up with the exact same problem. Ship would hit the edge and then keep bouncing off.

So instead I did it by building in a 5 pixel margin a little off screen like so:

ship x greater than 1034 > set ship x to -5

ship x less than -10 > set ship x to 1029

Works like a charm now. Strange... Must have something to do with the sprites? The way they're drawn, they seem to read as being at less than y=0 and more than y=1024 simultaneously (or very nearly simultaneously, anyway.) So construct just keeps bouncing them back and forth to fast to register, turning the edge into a virtual wall... Does that make sense?

Anyway, thought I mention the work-around in case anyone else ever runs into this.

Also, thanks to Davioware -- I keep forgetting that sometimes I can just solve these problems with a few lines of code... I never think to do my own version if the behavior already exists. I always think that someone else programed the behavior the "right" way, and my version is just gonna screw it up somehow.

I have a problem with the wrap behavior.

When a player's ship approaches the edge of the playfield at a shallow angle, say 15 degrees or less, and at low speed -- the ship refuses to wrap to the other side of the screen and instead just "bumps" off the edge over and over again.

I've tried to change a bunch of settings. Even turned the collision mask OFF. Nothing worked.

I've attached the cap file here. Hoping someone could try it out and tell me what I'm doing wrong.

http://www.mediafire.com/file/jn7hq04u5hz9zrb/WrapProblem.cap

P.S. Left and Right arrows to rotate. Up arrow to thrust.

Hey man, I've toyed with this a bit myself - got a video of my efforts here: http://vimeo.com/16387177

I have a .cap of this here also: http://dl.dropbox.com/u/3317708/SB.zip

I'm no expert, it's all very sticky tape and cardboard.

Thanks so much for sharing your game cap. That really helped!

Based on that and what Newt was saying, I think I should be looking at Turret Behavior (which, of course, never even occurred to me before!) Thanks!