| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Making smooth curve movements
K, so i want to make some kinda smooth curves to move sprites along.
I know I could use specially tailored sinus data, but then i still have to code something to do the movement exactly as i want it.
So i consider to make a small movement recorder, where i move a sprite with a joystick, and record the path.
So, now comes the hard part: if i record some (as perfect as can be) movement (a path), then how could i flatten out the recorded data afterwards, so my imprefect drawn move, becomes super smooth ?
This is some math i know nothing about, anyone ? |
|
... 20 posts hidden. Click here to view all posts....
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
get it ? = fuck you ?
if i hadnt complained before why csdb forums are utter shit, i do now, but it will be the last time. |
| |
Hein
Registered: Apr 2004
Posts: 954 |
Quote: get it ? = fuck you ?
if i hadnt complained before why csdb forums are utter shit, i do now, but it will be the last time.
No help is good enough for you, is it? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@Rambones:
You move your sprite, and you record a series of coordinates. You can make this curve smoother by averaging values. For each value N, you add it together with the value before, and the value after and then you divide the sum you get with 3, and store the result into a new table. Now each adjacent value will "influence" the other adjacent values in a way that makes the overall curve smoother. In order to make the division simpler to implement (i.e. division with 4 instead of 3) then you could always add value N two times to the sum, which would also give a weighting in favor of the actual value obtained at each point.
In case this will turn out too rough (depends on how rough your input data is), you can add the current value + two previous and two subsequent values. If this is too rough, then add values further back/ahead into each sum. A good idea is to always add the values together like a "pyramid". For example, for value 5 in the series (N5) and a "scope" of two values ahead/behind, you could add values like this:
N5
N4 N5 N6
N3 N4 N5 N6 N7
This table means nothing else than N3+N4+N4+N5+N5+N5+N6+N6+N7 = X
Then you divide X with the number of values, X/9, to get the "smoothed" value for N5. Let's say you prefer to divide with 8 instead (if you do this on the C64 instead of pre-calcing it). Just remove one of these values and divide with 8 instead. It might very well look alright.
An alternative, in case your new table is still too rough, is to just run the same sort of calculation again in a second pass, to smooth the curve further.
A special case is when you deal with values in the beginning/end of the table, where you can't pick values ahead/behind because the table stops there.... You can figure out yourself how to deal with that in some way that looks alright.
Note that this approach will reduce all "peaks" in the data, so it will result in a path of movement which is more straight than the actual input. That is, it will not actually result in a curve which is "fitted" to the data as good as possible. For that you would have to do some curve fitting the way RadiantX suggested for example. Nevertheless, I suspect that you will find the approach I described here easier to understand/implement.
Note that most of the posts above were actually good and relevant answers to your question. What I suggest here is a worse approach than many of them, in terms of accuracy, but I guess it may work for your purposes. |
| |
Partz
Account closed
Registered: Jun 2008
Posts: 17 |
I've been toying with the idea of writing an editor to do just this. The idea is that you will initially click on a canvas representing a visible screen space (say 320*200). Each click will add a vertex and between each vertex ALL points will be stored as calculated by a simple line drawing DDA. An option will then exist to smooth the points. There seem to be a fair few algorithms out there for this that don't call for the polynomial curves - much like the sliding window averaging approach mentioned above which looks like a simplified McMasters routine. The intention would be that vertex data could be saved off as either a dc.b text file for 64 usage or a static c# class/seriazable binary file for use in XNA.
I quite like the ideas regarding velocity discussed above - multiple objects look more natural bunching up and decelerating around a tight curve. Maybe if each vertex a target velocity for the end point so data is stored in x,y,v?. Might be a Christmas project.
Have you tried getting any of these ideas into a simple basic program yet, Rambones? |
| |
Mace
Registered: May 2002
Posts: 1799 |
This tool you are talking about... will it be some 'other platform tool' or something that will actually run on a C64?
I prefer (by far) the second option :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:if you have knowledge to code that on c64, then do.
so you don't actually want to know how this works, but you want someone to code it for you?
Quote:f.ex i move diagonal up right, then hard down right, a triangle. then the tip of the triangle shouldnt be hard, it should become a small smooth curve.
and thats a typical usecase for splines, as various people told you already. |
| |
Mace
Registered: May 2002
Posts: 1799 |
I think you should give Rambones a break, you are seeing things that aren't there...
|
| |
Partz
Account closed
Registered: Jun 2008
Posts: 17 |
Quote: This tool you are talking about... will it be some 'other platform tool' or something that will actually run on a C64?
I prefer (by far) the second option :-)
It will be "other platform". The intent is to do it in C# under windows. The output won't be C64 specific, it will provide output thats useable in my XNA too. |
| Previous - 1 | 2 | 3 - Next |
