Legacy GM Prevent player from "outrunning" diagonal bullets?

[Spin Attaxx]

So I have a 2D platformer with eight-way shooting. Shooting up/down/left/right while moving works fine, but when it comes to shooting diagonally while moving, it looks a little awkward. It's kind of hard to explain, but when the view is moving, it makes it look like the shots are moving at a higher angle than they actually are (and that they're coming out of my head and not my hand). Playing a game with a similar setup, Super Metroid, I notice that it doesn't have this issue - even if the screen is moving, the bullets still look like they're travelling on the same angle and aren't curving upwards/being fired out of my head.

So what should I do about this? I feel like the answer lies in affecting the way my bullets fire, but I tried making my bullets' x move based on my player's speed when it was created, but that made it actually curve up at a different angle as opposed to simply looking like it. Here's my code:

Player shooting code:

//xx and yy are the player's hand.
if (key_shoot) && (can_shoot == true)
{
   inst = instance_create(xx,yy,obj_bullet);
    inst.direction = dir; //dir is decided in a different script; 45, 135, 225 and 315 are my "aim diagonally" values
}

obj_bullet Create event:

speed = 25;

Apologies if I'm asking a stupid question that has a simple answer, or if I didn't quite do a good job of explaining the problem.

 

[BeastyBoy]

change the angles

 

[Spin Attaxx]

By "change the angles", do you mean "change them while you're firing diagonally and moving"? Seems like that'd look a tiny bit awkward if you were to do that, and then stop moving while a bullet you just fired is on screen.

As a side note, I changed the speed of my bullet, and it does look less awkward now, but I don't think it's necessarily the right way to go about this (what if I want slow projectiles?).

 

[Zaeith]

You could try increasing the speed of the bullet with reference to the velocity of the player. So, if the player is moving at a speed of 25 to the right then the bullet could start at the player's speed + the speed of the bullet. You could also try lowering the angle to be closer to the x-axis. That is, instead of 45 degrees or 315 degrees, use 30 degrees and 330 degrees. Do such might fall outside your "eight-way shooting" scope.

