The map editor does not calculate Real numbers correctly (as far as I test.).
1/3 is not 0.333333. but 0.333251. etc
screen provided here:
This caused me a big problem when I have a big amount of objects spawning with the real number variable (in my case was 60/music note speed in bpm), which follows the beat of the sound/music. I spent the whole night changing around triggers, trying to figure out why objects start to get off-beats after the game starts awhile. Then I found out at 3am, the math calculation was wrong from the top...
Have a peak the project I'm currently working on:
It will really be a fun game if the math can be fixed and every single arrows are on-beat... T_T
Up Down Left Right control. Space for enter option.
It's not at all published, patterns, difficultly, and more UIs are not yet set for the game yet. You are welling to change the music to 120bpm, 140bpm, 180bpm.mp3. They are useful for testing the speed.
It gets off-beat after the game starts awhile however... See if someone could come up something I will definitely write credit to you.
Try creating a one shot timer that lasts some super long time (say, 524288) of real seconds. Have a second variable that tracks the "last tick" of the timer.
Have a trigger that repeats relatively quickly (enough to fire close enough to your spawn times without fail - so likely 0.0625 or whatever triggers cap out at). That trigger should grab the current time, stuff it in a var, compare it to the stored "last tick" value for the elapsed time. Once the calculated elapsed time is >= your beat (or however often), spawn your arrows and store the saved current time as your last tick time.
He is saying that computers and calculators always make errors when you do arithmetic. They're just usually not as apparent. The Intel Celeron processor was made obsolete very quickly because a mathematician noticed that its error in dividing numbers was larger than others, for example.
There is nothing peculiar about this. It happens all the time — its just more apparent here than in other places, that's all...
Oh. I think I got what you mean. I will give it a try..
edit:
it doesn't work. the thing is that speed of one beat is calculated by the editor, with a given music speed in real number, which is calculated incorrectly..
by the way... isn't the (Current time - Last Tick) of the timer always the same?
The editor doesn't use floating point (floats) it uses fixed points (reals). Floating points are much more precise and are a requirement for working with precise numbers. Reals are trash. They're good for saving memory, I guess. They're bad for anything that actually relies on a precise number. It may be "working as intended" but it's also wrong.
Floats need to be implemented into Galaxy ASAP. Pointers or bulk copy also need to be supported. Lastly, structs are available in the Galaxy script but they are not supported in the Trigger Editor, which should also be changed ASAP.
Oh. I think I got what you mean. I will give it a try..
edit:
it doesn't work. the thing is that speed of one beat is calculated by the editor, with a given music speed in real number, which is calculated incorrectly..
by the way... isn't the (Current time - Last Tick) of the timer always the same?
Ahh yeah, I didn't quite think it through - check out my very rough test map on how to grab the beat offset of the current beat (basically, split it apart)
Since you can't rely on hitting the beat dead on, you need a reliable way of calculating the next fraction of a beat you want to hit.
One way to cheat the system here would be to actually switch over to integers. Say you know that the fastest your arrows hit is 1/8th of a beat. Calculate the "beat fraction" similarly to how I calc "beat num" in the attached map, except you'd multiply BPS by your fraction - in this case: 0.0625.
So beat fraction 0 would be the first beat, beat fraction 8 would be the second 16 would be the third and so on. Then just figure out the next fraction you want to spawn on, and do so when you reach/pass that value.
Note that you might see cases where you hit the same beat fraction twice - you'll likely want to keep track of whether you spawned as well.
The main problem with your map's method is that each calculation is slightly off, so you're accumulating rounding errors. If you calculate the beat each time, you're vastly reducing the number of rounding errors
The map editor does not calculate Real numbers correctly (as far as I test.).
1/3 is not 0.333333. but 0.333251. etc screen provided here:
This caused me a big problem when I have a big amount of objects spawning with the real number variable (in my case was 60/music note speed in bpm), which follows the beat of the sound/music. I spent the whole night changing around triggers, trying to figure out why objects start to get off-beats after the game starts awhile. Then I found out at 3am, the math calculation was wrong from the top...
Have a peak the project I'm currently working on:
It will really be a fun game if the math can be fixed and every single arrows are on-beat... T_T
Please if someone could test this and also response here. I also posted here: http:forums.battle.net/thread.html?topicId=24702394559&sid=5000
Sorry for bad english if you read something doesnt make sense lol.
The evil of floating point errors :(
Ummmm, no. . . It's correct. You just rounded, it makes no difference. Actually I think your Match is wrong. :/
Wraith,
Are you saying that
1/3 is not equal to 0.3333333333333...
Or that
0.333333333333... rounds to 0.333251...
:/
four significant digits for the input? o.O
@WraithChaser: Go
...what? Is there some secret higher echelon of math that I haven't gotten to yet?
1 / 3 = 0.33333333333
1 / 5 = 0.2
I'd like to know how 1/5 does not equal .2 or 1/3 does not equal .33333333333333333333
Hopefully this gets fixed, major problem if you need extremely precise math.
Welcome to the wonders of floating point arithmetic in computers. :D
http://docs.sun.com/source/806-3568/ncg_goldberg.html
I'd say this is working AS INTENDED.
Oh come on, lay off him even since he made a mistake.
@SCMapper: Go
yea...
and especially for this project im doing... even a little number can make the game off-beat...
I will attach my project soon, look for solutions...
@QuantumMenace: Go
I have attached the file.
Up Down Left Right control. Space for enter option.
It's not at all published, patterns, difficultly, and more UIs are not yet set for the game yet. You are welling to change the music to 120bpm, 140bpm, 180bpm.mp3. They are useful for testing the speed.
It gets off-beat after the game starts awhile however... See if someone could come up something I will definitely write credit to you.
@shaotang: Go
Try creating a one shot timer that lasts some super long time (say, 524288) of real seconds. Have a second variable that tracks the "last tick" of the timer.
Have a trigger that repeats relatively quickly (enough to fire close enough to your spawn times without fail - so likely 0.0625 or whatever triggers cap out at). That trigger should grab the current time, stuff it in a var, compare it to the stored "last tick" value for the elapsed time. Once the calculated elapsed time is >= your beat (or however often), spawn your arrows and store the saved current time as your last tick time.
He is saying that computers and calculators always make errors when you do arithmetic. They're just usually not as apparent. The Intel Celeron processor was made obsolete very quickly because a mathematician noticed that its error in dividing numbers was larger than others, for example.
There is nothing peculiar about this. It happens all the time — its just more apparent here than in other places, that's all...
@Nevir27: Go
Oh. I think I got what you mean. I will give it a try..
edit:
it doesn't work. the thing is that speed of one beat is calculated by the editor, with a given music speed in real number, which is calculated incorrectly..
by the way... isn't the (Current time - Last Tick) of the timer always the same?
The editor doesn't use floating point (floats) it uses fixed points (reals). Floating points are much more precise and are a requirement for working with precise numbers. Reals are trash. They're good for saving memory, I guess. They're bad for anything that actually relies on a precise number. It may be "working as intended" but it's also wrong.
Floats need to be implemented into Galaxy ASAP. Pointers or bulk copy also need to be supported. Lastly, structs are available in the Galaxy script but they are not supported in the Trigger Editor, which should also be changed ASAP.
@rrowland: Go
Does galaxy language support floating numbers?
Ahh yeah, I didn't quite think it through - check out my very rough test map on how to grab the beat offset of the current beat (basically, split it apart)
Since you can't rely on hitting the beat dead on, you need a reliable way of calculating the next fraction of a beat you want to hit.
One way to cheat the system here would be to actually switch over to integers. Say you know that the fastest your arrows hit is 1/8th of a beat. Calculate the "beat fraction" similarly to how I calc "beat num" in the attached map, except you'd multiply BPS by your fraction - in this case: 0.0625.
So beat fraction 0 would be the first beat, beat fraction 8 would be the second 16 would be the third and so on. Then just figure out the next fraction you want to spawn on, and do so when you reach/pass that value.
Note that you might see cases where you hit the same beat fraction twice - you'll likely want to keep track of whether you spawned as well.
The main problem with your map's method is that each calculation is slightly off, so you're accumulating rounding errors. If you calculate the beat each time, you're vastly reducing the number of rounding errors