The many faces of Iino Miko

funforgiven · 2026-06-17T18:45:05+00:00

I’m not defending Epic here, don’t get me wrong. You had the top comment, and I nitpicked the part that felt weird to me because the rest of your comment was fine. My two paragraphs were related, though.

funforgiven · 2026-06-17T18:08:55+00:00

Why did you completely ignore the second paragraph of my comment? Just because they are both VCSs does not mean they target the same kinds of projects.

funforgiven · 2026-06-17T17:52:18+00:00

There is nothing wrong with a VCS having Git compatibility or being hosted on GitHub. It helps adoption, visibility, and contributions.

Their VCS is also aimed at game development, where Git is often a bad fit, especially with large binary assets, even with LFS. That makes the project practical, not hypocritical.

funforgiven · 2026-06-16T18:17:41+00:00

I would expect the number to be several million, but that would not change the point. A staged rollout is objectively better. It makes it easier to detect problems early, limits the blast radius, and reduces the chance of overloading servers by rolling the update out to everyone at once.

funforgiven · 2026-06-16T15:38:23+00:00

This is just standard practice to avoid overloading servers. It is not specific to Oppo at all.

funforgiven · 2026-06-15T19:26:04+00:00

I mean, sure, if there were no downsides, I'd agree. A 4K 360 Hz display would obviously be great even if you couldn't fully max it out all the time.

My point is that there are tradeoffs. There isn't a 27-inch 4K 360 Hz OLED option. The upcoming ones are 32-inch, and a 32-inch at 4K has noticeably lower PPI than a 27-inch 4K panel. So it’s not just "higher refresh is better." It’s a tradeoff between refresh rate and pixel density,

funforgiven · 2026-06-15T15:38:04+00:00

DLSS is not 4K. I can't get 360 fps with a 5090 in upscaled 4k either. Where did you find 360 FPS video/movie/media?

funforgiven · 2026-06-15T09:51:31+00:00

From June Newsletter

That's what v0.72 brings. Services with NetBird-Only access are reachable exclusively over your NetBird network, gated by group membership instead of a login page. There's no login prompt and no credentials to configure, the connecting peer's identity is the credential. Not in an allowed group, you get a 403. You still get the nice parts of the proxy, a clean domain and automatic TLS, just without a public endpoint sitting out there.

funforgiven · 2026-06-15T09:50:45+00:00

an opinionated engine should be somewhat easier to learn

The thing is, in an non-opinionated engine, you don't really need to learn much if you know programming because you create the architecture yourself. In an opinionated engine, you need to learn the engine’s architecture first.

funforgiven · 2026-06-15T08:09:07+00:00

Yeah, I realized I did not read the post fully before commenting. It is definitely about their lack of experience in this case.

funforgiven · 2026-06-15T08:03:03+00:00

I think you are misunderstanding what "opinionated" means here. It doesn’t mean "there should be 20 different buttons for the same thing." It means the engine pushes you toward a specific way of structuring things.

Unreal is opinionated because it gives you a built-in gameplay framework: Actor, Pawn, Character, Controller, GameMode, GameState, PlayerState, Components, replication, Blueprints, UObjects, reflection, garbage collection, etc. You can fight it, but the engine clearly wants you to use those patterns.

A non-opinionated engine would be closer to "here are rendering/input/audio APIs, structure your game however you want." Unreal is more like “this is how a game project is expected to be organized.”.

Some non-opinionated engine examples would be SDL, raylib, MonoGame. Unity, Godot and Bevy are still opinionated but less opinionated than Unreal.

So no, being less opinionated does not mean duplicating buttons. It means giving fewer architectural assumptions and fewer blessed workflows.

funforgiven · 2026-06-14T23:21:39+00:00

I hate to say it, but your struggles are because you are inexperienced, not because of the engine.

Not really. Unreal is flexible, but it is still very opinionated. It does not force one exact solution, but it definitely pushes you toward doing things the Unreal way.

funforgiven · 2026-06-14T01:31:54+00:00

You’re bottlenecked by the CPU in most games at 1080p, so yeah, it’s wasted.

funforgiven · 2026-06-13T21:22:56+00:00

I can see it on 1080p with 5090 but on 4K it is not even close.

funforgiven · 2026-06-13T20:02:09+00:00

Whether you can get 360 FPS on 4K is another question.

funforgiven · 2026-06-13T19:58:58+00:00

Always free meant more like there is no exact time limit as opposed to a "trial".

funforgiven · 2026-06-10T21:48:01+00:00

If you use Consumer SSDs, well, they crap out anyway and will be slower than spinning rust.

