Register
Email: Password:
Forum » Another Javathingie.

Another Javathingie.

Narvius 6 years ago
Gravity thing with small 24 5x5 dots.

The .jar file.
Dah source code.
(Also, I did a similar thing in C# 3.5 with XNA 3.1. Again, next wednesday... or not.)
#
Amarth 6 years ago
Impressive, I like it. Fun to watch the chaotic behavior. Does every particle influence every other particle directly (i.e. complete double for-loop) or are there some more tricks going on?
#
Narvius 6 years ago
Plain double-for.
That means that for every pair, the whole thing is calculated twice.
Actually, I could actually optimize that a little bit.

...*tries*.

On second thought, no. That's a bad idea. Too much extra work :>
But I'll add a possiblity to remove and add points at runtime.
I just was a little sleepy at 3AM already :>
#
E_net4 6 years ago
It really is fun, even though I slightly despise Java. I think doing that in Linoleum would work. Dare for a challenge?
#
Anonymous1157 6 years ago
Ooo. I'd love to spectate this Linoleum vs. Java challenge unfold.

In other news, I like this gravity simulator! Hey, why don't you keep adding on to this? How about adding particles with different masses, or clumping and disintegrating particles? How about some interaction? (It can't be that hard to stop calculating for one dot while it's moved with the mouse cursor, or something.) You could even have the simulation speed throttle to the screen's refresh rate. >.>
#
Narvius 6 years ago
It supports different masses, but currently all of them have the same. It's no problem to make different sizes, although I WON'T make collision detection.
My current version (I'll update it on wednesday, seriously.) also allows to remove and add particles at runtime, but only randomly.

I've thought about click-drag to create new particles with initial speed, that would probably nice.

Also, Linoleum? oO

I currently explore the awesomeness of Ruby, and if I get some decent graphics library running...
#
E_net4 6 years ago
"Narvius" said:
Also, Linoleum? oO
Yes. There is no faster portable language than this one. Allow me to work on the Linoleum version of that.
#
Anonymous1157 6 years ago
"E_net4" said:
"Narvius" said:
Also, Linoleum? oO
Yes. There is no faster portable language than this one. Allow me to work on the Linoleum version of that.
You forgot to mention how awesome Linoleum's built-in GUI is. I LOVE IT. It's the prettiest GUI I will ever see in my life, considering where Windows and Linux are going with theirs.

I forgot to mention this before. I think the window is larger than my desktop vertically. Any chance it can be made to scale to the size of that computer's particular desktop rez instead?

Oh, and in case you do add the new-particle-via-click-drag thing, don't forget to include removing particles with a right-click, too. You could just leave that out and it wouldn't really be a problem, but then all we can do to remove particles is nuke it with the escape key.
#
E_net4 6 years ago
"Anonymous1157" said:
"E_net4" said:
"Narvius" said:
Also, Linoleum? oO
Yes. There is no faster portable language than this one. Allow me to work on the Linoleum version of that.
You forgot to mention how awesome Linoleum's built-in GUI is. I LOVE IT. It's the prettiest GUI I will ever see in my life, considering where Windows and Linux are going with theirs.
Actually, that is only a built-in library of a GUI system. It's not really part of Linoleum, and the GUI shouldn't be directly associated with Linoleum. Plus, I'm not going to use it.
#
Narvius 6 years ago
From what I've read, Linoleum is portable softcore-assembler. :>

Features I want to add:
- Add particle with drag-click to give it some initial momentum
- Remove nearest particle with right-click (it's hard to hit an eratically-moving 5x5 pixel square :>, probably with some graphical effect showing WHICH one was removed (it won't always be clear. Well, not that it actually makes a difference...)
- Instead of static 800x800, make it Min(800, screen width/height). Question - should it always be square? Or can it be a rectangle?
#
E_net4 6 years ago
"Narvius" said:
- Instead of static 800x800, make it Min(800, screen width/height). Question - should it always be square? Or can it be a rectangle?
Make it fixed in size. It always helps.
And a rectangle is most fitting to the screen.
#
Narvius 6 years ago
A few posts back Anon complained that fixed size DOESN'T help :>

Actually, SCREW it, I'll just make it resizeable.

Wait, no. What happens when you reduce the size and particles get outside?
...
I'll stick with the 800 or screen size.
#
Anonymous1157 6 years ago
If it isn't too much trouble, it would look much more professional if you figured what Windows says is the usable screen space and resized into that.

... And it's not that fixed size doesn't help per se. It would indeed make it easier on your end, but 768<800, hence I can't use my top bar. If the window would go behind the shell, it wouldn't matter as much.
#
E_net4 6 years ago
Having a fixed display size is fine, as long as you use a decent resolution. A resolution of 800x800 isn't. Try 800x600 instead.

As for Lino, I finished the initialization of the particles and managed to draw them with no outlines. Interaction between them is yet to be done. You know things in low-level take more time.
#
Narvius 6 years ago
I'll try doing it in Ruby with the Rubygame library (which is pretty much SDL with some stuff).
But it probably won't be done 'till saturday, since I still have to finish the Java one until tomorrow, and we have a lot of tests this week.

[Edeet]
Added click-drag and right click thing. You can also change the mass of newly created particles (the difference isn't visible through size or anything, but it works) with Numpad+ and Numpad- (for 10x bigger steps hold Shift).
Also, soorce coed.
#
Anonymous1157 6 years ago
Ooo, fun! *Plays with*

I put a few hundred particles on the screen before it slowed down.

Edit: Just then, I tried right-clicking a few dozen times, and the simulation froze, but I could still press escape.
#
Narvius 6 years ago
Wut. Freeze. Never happund to me :<
The best would be giving me the stack trace. :>
#
Anonymous1157 6 years ago
... I can't, because it never crashed. The simulation itself froze, but I could still exit by pressing escape because the Java applet didn't.

Bah, maybe I imagined it. Let me see if I can get it to do it again. Yup, it just did it again! Exactly what I did was spawn hundreds of particles until it slowed down, then right-click a few times.
#
Amarth 6 years ago
Exception in thread "Timer-0" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 615
at java.util.Vector.get(Vector.java:694)
at Main.Space.gravityAffect(Space.java:79)
at Main.Launcher$3.run(Launcher.java:101)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Probably multithreading issue when you remove a point during the calculation loop. Possible solution is to mark your calculation loop synchronized on the points-vector - google around on "java synchronized".
EDIT: mark the calculation loop AND all other parts modifying the vector as synchronized

Anon: the calculation thread crashed. The display thread (and the thread responding to keyboard input) still works, so that's why it seems like the whole program just freezes.
#
E_net4 6 years ago
I wonder if Linoleum, even with NO multithreading, can outstand that Java app.
#
Narvius 6 years ago
I already figured out what the problem is yesterday tonight, but didn't fix it.
Did so now.
#
MageKing17 6 years ago
If you put two dots right on top of each other (as when first starting the simulation, the first object has nothing to pull it around), for some reason they'll both shoot off toward the right side of the screen (and stay overlapped, so it looks like one dot that has spontaneously decided to ram the right edge of the screen). Either the way gravity acceleration is calculated is a little iffy, or it's some floating point error that can't really be eliminated.
#
Narvius 6 years ago
Yes, I've noticed that. But since that is pretty much the only situation when it can really happen, I wouldn't consider it a major bug :>

I guess this happens because the tangent (supposed "being-drawn-to" angle) is the same for both, and therefore they accelerate into the same direction (which would be 0rad, ie. right), at the same speed, so they stay on top of each other, accelerating each other. So, neither of the two things you guessed
#
MageKing17 6 years ago
"Narvius" said:
Yes, I've noticed that. But since that is pretty much the only situation when it can really happen, I wouldn't consider it a major bug :>

I guess this happens because the tangent (supposed "being-drawn-to" angle) is the same for both, and therefore they accelerate into the same direction (which would be 0rad, ie. right), at the same speed, so they stay on top of each other, accelerating each other. So, neither of the two things you guessed
No, I'd say that falls under "gravity acceleration calculated a little iffy".

Regardless, no physics engine should allow to objects to occupy the exact same space... it violates quantum mechanics.
#
Amarth 6 years ago
"MageKing17" said:
Regardless, no physics engine should allow to objects to occupy the exact same space... it violates quantum mechanics.
Which hasn't been properly unified with gravity yet, if I might remind you...
#
MageKing17 6 years ago
"Amarth" said:
"MageKing17" said:
Regardless, no physics engine should allow to objects to occupy the exact same space... it violates quantum mechanics.
Which hasn't been properly unified with gravity yet, if I might remind you...
Pshaw, a piddling detail. Actually, I believe the exact restriction is that two objects can't occupy the same space with the same velocity... although I could be wrong there.
#
Forum » Another Javathingie.

Post Reply


Your email:
Your name: