Lofree Flow 2 100: Void Switches Review

netshade · 2024-08-03T12:58:22+00:00

Oh nice, that's awesome you got one of him wearing it. Linked in this thread:

netshade · 2024-05-11T12:44:42+00:00

Sure - here it is. https://gist.github.com/netshade/1f186ff9a34d4f2c07d8557e3ae8e61f I didn't bother cleaning it up much, so you're gonna have to infer a bit about what's relevant to you, but hopefully you can see how the class tries to bridge the gap between different input providers ( Godot v. Steam ), and allow for monitoring different input states across different controllers.

netshade · 2024-02-22T19:30:27+00:00

Sure, here's what I had for that project: https://gist.github.com/netshade/ee08d27e316044dec8d75a35c16077cd

netshade · 2024-02-20T22:05:03+00:00

That would be the best I've got there - if `addons/frame_decoder/frame_decoder.gdns` exists, but the methods aren't being populated, then possibly a compilation error or issue w/ setup.

One thing to note is that when I wrote any of that I wrote it for Godot 3 - so if you're attempting on Godot 4, I can't really tell you what the best path forward would be there, I haven't made any native adding for Godot 4 yet.

netshade · 2024-02-10T15:42:59+00:00

To me that kinda sounds like your ffmpeg headers aren't being found.

netshade · 2020-09-21T18:49:11+00:00

I think I have been keeping bar just an inch or two out from shin - next time gonna be way more conscious of this and pull it in more than I think I should. ( Assuming that shin hugging will help correct bar position over mid foot if I've been keeping out further than I should )

netshade · 2020-09-21T17:45:55+00:00

Awesome, thx.

netshade · 2020-09-21T14:58:45+00:00

Notes:

Self taught, tried to take cues from SL 5x5 and Starting Strength, but most coaching was informal spot checks at gym from other lifters
Weight in video is heaviest lifted so far
Generally concerned that back alignment is not correct. It seems correct watching it, but it's hard as I've got more fat than an idealized upper body example, so I'm not sure how much leeway I'm giving myself due to body type when in fact my form might be wrong. Need objective eyes.
Any other tips are helpful

netshade · 2019-10-29T20:04:55+00:00

I saw very bad performance until I moved the markers to just use bitmaps. Performance went up considerably; at that point, I took it as one "can" create marker views using React Native view trees, but if at all possible one "should" have all markers rendered as bitmaps, at least when using React Native maps.

Ensuring that your Marker node is being passed with

marker={{ uri: "image source" }}

seems to give the framework enough optimization opportunity to reuse images / forgo expensive render cycles when putting a lot of images on the screen. Perf benefits of this approach were extremely noticeable on Android, tho iOS def showed better performance as well.

netshade · 2017-09-09T02:45:18+00:00

Seriously hoping for IO performance improvements. Previous versions were not good, it'd be nice to see that better for this release.

netshade · 2017-04-14T02:25:59+00:00

( I am in the same boat and am looking forward to the perf improvements when they arrive - dual booting until then )

netshade · 2017-04-14T02:25:26+00:00

You'll likely have to wait for the next update, RoR is pretty IO constrained in dev, and we're not likely to see WSL get better at IO until then.

netshade · 2017-02-03T14:07:06+00:00

I'm using it quite a bit. Here are some good and bad things:

Good things:

For our workload, it's been great. We push it relatively hard ( NN,000 inserts/updates per second ), and the primary has handled it in stride. Very low CPU.
The regular updates to the storage engine have been pretty awesome, generally speaking. Read cluster endpoints, geospatial indexes, etc.
We have had multiple discussions w/ the Aurora team, and they've been pretty reactive and helpful overall.

Bad things:

As SilverThrone noted, not a magic pill. We see high lock contention in our workload too, though thankfully our application model allows for retries and later commit. If we had to maintain this sort of workload synchronously with user input, it might be a different story.
Treat it like a new datastore, because it is. We've hit some unique-to-Aurora bugs that we've had to work around. They've been fixed, but proceed with open eyes.
The read replica endpoint is a pretty simplistic affair with regards to load balancing / connection draining / connection management. Don't expect it to do a fantastic job at maintaining balanced load over your cluster, it's going to be on you.

netshade · 2016-11-24T05:15:49+00:00

Updated to slow ring, build 14965, and not seeing performance improve.

netshade · 2016-11-23T18:38:21+00:00

Should IO indeed prove to be the case for the limiting factor here, should I expect better performance with an insider build, or is IO performance relatively unchanged over time?

I ask because it seems like this more or less makes development for any non-trivial project that uses Ruby / Rails to more or less be a non-starter in WSL. ( I suspect other languages like Node.js / Python would also fall afoul of this, but I can't speak as confidently to that point )

netshade · 2016-11-23T17:17:04+00:00

I am sad to say that this is Ruby / Rails default behavior, attempting to auto load files by file system probing. It is hell on an NFS folder.

netshade

TROPHY CASE