It's nice to see support for vulkan in qemu actually getting somewhere, being able to run modern accelerated workloads inside a vm (without dealing with sr-iov) is pretty cool and definitely has some use cases.
Generally you want to avoid wasting too much memory on a GPU, even today. That large text box texture also has to go over the PCI bus which can cause stalls depending on when its uploaded and if the GPU ends up having to evict resources. If you end up having a lot of independent texture text boxes being rendered by the comparatively slower CPU, that could add up quickly and cut into your budget.
Drawing using a glyph atlas is still a way better use of resources. Modern text rendering pipelines will also often use either SDF or encoded bezier curves to improve glyph legibility when scaling which is also a great way of saving more memory.
One issue I have with a lot of the N100 systems is there seems to be a lot of variants from different manufacturers, slightly different form factors, etc. The PI may be worse but at least you have a pretty good idea what you are actually getting most of the time.
I'm half-way porting another turn of the century game engine to emscripten but I'm a little stuck on the networking so it's pretty cool being able to have practical examples to reference.
My biggest problem with WebGPU is the documentation, especially if you delve into the native or emscripten variants. Not even fancy AI tools will save you - in fact in a lot of cases they make it worse as they often suggest solutions based on older webgpu variants or they make grossly inaccurate assumptions about how your particular webgpu implementation works.
Figuring out how to properly setup the "native" version was a nightmare, I had to find a random github project where someone thankfully made a SDL2 example.
I didn't really feel there was an active community that was interested in pointing me in the right direction either, more like a bunch of people too absorbed with building an API than actually caring about who is using it.
Maybe things will improve in the future but I remain skeptical.
Great to see more projects actually battle testing WebGPU.
I've been working on porting an existing engine to WebGPU and personally I think it's one of the worst GPU APIs I have had the pleasure of working with. Perhaps if we see more practical real-world use-cases with real feedback we'll see some improvement in a later update.
Writing an engine from scratch is debatably more complicated since you need to do a lot of guesswork around what capabilities you actually need and how badly the artists and gameplay programmers will break everything - assuming your not doing it all solo.
It amazes me how much terry latched onto that idea, even binding the "god says" functionality to the F7 key in TempleOS.
Sometimes I wonder how he would have reacted to ChatGPT and LLMs.
I've seen a lot of fancy full realistic 3d simulation games this past decade, but they can't hold a candle to a well thought out 2d simulation with solid controls.
I had a pretty bad concussion when I was very young and I still remember how distorted my short term memory was right afterwards and to a lesser extent weeks after. Couldn't imagine trying to be active nowadays under those circumstances.
Torque was pretty instrumental in kick-starting my career. Glad it's still being maintained to this day (despite it arguably getting steamrolled by unity and mismanagement).
Long-term I think the real problem for artists will be corporations generating their own high quality targeted datasets from a cheap labor pool, completely outcompeting them by a landslide.
Speaking of networking issues, one big problem I ran into was running out of memory for network devices when using a nested setup (requiring a system restart to fix). Would have been a great lxc alternative otherwise.
From recent experience I'd say it's the sort of tech that starts off simple enough with the right distribution, but then gets more complicated the deeper down you dive.
Probably the most hard thing I found was wrapping my head around the way the storage works.
Feels like there has been a noticeable shift globally these past few years in favor of burdening websites to protect kids online. Makes me wonder: has the internet really gotten worse, or is something else going on here?
It was more business logic issues relating to conditional logic which needed to factor in a lot of edge cases. I don't think strong typing would have helped much in this case.
I bumped into so many corner case and dumb bugs on a recent python project that I'm even more of a unit testing enthusiast than before. Past a certain level of complexity they are definitely a net benefit.
Onedev has pretty good features built-in. They even seem to have a paid option now too which adds some additional features, though I wonder what the division between paid and unpaid features will look like as the project ages. To be fair though, there only seems to be one person consistently working on it.
Also there is just something about its sidebar-centric UI I just don't like. It's not as bad as gitlab but still, it bugs me every time I use it.
I stayed away from jenkins for a long while because of its bad reputation, but after diving into it for a recent project I was surprisingly impressed how easy it was to set everything up (with the docker image at least), and it seemed that there was a solution for just about every convoluted build scenario I could come up with. In contrast, I've tried out other tools and encountered: confusing uis, too much focus on docker, broken interop with forges, poor documentation, too much yaml, ...
I guess the flexibility with jenkins is probably both a blessing and a curse.
One time I submitted a patch to implement a feature in an Open Source project, it got completely ignored for 6 months until someone else implemented the same feature which the project went with. Felt a little frustrating, but I've learned sometimes these kind of things happen in large projects.
In my experience, short-term pay for contracting is great. Long-term you start to run into problems because clients come and go, you always need to be on your feet looking for a new set of leads. Sometimes you have a bad project which sets you back. Being a salaried developer definitely shields you more from unpredictability.
Darling is a pretty impressive project. I checked it out a few years ago and was able to get an old 32bit osx program running on linux, which was pretty cool to say the last. The amount of work that goes into stubbing and reimplementing all the frameworks is pretty mind boggling though, I'd commend anyone who takes up such a mammoth challenge.