I make games

  • 0 Posts
  • 9 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle

  • So to answer your last question, yes. Video editing is probably one of the most demanding things you can do with a drive, and will shorten the lifespan of the device. But this is true for literally any kind of drive, and any operation you do with a drive. Hard drives may not have a write cycle limitation like ssds, but they have moving parts that wear with use. So theres not really anything you can do to avoid the issue. To video edit period, you’re going to put wear on your drive.

    Also to give some context, average SSDs have about 100,000 write cycles per cell, before write failure can have a chance of happening. Since it distributes it out across the cells, you could write 1GB to a 1TB SSD about 100 million times. This isn’t a small number really, it’ll take a while to do that. I’ve been editing here and there on my ssd for 5+ years on top of full time video game development and it still works fine, with no signs of stopping. I read some guy online who edited video nearly every day for three years, and the ssd software still said he had about 10% of the ssd life remaining before write failures. So depending in your work flow your drive could last 4 to 10+ years.

    The only real differences here are cost and speed. Do you want to wait around for a slow hdd while you’re editing, or do you want to edit quickly and enjoy the process? I personally would always edit on an SSD because you’re not solving the problem by using something else. Like yea, maybe a hard drive would last twice as long as an ssd, but it’s also twice as slow, so you’re just stretching those, say, 5 years of man-hours into 10. You’re not actually getting more work done on that drive.



  • Sorry, that’s almost it but they don’t emulate hundreds or thousands of frames, you’re right in thinking that would be implausible. Basically what happens is retroarch makes a savestate every frame and keeps a running list of the last few. When you press a button, retroarch will load one of those states from a few frames ago, press the same button then, then disable video and re-emulate those “rewound” few frames in fast forward. Then once it’s caught up to the present it re-enable video rendering. The end result is that you see the effect of your input happening the frame after you press it, instead of the normal input delay of 2 or more frames. It’s pretty neat. But yea, this means that they’re only emulating an extra 3-5 frames or so not hundreds, and they only have to do it when you press a button, not all the time.






  • You’ve almost got it. The thing is when you view content posted to another instance you’re not actually accessing the other instances, you’re viewing a copy of those posts stored on your instance. Federation works by distributing copies to all federated instances.

    So if a big company like Google did as you said, and then suddenly defederated from everyone, you wouldn’t actually lose any of the content. All those posts up until the point of defederation would still be stored on every instance they were previously federated with. You would just stop getting new posts from that point forward.

    There’s a bit of weirdness though, since the “true” post on the hosting instance is what handles syncing/distributing copies. So any new posts you made to those communities or comments on those posts couldn’t be copied back to the true post and then spread to the other instances. So everyone ends up with a desynced “ghost community”. So while you might see new posts/comments in those ghost communities from people on your instance, they don’t get synced to any other instance. (If you’re on an instance that beehaw.org recently defederated from, you can see that in action right now.)

    So at the very least, the content would still be backed up, but you’re right in that people would need to “start over” and create new communities with new mods and new posts if they wanted the content to be federated. We just wouldn’t lose the old content.