This was totally unexpected: the Diablo II remaster doesn't just ship same-ish gameplay with new graphics. They actually decoupled the graphics engine to render at 60 FPS from the (old) game engine to not replicate, but actually preserve the exact game feel.
If the D2 team pulled that off, how hard can decoupling our apps be )
@ctietze TBH I don’t know many ways to decouple UIs like that. (Given the links I assume running the same app also on Win and Linux was your point/goal?)
I think it is possible in the specific case due to them owning the whole relevant stack (and having their completely custom UI).
@helge I can't tell if you're being completely serious.
The short answer would be to write a common abstraction. If you wire file system events directly to NSTableView updates, that's not trivial. But if there's intermediary services to handle events, incorporate data, and update the UI, then "update the UI" is the piece that requires changing.
(Swapping out an ncurses-based TUI for some simple AppKit UI to display text, buttons, and forms in windows is simpler than more complex UIs of course)
@ctietze I am serious, you can of course rewrite parts of an app for different UIs (though that is also super rare).
But that’s not what has been done in the game case, but the exact opposite. They have taken exactly the same “app” and decoupled that from the UI.
Having SwiftUI for the platforms would not be the same but more similar. But we don’t have access to that.
@ctietze Generally "app" to me means the whole thing, highly simplified the M, the V and the C.
If you are very lucky, you may be able to share the or parts of the M. But that really depends how you implement it, it is actually also quite uncommon that you can do this (because you'll rely on things like networking, user defaults or even CoreData)
The V&C can generally not be shared at all between platforms as they depend on it.
Now you could wrap everything, but then you got Electron 🙂
@ctietze My understanding from reading the game article, they changed almost nothing in the M, V or C. Maybe the V a little. But instead did something similar to YellowBox/Win or adding a new type of renderer for SwiftUI.
@ctietze Yellow Box is Cocoa, but I was specifically thinking of YB for Windows, i.e. Cocoa for Windows.
Yes, I don't think they actually changed the V much in the game. My feeling is that it is more like a SwiftUI TextField is a UIKit UITextField on iOS. And on a more capable machine the TextField is the way more powerful NSTextField.
In the game case the article was talking about animations being replaced w/ higher FPS.
@helge the FPS part is what makes me thing that these are two systems that interoperate, but aren't that tightly coupled.
At 30 FPS, say, the game engine produces "ticks" to calculate actions. Nobody knows how they do it, but we could imagine a NSNotification like signal for simplicity.
The rendering engine operates at 60 FPS to display 3D graphics smoothly. Every 2 frames, it gets an instruction from the game world/engine.
@ctietze I think the article is more concerned about in-app API migrations.
The API surface of Cocoa (or any sufficiently advanced UI framework) is way too big to abstract it out.
E.g. one of the advantages of SwiftUI is that it does not have such a layer but directly integrates Cocoa (and gets corrupted by it, but for good reasons).
I’m not convinced. KISS.
@ctietze But getting back to apps on Windows/Linux, I think you essentially have to rewrite the app mostly from scratch, even if it is in Swift. Unless you want to replicate Cocoa or SwiftUI itself on those platforms (e.g. YB or GNUstep).
Even just on iOS&macOS this is some work. E.g. ASCII Cows (iOS) and CodeCows (macOS) are essentially the same thing, but the platform features are wildly different and those are a major part of the apps themselves (e.g. services on Mac or the widgets on iOS).
@ctietze It would be much different if we had access to the original "engine", like the game has, i.e. SwiftUI code and associated tech.
YB for Windows essentially had this, just recompile for Windows and you are done. It worked surprisingly well. https://mastodon.social/@helge/111732721989522119
@helge this actually looks really cool. I'm kind of sad that this Smalltalk editor inspiration era totally went past me and I was stuck with QuickBASIC in the 90's :)
@ctietze Cocoa is more advanced today, but this was essentially a complete implementation for Windows (there was also one for Solaris X11).
It wasn’t perfect though, as cross platforms frameworks go, they never really feel native. (even on Windows which is not very consistent in the first place)
Add comment