If only we could just ship a 256GB NVMe SSD with every game and memory map the entire drive like you could with cartridges back then. Never have loading times again.
Also: I think it got less common on the N64, but games on SNES and NES and other old home consoles routinely accessed static game data, like graphic tiles, directly from the cartridge ROM. Without loading it into system RAM at all.
So there literally were no "loading" times for these assets. This might not even be realistically possible with NAND flash based SSDs, e.g. because of considerations like latency.
Though directly accessing ROM memory would also prevent things like texture block compression I believe.
I’m vibe coding a little macOS OCR app since last weekend, and I’m really happy with the results so far. This is my first app, so fingers crossed. If it becomes feature-complete and polished enough, I’m considering open sourcing it. There’s still a long way to go, though.
You can get dynamic contracts based on the day ahead price in Germany. You pay a negative price for the electricity there. You still have to pay a transmission fee and taxes, so the actual end price is almost never negative though.
Of course sometimes you also pay much more than normal contracts.
Also without merit order, you'd still pay close to the most expensive source on the spot market. It's a consequence of the open grid where demand and supply has to match and price is not fixed.
Reference counting is not tracing garbage collection. To also quote a Wikipedia Link:
„The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object.“
Of course reference counting is not tracing garbage collection. I never said it was. The comment I replied to claimed reference counting was not garbage collection at all and seemed to think tracing garbage collection was the only kind of garbage collection. Reference counting and tracing garbage collection are two different types of garbage collection.
Indeed. I think I only mentioned it because of the original reference to it not being a RTX 4090, with a somewhat adjusted perspective of what performance it is closer to.
>I wish Apple would hire a team to properly maintain this, the way Valve has done with Proton and Steam Deck Verified.
Valve cooperated with Codeweavers, the makers of Crossover, to build Proton. And afaik Apple „works“ with Codeweavers. Well at least they don‘t get in the way to incorporate GPTK into Crossover. Apple changed the licence of GPTK so that Codeweavers can include GPTK.
Good point! Have you had any experience with CrossOver? Does it tend to work better than Whisky?
Part of the nuance here is that although both can use GPT underneath, there's still a lot of config that needs to happen beforehand (e.g. different "sync" modes that impact not just visual fidelity, but whether the game will even launch at all). Does CrossOver take care of all that for you (with predefined pre-game profiles, perhaps) or do you still have to manually configure every title?
> Good point! Have you had any experience with CrossOver? Does it tend to work better than Whisky?
It certainly does. It has presets for most mainstream games and it uses the latest version of Wine.
The author of Whisky, in a move that can't be praised enough, has decided to not update further the version of CrossOver on which Whisky relies. This is so that Whisky does not become a free clone of CrossOver, given that CodeWeavers are the ones developing Wine. So, I'd say it is worth using CrossOver! They also have a free trial, so I'd give it a try and compare it with Whisky for a specific game, and see what runs better!
Not in depth. I’m just a user of Crossover, I haven’t had time to try Whisky.
I think sometimes Codeweavers incorporates fixes for certain games into the app updates. Especially for the Steam app, for example. These appear in the changelogs.
I use Crossover with CXPatcher because I then can use more up-to-date versions of DXVK and GPTK. The update cycle of Crossover is a bit slow for what is going on in that space right now.
