[QUOTE=Chandler;18840025]Dude throw some AI onto that and you've got a swarm of bees. You wouldn't happen to be releasing that source code anytime would you? :X[/QUOTE]
I could give you the full source code if you want, but that's the only important part:
[cpp]public void think(ThinkEvent ev) {
Particle[] particles = ev.getEntities(Particle.class);
for (int i = 0; i < particles.length; i++) {
for (int j = i + 1; j < particles.length; j++) {
Particle p = particles[i];
Particle p2 = particles[j];
double xs = 0;
double ys = 0;
double deg = Math.atan2(p.getY() - p2.getY(), p.getX() - p2.getX());
double distance = Point2D.distance(p.getX(), p.getY(), p2.getX(), p2.getY());
if (distance < 1) { //I know I shouldn't do that, but the gravitational pull gets way to strong under 1
continue;
}
xs -= Math.cos(deg) / distance * 10;
ys -= Math.sin(deg) / distance * 10;
p.setXs(p.getXs() + xs);
p.setYs(p.getYs() + ys);
p2.setXs(p2.getXs() - xs);
p2.setYs(p2.getYs() - ys);
}
}
}[/cpp]
[QUOTE=Sippeangelo;18839911]The only code in the loop is to measure the time, and it's not 1 ms, it's less than 1 ms. But with my limited measuring method I can't get lower than a millisecond. Anyway that's not important. It reports 0ms for a while, then I get a 16 ms spike. The spikes are frequent and I've already ruled out my measuring code.
What kind of compiler options can cause this?[/QUOTE]
None. It's probably a syscall thing. Have you considered that the measuring system might only have a granularity of 16 ms? (in that 16 ms is the smallest amount of time that it can measure) so that when the timer rolls over, it goes from reading 0 ms suddenly to 16 ms difference between timer now and the saved previous value.
Have you measured a time period greater than 0ms, but less than 16 ms? What syscall are you using to measure time?
[editline]05:24PM[/editline]
High-precision time is usually measured with the clock() function. This counts CPU cycles. Keep in mind this is [I]precision.[/I] Not necesarily [I]accuracy.[/I]
[QUOTE=Cathbadh;18840405]None. It's probably a syscall thing. Have you considered that the measuring system might only have a granularity of 16 ms? (in that 16 ms is the smallest amount of time that it can measure) so that when the timer rolls over, it goes from reading 0 ms suddenly to 16 ms difference between timer now and the saved previous value.
Have you measured a time period greater than 0ms, but less than 16 ms? What syscall are you using to measure time?
[editline]05:24PM[/editline]
High-precision time is usually measured with the clock() function. This counts CPU cycles. Keep in mind this is [I]precision.[/I] Not necesarily [I]accuracy.[/I][/QUOTE]
Yeah, actually I believe I read that somewhere.
Any preferred method of doing the measures?
[QUOTE=Robber;18839912]My particles attract each other now, but I'm having some problems with the gravity formula I think. Could someone tell me how to properly calculate the gravitation based on distance?[/QUOTE]
I use something like this:
[code]force = magnitude_constant / distance_between_bodies;
force *= body_1_mass;
force *= body_2_mass;
body_1_force_applied = force / body_1_mass;
body_2_force_applied = force / body_2_mass;[/code]
May remember incorrectly though.
If you want to get good precision and accuracy, then it is customary to query the real-time clock. You can do this with clock_gettime() and giving it the CLOCK_REALTIME clock id argument. This can be trusted to give an accurate measurement of sub-millisecond resolution, usually in nanoseconds.
[QUOTE=Semas-LTU;18834755]Looks nice, keep up the good work.[/QUOTE]
Thanks man =)
[QUOTE=Robert64;18840549]I use something like this:
[code]force = magnitude_constant / distance_between_bodies;
force *= body_1_mass;
force *= body_2_mass;
body_1_force_applied = force / body_1_mass;
body_2_force_applied = force / body_2_mass;[/code]
May remember incorrectly though.[/QUOTE]
That's what I'm doing, except that everything has a mass of 1. The problem is that if distance is under 1 the force can become incredibly high and the particle gets flung out of the screen.
[QUOTE=Cathbadh;18840590]If you want to get good precision and accuracy, then it is customary to query the real-time clock. You can do this with clock_gettime() and giving it the CLOCK_REALTIME clock id argument. This can be trusted to give an accurate measurement of sub-millisecond resolution, usually in nanoseconds.[/QUOTE]
And in Windows the best I can get without inline assembly is QueryPerformanceCounter?
[QUOTE=Robber;18840732]That's what I'm doing, except that everything has a mass of 1. The problem is that if distance is under 1 the force can become incredibly high and the particle gets flung out of the screen.[/QUOTE]
That's how it works like. In reality objects collide together before they get that close, and they have much smaller masses (therefore it's not noticable). You might be better off calling this electrostatic forces rather than gravity, seeing how fast they move over there. I'm afraid either adding collision, or keeping "distance < 1" is the only solution to this.
Or actually you can add extra repelling force - which pushes particles apart, has reverse direction to gravity (electrostatic) pull, but instead has radius^4 dependance on distance, not radius^2 like in regular formula. Or even higher, just make sure it's even power. This will create force powerful enough to keep particles apart from each other, but fading to zero so fast that it doesn't really affect particles which are far away.
[QUOTE=Sippeangelo;18840742]And in Windows the best I can get without inline assembly is QueryPerformanceCounter?[/QUOTE]
Iuno. Maybe? The real-time timer shouldn't be off-limits to read from, it is just special hardware that probably requires you to link some library. I don't really know how to program high-level on a platform that refuses POSIX complaince.
[QUOTE=Cathbadh;18840811]Iuno. Maybe? The real-time timer shouldn't be off-limits to read from, it is just special hardware that probably requires you to link some library. I don't really know how to program high-level on a platform that refuses POSIX complaince.[/QUOTE]
All's good now :neckbeard:
[code]
0.000829954
0.000821229
0.000843299
0.000828415
0.000823795
0.000853565
0.000824308
0.00255607
0.00122722
0.000790433
0.000825848
0.000822769
0.000848945
0.000830981
0.000822255
0.000823795
0.000832521
0.000830981
0.000840733
0.000826875
[/code]
That's seconds... I hope.
End up using the clock() function? I know that is part of the C ISO standards, and is in every implementation of the libc libraries.
[QUOTE=Robber;18839912]My particles attract each other now, but I'm having some problems with the gravity formula I think. Could someone tell me how to properly calculate the gravitation based on distance?
[/QUOTE]
[img]http://upload.wikimedia.org/math/3/0/2/302f038d7d9460c6d984bf061e0ba7fc.png[/img]
Is that the one?
[QUOTE=Cathbadh;18841059]End up using the clock() function? I know that is part of the C ISO standards, and is in every implementation of the libc libraries.[/QUOTE]
Used QueryPerformanceCounter(). Had better resolution that clock().
For awhile now I have been stuck on 1 game for reversing and it was getting dull. Just picked up another game :D. Forgot how fun it can be learning how it works.
Just learned how the callbacks are stored in the widgets.
[code]PlaySound('/shared/sounds/ui/button_click_01.wav');
Call('effect_panel', 'StartEffect(\'/ui/common/effects/score_sparks_out.effect\', ' # GetAbsoluteFractionX(1.4) / GetScreenWidth() # ', ' # GetAbsoluteFractionY(1.5) / GetScreenHeight() # ', \'1 1 1 1\');');
Call('scoreboard_holder', 'SlideX(\'2.7h\', 250);');
Call('scoreboard_gear', 'Rotate(1129, 250);');
ShowWidget('menu_close');
HideWidget('halfscore_out');
ShowWidget('halfscore_disabled');
HideWidget('scores_mini_show');
ShowWidget('scores_mini_hide');[/code]
[QUOTE=Robber;18839912]My particles attract each other now, but I'm having some problems with the gravity formula I think. Could someone tell me how to properly calculate the gravitation based on distance?
[/QUOTE]
The Formula for gravity is:
F = (G * (m1) * (m2))/(r^2)
Where 'G' is the gravitational constant, which is 6.67*10^-11 in our universe.
Gravity is based on the inverse square law, where the magnitude of the force is relative to the inverse square of the distance between the objects.
I would start out with G = 1, and alter it 'till you find a value that suits your simulation. The formula given has mass in kg and distance in meters.
I would suspect that G will be a value smaller than 1 if all your distances are in pixels.
[QUOTE=windwakr;18841354]Yes, using assembly to access the realtime clock on a modern computer just won't work great. Too many processors have variable processor speeds with speedstep, multiple processors with different clock ticks, the list of things that mess up readings goes on. QueryPerformanceCounter is basically the best you can do.
Unless you know for sure that your processor doesn't use speedstep and it is single core(or you could lock your code to a single core if it has more than one I guess), then go ahead and use rdtsc to get the clock ticks in EDX:EAX(be sure to serialize the instruction pipeline with a cpuid first though), but you can't guarantee it will work properly on other computers.[/QUOTE]
The real-time clock is independent hardware from the CPU clock. (even though they are usually on the same chip) but you're right. Access to the RTC registers are not common across all CPUs. The difference is that the RTC has the [I]sole function[/I] of just incrementing a register's value upon a clock edge, and that clock drives only that RTC. RTC's usually have other functions too, like you can load values into a comparison register, and when the RTC counter register climbs above the comparison register, then it sends an interrupt to the hardware interrupt controller. Embedded systems use this ability all the time.
You should consider the RTC as a peripheral.
[QUOTE=Mattz333;18842123]The Formula for gravity is:
F = (G * (m1) * (m2))/(r^2)
Where 'G' is the gravitational constant, which is 6.67*10^-11 in our universe.
Gravity is based on the inverse square law, where the magnitude of the force is relative to the inverse square of the distance between the objects.
I would start out with G = 1, and alter it 'till you find a value that suits your simulation. The formula given has mass in kg and distance in meters.
I would suspect that G will be a value smaller than 1 if all your distances are in pixels.[/QUOTE]
That suffers from same problem, when R -> 0, the force goes to infinity. I suggest adding repulsive force, using same formula, except r^4 or r^8 instead, and in reverse direction (so it pushes away, not pulls)
[QUOTE=BlackPhoenix;18842973]That suffers from same problem, when R -> 0, the force goes to infinity. I suggest adding repulsive force, using same formula, except r^4 or r^8 instead, and in reverse direction (so it pushes away, not pulls)[/QUOTE]
That, or impose a limit:
[code]
float r;
if(dist<2)
{r = 2;}
else
{r = dist;}
[Then calculate force][/code]
[QUOTE=Mattz333;18843026]That, or impose a limit:
[code]
float r;
if(dist<2)
{r = 2;}
else
{r = dist;}
[Then calculate force][/code][/QUOTE]
He already imposed a limit, just suggesting an alternative to the limit
[img]https://dl.dropbox.com/u/99765/jhfdufhsdvuh8.png[/img]
Nothing to say really. If I wanted to tell people stuff I'd make a twitter account :v:
[QUOTE=windwakr;18842885][url=http://en.wikipedia.org/wiki/Programmable_Interval_Timer]Are you talking about the PIT?[/url] That's not the same as what you access with RDTSC. You can't program interrupts to go off every x milliseconds or whatever with the realtime clock, but you can with the PIT. And the PIT runs at 1.193182MHZ, not the speed of your processor.
But anyways, [url=http://en.wikipedia.org/wiki/Time_Stamp_Counter#Implementation_in_Various_Processors]I was just reading up on this and yeah, the RDTSC is constant on newer processors[/url], even ones that use speedstep. But is there any way to tell whether or not the processor your program is running on has a constant rate RDTSC or not? Is there a CPUID flag for it?[/QUOTE]
Well, what you are thinking of is not what I'm thinking of. The RDTSC is not a peripheral, it is just a read-only register on x86 cpus that counts the number of clock cycles that have gone by. It still uses the same clock that the CPU does.
As for your question about detecting processors and ensuring proper usage of RDTSC, refer to the CPUID manuals. Specifically CPUID instruction call concerning APM info. I believe there is a flag that call will set along the lines of TSC invariance. If that flag is set, you can safely assume that the RDTSC counter clocks in at a constant rate.
[editline]10:38PM[/editline]
Yeah, here it is:
[quote=AMD CPUID manual]
CPUID Fn8000_0007 Advanced Power Management Information
Register EDX.8 : TscInvariant 1 = The TSC rate is ensured to be invariant across all P-States, C-States, and stop grant transitions (such as STPCLK Throttling); therefore the TSC is suitable for use as a source of time. 0 = No such guarantee is made and software should avoid attempting to use the TSC as a source of time.
[/quote]
[QUOTE=BlackPhoenix;18842973]That suffers from same problem, when R -> 0, the force goes to infinity. I suggest adding repulsive force, using same formula, except r^4 or r^8 instead, and in reverse direction (so it pushes away, not pulls)[/QUOTE]
If R = 0, that's unrealistic coding.
That would mean you have one mass inside another. Only way that is possible if it is the same mass, in which case gravity wouldn't be in play. Just electromagnetic, strong nuclear, and weak nuclear, which has nothing to do with this (although if he got it so the particles contained the subparticles, that would be pretty interesting).
Slightly relevant note: The mass on the periodic table is the mass in grams per mole, right?
[editline]08:00PM[/editline]
So I would say try making it so that distance can be a float, not a single integer based on distance in pixels.
Is data in a class optimized at all? Like if I make a class parser all I need to do is have it support defines and data alignment right?
[QUOTE=high;18847622]Is data in a class optimized at all? Like if I make a class parser all I need to do is have it support defines and data alignment right?[/QUOTE]
What do you mean optimization? Data in classes and structs are packed in order of declaration conforming to alignment rules. In no cases can you remove data fields, and reordering them for better packing efficiency is dangerous at best.
[QUOTE=GreyIOutcast;18847524]If R = 0, that's unrealistic coding.
That would mean you have one mass inside another. Only way that is possible if it is the same mass, in which case gravity wouldn't be in play. Just electromagnetic, strong nuclear, and weak nuclear, which has nothing to do with this (although if he got it so the particles contained the subparticles, that would be pretty interesting).
[/QUOTE]
Pretty sure he meant that as the radius approaches zero, the force increases and approaches infinity; he didn't mean that the radius equals zero.
[QUOTE=Cathbadh;18848516]What do you mean optimization? Data in classes and structs are packed in order of declaration conforming to alignment rules. In no cases can you remove data fields, and reordering them for better packing efficiency is dangerous at best.[/QUOTE]
I figured that, just want to make sure.
Anyways, I guess this will be the base for my scripting language too because aside from parsing/executing code, it will have to do everything else.
I wonder if you can get all the defines from a compiler.
How the hell do I specify the size of a Win32 window excluding the window borders?
I guess I could just assume that the side and the bottom border are 4 px and the top is whatever size, but it can differ from os to os and user defined settings...
[QUOTE=Chandler;18839878]If you want to try actual multiplayer editing check out [url]http://www.moddb.com/games/platinum-arts-sandbox[/url]
it has it built in (Uses the Saurbraten engine)[/QUOTE]
this is madly off topic and probably noones cares, but platinum arts sandbox is just a worse version of cube 2 where everything is taken away and what is added doesn't even work.
Sorry, you need to Log In to post a reply to this thread.