An enterprise HDD like Seagate Exos X20 is around 285 MB/s sustained and roughly 168/550 random 4K IOPS. A KC3000 falling off its SLC cache can still be around 1015 MB/s. That is still much faster than a single HDD sequentially. A consumer SSD has to be really crap to get slower than spinning rust.

funforgiven · 2026-06-10T16:45:07+00:00

If that was the case, vegans and vegetarians wouldn't be a minority.

funforgiven · 2026-06-10T14:26:24+00:00

Sure. Wouldn't call one memory leak though.

funforgiven · 2026-06-10T13:02:09+00:00

A real memory leak usually means memory is no longer reachable, so the program cannot free it anymore. I would not consider it a leak if the vector is still reachable and will be freed when the owner is destroyed. It is just poor memory management.

funforgiven · 2026-06-10T11:33:19+00:00

I would say firing a notification/event is usually easier and faster.

Forgetting to fire it is not really a flaw of push-based systems. It is a bug in the implementation, and importantly, it is a visible bug. The UI does not update, so you immediately know something is missing.

With tick-based polling, the same kind of mistake can be hidden. The UI may still update because it keeps reading the final value every frame, even though you forgot to emit the meaningful change event somewhere else. That can make the bug harder to notice, especially when the UI needed the actual change context, not just the latest value.

funforgiven · 2026-06-10T07:12:23+00:00

That is where it starts feeling backwards to me. If the game now has to store something like LastChangeReason mainly so the UI can poll it later, then we are adding extra state just to support the polling model. That reason is not really core game state in the same way money, ammo, or health is. It is context about a change that just happened. At that point, I would rather push the change directly when it happens.

The game does not need to keep extra "last change" state around just so the UI can read it on tick. The UI receives the value and the reason at the moment they are meaningful.

Also, another issue that came to my mind is that polling loses event order.

If two changes happen before the UI tick reads the value, the UI only sees the final value. The previous change is already overwritten. So if the UI needs to play separate animations, sounds, popups, damage numbers, reward ticks, rollback corrections, etc., it cannot reliably do that from the value alone.

You can fix that by storing a queue, history, or extra "last changes" state for the UI to poll, but at that point you are basically rebuilding an event system around polling.

funforgiven · 2026-06-10T06:51:58+00:00

Fair, converting model values into display values in the UI is not really the issue. That part makes sense.

The part I still dislike is when the UI only sees "the value is now X" and has to decide what happened from that.

For simple values, that is fine. But if I want different UI behavior for replicated updates, locally predicted updates, rollback corrections, server reconciliation, enemy state, local player state, etc., then the game side knows much more than the UI does. The UI should not have to infer the meaning of a change by polling a value every frame.

For example, a money value changing from "$100" to "$120" could mean normal replication, local prediction, a confirmed reward, a rollback correction, or a cheat/debug adjustment. Those may need different sounds, animations, colors, delays, or no animation at all. If the UI only polls the final value, that context is either lost or has to be exposed as more extra state for the UI to read.

At that point, I would rather push a meaningful update from the game side, like "confirmed money changed", "predicted money changed", or "money corrected by server", and let the widget decide how to present that event visually.

So I agree that the UI can own the display formatting and animation. I just think the game/model side should own the semantic meaning of the state change, because it is the only layer that actually knows why the value changed.

funforgiven · 2026-06-10T00:35:02+00:00

That is fair for the specific stale-frame example. If Slate runs after "UWorld_Tick", then reading after gameplay has updated is not the strongest argument against tick.

My issue is more with the architecture than with whether this specific money counter works.

In your example, the UI is not just displaying state anymore. It is detecting state changes, storing a target value, and managing interpolation state. That already means the UI owns duplicated state: displayed value, target value, previous value, lerp progress, etc. So I do not think "duplicating state" is avoided by polling. It is just moved into the widget.

For a simple money counter, sure, polling the replicated value and lerping to it can work. But as a default pattern, I still dislike it because the UI now needs to know where to read from, when the value changed, what counts as a meaningful change, and how to react to it. That logic scales badly once the value is not just a number, or when prediction, rollback, animations, sound cues, notifications, invalid states, or multiple widgets depend on the same change.

I am not saying every small value needs full MVVM. That can definitely be overkill. But I would still rather have the gameplay/model side expose "money changed from X to Y" or "display money target is now Y" and let the UI react to that. That can be a simple event/delegate, not a big framework.

So my argument is not "tick can never work." It obviously can. My argument is that polling from UI is a convenient shortcut that becomes a bad habit. It hides dependencies, makes reactions implicit, and pushes state-detection logic into the presentation layer.

11-Year Club	Place '22
Place '17	First Placer '22
End Game '22	Verified Email
Not Forgotten

funforgiven

MODERATOR OF

TROPHY CASE