I have objects equally spaced out and after a certain point...
all the new objects are closer together than the earlier ones but still equally close together to each-other.
How do I do this using only events and calculations?
And no, I do not want to use an active to trace that distance between them because these positions have to be ultra-precise and scalable.
I'm assuming you have two points and you want all the objects to be positioned between those points equally spaced apart.
The algorithm would work like so:
1. Calculate the distance between the points: dist = sqrt((x1-x2)^2 + (y1-y2)^2)
2. Divide by the number of objects to find the spacing: spacing = ( dist / # of objects )
3. Calculate the angle between the two points: angle = atan2(y2-y1, x2-x1) Note: you might have to flip the points around, I can't remember.
4. Use a loop (or whatever you want) to position the objects like so:
X position = cos(angle) * spacing * n
Y position = sin(angle) * spacing * n
I agree with sketchy, its hard to tell what your going for without some kind of diagram.
"all the new objects are closer together than the earlier ones but still equally close together to each-other"
this confused me as to what you actually want to do lol.
[Game design makes my brain feel like its gonna explode.]
Would it help if I told you that the dimension was time and that this was for my guitar hero game and also that changes in distance are actually changes in tempo and that the positions of the objects are measured in milliseconds?
Yes, milliseconds!
Always
Set counter to timer
So if it was at 120 bpm and you had four chrotchets.
They would be at...
0 ms
500 ms
1000 ms
1500 ms
But then after the fourth note for whatever reason you decided to change to 140 bpm, the new notes would have to be at...
2000 ms
2429 ms
2857 ms
3286 ms
That sounds like a real challenge to get all that math to work. Because i feel once you got it up and going it would run slow. Ever thought about using the surface object, and build graphics for the buttons from one long guitar graphic stored outside the program.
Then maybe check for rgb values at spots using an array of some sort. So time is hard coded into the array, ever cell stands for a millisecond.
I don't know if it would even work. but that's how i would try and do it. Just to keep the object count down. It can get out of hand really fast.
Originally Posted by Maltar Draco Would it help if I told you that the dimension was time and that this was for my guitar hero game and also that changes in distance are actually changes in tempo and that the positions of the objects are measured in milliseconds?
Yes, milliseconds!
Always
Set counter to timer
So if it was at 120 bpm and you had four chrotchets.
They would be at...
0 ms
500 ms
1000 ms
1500 ms
But then after the fourth note for whatever reason you decided to change to 140 bpm, the new notes would have to be at...
2000 ms
2429 ms
2857 ms
3286 ms
How do I calculate that?
How'd you calculate the numbers you have in your example? Use the same math.
i still don't fully understand what you are looking to solve for. i don't see the connection between the beats per minute and the spacing of pixels.
All i see is at 120 bpm ever new chrotchet steps by 500ms. To space that example all you need is a simple ratio for spacing pixels. Right now it looks like all have to do is times it by 4.16
but that seems to simple. So i got to wonder if i understand the question correctly. i don't see what i'm missing.
The part you're missing is that fact that at one point it changes and from there in on there the amount you calculate by from that point changes. I think!
I could very easily calculate the whole thing if the song were to be entirely in a single consistent tempo but practically everything except folk music changes tempo and my game engine has to account for that.
I have good reason to suggest that GH actually does it in the way that I want to do it, GH is very much a millisecond-based game engine, a detailed explanation of GH's game engine would probably get me to exactly what I want.
Milliseconds is also the only reliable method of doing it, if it was based on fps and then it lags, the game desynchronises and that timing window is very sensitive.
i see what your saying. you could use 0.3472 as a base. i came up with that number by dividing 12 into 4.16
which represents 10bpm. so if the temp went from 120 to 130 you would subtract ( 4.16 - 0.3472 )= 3.8128
then 130 * 3.8128 which gives 495.6
so if the fourth note changed to 130bpm you would add the above to the 3rd note ( 1500 + 495.6 )
That helps you build your ini file. but still has nothing to do with spacing pixels. but in trying to make my own example just to test it out. i recommend increasing the frame rate as the tempo goes up. This allows you to keep all the notes the spaced at the same distance.
The positions in the ini are actually relative to the beats and not their actual position in time else the level editor would be completely impracticable.
Edit: The pixels are determined by the position in time and this moves across the screen as time progresses.
if the ini file is the source for all your conditions. Then i'd suggest making a ini group for bpm.
something like
[bpm120]
note01=500
note02=1000
[bpm140]
note01=429
note02=857
then when the tempo changes. All you have to do is use the str$() function to change the group of the ini.
-Always
-set the group
-"bpm"+str$(global value A)
Then do the same for the groups item
-Always
-set the item
-"note"+str$(global value B)
That kind of implementation would only require keeping track or the bpm (global A) and the current note (global B)
it's a bit messing using all those conversions from numbers to strings, but i really don't think their is another way with ini's. because set group and item require strings.
Dropped in from the start, read something about pixels, distance and guitar hero. I thought: do you want the objects to move away from the viewer while maintaining an equal distance between them? Just like in 3D or perspective viewing? Because that might be the answer to your problem. Sorry if I skipped your BPM part of the game.
Originally Posted by Jenswa Do you want the objects to move away from the viewer while maintaining an equal distance between them? Just like in 3D or perspective viewing? Because that might be the answer to your problem.
At this stage, I'm starting to think that people are intentionally misunderstanding me. What I want is entirely to do with timing and absolutely nothing else. Each note needs to be told what time it is and must go to that.
I have to fuss up that I was not a lot of help. Their might be some sort of guitar hero algorithm out their. But I don't know of it, and haven't seemed to be able to find one either.
The level of complexity your looking for is probably out of my league.
I'm kind of wondering though. How many known values do your calculations have? Do you know any more info about the track besides the bpm and the notes?
Originally Posted by Jenswa Do you want the objects to move away from the viewer while maintaining an equal distance between them? Just like in 3D or perspective viewing? Because that might be the answer to your problem.
At this stage, I'm starting to think that people are intentionally misunderstanding me. What I want is entirely to do with timing and absolutely nothing else. Each note needs to be told what time it is and must go to that.
Not intentionally, just focused on the spacing part of your pixels which is a part of your problem and therefore of the solution. But it probably didn't help much.
Do you have a series of pictures linked with the timing of how you want it to function?
Because with BPM added it sounds like you just need to use that as a scaling factor to get your base time unit. But it is probably eaiser to use 1000 milliseconds as base. So that 1000 divided by BPM will give you your timesteps to play the notes.
However when BPM changes you need to recalculate that timestep number (1000/BPM I called it) and you need to play the 2nd note 2 times the difference faster (or slower) but the 10th should be ten times the difference faster (so slower).
You can either keep an array (or temporary ini) and recalculate everything or keep track of the time difference and the number of the note being played. Because when playing the 15th note you will need 15 times the time difference. And that skips the recalculation part.
If you have this 1000 ms based timing system up and working, the relative positions of your objects shouldn't be that hard anymore.
Getting your objects closer together and equally close to each other can be done easily by calculating the total length of all objects arranged along a line and than dividing the length by the number of objects (lets say: delta distance) and place your objects at delta distance from each other.
Advertisement
Post Reply
Edited by Maltar Draco
jenswa.neocities.org
