Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / 2d X and Y to movement

Author
Message
BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 13th Oct 2011 17:25
Hello currently I my sprites can only move x and y, since move sprite doesn't seem to work when rotating all of the sprites in the array. I figured I'd need to use trigonometry to make the sprites move in both x and y.

Currently I rotate my sprites to face the player, but I can't move them closer to the player. My player is static and never moves.

Any tips?
Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 13th Oct 2011 18:34
Posting some of your code would help us find the problem.

Sprites are 2D (as you noted in the thread title) so if you can only move by x and y coordinates then you've covered every available direction. Your sprite can move horizontally along the x axis and vertically along the y axis.

In the command MOVE SPRITE the last number is the velocity of the sprite which is how many pixels you wish to move the sprite. MOVE SPRITE however is not the only way to move sprites... the SPRITE command allows you to place the sprite on a specific x and y coordinate.

In this code snip use the left/right arrow keys to change the angle of the sprite and use the up/down arrows to make the sprite move by 2 or stop the sprite.



BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 15th Oct 2011 23:52
Ah forgive my previous post, what I need is a function that will allow a sprite to move to the x and y co-ordinates of the player. Example sprite 2 is on 20, 40 and the player is on 400, 300, I need sprite 2 to move to the player only by changing it's x and y position.

How would I do this without using move sprite?
BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 16th Oct 2011 01:04
Hmm sorry for double post(I can't see the edit button anywhere) but I render my sprite again in the main loop.

Outside the main loop: Create the sprites (array)
Inside the main do loop: Call a function that will create the sprites again.

Doing this will stop move sprite working any more. However if I don't call the sprites again in the main loop, move sprite will work. if I try to move away from the sprites they will get closer much quicker and I can't run away from them. It will gradually get to a point where all the sprites will be same x and y as my player.

Also just background info: whenever I press the arrow keys, for example up, I will move the array y values up 1 and the background y value up 1. The player never moves, the background and everything else does.

How can I solve the issue?
Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 16th Oct 2011 06:21
There's no edit button for you probably because you're still in a Newbie Slap (post approval). Without seeing your code I'm just guessing.

You can move sprite number 2 by the x and y coordinates in the sprite command... to move it towards the player you just need to add an IF/THEN to check the current coordinates of sprite 2 vs where the player is and add to sprite 2's x coordinate if the player x is greater or subtract from the x coordinate if the players x is lower than sprite 2's x coordinate. Do the same for the y coordinate and it'll go to the player. Use the SPRITE command to move the sprite.

What's probably happening is you have variables that are outside the function that you're trying to use inside the function... but because their not defined as GLOBAL they are zero inside the function.

The best way to solve this issue is post your code. I can tell you a million different reasons why it's not working right and only be right on 2% of them... the above is all guesswork without seeing your code.

Use code snips like this:
[ code ]
Your code here.
[ /code ]

Take out the spaces between the brackets and you see this:


BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 16th Oct 2011 14:29
Ah sorry about that, haven't been able to get on my computer with the code on it, but here's a quick demo of what I was trying to do here:

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 16th Oct 2011 16:11
I may be wrong but I THINK... You are using conflicting commands.
First you SPRITE your sprites
Then you MOVE your sprites
Then You sprite them
...etc.
The whole time, DBP doesn't "know" their updated positions since you've moved them so when you SPRITE them again, you put them back where they were before the move.
You need to GET your sprite positions before adding/subbing to them. Will write you a quick example later.

PS: DO NOT USE SPRITE OFFSET UNNECCESSARILY, IT SCREWS WITH ROTATION.

Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 17th Oct 2011 01:21 Edited at: 17th Oct 2011 01:33
I'm betting one of the problems is that you use MOVE SPRITE at .5... so even if you save the current sprites x and y coordinates (but you don't right now) it'll stay in exactly the same spot because all coordinates are whole numbers. There is no such thing as a half-a-pixel. If you make MOVE SPRITE use a 1 instead and save the current sprites coordinates in the enemy array it should work with both SPRITE and MOVE SPRITE.

As NonZero pointed out the SPRITE command you have uses the coordinates stored in the array... but MOVE SPRITE uses the sprites current location internally with SPRITE X() and SPRITE Y()... this way does work but it does not change the coordinates stored in the array. If you unrem the SPRITE command it'll always show whats in the array (the initial coordinates you randomly picked) resetting it back to it's beginning each time.

If you're concerned about the speed of the enemies you can make a timer to allow something to happen after a certain amount of time. With the TIMER() command 1000 = 1 second.

