Based on the latter tweet in the chain, I'm wondering if Carmack is hinting that Foveated Rendering (more processing power is diverted towards the specific part of the screen you're looking at) was one advantage envisioned for it. But perhaps he's saying that he's not so sure if the performance gains from it actually justify building a custom OS instead of just overclocking the GPU along with an existing OS?
Wouldn't that be an application (or at most system library) concern though? The OS is just there to sling pixels, it wouldn't have any idea whether those pixels are blurry… well for VR it would all be OpenGL or equivalent so the OS just did hardware access permissions.
I think the context is that foveated rendering ties sensor input (measuring gaze direction) to the rendering pipeline in a way that requires very low latency. Past a certain point reducing latency requires optimizations that break normal abstractions made by user land, so you end up with something more custom. I'm not sure why that would require a whole new OS, the obvious path would be to put the latency-sensitive code onto dedicated hardware and leave the rest managed by Linux. If a bunch of smart people thought XROS was a good idea there's probably something there though, even if it didn't pan out.
Costco requires a yearly membership, so I think they are implying that the incentive is different. Costco has a strong incentive for you to leave with a decent time there, and feeling like you got a good deal (mostly through buying items in bulk) so you'll continue to renew your membership year after year.
At Walmart they might organize the store to get you to buy candy at the checkout line, or have a lot of less-than-healty options to tempt you near the essentials, to maximize the profit in that way. Because you're not shopping at Walmart because you want to be.
Disclaimer: I haven't been to Costco at a long time. And they still try to get you in their own way with free samples you can find all over the store.
First I had an unsuccessful journey with GameMaker, then a lot of time spent modding Minecraft in middle school without really understanding how to code. Finally, LÖVE ended up becoming my main time-sink for most of my free time through high school, about a decade ago.
Every evening I would start a new project. Some were random game ideas, some were to study certain aspects of math (like fractals), some were just meant to be nice to look at. This is where I learned a lot about game design, and also a lot of the harder aspects of programming (after that, my college CS degree ended up being a breeze).
I was working alongside an internet friend on these. Sometimes we would collaborate on something exciting, sometimes we would work alone on something and share lots of progress updates between each other. It was a really fun time. I think LÖVE having no GUI really helped our minds to run free while we learned how powerful computers could be.
Some of my LÖVE projects I remember the most fondly:
- A gravity simulation / art canvas where ships would fly around planets and paint a trail behind them [1].
- An online multiplayer platformer roguelike with full rollback netcode that handles 150ms+ ping (this was a real challenge!) - never completed.
- An online pseudo-rhythm game where you only have one button to use and you have to work with your friends to input in the correct order while a timer keeps ticking down [2].
The last one still lives rent free in my mind. This one still gets downloads today, it's the most popular project I've been a part of. But I suspect most players don't get past the step of needing to forward ports and find 3 friends to play a short 5 minute indie game. I'm proud of the idea behind it, but I don't have a good way to turn it into a full game without ruining the core idea.
LÖVE was my tool of choice for many gamejams, it was a breeze to put together a prototype once I had gotten comfortable. Today I think I have more perspective and wish I could go back in time to see more of my 100+ prototypes to completion, instead of always finding a reason something was imperfect and not worth pursuing. Now I just don't have the same amount of energy when I get home from my software day job, I often need the time just to unwind. Lately I'm trying to push through and make gamedev a habit even if it's hard, to get back some of the joy during the days I was in love with LÖVE.
> An online multiplayer platformer roguelike with full rollback netcode that handles 150ms+ ping (this was a real challenge!) - never completed.
I worked on something similar in high school(also never finished). Implementing good netcode on a novel multiplayer game can be very hard to get right. Made me a lot more forgiving of games that didn't do it well. You pretty much need to design your game with multiplayer in mind.
Great article, thank you for sharing this experience. The part I found most interesting is the section about the aspect ratio and interpolating between the 16:9 and 16:10 views relative to the original, although I'm having some trouble fully understanding the implementation. Why is the game interpolating between them based on the games aspect ratio?
I can't know ahead of time the exact aspect ratio the player will run the game at. 16:9 and 16:10 are the most common on today's monitors, but the game might be running in a window, or fullscreen on an unusual monitor.
If I just made the game at a fixed 16:9 ratio, it'd leave empty space at the edges of any window that isn't exactly 16:9. Same if I chose 16:10 or any fixed aspect ratio.
By supporting a range of ratios between 16:9 and 16:10, I maximize the number of window sizes that the game will display nicely in without any empty space (black bars) at the sides.
The best way, I thought, to support a range of aspect ratios was to define two rectangles in the scene, having the minimum and maximum ratios supported, and interpolate the camera rectangle between them.
Have the XM3 as well but I use Windows. This is an annoying issue with current Bluetooth headphones. Basically your choice is high quality audio but no microphone, or low quality audio with microphone. When you have the headphones connected it should offer 2 different sound outputs. One for stereo and one for hands free audio. If the stereo output is active then the microphone won't work at all.
It's not perfect, but the combination of "you can select the codec" and "the bluetooth stack is 100% out of the hands of the OS" gave me dramatically better results on almost every headset I tried.
