Map Collision woes
-
-
@SteveZX81 How did you handle the movement forwards and backwards with arbitrary angled turning? I literally just hit that problem, then I saw this video and said "Steve has already accomplished it" :) Do I need fancy maths to manually calculate the sprite X and Y speeds, or is there a command which handles it?
The wall thing is weird, almost like it's either "polling" for the collision at a not-every-frame rate-- then in one of those gappish "windows" the tank flies forward-- or, the tank is still "moving" in your code, but the map collision is only temporarily disabling the drawing of the sprite.
You're way ahead of me. I plan to implement my first map in the coming days, so I may have more ideas then.
-
@SteveZX81 Never mind, I figured it out!
velocityX = sin(playerDirection) * playerSpeed velocityY = cos(playerDirection) * playerSpeed setSpriteSpeed(player, velocityX, -velocityY)
And I now get a sprite moving about the screen, in the direction it's facing.
-
Note: Not on my Switch right now so syntax may not be 100%, but point is you can do this in a single command.
setSpriteSpeed(player, { sin(player.rotation), -cos(player.rotation) } * playerSpeed)
Assumes your sprite is called 'player'
-
Thanks @Martin , I'll make this change! Is "player.rotation" writable too, or is it read only?
Looking at this, I think there is a lot of removal of unnecessary variables I can probably make. Once I have a working demo, I should post it for a code review :)
-
@Spacemario The sprite engine allows properties to be read or written either directly or via getters/setters so you can do
setSpriteRotation( sprite, angle )
or
sprite.rotation = angle
See https://fuzearena.com/help/view/setSpriteRotation
You can even add your own properties e.g.
sprite.hitpoints = 100
-
@SteveZX81 Sorry Steve we are not answering your question. I think that this might be one for @Dave
-
@Spacemario said in Map Collision woes:
@SteveZX81 How did you handle the movement forwards and backwards with arbitrary angled turning? I literally just hit that problem, then I saw this video and said "Steve has already accomplished it" :) Do I need fancy maths to manually calculate the sprite X and Y speeds, or is there a command which handles it?
The wall thing is weird, almost like it's either "polling" for the collision at a not-every-frame rate-- then in one of those gappish "windows" the tank flies forward-- or, the tank is still "moving" in your code, but the map collision is only temporarily disabling the drawing of the sprite.
You're way ahead of me. I plan to implement my first map in the coming days, so I may have more ideas then.
Hello, tbh the movement code is not mine (I am useless at maths and to this day I do not understand things like sin and cos. it's all Martian to me)
The movement code is like this, first it gets the players angle with
r = getspriterotation(player.spr)
then its moved with this line (that I don't understand if I'm honest)
player.pos += {sin(r),-cos(r)}*3
setspritelocation(player.spr,player.pos)Not sure if that helps you but its what my game uses right now.
-
@pianofire said in Map Collision woes:
@SteveZX81 Sorry Steve we are not answering your question. I think that this might be one for @Dave
No probs, Martin came to my aid (again) and fixed it for me last night. (he said it's not working 100% but it seems great to me and 1000% better than what it was before)
-
Awesome job, @Martin! Steve apologies I wasn't there to help last night.
-
Hello, tbh the movement code is not mine (I am useless at maths and to this day I do not understand things like sin and cos. it's all Martian to me)
Hah, I was just telling my wife the same thing yesterday! "Boy do I suck at math, I don't even know what cos and sin do!" Glad I'm not alone :D
-
@pianofire This is great, thanks! I'm going to do some refactoring tonight; I really like the idea of self-containing all of my player-related properties like this.
-
@pianofire Whao. I can add properties to sprites? Can I add properties to other kinds of variables? Like...
x = 3
x.meta = "foo bar baz"I've seen stunningly beautiful things done with properties that work like this in both Lisp and Smalltalk. Being able to use any object as a namespace could prove stunningly useful in a state machine I'm building currently (though I've decided to wait for the next patch before continuing) because it has a bunch of unfortunately global variables. It's also code that's meant to be pasted into other people's projects, so it would be a real boon to put them all in a variable "globals." E.g.
globals = "A set of globals for Casey's state machine."
globals.currentPosition = 0
globals.lookAhead = 1
globals.etc = "etcetera"Is there a way to get a list of the properties an object has at runtime? E.g. getProperties(globals) -> [.currentPosition = 0, .lookAhead = 1, .etc = "etcetera" ], or even just [ "currentPosition", "lookAhead", "etc" ] would do the trick.
-
@Zero-Division Afraid not. This is currently just a feature of the sprite engine. I suppose you could use a sprite to hold your global variables!. I am not sure on the limits of it either: whether it is just simple types or arrays/structs. I will have to check.
-
@pianofire said in Map Collision woes:
@Zero-Division Afraid not. This is currently just a feature of the sprite engine. I suppose you could use a sprite to hold your global variables!. I am not sure on the limits of it either: whether it is just simple types or arrays/structs. I will have to check.
I suppose the way to do what I want is to use a struct then. It can be very powerful to associate arbitrary properties to arbitrary objects, though. Combined with lambdas, we'd get to OOP pretty fast this way.