Algodoo

Tetris incoming

kinda. the Tetris scene is 30x20 but it's on hold for some time

You did nail down burst, but auto doesn't work lol. it's just burst too at least in my case?

It's very nice though

"pistol engines" don't exist

I think this is the fastest realistic mechanism. The actual fastest one probably goes to Meerkoos on a belt-fed, but he didn't even chamber the rounds. otherwise maybe lololoer's turret (or my improved version, dunno if i ever uploaded it but it was even faster).

But this is awesome

lol, huge fail...

The "engine" is running at that max speed because you're hitting the angVel limiter... Set it to infinite (open the console with F10, write "Sim.limitAngVel = +inf" and check again)

Try something more complicated next time. anyone can make a circle and slap a spring on it

Kilinich's 3d engine maybe. he uses lasers to scan a 2d scene and then projects all that on a screen with some X pixels that can change height

@Xray:
-Why don't you just delete the cloud image file from your Algodoo installation folder? Lol

-That is literally the snippet of code that my scene uses, but I also added the option to turn it off when the scene is running (by clicking the button). It used to be that the play mode got enabled when you hovered over the slider, but there's a slight delay and Algodoo freezes for a fraction of a second; it was bearable but not ideal. Plus, I think you should actually take this as feedback; I hate not having a button to turn play mode off while the scene runs. In this case Play Mode is enabled when the scene starts and disabled when the scene is paused, unless you hit the button in which case it will not be enabled.

-I know about 128 text, it's more of a style - i just like how 12 text looks with high alpha value (around 200, 300)


Jakub just said it right above this comment... It's better to be able to DISABLE the automatic play mode without having to pause, then mess with the scene's code...

EDIT: There was a very strange bug; for some reason play mode gets enabled even though the code shouldn't let it do that at all (the scene was obviously uploaded with play mode off). Anyhow it's fixed now.

the Play Mode button works as it should now, but I suspect a massive bug, since playMode would be either off or dependent of sim.running - no chance that play mode would be on with the scene paused. idk. anyhow this is not related to the actual slider

Your butt-blistering 110 rad/s is 1050 RPM. just multiply rad/s by 9.54

Tbh it's pretty good as a start, but there are some things you're doing backwards.
Use a circular, balanced flywheel, otherwise it'll be all over the place
Use a spring instead of a polygon for the rod (constant 1e10, damping +inf, and also set "forceDirectSolve" to true, on the script menu), they are miles ahead
Use less reciprocation (rod closer to the center of the flywheel) and maybe a shorter rod, honestly it's more of an aesthetic thing
Don't use polygons for ANYTHING that collides with a lot of force (for example, the cylinder walls). Use boxes there. Any actual physics entity (circles & boxes) are way better at physics than polygons and also lag a lot less. even if the polygon is just box-shaped, it'll be worse
To get any real power from the engine without making it explode, you have to set the spring with the negative damping to legacyMode 0 on its script menu. you should be able to go stupidly high on constant
And probably the most important of all, use VERY HIGH DENSITY on all the colliding parts! For example 100 or more on the piston. High density is like higher frequency but without the horrible performance drop.

Btw if your engine explodes as soon as the scene starts or stutters and freezes it's most probably because a spring is connected to a low mass object on one of its ends. just get the density to something reasonable like 100, 200, mabe even 500

Follow all this stuff and you'll be able to make a realistic size engine

also where's a scripted hinge??
If you mean the one with bend on, that's not set correctly. you need to set bend to true, bendConstant to whatever amount of Nm you want (just +inf) and bendTarget to the angle in between (just use 0).
If the connection is still horribly weak then you need to incerase the density on the objects that the axle is connected to. a lot too

And lastly use a much, MUCH lower hingeConstant on it, usually 1e-30 is the lowest value you can use. that value is the Newtons that the hinge does when stretched, so 1e-30 is 0.000000000000000000000000000001 N while you're using 900 N. that's around 90 Kg of force

that's really fast!
how long have you been around?

Because it is made like this on purpose. More "GPU's" (or rather, make 2/3/more rows of pixels at the same time) will mean MUCH slower simulation speed. On your PC you have the same CPU of which only one core is being used, so making two rows of pixels at every scene step would be roughly the same to doubling the simulation frequency

even better, why not use update to check whether your mouse is close to the center of the scene? For example if the mouse is close to the leftmost edge of the screen, turn the nodes off, because this means the user is probably going to go to another scene. if the suer moves the mouse out of that "off" area the nodes should turn on again or just stay off depending on the "show nodes" button state.

just an idea

Also, it'd be very nice to test whether more nodes for a polygon with the same geometry means worse physics, and how much impact they have in performance. i'd try that myself but i don't have that much time really

Also one more thing, why is it that only sometimes you can delete nodes, while most of the times it simply moves it so that it's as if it wasn't there?

this is awesome

I was going around on your scenes and found something weird that you were talking about (the "resonance"). That is just your axles going above the directSolve limit of sanity and going boom. Use legacyMode 0 on all of them and you'll be able to eliminate that entirely (try that on your "super smooth spring engine").

legacyMode 0 axles are weaker and usually require higher mass to brake decently though. it works on your scene

Lol, I'll have to rewrite a lot of the Tetris scene... it's a mess

eh what
it's not just the pic
this is a variable compression engine

Dude. I really want to lend a hand here. This thing is way over the average level in here...

When you say Algodoo doesn't let you use loops longer than 32, did you try using smaller loops (or simply one instruction) and repeat that every step until you're done? It's much slower, for example at 120 Hz (you're using 60, but you could use 120 Hz perfectly) you would get 120 code runs per second, which is pretty good. If you loop 8 times, you can get 120*8 = 960 runs per second, assuming your PC is fast enough to run 8 each step. if you pair that with PC graphics, you can make a very nice thing.

you might be able to integrate my 20x15 screen here, too. like Kutis96 did; use a pixel array on the back and a transparent box that uses text on the front to display text. i have a 30x20 screen too but it might be too resource-intensive.

Also another thing, with a decent amount of Thyme-fu you can make rather simple interconnects that use Scene.entityByGeomID to communicate with other objects, and thus be able to forgo scene.my's and not cause lag while you are not transmitting.

and yet another thing, you can use Keys.isDown("x") to know if the key is being pressed, and also you can get which key is being pressed if you use e.keycode in onKey, like this:

onKey = (e)=>{ _keyCode = e.keycode}

it will return a string like "w", "right", or whatever.

i tell you this because i saw your "text manager"

poor dude actually hit the steering wheel, so he might as well be dead. But nice anyways

this is kind of a digital jfet. instead of trying to make a computer with an absolute crapton of discrete transistor-esque thingies, why don't you make logic gates with lasers, and make your CPU (i'm guessing just ALUs) out of those?

But yeah this is better than that physical transistor thing by a long shot

well nice, but i still think "e.keycode" on onKey will be more useful to you, since your keyboard grabber would be made with a few lines of code

Lol, I actually need one of these, but getting one here for free/cheap is not nearly as easy as in the US... People just keep fixing the CRT dinosaurs and sell them for $100 or more, and i don't really trust one of these so much as to buy one at that price

I'm currently using Soundcard Scope with my pc any time I have to troubleshoot audio stuff, but other than that it's unusable for digital or anything above ~40KHz

Lol, pretty much. I'll see what I can get eventually

you pretty much have to learn yourself. I could lend you a hand if you could use Telegram.

You have to use if statements to check for instructions, i'm not sure how you would go around that. maybe using switch case but it doesn't exist on Thyme

can't find you on Telegram - find me on +5491168228743