14,277 karma · joined March 19, 2015
Same thing with watch windows, memory views and the like. There are classes of problems that do well with printf but calling them "no-code" is vastly underselling them.
I really wouldn't like to migrate away but I can't say all the info that's been coming back has been making me want to have them as a part of my network infrastructure.
It's not like their hardware is cheap, I'd much rather pay a monthly subscription than be served ads.
The only reason the things aren't outright banned is the frequencies tend to be sub 100mhz so it only has a significant impact on HF. Still, nasty things and many have been found over the legal noise limits.
If you can I recommend point to point 2.4ghz wifi links. Since wifi is regulated by ERP they have a high gain antenna that usually punches through things better than an omni AP. I've done them through multiple walls from 300-400ft away.
From a hardware perspective just about every Android SoC minus a few odd ones have unified memory so there's really no reason for them to take a lock, at least for the heavy part of the operations that copy the texture and tile/swizzle.
> If we were talking about OpenGL, there would be absolutely nothing you can do. In OpenGL or other older APIs, it’s only possible to do API calls from one thread.
Isn't really true. You can load textures off thread[1] and other things which come in handy. Vulkan expands that but I've done multithreaded texture loading for instance almost a decade ago.
This is particular important if your not loading compressed textures as there's usually a tiling/swizzle pass and the texture copy can be significant on large textures(unless you're using something like eglCreateImageKHR).
[1] https://www.khronos.org/opengl/wiki/OpenGL_and_multithreadin...
There's a reason that they say performance is the most leaky abstraction.
Thankfully we have an amazing new technology called Light Emitting Diodes so we don't have to worry about that theoretical problem.
It's like expecting good intentions and then being surprised when a few bad actors ruin things for the larger group. Tragedy of the commons is exactly why stuff like this should be called out, each and every single time.
I don't know how you get to defend something when you're sidestepping the biggest problem with NFTs.
I'm fine with stupid and pointless things as long as your stupid and pointless things don't wreck the environment. If someone decides to poison the local water supply because it's an "art project" they still poisoned the fucking water supply.
The part that makes game engines both interesting and difficult is they made a series of discrete trade-offs to support the use cases of the types of games they ship. This is true from tooling workflows to rendering stacks to core engine layout like if they do heavy arena allocation or more open world dynamic entities.
We extended the engine we licensed with some fairly reasonable features and even doing the uplevel was a brutal, 4-6 month process to reconsile those changes.
The more recent versions bring it up to date well, it's a dense book but one I find myself coming back to more than any other for the incredible depth of practical engineering knowledge.
What makes those games interesting is the concept of Yomi[1] and learning to read an opponent. There's a decent amount of literature in the fighting game space and a bunch of other genres overlap as well.
I remain pretty skeptical of ML being a primary tool here since a lot of Yomi is psychological and not necessarily an optimization problem.
[1] https://www.gamasutra.com/blogs/CalebCompton/20190211/336365...
[1] http://imajeenyus.com/electronics/20120908_improving_adc_res...
[2] https://accidentalscientist.com/2014/12/why-movies-look-weir...
I like PLCs a bit more since they're dead simple to program and designed to handle a harsher environment than the RPi. They also have a whole host of I/O options and everything in industrial automation is standardized(-ish) so that you can interop between vendors for their different specialties.
One of the most fun part of the project was running the whole thing from solar, we have irrigation water so I build a neat little PID controller in the PLC that runs to a hefty Solid State Relay connected to a RV water pump with variable speed/flow. If you bypass the pressure relay, put in an appropriately sized flyback diode and use the SSR to do PWM it works quite well. It's no 3-phase VFD that you find on well pumps but it's held up well over the last year(and gave me an excuse to get a cheap hand-held scope to verify I had the flyback diode sized correctly).
[1] https://www.automationdirect.com/adc/shopping/catalog/progra...
Last year I stumbled across DIN rails and now unless I'm space constrained that's 100% the way to go for electronics stuff.
If you have binary assets and they don't support merging or regeneration from source artifacts that mandates locking(ideally built into SCM but I've seen wiki pages in a pinch at small scale).
Not directly related but learning about the diesel-electric locomotives and the transition from PWM DC to 3-phase VFD with the traction improvements(I seem to recall they doubled available traction but would have to check my sources[1]) was also something that caught me by surprise. All these EVs out there now owe a lot to the work that happened back in that industry.
Edit: found the one of the sources I remember reading.
[1] http://www.republiclocomotive.com/ac-traction-vs-dc-traction...
First, most of my background in this area comes from gamedev so YMMV if the same applies in your use cases.
For our usage we'd usually have a repo history size that crossed the 1TB mark and even upwards of 2-3TB in some cases. The developer sync was 150-200GB, the art sync was closer to 500-600GB and the teams were regularly churning through 50-100GB/week depending on where we were in production.
You need discipline specific views into the repo. It just speeds everything up and means that only the teams that need to take the pain have to. From a performance perspective Perforce blows the pants off anything else I've seen, SVN tries, but P4 was easily an order of magnitude faster to sync or do a clean fetch.
I've seen proxy servers done with git but it's usually some really hack thing scripted together with a ton of ductape and client-specific host overrides. When you have a team split across East Coast/West Coast(or other country) you need that proxy so that history is cached in a way that it only gets pulled in locally once. Having a split push/pull model is asking for trouble and last I checked it wasn't clear to me if stuff like git LFS actually handles locking cleanly across it.
From an overhead perspective git just falls over at ~1gb(hence git LFS, which I've seen teams use to varying degrees of success based on project size). The need to do shallow history and sidestep resolving deltas is a ton of complexity that isn't adding anything.
With a lot of assets, merging just doesn't exist and a DVCS totally falls over here. I've seen fights nearly break out in the hallway multiple times when two artist/animators both forgot to checkout a file(usually because someone missed the metadata to say it's an exclusive access file). With unmergeable binary files that don't get locked your choice is who gets to drop 1-3 days of work on the floor when the other person blows away their changes to commit. If those changes span multiple interconnected packages/formats/etc you have a hard fork that you can never bring back together.
There's a couple other details but that's the large ones, Perforce worked incredibly well in this space but it is not cheap and so I've seen teams try to go their own way to mixed success. I'll admit that you can't do a monorepo in P4(and even tools like repo in the Android world have their problems too) but if you segregate your large business/product lines across P4 repos it scales surprisingly well.
Anyway, you may or may not hit any or all of this but I've yet to see git tackle a 1TB+ repo history well(and things like repo that uses many mini-repos doesn't count in my book due to the lack of atomicity across submissions that span multiple repos).
Lack of locking for binary files, overhead > 1gb and all the shenanigans you need to do for proxy servers. There's better solutions out there but they aren't free.
We used to use the floating point hack for radix sort[1] in alpha sorting transparent quads on a back to front renderer. Depending on the cache line size we'd either have 3 or 4 pass sort radix with a puny little arm chip.
Guess what, that thing screamed because it was linear memory reads all the way through. We could throw thousands of quads at the thing and it wouldn't even flinch.
"If I had to delete this feature tomorrow how quickly could I do it?"
If you come back to this question a few times over development it does a wonderful job of really forcing you to consider your coupling and dependencies. In most cases it's been "delete a few dispatch calls and nuke the whole feature namespace" which has held up very well when future changes come down the pike.
Your dates are right too, at least from my experience during '04~'12. Being on the tail end of that inheritance based approach was brutal and was so happy to leave it behind.
The "S" in unreal is a tick. It's been about a decade since I last worked with Unreal but there was very much the concept of systems that processed batches of things in areas where performance was a concern.
Keep in mind that ECS is a design pattern and just like any design pattern applied blindly you can end up in a worse place than you started. A FactoryDispatcherQueuePatternImpl helps no one despite using many design patterns. When it comes to ECS it's much more about the spirit than the letter of the law.
We had a similar thing at one gamedev place that I worked at where and email would go out to the team if you left your computer unlocked(I forget the exact phrase but it was fairly silly).
We had shared offices and one of the programmers had the office right next to the kitchen. One day we all heard the senior programmer shout "WHAT THE FUCK!" and all ran over to see what had happened.
It turns out one of our engineers had walked into the kitchen and left his computer unlocked. The senior developer seeing this had opened up outlook, started a new message and began typing in the subject. What he didn't know is the developer had hand-rolled a keylogger with a match pattern for the message that everyone would send and dispatched Windows+L via key injection to the main window loop.
The trap was sprung and the machine locked right in front of him as he typed the last letter unable to send the email.
There was all sorts of other shenanigans at that place(like a fake "April 2nd" firing, they got the person who did that back with an annoy-a-tron over a 6 month period) but that was one of the more memorable ones.
The coroutines there was incredibly useful, our designers could write AI that was almost literate programming(yield value was number of frames to wait to re-eval coroutine). Something like: Walk to point A, yield until at A, turn, walk to point B, yield, check for nearby entity of type, yield, etc.
Oh and it also ran the whole game state in a 400kb preallocated block in a system than only had 8mb of accessible ram(rest went to vram).