(⬤ᴥ⬤)@lemmy.blahaj.zone to 196@lemmy.blahaj.zone · 2 months agoefficient game design rulelemmy.blahaj.zoneimagemessage-square47fedilinkarrow-up1760arrow-down117cross-posted to: microblogmemes@lemmy.world
arrow-up1743arrow-down1imageefficient game design rulelemmy.blahaj.zone(⬤ᴥ⬤)@lemmy.blahaj.zone to 196@lemmy.blahaj.zone · 2 months agomessage-square47fedilinkcross-posted to: microblogmemes@lemmy.world
minus-square9point6@lemmy.worldlinkfedilinkarrow-up75arrow-down2·edit-22 months agoSo 300×1024×1024= 314,572,800kb Assuming something like 200 bytes per log line x5 = 1,572,864,000 logs Assuming this is your standard console port with a 60fps frame rate lock: ÷60fps ÷ 60 seconds ÷ 60 minutes ÷ 24h = 303.407… days You would need to play for nearly a year solid to generate that many logs at a rate of one per frame. Given that’s probably not what’s happened, this is a particularly impressive rate of erroring
minus-squaremogoh@lemmy.mllinkfedilinkarrow-up51·2 months agoYeah, that does not add up, you are right. There must be several error or it must include the stacktrace or something.
minus-squarertxn@lemmy.worldlinkfedilinkEnglisharrow-up31·2 months agoIt’s possible that the log writer wanted to fseek to the end of the file and write something, but the target pointer value was somehow corrupted. Depending on the OS, the file might end up having a fuckton of zeroes in the skipped part.
minus-squareTheEntity@lemmy.worldlinkfedilinkarrow-up11arrow-down1·2 months agoThat should result in a sparse file on any sane filesystem, right?
minus-squarertxn@lemmy.worldlinkfedilinkEnglisharrow-up9·2 months agoTheoretically, yes. Theoretically NTFS supports sparse files, but I don’t know if the feature is enabled by default.
minus-squareThe_Decryptor@aussie.zonelinkfedilinkEnglisharrow-up2·2 months agoIt supports it, but it’s opt-in by apps. Enabling compression is another option (Though with a speed and size penalty), it’s user visible at least.
minus-squarefallingcats@discuss.tchncs.delinkfedilinkarrow-up8·2 months agoIf you’re getting a stack trace every frame youd be there much sooner. Maybe like a week.`
So
300×1024×1024= 314,572,800kb
Assuming something like 200 bytes per log line
x5 = 1,572,864,000 logs
Assuming this is your standard console port with a 60fps frame rate lock:
÷60fps ÷ 60 seconds ÷ 60 minutes ÷ 24h = 303.407… days
You would need to play for nearly a year solid to generate that many logs at a rate of one per frame.
Given that’s probably not what’s happened, this is a particularly impressive rate of erroring
Yeah, that does not add up, you are right. There must be several error or it must include the stacktrace or something.
It’s possible that the log writer wanted to
fseek
to the end of the file and write something, but the target pointer value was somehow corrupted. Depending on the OS, the file might end up having a fuckton of zeroes in the skipped part.That should result in a sparse file on any sane filesystem, right?
Theoretically, yes. Theoretically NTFS supports sparse files, but I don’t know if the feature is enabled by default.
It supports it, but it’s opt-in by apps.
Enabling compression is another option (Though with a speed and size penalty), it’s user visible at least.
If you’re getting a stack trace every frame youd be there much sooner. Maybe like a week.`