51–60 of 76 posts
Earlier quoted context omitted.
Maybe never had to physically blow air on a video game to make it work either, ha.
I bought a nintendo switch with zelda, and the cartridge wasn't detected the first time I put it in. Took it out, blew a bit on it, back in, working perfectly! Some things never change.
Earlier quoted context omitted.
> Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available I think you're underestimating the accretion of software bloat. You remember the days when you did exactly the same things , exactly as fast, with 1GB machines? 512MB machines? As long as devs don't give a fuck (er,…
It feels like that dev time cost is instead being crowdfunded by energy, disk, CPU and RAM that every user has to pay with and eventually that cost is paid by Earth itself. An app might be cheap or free but in the long time cheaper for the planet and each user would be an app costing a dollar or two more per install. I was using a 2011 laptop with only an HDD, 2 gigs of RAM and no discrete GPU until it actually went…
And quite more often, it's a choice between doing a game using a modern engine or not doing the project at all.
Earlier quoted context omitted.
> Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available I think you're underestimating the accretion of software bloat. You remember the days when you did exactly the same things , exactly as fast, with 1GB machines? 512MB machines? As long as devs don't give a fuck (er,…
It feels like that dev time cost is instead being crowdfunded by energy, disk, CPU and RAM that every user has to pay with and eventually that cost is paid by Earth itself. An app might be cheap or free but in the long time cheaper for the planet and each user would be an app costing a dollar or two more per install. I was using a 2011 laptop with only an HDD, 2 gigs of RAM and no discrete GPU until it actually went…
If you're company owner, which path will go? 1. Adding features less frequently, costly development, more people needed, but highly efficient code. 2. Frequent feature updates, cheaper development, less people needed, but shitty code base.
Even if you're brave enough to go for 2, there always will be competitor with 1. attitude, that will crush you into oblivion.
In case of game development, there is Duke Nukem Forever example. They tried to perfect it, changed game engine twice, but release took them so long, game looked dated anyway.
"When finishing a level, the game would reboot the console and restart itself with a command-line argument(the name of the level to start) ... into the next level. Voila, the perfect(?) way to clear all memory between levels." Well, that's basically how most websites work, lol
Earlier quoted context omitted.
Yeah, I've seen something similar done to the art budgets, but hiding memory from programmers is impossible if they had any clue, especially on PS2/Xbox (32M/64M RAM). You could read .map in 5 minutes and see anything suspicious. Same with delay loops - good luck with that. Though I've observed some "miraculous" recoveries due to utter idiocy. E.g. a PS2 game using double floats (because your time calculations will b…
The point was not to hide memory from programmers who "had a clue" if they went looking. During production, most programmers on the team would be focused on delivering features they were responsible for and fixing bugs. If they were doing perf or memory profiling it would mostly be focused on whatever feature they were implementing. Only a few people on the team, perhaps only the lead, would be looking at global memo…
And if your performance is poor the first thing you do is add some debug code to measure what is taking too long and where the biggest gains can be made.
The whole point of these tools is to make this stuff easy to find.
Makes me wonder why Rust isn't popular with game devs. Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
One reason is SIMD. Videogames contain quite a lot of math that benefit from SIMD a lot, be it MMX, SSE, AltiVec/VMX or NEON. Another one is that borrow checker. Games are heavily multithreaded since X360. Game state + game assets = huge pile of data shared across threads. Borrow checker in Rust makes it harder to write parallel code that operates on that large shared state. For small state and/or plenty of RAM you c…
"When finishing a level, the game would reboot the console and restart itself with a command-line argument(the name of the level to start) ... into the next level. Voila, the perfect(?) way to clear all memory between levels." Well, that's basically how most websites work, lol
As long as the process is acceptably fast, nuking & restarting (with an appropriate amount of isolation) is a fine approach to many things that would be harder or less efficient if done the “right” way. Memory pools and “let it fail” architecture in Erlang come to mind; and there’s a practice sometimes seen in Forth, where you ensure that the codebase itself is always small enough that it can always be easily rewritt…
New screen? Okay, lets throw everything away.
As long as performance is okay, I don't keep stuff around in memory.
"When finishing a level, the game would reboot the console and restart itself with a command-line argument(the name of the level to start) ... into the next level. Voila, the perfect(?) way to clear all memory between levels." Well, that's basically how most websites work, lol
I mean it can work and it's a viable tactic if startup time is fast enough.
When finishing a level, the game would reboot the console and restart itself with a command-line argument (the name of the level to start) ... into the next level. Voila, the perfect(?) way to clear all memory between levels. OH MY At 22 years old, this is one of those moments where I'm in awe of the strange issues and workarounds that existed merely ~5-10 years ago which I'll probably never have to deal with. Very f…
You'll run into today's equivalent soon enough :)
Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available, but the increasingly popular IOT devices and smart consumer hardware (like streaming media boxes, etc.) try to limit the BOM cost and thus limit memory as much as possible. Tiny memory leaks become an issue, or random…
To add on to this, I am currently working on a project where the only source of persistent storage is [0], which offers 64B of general purpose SRAM. It is a $0.70 low power clock with built in support for battery backup. Our main processor has more memory, but that goes away when we loose main power. Still, 64B should be enough for everyone. [0] http://www.mouser.com/ds/2/268/20005010F-737592.pdf
I wrote a thing way back when, probably a TI chip or something, which had like 300ish? bytes of memory. It got commands from a serial in (which was a bluetooth device, commands were sent from a java application on a laptop), the commands were a simple self-made thing which was a command (two numbers) and an argument (like, "set speed to 10"). That then controlled a PWM for the engine and things like that. RC boat with a few hundred bytes of memory.
I'm reinventing all that now with using raspberry pi's and arduinos and such. I just got an EPC32, which is a $5 device that should have wifi and bluetooth and such built in already.