gcn-x86.bsky.social
I like to pretend I know what I'm doing.
I'm into gamedev, gfx/physics/emulator/os programming & electronics. Not particularly good at any of those but hey, I'm trying.
Also at @[email protected]
26 posts
48 followers
136 following
Getting Started
Active Commenter
comment in response to
post
There's also the nuclear option for removing crap that can't be uninstalled, which is to boot into linux from a live usb drive, mount Window's file system and then go wild in it.
comment in response to
post
Have you tried, like, just not having problems?
comment in response to
post
Vulgar display of (a negative) power
comment in response to
post
"Should we show full folder paths? Naaaah, users are just too dumb to even know what's that."
comment in response to
post
Looks a bit like an Earthbound fight background
comment in response to
post
comment in response to
post
Tbf, gfx programming requires you to lose your mind, so it's not entirely wrong.
comment in response to
post
I bet you can glitch through that gap if you jump-slash just right.
comment in response to
post
Damn, that's pretty dope. Can you fly around the map while it builds the pvs?
comment in response to
post
So, the S stands for Sum? I always thought it stood for Suffering.
comment in response to
post
That's interesting. Are those toggleable portals used in things like doors, so when it closes the portal gets toggled off? Also, are those portals hand placed or are they generated from the bsp?
comment in response to
post
Does HL2 still uses the quake-style pvs for the bulk of occlusion culling?
comment in response to
post
Considering how much stuff people seem to manage to fix using noodles, I don't think there's much they are not.
comment in response to
post
C is mostly on embedded/driver stuff, as far as I know. Gamedev, assuming you'll do engine work, is mostly C++ (and if the place is sane, it'll be closer to C with classes).
comment in response to
post
And you gotta do it fast, because the game will wait just a couple of seconds before switching again.
comment in response to
post
That gave me a great idea. Instead of having it be a dropdown, it'll be a button that makes the game automatically cycle through all resolutions, and you have to click it again to pick the right one before the game changes to the next. The perfect UX.
comment in response to
post
The same thing also happens with all the rest of the draw state. It gets set over and over and over.
comment in response to
post
Also, dbvt go brrrr
comment in response to
post
I think the only annoying part then is to convert from this tiled format to a linear one for presentation, but the access pattern for this is pretty regular, so the prefetcher should pick up on it.
comment in response to
post
Then, if you bin triangles per tile, you can process tiles independently, and read/writes to the framebuffer should always hit L1, which would make things like depth-testing and blending a ton faster.
comment in response to
post
Ah, I see. The tile thing is mostly so accesses to the framebuffer always hit L1. Like, imagine you have a rgba8 framebuffer, so 4 bytes per pixel. If you split the framebuffer into 4x4 tiles, where tile rows are contiguous in memory, then each tile would fit entirely in a cache line.
comment in response to
post
I was wondering, have you considered the idea of rasterizing in tiles instead of rows? I know gpus do something similar, and I've been curious for a while whether the same approach would work well on the cpu.
comment in response to
post
Ah, gotcha. And you do that over all pixels inside the triangle bounding box, one pixel row at a time?
comment in response to
post
Scanline rasterized?