Frickin' shaders with frickin' laser beams
1–10 of 27 posts
Re: Frickin' shaders with frickin' laser beams
#2The screenshots are from one of my favorite games called The Talos Principle. Curious, is the author of the site associated with it? That game is custom built, looks incredible even on cheaper hardware (e.g. it looked beautiful on my 2015 MBP when I first played it). Crazy stuff.
Re: Frickin' shaders with frickin' laser beams
#3While I hate tons of javascript as much as the next HN'er, do yourself a favor and scroll _up_, enjoy the view and press play. So awesome!
Re: Frickin' shaders with frickin' laser beams
#4The idea of writing shaders in something akin to Typescript sounds a bit like a dream.
Re: Frickin' shaders with frickin' laser beams
#5The screenshots are from one of my favorite games called The Talos Principle. Curious, is the author of the site associated with it? That game is custom built, looks incredible even on cheaper hardware (e.g. it looked beautiful on my 2015 MBP when I first played it). Crazy stuff.
Croteam did wonders with that engine, truly a beautiful looking game inside and out.
Shaders are one of those topics that you can easily get lost in. It was one of my more recent "you don't know what you don't know" topics. The idea that your code will run one time for each pixel on your screen, 60-144x a second (!), is mind-boggling. It's still hard for me to wrap my head around it sometimes and when I finally write something that compiles it feels like magic every time.
Re: Frickin' shaders with frickin' laser beams
#6The screenshots are from one of my favorite games called The Talos Principle. Curious, is the author of the site associated with it? That game is custom built, looks incredible even on cheaper hardware (e.g. it looked beautiful on my 2015 MBP when I first played it). Crazy stuff.
Croteam did wonders with that engine, truly a beautiful looking game inside and out. Shaders are one of those topics that you can easily get lost in. It was one of my more recent "you don't know what you don't know" topics. The idea that your code will run one time for each pixel on your screen, 60-144x a second (!), is mind-boggling. It's still hard for me to wrap my head around it sometimes and when I finally write…
It gets even weirder when you realize it's not just running your code for each pixel it's running the exact same instructions in parallel for large square blocks of pixels, which makes branching incredibly expensive.
Re: Frickin' shaders with frickin' laser beams
#7> The key thing is that I don't intend to make thousands of draw calls this way either. I just want to make a couple dozen of exactly the draw calls I need, preferably today, not next week. It's a radically different use case from what game engines need, which is what the current industry APIs are really mostly tailored for.
Whenever I try to learn WebGL (or similar technology) I give up after a while. In my head I imagine it as if the entire automotive industry was only aimed at F1 race cars, and people who want to do practical day-to-day things with cars only had F1 tech to work with, including the cost and complexity.
Re: Frickin' shaders with frickin' laser beams
#8The screenshots are from one of my favorite games called The Talos Principle. Curious, is the author of the site associated with it? That game is custom built, looks incredible even on cheaper hardware (e.g. it looked beautiful on my 2015 MBP when I first played it). Crazy stuff.
The Talos Principle is really one of the best puzzle games I've played. It scratched the same itch for me that Portal did.
Re: Frickin' shaders with frickin' laser beams
#9The idea of writing shaders in something akin to Typescript sounds a bit like a dream.
What about in (Common) Lisp? https://github.com/cbaggers/cepl
Re: Frickin' shaders with frickin' laser beams
#10"In my case, I want to construct and call any shader I want at run-time. Arbitrary composition is the entire point. This implies that when I want to go make a GPU call, I need to generate and link a new program, based on the specific types and access patterns of values being passed in."
For toy apps, sure. For professional apps or games, abso-frickin-lutely not. Shader compilation jank is still an annoying issue in even recent games, and even having the ability_ to define arbitrary shaders at any point is such a huge footgun that I'd never let it past code review.