• 3 Posts
  • 582 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle
  • The original did have a lot of varied and interesting quest ideas, and some of the graphics still hold up now - dawn breaking over the mountains and reflecting off a lake looks even better in higher resolutions. The problem is more that there’s about a billion identikit dungeons which only contain level-appropriate loot, so you never find anything really exciting, and of course the leveling system is completely busted so every fight is a slog everywhere you go. Felt so limited compared to Morrowind, too - MW might have been a completely broken sandbox, but at least it was open enough to break.

    I don’t really feel that the main problem with Oblivion is how it looks.


  • Google did claim “half their new code” was AI-generated; obviously, take that with a pinch of salt, since they’ve a vested interest in promoting LLM.

    Speaking as a professional dev, about half of my lines-of-code consists of whitespace, opening-and-closing marks for the javadocs, and such matters as function, method and class definitions and their matching curly-close-brackets. My IDE generates all of that for me, but I dare say that I could use an LLM to do it as well, and then “half my code” would be AI-generated as well.

    My colleagues who are most enthusiastic about AI do turn in some right shit for code review; I suppose the best of it is over-complex and has confused error handling. They also tend to have about a hundred lines of what they’ve changed in the pull request description, and little or nothing about why. Github shows me what you’ve changed, I’m only interested in why you’ve done it, so that’s actually providing negative value by wasting my time having to read it.







  • Money is an emotional thing. Do I believe that this coin / bit of paper / number on a website is something that I can exchange for goods and services? If not enough people believe that, that currency will collapse.

    Mind you, not using money is inefficient at scale. Sending the bag of potatoes that I’ve grown in my garden this month to my internet provider for continued shitposting privileges only goes so far.



  • addie@feddit.ukto196@lemmy.blahaj.zoneRule
    link
    fedilink
    English
    arrow-up
    12
    ·
    10 days ago

    As well as running as root, you can also disable kernel-level protections against Spectre and shit like that on Arch, which as far as I can tell doesn’t even gain you a single FPS. But no real gamer would turn that optimisation down.


  • addie@feddit.ukto196@lemmy.blahaj.zoneRule
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    10 days ago

    Indeed. Back in the day (by which I mean, up until about when Doom was released, around '93) then one of the “joys” of PC gaming was that you had fuck all memory and had to prepare a “boot disk” for every game, bypassing the operating system, basically to load as little as possible so that there was space for your game to run. Trying to fit the bare essential drivers - sound card, memory extender, CD ROM if you needed it for that game, mouse or joystick if you needed those - was a right fucking adventure every time, and it was always a toss-up whether you could get sound, music, or both, in any particular game.

    If you’re an old fart, or if you’ve ever used DosBox to play retro games, you might be familiar. DosBox makes it altogether too easy - loads of RAM and disk space, emulates anything, and it’s very quick to swap things out.

    A few things changed around that time:

    • much more memory, and better processors (486s!) that could use it
    • games starting to want hardware acceleration for 3D, and therefore need graphics card drivers, which were impractical to fit on a floppy disk, usually
    • Windows 95 / DirectX meant that people wanted to play games by double-clicking them, and there being a “unified” way of accessing hardware, rather than directly writing to VGA- / SoundBlaster- compatible hardware.

    I’m no Windows fan, but it was a hell of an improvement.

    The concept of a “pure UEFI” gaming environment might sound great - direct access to hardware, what could be more efficient? - but the unfortunate reality is that direct access to hardware is a real pain in the arse. Every game would need a complete copy of everyone’s graphics drivers, everyone’s sound drivers, everyone’s network stack, .,. . Computers are much more complicated than they used to be (although in some ways, simpler too) - very few games would work at all. You might get Terraria in 640x480 in 16 colours and no hardware-accelerated drawing, and maybe some sound effects if you’d a very common integrated sound chip on your motherboard.

    The operating system is both a gateway and a gatekeeper to hardware; makes a lot of stuff appear to work the same, regardless of what it is really, and the ones that haven’t been enshittified are really quite efficient, do their thing and get out of the way. Even the consoles have an OS for hardware access now, although they’re lightweight. I think it would be a very backward step to be rid of them.







  • addie@feddit.uktoScience Memes@mander.xyzSpace Quarry
    link
    fedilink
    English
    arrow-up
    44
    ·
    16 days ago

    Hey! The images of Ryugu that were taken from Hayabusa2. What a sad lonely rock that place is - a loose collection of boulders in an endless orbit, in which it will probably continue without further interaction from now until the end of time. You could sneak a few ghosts onto that place, right enough, and no-one would notice.



  • addie@feddit.uktogames@hexbear.netFucking nerd.
    link
    fedilink
    English
    arrow-up
    2
    ·
    17 days ago

    That disables a whole pile of the potential optimisations, of course. You could define jackApples as a “static variable” (as opposed to making it eg. a field in a class or struct):

    namespace {
      auto jackApples = 3;
    }
    
    auto setJackApples(int newJackApples) -> void {
      jackApples = newJackApples;
    }
    

    The most obvious consequence of this is that jackApples now has an address in memory, which you could find out with &jackApples. Executable programs are arranged into a sequence of blocks when they’re compiled, which have some historical names based on what they used to be for:

    • the header section, which identifies what kind of program it is, and where the other blocks start
    • the text section, which contains all of the executable code, and which might be made read-only by the OS.
    • the data section, which contains variables that have a known value at startup
    • the bss section, which contains variables that we know will exist but don’t have a value. Might be zero’d out by the OS, might contain unknown leftover values.
    • after those sections, the heap starts. This is where we allocate anything that we don’t know the size of at startup. Your program will ask the operating system to “move the end of the heap” if it needs some space to eg. load a picture from disk that your program will then use.
    • at the very end of memory, and counting down, the OS will allocate “the stack”. This is where all of your variables that are local to each function are kept - it’s the “working area”

    Because it’s statically allocated, jackApples will be in the data section; if you opened up the executable with a hex editor, you’d see a 3 there.

    getTheNumberOfApples() will be optimised by the compiler to return the contents of the memory address plus 4. That still counts as a very simple and short function, and it’s quite likely that the compiler would inline it and remove the initial function. The actual process of calling a function is to:

    • push the address of where we are in the program onto the stack
    • push any variables used by the function onto the stack (which would be none, in this case)
    • if on x86 / x64, do a whole pile of stack alignment operations :-(
    • set the address of “where we are in the program” to the address of the function
    • push some extra space on the stack for all the variables used by the function
    • run all the code in the function
    • put the result of the function into one of the CPU registers
    • pop all of our “working space” back off the stack again
    • pop the address of “where we came from” off of the stack, and make that the place that we’ll continue running the program for

    That takes a while, and worse - modern CPUs will try to “pipeline” all the instructions that they know are coming so that it all runs faster. Jumping to a function might break that pipeline, causing a “stall”, which slows things down enormously. Much better to inline short functions - the fact that the value is “number in memory address plus four” might be optimised away a little wherever it’s used, too.