Bullets travelling in the same direction as the player will appear slower than bullets moving in the opposite direction. Bullet moving on diagonals will be moving even slower. Looking at a unit circle the position of a bullet moving to the right at a speed of X where X = 25 pixels will be 25 pixels away from the y-axis. While, a bullet moving at a 45 degree angle will be roughly root(2)/2 * 25 pixels away or around 17.678 pixels away from the y-axis. (I'm not extremely confident in my math, so someone please correct me if I am wrong)

So, over time after four steps, rounding the numbers the position of the bullet from position (0,0) should be as follows..

A bullet fired to the right: (25,0) - (50,0) - (75,) - (100,0) pixels
A bullet fired to the right at 45 degrees: (18,18) - (36,36) - (54,54) - (72,72) pixels

With that in mind, the bullets are moving as you have coded them ...and there are some options to attack your problem.

 

[Spin Attaxx]

I added this to my code, and It's making the shots move at different angles.

inst = instance_create(xx,yy,magic_grid[#cur_element,0]); //Create default shot of current element
        inst.direction = dir;
        if (sign(hsp) == 1) inst.speed = inst.speed + hsp;
        if (sign(hsp) == -1) inst.speed = inst.speed - hsp;

Since showing is probably better than telling for this, here's a gif of what happens with the above code in play. It's using a different weapon with a slower speed (but still faster than my player's speed), but the principle applies.

Spoiler

Note how one of them moves differently to the rest. Ideally, I want my shots to fire the same way/at the same angle regardless of if you're moving or standing still.

 

[TheouAegis]

Only thing I can think of to try differently is add the player's momentum to the bullet. But i forsee odd, adverse effects with that.

 

[Spin Attaxx]

Only thing I can think of to try differently is add the player's momentum to the bullet. But i forsee odd, adverse effects with that.

Yeah, I tried that and gif'd the results above. This is basically what I'm trying to achieve:

Note how, unlike my example, the bullets aren't that fast, yet there's no issue with the way they travel while I'm running. They're at the same angle while I move, I'm not outpacing them as they travel diagonally, etc. It's weird; adding momentum to them seems like the obvious answer, but it doesn't look like it is.

 

[Roderick]

Yeah, I tried that and gif'd the results above. This is basically what I'm trying to achieve:

Note how, unlike my example, the bullets aren't that fast, yet there's no issue with the way they travel while I'm running. They're at the same angle while I move, I'm not outpacing them as they travel diagonally, etc. It's weird; adding momentum to them seems like the obvious answer, but it doesn't look like it is.

In that screenshot, Samus never moves. Everything else - the bullets, the enemies, if there were any, and even the background - are all moving relative to a fixed position main character.

To mimic that effect, you'd need to use a view port that kept the character locked in a specific spot on the screen.

 

[Bingdom]

I'm not sure how you are shooting but try make the shooting the very last thing you do in a step.

So you would put all of your movement code in a 'Normal step event'.

Put the shooting code in a 'End Step' event.

What is currently happening with your code is that the bullet is spawning at the current x and y coordinates, then the player moves.

 

[TimothyAllen]

In your players endstep you could do:

with (obj_bullet)
{
    x += other.x - other.xprevious;
    y += other.y - other.yprevious;
}

It will look correct... but when it comes to shooting things, who knows what it will feel like until you test it out.

 

[Spin Attaxx]

In that screenshot, Samus never moves.

Except... she does? Like, I'm at the centre of the view in that screenshot; I only cropped it to the relevant part. She's able to go to the sides of the room when she reaches them, it's not like she's strictly only ever in the centre of the screen at all times.

I'm not sure how you are shooting but try make the shooting the very last thing you do in a step.

So you would put all of your movement code in a 'Normal step event'.

Put the shooting code in a 'End Step' event.

What is currently happening with your code is that the bullet is spawning at the current x and y coordinates, then the player moves.

In your players endstep you could do:

with (obj_bullet)
{
    x += other.x - other.xprevious;
    y += other.y - other.yprevious;
}

It will look correct... but when it comes to shooting things, who knows what it will feel like until you test it out.

I did both of these (putting my shooting code in an End Step event and adding that With statement in)... and it's still not working. I keep outrunning my shots when I fire them diagonally and they look like they're travelling at a different angle.

 

[Jezla]

I added this to my code, and It's making the shots move at different angles.

inst = instance_create(xx,yy,magic_grid[#cur_element,0]); //Create default shot of current element
inst.direction = dir;
if (sign(hsp) == 1) inst.speed = inst.speed + hsp;
if (sign(hsp) == -1) inst.speed = inst.speed - hsp;

Since showing is probably better than telling for this, here's a gif of what happens with the above code in play. It's using a different weapon with a slower speed (but still faster than my player's speed), but the principle applies.

Try adjusting just the bullet's hspeed instead of the total speed.

 

[Spin Attaxx]

Try adjusting just the bullet's hspeed instead of the total speed.

Tried this; the shots travel at wonky angles.

I'm seriously stumped as to what I'm doing wrong that the games I mentioned/giffed earlier do right, so that their bullets move at the correct angle while fired when the player is moving without needing to adjust their speed or angle or anything.

 

[Zaeith]

In many games, as the player moves the bullets will bunch up or spread apart from their normal pattern. In your example, the bullets do not bunch up and probably don't spread as the player moves away. As @Roderick is saying, the bullets are travelling in relation to the player. It means that the bullet's position is changing relative to the player's position and almost absolute. So, if the player is standing still and shooting at an angle, the bullets will looks fine... but as the player moves the bullets will also move. The issue with this is that if the player changes directions the bullets should continue their course, so keep that in mind.

@Spin Attaxx again just to clarify, the issue we are seeing is that in your game is the Bullets are moving in relation to the Bullet's position in the game world vs the Metroid example where the bullets are moving in relation to the Character.

To get something moving in relation to another object you could use something like...

inst_bullet.x = obj_player.x + inst_bullet.speed;

// Where obj_player is your player object and inst_bullet is an instance of your bullet object
// Remember, you'll want to remove this relation if the player changes directions

 

[Spin Attaxx]

To get something moving in relation to another object you could use something like...

inst_bullet.x = obj_player.x + inst_bullet.speed;

// Where obj_player is your player object and inst_bullet is an instance of your bullet object
// Remember, you'll want to remove this relation if the player changes directions

Put this in my shooting code (in the instance_create block), and I still outrun my bullets unlike in the Metroid example. Nothing's changed (well, aside from the fact that if I fire while facing right, my shots spawn just behind me before going in the right direction).

 

[TimothyAllen]

Except... she does? Like, I'm at the centre of the view in that screenshot; I only cropped it to the relevant part. She's able to go to the sides of the room when she reaches them, it's not like she's strictly only ever in the centre of the screen at all times.




I did both of these (putting my shooting code in an End Step event and adding that With statement in)... and it's still not working. I keep outrunning my shots when I fire them diagonally and they look like they're travelling at a different angle.

Tested what I posted and it worked just fine.

Edit : note that it should be called after the player moves.

 

[Spin Attaxx]

Tested what I posted and it worked just fine.

Edit : note that it should be called after the player moves.

I added this:

if (move != 0)
{
        with (inst)
        {
            x += other.x - other.xprevious;
            y += other.y - other.yprevious;
        }
}

Aaand it still doesn't work. I fire diagonally while moving, the bullets look like they're coming out of my head at 67 degrees and not 45 unless I stop.

 

[TimothyAllen]

Post your move code, shoot code, and the above code as they are in your game currently.

Aaand post the event that each is in if they are in seperate events.

 

[Spin Attaxx]

OK.

Step Event:

//Normal Movement
move = key_left + key_right; //move = -1 if left, 1 if right, 0 if both/neither.
if (move != 0 && sign(move) != sign(hsp)) //If move isn't 0 and the sign of move isn't that of hsp...
{
    hsp = -hsp; //...hsp equals negative hsp.
}
if (hsp < move * movespeed) hsp += fric; //If hsp is less than movespeed (positive), add fric.
if (hsp > move * movespeed) hsp -= fric; //If hsp is more than movespeed (negative), subtract fric.
if (move == 0) hsp = 0; //If not moving/move is 0, set hsp to 0.

End Step Event:

//Shoot
var xx = x + lengthdir_x(25,dir);
var yy = y - 32;

if (state == "DUCKING") var yy = y + 16;

if (key_shoot) && (can_shoot == true)
{  
    //Create Bullet
    inst = instance_create(xx,yy,obj_bullet); //Create default shot of current weapon
    inst.direction = dir; //dir is decided in a different script called in Step Event
    if (move != 0)
    {
        with (inst)
        {
            x += other.x - other.xprevious;
            y += other.y - other.yprevious;
        }
    }
}

 

[TimothyAllen]

The code I posted should be outside you shoot condition. So the bullets get updated each step. Use obj_bullet as the with argument not inst.

Edit: and needs to be AFTER you move the player. You didn't post movement like I asked. So can't say you are doing it already or not. (Setting hsp is not moving the player at that moment)

 

[Spin Attaxx]

The code I posted should be outside you shoot condition. So the bullets get updated each step. Use obj_bullet as the with argument not inst.

Edit: and needs to be AFTER you move the player. You didn't post movement like I asked. So can't say you are doing it already or not. (Setting hsp is not moving the player at that moment)

Forgot to add an "x += hsp" there; that was a little closer to the bottom. But my shooting code is now in the End Step event, so it should be after I move the player.

Anyway, I tried it and if I fire and move, my shots automatically curve, even if I've already fired them. Also, something someone else I've asked about this pointed out: given that my shots spawn relative to my sprite (specifically 25 pixels away from the centre), is it possible my animated sprite is throwing xx and yy off?

 

[TheouAegis]

Okay, I was going to try cracking Super Metroid's code to see how they did it, but just after a couple minutes in the tutorial stage (the ruined space station), it was immediately clear what they did.

When Samus moves, the bullet's position is moved as well.

if keyboard_check(RIGHT_KEY)
{
    x += hspd;
    with obj_samus_shot
        x += hspd;
}

This is literally all that happens and it actually causes a bug in the game. Start up a new file and drop down to the very bottom of the first shaft in the tutorial stage. Fire your beam to the right. It explodes upon immediate collision. Now hold down your shot button so it autofires and step right a few times. If you time it right, the bullets will skip over the first collision and explode on the next collision point (right under the door). This doesn't always happen, so I'm not sure why it bugs out there.

Quit liking this post! I eventually cracked the game code and have said in more detail what happens. Keep reading; nothing to see here!

Note also that the explosion is not moved, only the bullet. So if the bullet hits a collision point and then Samus moves, the explosion will stay in the position in the view.

 

[HayManMarc]

Make your bullets move relative to the view instead of to the room. It is the changing of the view as your character moves that makes the bullet appear to travel weird. Look up view_xview in the help doc (and other functions related to views) for more info.

 

[Yal]

When Samus moves, the bullet's position is moved as well.

An interesting find. You'd think it would allow for more gamebreaking, but I guess that since all movement in Super Metroid is relatively slow-paced (and the view is really 'zoomed in' compared to, say, Axiom Verge or the Igavanias), the effect isn't that noticeable.

It's kinda interesting to think about whether this was implemented to make diagonal shooting look better, or if it's an oversight when implementing scrolling... the way the SNES - and NES for that matter - works, you'd actually scroll the level rather than the character. The HUD in Castlevania and Super Mario Bros both are made from tiles that simply aren't scrolled, which adds a limitation that it can't overlap with tiles. Metroid 1's HUD is made from sprites instead to allow for this, which is necessary with vertical scrolling... and it's also why it's a lot more barebones, because the NES had limitations to how many sprites could overlap in a vertical region. Darkwing Duck also uses sprites, which is why the HUD has exactly two elements - your life heart and your active weapon (you even have to pause to check how much ammo you have if I remember correctly).

 

[TimothyAllen]

When Samus moves, the bullet's position is moved as well.

if keyboard_check(RIGHT_KEY)
{
x += hspd;
with obj_samus_shot
x += hspd;
}

What I suggested a while ago. He claims it doesn't work (though I tested it and it does).

In your players endstep you could do:

with (obj_bullet)
{
    x += other.x - other.xprevious;
    y += other.y - other.yprevious;
}

It will look correct... but when it comes to shooting things, who knows what it will feel like until you test it out.

 

[Spin Attaxx]

Okay, I was going to try cracking Super Metroid's code to see how they did it, but just after a couple minutes in the tutorial stage (the ruined space station), it was immediately clear what they did.

When Samus moves, the bullet's position is moved as well.

if keyboard_check(RIGHT_KEY)
{
    x += hspd;
    with obj_samus_shot
        x += hspd;
}

This is literally all that happens and it actually causes a bug in the game. Start up a new file and drop down to the very bottom of the first shaft in the tutorial stage. Fire your beam to the right. It explodes upon immediate collision. Now hold down your shot button so it autofires and step right a few times. If you time it right, the bullets will skip over the first collision and explode on the next collision point (right under the door). This doesn't always happen, so I'm not sure why it bugs out there.

Note also that the explosion is not moved, only the bullet. So if the bullet hits a collision point and then Samus moves, the explosion will stay in the position in the view.

Huh, that's interesting. I didn't know that. Trying it out myself, it does seem that running, firing a shot, and stopping causes the bullet to go in a different angle compared to just firing it normally.

What I suggested a while ago. He claims it doesn't work (though I tested it and it does).

This is what happens:

Spoiler

You told me to put your code in the player's End Step event (and my movement code is in the regular Step, so this is after they move), and my bullets curve completely based on if I'm moving or not.

 

[TimothyAllen]

If you don't want it to also adjust y, then take it out.

 

[Spin Attaxx]

If you don't want it to also adjust y, then take it out.

OK, I think I'm getting close to a solution here. Now the shots don't curve as drastically, but their direction still changes as I move (it curves up if I shoot it diagonally left then run right, for instance), as opposed to it being decided on creation and staying unchanged for as long as they're onscreen.

EDIT: Also, if I fire it straight ahead in one direction and run the other way, the shot slows down for as long as I'm moving in the other direction. I think the problem is that this is being done in the End Step event as opposed to when the bullet is created (hence why it curves/speeds up/slows down if my hsp changes after firing it), but putting it in the bullet creation event does nothing (except take me back to square one with this issue).

 

[TheouAegis]

Also, if I fire it straight ahead in one direction and run the other way, the shot slows down for as long as I'm moving in the other direction. I think the problem is that this is being done in the End Step event as opposed to when the bullet is created (hence why it curves/speeds up/slows down if my hsp changes after firing it), but putting it in the bullet creation event does nothing (except take me back to square one with this issue).

Wait, I'm not sure what the hell actually was happening in Super Metroid, but I tried again and noticed a couple things:

The bullets aren't affected by vertical motion. I shot diagonally while jumping. The bullet would be BELOW Samus's gun when jumping up. When falling, the bullet would be ABOVE her gun.

The bullets seem to only be affected by Samus' horizontal speed when they leave her gun. So in that first corridor, only bullets fired when samus is moving (and slowing to a stop) will skip that first collision. Any bullet fired before she starts moving will hit the first collision point.

Update: (okay, so I never did post before I got to this update) I peeked at the code, or rather, I peeked at the RAM values. Samus' hspeed is added to the bullet's hspeed. So the bullet is created with an hspeed of 2 diagonally, 4 straight ahead. If Samus is running, it adds 2. Moonwalking doesn't seem to affect the bullet's speed, though. Either that, or I just didn't test it right. I used SNES9XDebugger and I couldn't find a way to do conditional breakpoints.

Update 2: The bullets actually accelerate. You probably never noticed that (I don't think anyone did) because the difference is negligible. And so does Samus, which you probably noticed. The bullet's speed is affected by the integral value. So when Samus moonwalks, her speed is less than 1, so the bullet has 0 added to its speed. When Samus steps forward, she has a speed of 1, so the bullet has 1 added to its speed. When she's running, she has a speed of 2, so the bullet has 2 added to its speed. Also, when falling or jumping, Samus' speed is 1.

 

[Spin Attaxx]

Update: (okay, so I never did post before I got to this update) I peeked at the code, or rather, I peeked at the RAM values. Samus' hspeed is added to the bullet's hspeed. So the bullet is created with an hspeed of 2 diagonally, 4 straight ahead. If Samus is running, it adds 2. Moonwalking doesn't seem to affect the bullet's speed, though. Either that, or I just didn't test it right. I used SNES9XDebugger and I couldn't find a way to do conditional breakpoints.

Update 2: The bullets actually accelerate. You probably never noticed that (I don't think anyone did) because the difference is negligible. And so does Samus, which you probably noticed. The bullet's speed is affected by the integral value. So when Samus moonwalks, her speed is less than 1, so the bullet has 0 added to its speed. When Samus steps forward, she has a speed of 1, so the bullet has 1 added to its speed. When she's running, she has a speed of 2, so the bullet has 2 added to its speed. Also, when falling or jumping, Samus' speed is 1.

OK, but I'm still not sure on how to make that work for my game, since my character moves faster than one pixel per frame (it accelerates up to 10). Also, I have a weapon that's meant to move slowly (its speed is 15; my default weapon is 25), but be more powerful. Increasing its speed kinda defeats that, but as-is if I fire it while moving, it looks like it's coming out of my character's head and not her hand (or at least where her hand would be) as it does when I'm standing still.

 

[Yal]

You could always have the recoil from the heavy weapon stop/knock back the player so that they can't run while firing it, that way you'd avoid those graphical issues AND the gameplay issues of being able to 'boost' the projectiles. The weapon will also FEEL more powerful if you're visibly affected by the recoil. Just don't overdo the recoil so much that you end up falling off ledges a lot.

 

[TheouAegis]

Then add 10 to its speed. Or don't.

You cited Super Metroid as a reference. I'm telling you what your reference did to handle this problem. The horizontal speed of the player was added to the bullet's speed upon creation. The vertical speed was added to the bullet's speed upon creation if shooting up or down, but only when shooting vertically - thus when shooting horizontally the bullets do not come out of the gun.

The physics of Super Metroid are akin to real-world physics. The speed of the shooter is added to the speed of the bullet. That's how things work in the real world. That's why in the game of cricket the hurler runs.

 

[HayManMarc]

If you want to maintain the same angle at all times, I'm pretty sure you'd have to update the bullet speed per step in relation to the character.

Or just move the bullet across the "view" instead of the "room", using "view" coordinates (view_xview, view_yview).

 

[Spin Attaxx]

Then add 10 to its speed. Or don't.

You cited Super Metroid as a reference. I'm telling you what your reference did to handle this problem. The horizontal speed of the player was added to the bullet's speed upon creation. The vertical speed was added to the bullet's speed upon creation if shooting up or down, but only when shooting vertically - thus when shooting horizontally the bullets do not come out of the gun.

The physics of Super Metroid are akin to real-world physics. The speed of the shooter is added to the speed of the bullet. That's how things work in the real world. That's why in the game of cricket the hurler runs.

OK, I've changed my shoot code to be this:

var xx = x + lengthdir_x(25,dir);
var yy = y - 32;
if (key_shoot) && (can_shoot == true)
{   
    //Create Bullet
    inst = instance_create(xx,yy,obj_bullet); //Create default shot of current weapon
    inst.direction = dir;
    if (dir == 90 || 270)
    {
        if (sign(vsp) == 1) inst.speed += vsp;
        if (sign(vsp) == -1) inst.speed -= vsp;
    }
    else
    {
        if (sign(hsp) == 1) inst.speed += hsp;
        if (sign(hsp) == -1) inst.speed -= hsp;
    }
}

It works OK, though the angle it moves at when fired diagonally and moving is still slightly suspect (hat may just be due to where the bullets are created at and/or my character's speed in relation to that of the shots):

Spoiler

Not sure what to do about the vertical issue though. I tried doing this, but it ended up affecting my horizontal shot speed too, even if it wasn't fired in the stated directions:

if (dir == 90 || 270)
{
    if (sign(vsp) == 1) inst.speed += vsp;
    if (sign(vsp) == -1) inst.speed -= vsp;
}
else
{
    if (sign(hsp) == 1) inst.speed += hsp;
    if (sign(hsp) == -1) inst.speed -= hsp;
}

 

[sndfnts]

You could think relatively and look at objects from a different perspective. For example, if you attach the camera to the player, the illusion is that the player is standing in place while the whole world moves instead.

Now you want to fire a bullet traveling 25 mph at 45 degrees while you are moving 10 mph to the right. If the camera is attached to the player, the projectile appears to be traveling at that exact speed and direction (25 mph at 45 degrees). However, the bullet is probably traveling at a different speed from an outsider's viewpoint. The outsider would see the bullet travel with the desired speed plus the speed of the moving player (25 mph at 45 degrees + 10 mph to the right). The basic principle is "actual momentum = your momentum + desired momentum". To keep it simple, we will ignore some aspects of momentum and keep it to "actual velocity = your velocity + desired velocity"

For your original player code (if you're still using it), set the desired speed and direction of the bullet and then add the speed (vspeed, hspeed if necessary) of the owner:

if (key_shoot) && (can_shoot == true)
{
  inst = instance_create(xx,yy,obj_bullet);
    //from your create event, the speed is already set
    inst.direction = dir;
    //this assumes that setting speed and direction also sets vspeed and hspeed
    inst.vspeed = inst.vspeed + vspeed; //add your momentum to the bullet
    inst.hspeed = inst.hspeed + hspeed;
}

You may need to break up the desired speed (direction, speed) into horizontal and vertical speed (vspeed, hspeed) by using lengthdir_x(spd, direct) for hspeed and lengthdir_y(spd, direct) for vspeed.

 

[Spin Attaxx]

if (key_shoot) && (can_shoot == true)
{
  inst = instance_create(xx,yy,obj_bullet);
    //from your create event, the speed is already set
    inst.direction = dir;
    //this assumes that setting speed and direction also sets vspeed and hspeed
    inst.vspeed = inst.vspeed + vspeed; //add your momentum to the bullet
    inst.hspeed = inst.hspeed + hspeed;
}

You may need to break up the desired speed (direction, speed) into horizontal and vertical speed (vspeed, hspeed) by using lengthdir_x(spd, direct) for hspeed and lengthdir_y(spd, direct) for vspeed.

I've added this, and the result is that if I jump and shoot, my shots fly all over the place if I try and shoot straight ahead.

As an addendum to my last post, it feels like my diagonal shots/moving shots in general are moving faster than they comfortably should.

 

[DeathandGrim]

The trick is that Samus's position isn't changing in the view so it looks like it does.

Yeah, I tried that and gif'd the results above. This is basically what I'm trying to achieve:

Note how, unlike my example, the bullets aren't that fast, yet there's no issue with the way they travel while I'm running. They're at the same angle while I move, I'm not outpacing them as they travel diagonally, etc. It's weird; adding momentum to them seems like the obvious answer, but it doesn't look like it is.

So you'll have to manipulate the bullets to stay relative to the position they appear in the viewpoint. Essentially a fixed viewpoint trick

 

[Spin Attaxx]

The trick is that Samus's position isn't changing in the view so it looks like it does.


So you'll have to manipulate the bullets to stay relative to the position they appear in the viewpoint. Essentially a fixed viewpoint trick

How would I go about doing that?

 

[HayManMarc]

Try this bit of code:

if (key_shoot) && (can_shoot == true)
{
    // get player's coordinates relative to the view (+ where you want the bullet to start relative to the player)
    var vx, vy;
    vx = player.x - view_xview[0] + lengthdir_x(25,dir);
    vy = player.y - view_yview[0] - 32;

    // create bullet at desired position relative to player using the view coords
    inst = instance_create(view_xview[0] + vx, view_yview[0] + vy, obj_bullet);
    with (inst)
    {
        // set bullet's hspeed and vspeed (This bit is pseudo-code)
        // however you set the bullet speed according to the direction you want the bullet to travel.
        (bullet hspeed) = (?);
        (bullet vspeed) = (?); // (bullet hspeed) and (bullet vspeed) = whatever variable names you gave to the bullet's hspeed and vspeed.
}

in the bullet CREATE event:

// assign the beginning coords to new variables
vx = x;
vy = y;

In the bullet BEGIN STEP event:
 // update the vx and vy variables
vx = x;
vy = y;

In the bullet STEP event:

// manipulate the bullet's movement by using the view coordinates
vx = view_xview[0] + (bullet hspeed); // (bullet hspeed) and (bullet vspeed) = whatever variable names you gave to the bullet's hspeed and vspeed.
vy = view_yview[0] + (bullet vspeed);
x = vx;
y = vy;

I have not tested this.
Be sure to substitute in your real code in place of the pseudo-code for determining bullet h- and v-speeds. I hope it works for you.

Edit: forgot to update the vx and vy variables to have the new coords. Should be in the bullet's BEGIN STEP event.

Edit 2: this all assumes you are using views. I forgot to add the view number to the view_xview constants. They should be: view_xview[0], view_yview[0] --- or whatever view number you are using.

 

[Spin Attaxx]

Try this bit of code:
//code
I have not tested this.
Be sure to substitute in your real code in place of the pseudo-code for determining bullet h- and v-speeds. I hope it works for you.

Tried this, and as soon as the bullet is created, it immediately warps to the top left corner of the view. I only have one speed variable for my bullets and not hspeed and vspeed variables.

The problem must lie with them, since my alternate bullets haven't been modded, yet they don't teleport.

EDIT: I'm pretty sure it's that STEP vx/vy thing; it sends them to the top of my view + 25 on the x and y axis and they just float there.

 

[HayManMarc]

Try changing the code in the STEP to this:

vx += view_xview[0] + (bullet hspeed);
vy += view_yview[0] + (bullet vspeed);

EDIT: nope, this isn't right either.

In the begin step, change the code to this:

vx = x - view_xview[0];
vy = y - view_yview[0];

Then, change the Step code to:

vx = view_xview[0] + vx + (bullet hspeed);
vy = view_yview[0] + vy + (bullet vspeed);

 

[Spin Attaxx]

Try changing the code in the STEP to this:

vx += view_xview[0] + (bullet hspeed);
vy += view_yview[0] + (bullet vspeed);

OK... now it's hovering in place in front of me, and if I move to the middle of the view it flies away until it's offscreen, but only if I'm moving. Also, it stays on the same height level as me (i.e. if I jump, it goes up with me).

 

[HayManMarc]

Edited last post. If that doesn't work, I'm going to prototype this myself.

 

[Spin Attaxx]

Edited last post. If that doesn't work, I'm going to prototype this myself.

Just noticed, and now the bullet hovers in place directly in front of me (or behind me if I go left). Also, I can't shoot in any direction but to the right anymore.

 

[HayManMarc]

Prototype as promised: https://dl.dropboxusercontent.com/u/46956737/GMC/Diagonal_Shoot_Prototype.gmx.zip

 

[Spin Attaxx]

Prototype as promised: https://dl.dropboxusercontent.com/u/46956737/GMC/Diagonal_Shoot_Prototype.gmx.zip

OK, I've tried reverse engineering this, and when I run it in my game... the shooting works exactly as it did when I first asked this question. It doesn't change angles to keep up with the view, firing them diagonally while moving still gives the illusion that they're coming at a different angle than normal (and that they come out of my head)... nothing's really changed.

 

[HayManMarc]

Sending PM.

 

[TimothyAllen]

Prototype as promised: https://dl.dropboxusercontent.com/u/46956737/GMC/Diagonal_Shoot_Prototype.gmx.zip

This is just a more complicated version of what we have already posted for him.

EDIT: Except if the view ever hits a boundary and stops moving while the player continues to move. Then moving according the view is actually better.

 

[Spin Attaxx]

OK, after messing around wth things, I think I'm finally getting somewhere. Maybe it's not perfect, but I guess this is one of those things where you have to go, "make the rest of the game good and hopefully the player won't notice".

Shoot code:

if (key_shoot) && (can_shoot == true)
{
    //Create Bullet
    inst = instance_create(xx,yy,obj_bullet); //Create default shot of current weapon
    inst.direction = dir;
    inst.hsp += (hsp/2); //hsp is a sperate variable existing with speed. I can change the divide-by number for a more natural angle
}

Bullet Step:

x += hsp; //hsp is set to 0, and changes to half of the player's speed at instance creation

I think the only thing I need to do for shot physics is make my shots go faster when I'm jumping/falling so I don't out-fall them, but I'm not quite sure how to do that (my attempts make horizontal bullets fly all over the place, and apparently putting "if (direction == 90 || 270)" in the shooting code does jack squat since that problem still occurs).

 

[Wraithious]

You could try having the bullets move twords a fixed point on the view boundry in the bullet's step event and when you're near the beginning or end (where your view is no longer moving) increase or decrease the x and y values you're aiming for