• 0 Posts
  • 137 Comments
Joined 4 months ago
cake
Cake day: November 20th, 2024

help-circle
rss
  • Vector/polygonal, truly implemented for the technical benefits* and likely untextured**. Which will make it more niche than the early 3D stuff that did use vertex colors ( EDIT: such as Spyro (specifically skyboxes, LoD) and Crash Bandicoot (Crash’s animations are cool too)).

    3D polygonal+vertex color actually isn’t that difficult to do. I’ve done some, the real issue (aside from making it good) is actually the animation/game around it. I haven’t done much and continue not doing much because personal stuff.

    2 examples (of my own stuff) I've used many times before

    * less data while also rendering at native res without needing extra work (8K or even on a 50ft Billboard? Sure). MIDI (you can use higher-quality soundfonts) or other procedural stuff (sounds/sfxr, textures) are nice too.

    ** I’m not against not-too-many general-use textures, but I tried this (including a watercolor splatter texture I made) without mapping and wasn’t really happy with the results… plus normal maps won’t work with per-vertex¯ materials. So this probably takes a lot of effort/skill to work as-intended.

    ¯ not strictly necessary, but I don’t mind the idea aesthetically and a free optimization sounds nice even though low poly+vertex-color is already a low bar (unless per-vertex could help with webGL, mobile, VR, or really old devices etc?)








  • Similar but slightly different reply to Kelly’s, not really responding to your comment on testing viability (though I don’t feel like this comment should be a top-level comment).

    It seems to me that at least for opt=size, it actually did improve performance (for a basic benchmark at least) somewhat for low cost compared to no flags. I’m sure this is not as fast as opt=speed, but I would call that more of a trade-off than a sacrifice especially when also considering compilation-time to get a measure of efficiency.

    At least that was my impression with Clang (which I was seeing size-optimized Clang giving decent performance but half the compilation time of default GCC). An efficient middle-ground.

    EDIT: Though this was also for code (via bindings) not Godot/exports themselves, so it could be different (though I’m not sure why unless a difference of defaults).


  • because every bloated 100gb game is a mix of a thousand different assets/executables/libraries

    Also needlessly uncompressed audio or poorly compressed video (that likely could instead be in-engine) particularly when multiple resolutions are needed. Sometimes one of these might be the bigger issue, particularly with remasters.

    @Gladaed I have less-than-stellar internet* (~6mb/s, shared with others), 20GB is definitely not a reasonable size for me. 100MiB is fine, but not negligible. Consider also storage space, particularly because users will run games from slower(->cheaper) drives when they deem games too big (which for me is already at 1GiB+, at least in terms of having a library because that adds up).

    * and I live in the US, not even in the woods! The price isn’t even great, either.



    As I see it, data size is an inverse multiplier for viability. The smaller a download is the more likely that users will be able to get and store it (long-term even) without issue. The difference between a day and an hour is huge, the difference between an hour and 5 minutes is still worthwhile (especially if this impacts household internet speed). Less than that (nearing instant download) is peak.

    Updates also make this difference larger.

    EDIT: A better way to say this is that this probably makes a lot of sense for small developers to do in stable releases at-very-least. Even then I could see picking-and-choosing for all sorts of different reasons. If this is part of an export script I could see it being practically free minus a slightly longer build time that is probably still in an acceptable range.





  • Sure, but that doesn’t help me now.

    It doesn’t install a better auto-level sensor or tool-changing on my printer. It doesn’t give me a good print bed (one I bought was damaged by prints) or even just a newer control board. I’m not even going to buy a slicer key, I don’t want to spend more money on this nor do I want to think about it.

    I’ve already acknowledged that some of this was my hubris and I would likely still be printing had I just stuck with what I had. Maybe someone could even help me get back there in exchange for/using my spare parts, but I live in nowheresville w/no car and don’t know anybody so that is not happening.




  • well yeah most people don’t have the hardware to play the pre-HD versions at their best

    Maybe you mean an actual PS2, but IME using emu w/higher internal res on a non-stellar computer was a pretty good experience.

    Meanwhile the HD version is data bloated (likely because everything is uncompressed for no reason, or multiple resolutions of FMVs including 4K) so the download would be painful for me. And really with Okami’s aesthetic especially, I don’t think HD is necessary (again, beyond just higher internal res and whatever other enhancements based on preference).

    I think it would’ve been better to change the FMVs into in-engine if viable, I assume the ones that were pre-rendered was just a hardware limitation if not just some production thing.