BluepointVance's Forum Posts

  • I can't for the life of me get this to work.

    Using Xaudio I want to play an engine thrust-type sound as long as a key is pressed. Then stop it when you let go of the key (think Asteroids.) But no matter how I try it, I end up getting an annoying "Click" noise at the start and stop of the sound that doesn't exist in the original wav file.

    Here is the cap with the sound:

    https://www.sugarsync.com/pf/D283703_6063149_98502

    Sound gets cashed at the start of layout, then:

    + MouseKeyboard: Key Space is down

    + System: Every 260 milliseconds-> XAudio2: Autoplay file AppPath & "boostshorter.wav" (No loop)

    The sound file itself is about 269 milliseconds long. But if I set it to repeat at 269 I get clicks all over the place.

    As it stands now, first time you hit the space bar, the sound will come on WITH NO CLICK. But then when you let go of the space bar you get the CLICK. And from then on it CLICKS at the start and end of the sound without fail.

    Any idea what am I doing wrong? Any suggestions?

  • No need to calculate the angle. Just give the bullets the physics behavior and the kickback from the bullets hitting the player will be handled automatically.

    Here's an example of what I'm suggesting:

    http://dl.dropbox.com/u/5426011/examples3/space.cap

    Strange... In that space.cap -- When I just run it, there is no kickback at all. But if I change the red ship's collision mask from "custom" to "bounding box" it works perfectly. I've got no idea why... I'm running Construct 0.99.96. Weird.

    Anyway, I think this "physics bullet" route is the one to take. Thanks R0J0hound and Newt! Gotta go be sociable for Christmas now. Damn.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I solved part of it... The problem was the amount of force being applied.

    When I set it to a normal amount of force (250-400, about the same amount the ship gets when you're thrusting) the ship refused to move. But if I upped that amount to say, 100,000 -- suddenly the ship moved just a little bit as desired.

    I think this might have to do with the amount of time before the bullet is destroyed (a tick, two?) -- Because when I removed the bullet destroy action and just let the bullet fly right through the player's ship, suddenly the ship would move -- even at low force values of 200 or so... I *think* because the bullet and ship are interacting for more ticks in that scenario. (This is all just my guess, what the hell do I know??)

    Anyway, the code to move the ship now looks like this:

    Ship1: Add force 100,000 towards (Ship1.X + cos(Bullet.Angle), Ship1.Y + sin(Bullet.Angle))

    Seems to work anyway...

    But I also need to apply some amount of torque to the ship so it's angle is changed as well as it's force... The net result of these two lines of code should be a physics version of the "bounce" action from custom movement.

    Unfortunately, I can't figure out how to calculate the angle of the bullet vs the angle of the ship to make that torque direction look believable.

    Is there a way to do that?? I'm guessing by using math which I suck at?? Thoughts???

  • Again this would easily be solved by the custom movement behavior, bullet on collision with ship, ship bounce.

    Also I don't think the bullets destruction is the problem. The bullet's information is still available, as long as its within the same event.

    If this is just for effect, I would suggest a camera shake. Linkmans camera plug does this quite well.

    Tried custom movement and bounce... Ship wouldn't move. Possibly because I have physics on the ship? Tried set force towards and add force towards -- also does absolutely nothing... I'm totally confused... Any other ideas?

    Also this isn't really for effect, it's an actual gameplay mechanic that you get knocked back or to the side when your ship is shot.

    The only thing I can think is to add the physics behavior to all the bullets -- and then give them a large mass. I guess I'll try that out, unless anyone has a better suggestion.

  • In the Space Wars-type game I'm doing, I want to make it so when a bullet collides with a ship, it imparts some amount of force -- i.e. the ship gets knocked back a little.

    The ships are set up with the physics behavior, so I figured I could just use the ADD FORCE TOWARDS action -- with the angle being the angle of the bullet... Unfortunately when I try this, it seems to do nothing at all... I think *maybe* because the bullet is destroyed immediately afterwards..?

    Is there a smarter way to be doing this? I'm I approaching it incorrectly?

    I kept thinking maybe I should be storing the bullet trajectory in a variable and using that -- not that I'd actually know how to do that... It just sounded good in my head.

    Any advice?

  • Hi all!

    I'm trying to custom my "ghost shooter" game from the tutorial.

    Instead of repeatly click the mouse button to shoot, i've done this :

    Then I just have to keep the mouse button down to make my character shoot.

    The bullet is supposed to appear to the character image point "canon", but when I press the mouse button, only the first bullet appears to this point.

    The other ones appear on the center of the character sprite instead of its image point "canon".

    Does someone could help me about this?

    Thank you very much.

    My guess is, you've got the "canon" image point set for the first frame of your "shooting" animation, but not for the subsequent frames.

    From the layout editor, double click on your mainCharacter sprite to load it up in the picture editor. You should see all the available frames for this sprite along the bottom there. Cycle through them and check to see if your image points are in the right place on every frame.

  • 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!