Hacker Newsnew | past | comments | ask | show | jobs | submit | enbugger's commentslogin

Virtual Desktop is the only app which makes Quest 3 usable for work. And it is bad thing because it is available only on Win and Mac. Unfortunately, Linux alternatives' video encoding/postprocessing is inferior. Judging by my WiVRn experience. Hopefully that changes

Interesting observation. This is what was lurking in the back of my mind when I was playing Path of Exile. But I usually thought it would be very elegant to implement it in the form of Lisp macros that transform all the computations into fast code that would need to be executed every tick.

I also think something similar could be implemented for an in-game rig of animated characters. In order to cut off the computation of animations that don't affect the result in any way at an earlier stage — for example, when the character switches weapons. This could make animation code more CPU cache friendly as many conditions could be optimized out.


Yeah, that’s close to my intuition too.

I’m not generating code for this, at least not currently. It’s more like lowering authored content into fixed-size runtime data that the hot path can consume.

The animation graph example feels like the same general shape.


> Making it a "Compiler problem" makes it an unsolvable one in acceptable time.

If I understand correctly, "compilation" is needed only on equipment change. I remember some FPS drop in PoE when changing the gear too.

>in a beautiful mess of about 20k lines of calculations in various files.

And is it actually suitable for realtime? PoB is not a realtime application.


Stat recalculations are pretty much immediate, yes. The only thing that takes a while is calculating the nodes with the most potential gains, since you're in effect calculating reachability, combined stat increases, etc, which is a few thousands to millions of calculations depending on how far you look.

FPS drops in PoE would not be caused by damage recalc: this is done entirely server side and on application of the damage/dot tick. That drop you're seeing is just loading the assets and recompiling some shaders, if anything.

But also: it doesn't need to be realtime. Your damage is a simple math formula, applied against another for enemy defense, for each hit instance. There are definitely some builds that stress servers due to the sheer amount of hits/tick, but that's a matter of optimisation. PoE lowers server ticks when it can't follow.

The post is talking about optimizing for build damage/resistance/etc, crafting a build. Which probably doesn't even take into account conversion shenanigans, over time things like wardloop that requires setup, cwdt and a load of other things. This is not an optimizable thing in any reasonable time, and human application of logic is pretty much faster.


Small clarification: I don’t mean optimizing buildcraft in the Path of Building sense, as in searching the space of possible gear/tree/support setups and finding the best upgrade.

I mean the engine-side representation problem after the player already has a concrete setup.

So the “compiler” part is closer to:

equipped skills/supports/items/statuses -> emitted modifier/behavior rows -> dirty derived caches -> runtime facts consumed by combat

The output is not “the optimal build.” The output is things like increased damage, more multipliers, pierce count, area radius delta, conversion rules, status payloads, etc.

I agree that global build optimization quickly becomes a much harder and more human-guided problem. I’m mostly interested in how to keep normal runtime resolution from becoming a giant matrix of skill/support/item/status branches.


It shouldn’t. Same 3rd party extensions distribution model like in VSCode just written in Lua instead

A decision to move native because of the crisis seems like an expensive populist move to please not very solvent users. Why bother with that if many predict the RAM crisis will last merely until 2027?

If you can predict the future so accurately, why aren't you the richest man on the planet?

Because predicting the future roughly as well as everyone else doesn't make you rich.

Predicting a surge in RAM supply after a surge in RAM demand and a huge increase in RAM margins is economics 101.


We are still bound by natural resources, as much as economics 101 loves to ignore this simple fact.

Supply of RAM isn't really limited by natural resources - silicon is literally one of the most abundant materials on the planet. It's limited by the construction of billion dollar factories.

Scarcity of natural resources is squarely within the realm of economics 101.

The open question in my mind is for how long semiconductor demand will continue to grow faster than we can increase production capacity.


I can't. But I'm sure I will be happier and richer person if I don't opt out self from a working stack in favor of saving 100-200mb RAM

You're off by an order of magnitude there.

super happier and super richer?

How does it replace Obsidian though? I somehow think the author does not fully understand that knowledge management systems are inherently interactive and need to handle queries like in databases because they are databases.


1) Are there any benefits in replacing a personal private project git repo with jj? I usually just commit straight to master in order to just not to lose the changes and be able to roll back. 2) Are there any pros in doing so in a project with many large binary files (3d models, images)?


You don't replace. jj is backed by git anyway.


You can switch an existing git repo to jj by using:

jj git init --git-repo my-repo

I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.


No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though.

If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!


Okay but why would they use jj when they do trunk-based dev


I do trunk based dev. My colleagues prefer git. I still prefer to use jj.


Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.


I agree, however most indies don't need them, and most pros are getting into Unreal instead.

Also something like Burst is a workaround for using Mono with C#, which gets solved in Godot with C++.

How's the whole DOTS adoption going?


>gets solved in Godot with C++

if only by rewriting half of the Godot codebase. With design choices they made, Godot will never be performant enough for RTS/Crown simulation games.

https://github.com/godotengine/godot/issues/101494

>How's the whole DOTS adoption going?

I'm quite impressed to what people build on top of it: https://github.com/Dreaming381/Latios-Framework https://assetstore.unity.com/packages/tools/animation/mesh-a... and many more


> I don't want to design anything in any UI.

I had the same need and found Raylib_cs suit very well for that


Cool, you now can implement Elm architecture inspired GUI framework in C#.

As much as I hate Microsoft, I admit they are doing great things for C#


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: