You wanted optimized code size and optimized performance?
I mean, sure, but think about how big 4KB is, the tricks that are being used to create the scenes are crazy hacks using default Windows sound files and literally anything the executable can reference on the cheap.
Procedural content generation is really expensive (in general), but that's the beauty of it. You find a way to abstract the content into an algorithm, and then you can reduce the size of the assets, but you pretty much always need to pay the price somewhere.
But hey, I understand the sentiment, I wish Slack didn't consume 2 GB of RAM on my machine.
"Being allowed to use 300MB of RAM doesn't strike me as very limiting."
BOOM! I knew it was going to be huge. That's a beefy GPU + 300MB in RAM + pregenerating. I'd have... made sacrifices to have that even in the Half-Life 1 days. :)
The wink face makes it seem like you think this is easy because using a GPU to execute the program is allowed. No?
Edit: just read your other comment about real challenges in the C64 subset of the demoscene. That's like "You set a record in a 1600m race? For a real challenge, set a record in a marathon." It's just arbitrarily moving the totally legitimate goalposts to a different challenge because you prefer it.
Response to edit: more like they couldn't pull it off so they asked people to buy a better graphics card. That's in their own race. Then I pointed out doing graphics operations, mostly rendering, almost entirely on a graphics card designed for that was barely an accomplishment vs stuff like in C64 demoscene. .kkrieger had me way more impressed due to all the elements involved vs size. So, I suggested subsetting or constraining the graphics card so its hundreds of millions of transistors don't just hand people their victories. Plus allow more creativity.
However it does irritate me that it's pregenerating the entire scene in memory. Being allowed to use 300MB of RAM doesn't strike me as very limiting.
You wanted optimized code size and optimized performance?
I mean, sure, but think about how big 4KB is, the tricks that are being used to create the scenes are crazy hacks using default Windows sound files and literally anything the executable can reference on the cheap.
Procedural content generation is really expensive (in general), but that's the beauty of it. You find a way to abstract the content into an algorithm, and then you can reduce the size of the assets, but you pretty much always need to pay the price somewhere.
But hey, I understand the sentiment, I wish Slack didn't consume 2 GB of RAM on my machine.
"Being allowed to use 300MB of RAM doesn't strike me as very limiting."
BOOM! I knew it was going to be huge. That's a beefy GPU + 300MB in RAM + pregenerating. I'd have... made sacrifices to have that even in the Half-Life 1 days. :)
I figured that. It's just that almost everythings done on the GPU for a rendering demo. That's really pushing people. ;)
The wink face makes it seem like you think this is easy because using a GPU to execute the program is allowed. No?
Edit: just read your other comment about real challenges in the C64 subset of the demoscene. That's like "You set a record in a 1600m race? For a real challenge, set a record in a marathon." It's just arbitrarily moving the totally legitimate goalposts to a different challenge because you prefer it.
How much harder would it be if software rendered or on a simple GPU from the late 90's? Their executable still 4KB? No?
6 replies →
Response to edit: more like they couldn't pull it off so they asked people to buy a better graphics card. That's in their own race. Then I pointed out doing graphics operations, mostly rendering, almost entirely on a graphics card designed for that was barely an accomplishment vs stuff like in C64 demoscene. .kkrieger had me way more impressed due to all the elements involved vs size. So, I suggested subsetting or constraining the graphics card so its hundreds of millions of transistors don't just hand people their victories. Plus allow more creativity.