In the following example each box has it's own TIMER() stored because they all may have different delays.



Quote: "PS: DO NOT USE SPRITE OFFSET UNNECCESSARILY, IT SCREWS WITH ROTATION."


He's doing it exactly the way it should be done. He uses OFFSET SPRITE once for the player and once for each enemy... and doesn't do it again.

I am amazed he was able to get away with not defining each variable in the UDT though.

This:


Should be this:


I guess Darkbasic Pro defaults all UDTs to integers.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 17th Oct 2011 12:06
Ah, I see I won't be having to post that tutorial after all... Oh, well, I'll save it for another time.

Quote: "I guess Darkbasic Pro defaults all UDTs to integers"


Lol, I've actually been not bothering to define varia's either for ages because of this. It's a bad habit though XD

You can even take it a step further:


Gone are the days of declaring anything. DBPro saves us a lot of work and teaches us bad habits so that we slowly lose the ability to use any other languages. Another milkman conspiracy!

BTW: Purely academic question, but why bother with any sprite offset? Isn't it easier to center the player with:



rather than:



...Then you wouldn't need to offset anything at all. The reason I ask as I'm always curious about the WHY when I see things being done a different way.

Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 17th Oct 2011 21:28
Quote: "It's a bad habit though XD"


Yeah, a bad habit I'm not going to start.


Quote: "BTW: Purely academic question, but why bother with any sprite offset? Isn't it easier to center the player with:"


I imagine the only reason the OFFSET SPRITE command exists is because of the ROTATE SPRITE command. As you know sprites are just like images and are placed in relation to the upper left corner of the sprite. The ROTATE SPRITE command rotates via that spot so if you rotate a sprite without OFFSET SPRITE it'll go around that upper left corner.

In the following code snip hold down any mouse button to OFFSET SPRITE to it's center and let go to reset it to it's starting position.



Although he doesn't use ROTATE SPRITE with the player I'm sure he will eventually since he's set up the player to prepare to rotate it.

Actually (using his code) I wouldn't use the variables player.width and player.height and use SPRITE WIDTH() and SPRITE HEIGHT() directly.



Quote: "Then you wouldn't need to offset anything at all. The reason I ask as I'm always curious about the WHY when I see things being done a different way."


One of programming greatest strengths is all the different ways to do exactly the same thing. We all may have different methods but ultimately we reach the same goal.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 17th Oct 2011 23:05
Firstly, Grog, thanks for that example. I always enjoy seeing things from a different POV.
I actually had a bad experience when I first tried out DBP where I tried to use OFFSET SPRITE to compensate for different aspect ratios (looong story) and I was using sprite rotation straightforward along with my vector-collision system and the sprite offset wreaked havoc on my collisions...
Consequently I marked OFFSET SPRITE on page 10000 of my brainvault as "bad command" and went back doing things manually using very complex math (which I've since simplified, *sigh*). I never actually thought of implementing OFFSET SPRITE in this way though and it's nice to keep this in mind if it comes up in future projects of mine. Tks again.

Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 18th Oct 2011 01:02
Np. ROTATE SPRITE is actually one of the commands that convinced me to buy Darkbasic Pro so long ago. I saw Classics sprite commands and saw Pro had the ability to rotate them too so I set my mind to getting Pro and if I remember correctly I got it a few days later. ROTATE SPRITE is a lot of fun to play with.



nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 18th Oct 2011 10:04
Yeah, I know. I've actually made use of ROTATE SPRITE a lot more since I started with DarkBasic than I thought I would. But I always used careful maths to reposition sprites after rotating them in stead of using OFFSET SPRITE. All because of one lousy experience with OFFSET SPRITE. Just goes to show how easily we can miss the things in front of us.

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 18th Oct 2011 22:26
Hmm I still can't get it to work, I've made it so the array x and y values are now equal to the sprite x and sprite y values, I have them following me while I'm able to move around the world however they only start chasing the player when they are at a certain y position?

It's best if you run the code:


I appreciate everyone's help
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 19th Oct 2011 12:34
Could be your geometry. If I remember correctly from the topdown shooter I made, it depended on the hemisphere whether your ATANFULL value should be positive or negative. I can't remember my geometry (or anything other than algebra, lol) so I can give you a one line patch that SHOULD fix it. Add this line:



below this line:



This will compensate it. There is, I'm sure, a formula though. Hope this worx!

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 20th Oct 2011 01:17
Hmm after adding the above code under the calculation of the angle, I see no effect am I re-spriteing in the wrong place? They only seem to follow me when i'm on the same y position as them, why is this?
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 20th Oct 2011 17:22
I think there is something buggy in the code. I'll have to copy and paste and analyse it on my machine. Can't say if I'll have enough time to work on it today.

Perhaps, in the meantime, this may help you fix it.


It's a simple code that I made just now to try and figure out any problems with geometry (I wish I remembered high school math better). I'm sure there are unneccessary parts to the formula but it works.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 20th Oct 2011 17:30
Kay, so I have a rework of your code:



The only changes I made was the angle calculation formula and I changed the enemies move speed to 2. Seems to work now with the y-axis, gonna test it with the x-axis later.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 20th Oct 2011 17:38
Okay, 100% working code. Enemies chase you and you can move around x and y.



Enjoy!

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 22nd Oct 2011 14:05
Ah thanks nonZero for helping

I did spot some errors which were easily fixed, however now running the current code there are new introduced problems, for example if you hit up and right you will move faster than going left by itself.

Also is there a reason why move sprite 1 doesn't work instead move sprite 2 does?
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 22nd Oct 2011 21:20
Quote: " Also is there a reason why move sprite 1 doesn't work instead move sprite 2 does? "


Not 100% sure, but it may be related to the angle. You may get different results if you used floating-point variables for your angles. I'm not too clued up on geometry (It's been years since I did any real math).

