vvanders

Oh it totally matters, any sort of chatty interface over FFI you will pay for it.

There's a reason a lot of gamedev uses luajit, I've personally had to refactor many interfaces to avoid JNI calls as much as possible as there was significant overhead(both in the call and from the VM not being able to optimize around it).

Ex-gamedev and this totally rings true.

We had one title I worked on where the "interviews with the dev team" was all just interviews with the external producers(aka PM who came in from the publisher to keep everything "on track").

Never happened to us but the best one I heard was that the publisher puts a clause in your contract that they get the source+IP if you go bankrupt(protect their investments, their taking huge risk, etc....). However about 2/3 through development when the studio is at peak HC burn they would start denying milestones for trivial things. One, two milestones go by and the studio burns through all cash, folds and publisher gets source+IP. Publisher then hires the dev team, who just lost their jobs, at a reduced rate(most gamedev a don't have great savings...) to finish out the game, avoids paying any royalties and picks up the IP.

Happy to be out of that industry, some really interesting technical challenges and driven people but the whole thing is similar to the recording industry in the way they exploit people and passions for their own gain.

Nooo, please don't use that.

They basically turn all the electrical wires in your house into a giant antenna and radiate broadband noise.

I honestly don't know how the damn things are even legal by the FCC given how noisy they are.

I often joke that I have an amateur radio license and only use wired earbuds for conference calls.

The 2.4ghz ISM bands are just noisy, sometimes all it takes is a poorly shielded microwave to take out everything in a 50 yard radius.

Head of line blocking in TCP is what made/makes this hard. I've seen some approaches stagger multiple sockets to mitigate but it is highly dependent on packet loss.

I would argue WebRTC is where this really became possible, although last I looked at the spec it made a best-effort at using UDP for datagram based messages but would fallback to TCP in some cases.

It's a fun domain and lots of really interesting approaches(like lockstep called out above as well as other fun things like dead reckoning).

Everybody forgets about sidekick in this comparison. Had apps, email(push pop3!), IM, a functional browser was a killer device esp considering what hardware they were working with at the time.

> The entry barrier is also too high; you need too many years of serious CS education, usually a PhD.

School taught me none of that(the opposite with more of a focus on big-o and ignore the constants), all the good systems engineers I know either learned it on the job or were self taught.

I don't think the OP said those things were pointless, only that they are already actively used in industry standard approaches.

FWIW I agree with the assessment, the terms are broad, generic and have no specific connotation for gamedev. It's not oriented at anyone in industry since you'd talk about specifics and not the "cloud", "ai", or "blockchain".

If you're curious about this area, Real-Time Collision Detection[1] is one of my favorite technical books on this topic. While the title is "Collision Detection" it's basically data structures for 2D/3D. It's also the only algorithms book I've seen to actually have a section on CPU cache-aware algorithms instead of assuming you only care about big-O notation.

[1] https://www.amazon.com/Real-Time-Collision-Detection-Interac...

I think his point about the amount of research done on ARC vs GC was interesting. Only recently have we see things like biased reference counting[1] that can significantly reduce the overhead of ARC.

[1] http://iacoma.cs.uiuc.edu/iacoma-papers/PRES/present_pact18....

Yep, you can see this if you go poke into LoRa and associated protocols. 915MHz does have some restrictions on either using spread spectrum, frequency hopping or much lower power limits so it's still quite different than say the ham bands.

The claim is that if you don't "optimize" for TBDR then you are gated by the TLB and that software written for immediate mode rendering isn't optimized this way.

However drawcall batching, minimizing render target(and state!) switching are all bread-and-butter performance optimizations you'd make for an immediate mode renderer as well. You can get away with more drawcalls and there are specific things you can do on a per-architecture basis but they don't involve anything having to do with TLBs to the best of my knowledge. If someone wants to spill the beans on how the M1 is somewhat different here I'm all ears but it just doesn't line up with most GPU architectures I've seen.

The big wins between TBR and IMR usually involve getting larger tiles through less usage of rendertargets[1] as it increases the total size of the tiles which drives efficiencies in dispatching the tiles.

[1] https://developer.qualcomm.com/sites/default/files/docs/adre...

I'm not privy to the security mechanisms of the integrated GPUs I've worked with however I've got a decent amount of experience with mostly tile based GPUs and I've never hit TLB misses as a reason the GPU is going slow. On the CPU? Sure, but unless they want to get a lot more specific on what these optimizations are it's a bit hard to piece together what's going on here.

GPUs don't like to read around in memory(neither do CPUs for that matter but then tend to branch and be a lot less predictable) so optimizing reads/writes are something you will do regardless. The painful parts of TBRs usually(but not universally) have to do with drawcalls setup and render target switching. I remember some of the early iPhones had pretty painfully low drawcalls limits associated with the overhead with dispatching the actual calls as opposed to triangle count or fillrate. It's fairly easy to put together the synthetic benchmarks to shake that out.

Yeah but a TLB is for user space virtual memory mapping. When your talking about GPU operations those usually go through opaque handles or allocated buffers and the DMA/read/write is done outside of user space(aside from initial data uploads or the case where you have unsynchronized user space memory buffers, but that's not usually the norm). Some of this changes a bit with Vulkan but it's not really clear from the thread how a TLB fits in.

Optimizing for TBR involves reducing drawcalls, buffer target switches and operations that are orthogonal to what a TLB historically does.

I've never heard it called TBIR, always TBDR or just tile based rendering.

I honestly can't make heads or tails of the Twitter thread. It talks about having too many small reads/writes but that's the whole point of tile based rendering. You use the tile as scratch space to do operations that are expensive in system memory.

This approach is well over a decade old at this point and pretty ubiquitous in power constrained rendering scenarios[1]. Best I can tell you need to take architecture into consideration when trying to get the peak GPU usage which has always been true of any platform regardless of tiled or immediate mode rendering.

[1] https://developer.qualcomm.com/sites/default/files/docs/adre...

> ... and you'll never convince me that creating boxes and wiring them up will ever be as good as text at expressing game logic and game rules.

Sure, that's pretty clear :). If you want to re-read my post above I wasn't saying that would be as good at game rules and there's a very real limitation as soon as you get away from scripted encounters and into anything more complex.

At the same time consider there may be people, teams and designers who it does work for. Very few things are in absolute and there are places where I've seen tools like this used effectively.

Sure but as far as scripting languages go it was enough to get the job done at the time. I don't think swapping to Lua would fundamentally change that.

I say that as someone who's worked on both sides and shipped production Lua, Unreal script and C++ during that era. Visual scripting/programming tools are for your designers/artists/animators or as glue code between content that is under high iteration cycles. You can do things such as "find all references to this actor" or realtime visualization of states that just aren't as streamlined as text based languages.

The tradeoff is there's a level of complexity where text based languages are better at expressing abstractions and structure, you use them in different contexts and for different parts of a project.

Not many game engines are well documented so there's more than a few out there that do this. One that I worked on used Maya DAG extensively for similar features(although it made it fun to fight over the floating licenses sometimes).

We used to have UnrealScript and 9/10 our designers still reached for Kismet instead.

Lua is great and I'm a huge proponent of it but different tools are meant for different use cases.

Yep, and Kismet before that. The usual consumers are designers and tech artists, at least in the teams I was on.

Previous to that we also heavily leveraged Lua coroutines as a form of literate programming/game "script". Since the coroutines would execute in a linear manner(with yield() where it handed execution back to the engine) it was really powerful for scripted sequences.

Another interesting area is industrial/PLC programming. The parallels between what we did in gamedev and ladder programming was striking. Visual state representation, online edit-deploy-debug. I'm fairly confident you could give a designer a copy of a ladder editor connected to a game engine and they would have no problem scripting out a sequence.

I would hazard that game engines are an order of magnitude more complex than web frameworks. A better analogy may be game engine vs db engine or web framework+runtime(ex: Erlang/Elixir+Phoenix). If you have performance issues with a web framework you can scale it horizontally to a degree(depending on downstream dependencies like your DB). Games are built to run against resource constrained hardware and so they optimize for specific usage patterns.

There's also the issue that most engines are built to be good at a specific game type and may make trade-offs in terms of how assets are managed and scene complexity. An open-world has much more different requirements than an on-rails shooter. For instance I had to do some pretty heavy retrofitting of one of those engines to handle LoD/geometry streaming and a bunch of other optimizations to make them work well with a large sight-distance game.

Maybe I read it differently but I think the bar that one can hold and the performance against that bar("high"/"low") can be two separate things. Sometimes they correlate but not always.

My read on the article was more on a mis-alignment of values and what is considered success. High bar / low "performance"(which is a subjective thing and can vary based on external factors) are those who want to learn because they know they aren't at that bar now but they want to be.

"Low bar" / high or low performance means that you have different goals and different measures of "success". If you don't resolve those first then that leads to the friction and the pattern the author outlines.

This can be in a bunch of different areas(security, performance, maintainability) and sometimes if you have two people who hold velocity and architecture separately as their highest bar it can appear that they don't value each other's bar since they are in direct conflict. It's been my experience that if you can ground it in why people hold certain bars and that the goals are actually aligned then the sum of the team that hold a high bar in different areas is greater than the parts.

Oh man, the eDRAM on X360 makes so much more sense now. I always wondered why that was the case but I wasn't as close to the graphics side of things when I was working in gamedev.

GPUs are always something where people have... strong opinions about. That said having spent a bunch of time with the Adrenos they were pretty solid embedded GPUs and watching the generational leaps from 100/200/300/400 was a ton of fun. The GPU group over there at QC had some sharp people and were always great to work with(at least from my exposure).

Working in gamedev the audio team would always share how they did certain sounds on the condition that you never mentioned how outside of the room.

There's nothing more infuriating for the audio team then someone pointing out how an audio was made in a demo only to then have to redo a track because that's all key people can think of when they hear it.

This is so good, I clearly remember in the early days of gamedev a lot of this was known very much by word of mouth(we used to call it NAT punch-through) and it was a right pain in the ass to get working(layer on dynamic host migration and you had one of the most fun/challenging problems in gamedev networking).

As someone who's rolled a few custom UDP network stacks I would tend to agree.

UDP is pretty low level(yay MTU discovery) but it gives you most of the tools you need which is why a good number of SCTP implementations are just built on top of it.

Yep, we used to have it and I'd happily pay but went ~2 months checking the app with no appointments other than a 3 hour one-way trip across a ferry.

The app does a pretty poor job of not allowing you to specify issues outside of the standard flow. I could have called a service center but between how hard it was to source a 12v battery independently(I know it's a deep-cycle battery but still!) and high mileage I just don't think it's a car for us any more.

Yup, the really frustrating part is you can't even order parts. It's easy enough to replace but I just couldn't source it.

Tesla has stopped doing the mobile service thing(at least in our area). Used to be able to get a mobile appointment at a cost, this time I couldn't even get them to come out to swap a battery(much less an LTE upgrade).

If they can't provide service I'll be going to other brands that's have a larger service network.

A good chunk of my time was in SoC eval so if the vendor was being complacent they didn't get the bid. You should always be running multiple solutions so you don't get locked in with a certain vendor(and also a really good reason to keep any tech stack you have highly portable).

Even then though there's ways to approach it that don't disclose. You can set KPIs that you expect to hit and talk through how they plan too approach it from their side. If something is known in the public you can reference it although I generally prefer not to.

Depending on what part of the industry you're in some vendors prefer not to patent and keep approaches internal so discussion of certain aspects can be pretty sensitive.