Quote: " ...for example if you hit up and right you will move faster than going left by itself. "


Are you sure? Doesn't look like it. The enemies do seem to move slower (but that's likely because of the angle change) but the background looks to be scrolling at the same speed.

Will look into thesequestions a little more thoroughly tomorrow and try and give you a more conclusive answer as soon as I can. My head's not quite in the game today.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 25th Oct 2011 15:25
Okay BeastDeath, firstly lemme appologize for the delayed response. My RL character is going through a period of serious turmoil and I was suffering to find a save point (After hours of searching I suddenly realised there are no save points IRL). Anyhow, I survived.

After doing a more thorough exam of the code, the following was determined.

The background doesn't move faster. After staring at it for a while it started to look like it was. Then I timed it with this code at the bottom of the PlayerWorld() function:


First I used just up. I got a return of 2433 (That's 2.4 seconds). Second time I got a return of 2418 (2.4 seconds). But these stats varied by ten of milliseconds so I repeated the experiment multiple times. In some cases UL was higher, others U alone was higher. Conclusion: Definitely and optical illusion.

Secondly, the Speed factor. It is something to do with geometry. When you MOVE SPRITE, you move it by the Velocity# per loop (ie If I set Velocity to 0.5, it will move one pixel every second loop - since it cannot move 1/2 a pixel... At least I think based on my deductions, I haven't looked at the technical docs, only the help files.). Now for some reason that I have failed to fathom, the minimum speed you'll get a result on is 1.5. This could be related to some sort of geometry-thing as setting the speed to 1.4 will cause the enemies to line up at 315degrees from the player. Sadly I am no geometry expert (I hated geometry at HS). My hack 'n slash style formula...

...could also be playing a roll. My suggestion to you is to either do some heavyweight math reading to find a good formula and see if that helps, or start a new thread focused solely on this speed anomaly. Perhaps someone more geometrically-inclined than me can help. Perhaps somebody will even point out something obvious that's staring us both in the face (The number of times I've hit a dead end and been ready to tear my hair out for hours before spotting something as silly as a spelling error is over 9000!). Anyway, I hope this information was in some way useful.

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 26th Oct 2011 20:50
Thanks again nonZero, sorry I haven't been able to reply sooner. I have been debugging with the angles and the speed of move sprite too they seem to lock on angles such as 90, 180 when they do they appear to move the same speed as the player, if you move diagonally you can move faster and run away.

I haven't been able to spot any other errors with the code such as spelling mistakes, the movement is the core to my game I'm making, does anyone or has anyone been able to solve this a different way?
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 27th Oct 2011 01:21
Hi everyone. I haven't read through all of this so sorry if I missed something.

I wrote this a while back. It shouldn't be too hard to manipulate to the way you want, if you want to use it. There is a bit of trig involved but nothing mind bending.



A small note. You can multiply com.xspeed and com.yspeed by variables to increase/decrease the computer's speed. Play around with it and I hope it's what you're looking for.

Login to post a reply

Server time is: 2024-11-24 01:03:53
Your offset time is: 2024-11-24 01:03:53