• HugeNerd@lemmy.ca
    link
    fedilink
    arrow-up
    15
    ·
    10 hours ago

    Have you seen the insane complexity of modern CPUs? Ain’t no one hand coding that like a 6502 in 1985.

      • Blackmist@feddit.uk
        link
        fedilink
        English
        arrow-up
        5
        ·
        9 hours ago

        If the hardware was fixed, I don’t see why not.

        Might not be as fast as the optimisations compilers do these days though.

        If you have to support thousands of types of GPU and CPU and everything else, then fuck no.

    • skuzz@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      9 hours ago

      Even if one did, say using x86, it would still just be interpreted by the CPU into the CPU’s native opcodes, as the legacy instruction sets are interpreted/translated.

      • FromPieces@lemmygrad.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        8 hours ago

        Wait, it looks like the only way to install OpenRC2 is to have already installed RC2?

        Installing on my Linux machine:

        OpenRC2 needs files from the original RollerCoaster Tycoon 2 or RollerCoaster Classic in order to work. Please select the directory where you installed RollerCoaster Tycoon 2 or RollerCoaster Classic. (I haven’t learned anything about how to live in the Linux environment, I barely use this machine)

        • lessthanluigi@lemmy.sdf.org
          link
          fedilink
          arrow-up
          3
          ·
          8 hours ago

          You just need the main game files. If you want to be legal, you can just buy RCT2 off of gog, and then just use wine to “install” the game, of which, you just copy the installed files into OpenRCT2. RCT1 is not needed, but adds more to the game.

            • lessthanluigi@lemmy.sdf.org
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              7 hours ago

              The internet archive probably has a copy. That’s the way I usually go with old PC games.

              I did find a site called gog-games.to , but I have never used the site, so be careful.

              EDIT: ripped.guide is a great website to find piratable stuff. Just make sure you use a VPN when doing this stuff (besides the Internet Archive, ofc)

  • humanspiral@lemmy.ca
    link
    fedilink
    arrow-up
    46
    ·
    edit-2
    22 hours ago

    is there a NPM package for assembly? I need to keep access to right pad my strings package.

  • Frezik@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    205
    arrow-down
    2
    ·
    1 day ago

    Rollercoaster Tycoon was the last of an era, not a sudden burst of genius.

    Before Doom (1993), almost all games were assembly. Doom was a shock to the industry. You could now write a high performance, multiplatform, sophisticated game in a compiled language ©. When I say multiplatform, I don’t just mean how it was ported to everything later. It was developed on NextStations first. DOS was the first port. So it proved all of the above immediately on release.

    We take for granted that C is performant now, but that wasn’t obvious until optimizing compilers got good and someone tried.

    Rollercoaster Tycoon (1999) is the last notable title that used ASM. It’s impressive in many ways, but it wasn’t as much of a standout as it seems now. Six years earlier to its release, that was just how games were done.

    It’s notable that the only port of Rollercoaster Tycoon was the original Xbox, which was also x86. Nobody wants to rewrite it for anything else.

    • NocturnalMorning@lemmy.world
      link
      fedilink
      arrow-up
      52
      arrow-down
      3
      ·
      1 day ago

      You couldn’t pay me to write a game in C today. Our expectations of what games have to be are sky high today. You cant get away with the productivity lost writing in c, maybe c++ since its supported by a number of engines. But, im personally not aware of a single engine that uses C. I tried my hand at writing a game without an engine, and it was a hot mess. Writing low level code to make a button with text, no thanks…been there done that, in my game, you could bump into trees and get stuck…not very fun in my opinion, and thats after a few months of writing code.

    • Blue_Morpho@lemmy.world
      link
      fedilink
      arrow-up
      34
      ·
      1 day ago

      Before Doom (1993), almost all games were assembly.

      Carmack wrote Wolfenstein 3d in C. Star Control and Dune 2 were C.

        • Blue_Morpho@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          6 hours ago

          I used those as examples but I claim that most everything was C by the early 90’s. The statement that C compilers got fast which allowed it isn’t true. When a new compiler came out it was always a couple of percentage points faster than the old version. Meanwhile hardware was doubling in performance every two years.

          C compilers didn’t need much optimization because there wasn’t much performance that could be optimized into code on the simple CPUs of 1992 when Doom was being written. CPU’s weren’t the superscalar multi core monsters they are today. A compiler couldn’t take advantage of reordering instructions to use multiple adders because there was only one.

      • Frezik@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        20 hours ago

        Those games didn’t have the splash that Doom did for this sort of thing.

        https://web.archive.org/web/20010105180900/http://www.gamespy.com/legacy/articles/devweek_c.shtm

        Mainstream application programmers switched to C in the early 80’s. Game developers were slower to switch, because their small teams and focus on performance kept assembly language viable till the following decade. When id Software released DOOM, they surprised much of the industry by having no reliance on assembly code–despite excellent game performance, and by successfully cross-developing the game (in NeXTstep and DOS), then successfully porting it to an astounding variety of platforms.

        • Ensign_Crab@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          13 hours ago

          Those games didn’t have the splash that Doom did for this sort of thing.

          I would say that Wolf3d would certainly count as proof of concept.

      • Aria@lemmygrad.ml
        link
        fedilink
        arrow-up
        2
        ·
        21 hours ago

        Wolfenstein 3D is a lot less impressive than Doom. Doom was faster and more complex than other games, where as Wolfenstein had a strong and appealing gimmick but was slower and less complex as a trade-off. In-line with the expectations around compiled languages.

    • jqubed@lemmy.world
      link
      fedilink
      arrow-up
      12
      ·
      23 hours ago

      Eventually it sort-of got a rewrite to create RollerCoaster Tycoon Classic, initially for iOS and Android, later for Windows, macOS, and Nintendo Switch. It largely is a rewrite of RollerCoaster Tycoon 2, with the goal of bringing the game to more modern platforms, and the save files for parks and rides are compatible. In this interview with Atari Club, Sawyer says the rewrite was in C++ but even with a team of people still took longer to write in C++ than it took him to write the original in x86 assembly.

      If anyone previously paid attention to RCT Classic, it’s been seeing some development work again and is working on Android again. They also made RCT Classic+ on Apple Arcade (basically just the game and all the expansions included) and also updated the regular versions of RCT Classic so they run correctly again (RCT Classic stopped working on macOS when Apple dropped support for 32-bit applications and Atari didn’t release a recompiled game until recently).

    • sp3ctr4l@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      23
      ·
      1 day ago

      Just to throw on more factoids:

      Wasn’t Gabe Newell either the first, or among the first, to port Doom to Win 95?

      • ChicoSuave@lemmy.world
        link
        fedilink
        arrow-up
        39
        ·
        1 day ago

        He was an analyst at Microsoft who was tasked with finding out how many computers ran Windows to determine market share. Part of the question involved asking what other software was installed and the only software used more than Windows was Doom. This made GabeN realize the market potential of games and he left Microsoft shortly afterward.

        • sp3ctr4l@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          19
          ·
          edit-2
          1 day ago

          See, I’ve heard that story, that he basically ran … well, arguably, a worm that did network analysis on what was installed on every computer in the MSFT internal network, realized more people had DOOM installed… than Windows…

          … and I have also heard that he actually ported DOOM to… either MS DOS, or Win95… ?

          I genuienly do not know which is true, if they’re all true, if they’re all false… I can’t remember the source for each of these, but I know I’ve heard or read all these semi-close variants from somewhere, over the years.

          • jqubed@lemmy.world
            link
            fedilink
            arrow-up
            13
            ·
            23 hours ago

            Just saw this article recently. Gabe was part of a team trying to convince developers that they would be better off writing their games with more abstracted code/libraries instead of writing their own interfaces (some of which were written by people convinced they were being really efficient but were actually terrible). One thing they did to prove their point was going to id and offering to have Microsoft port Doom to Windows for free. But the experience and seeing the success id was having distributing their own game led Gabe to launch Valve.

    • Angry_Autist (he/him)@lemmy.world
      link
      fedilink
      arrow-up
      7
      arrow-down
      10
      ·
      20 hours ago

      Before Doom (1993), almost all games were assembly

      No? Not even close? Why is it people get away with saying such stupid things on the internet?

      • Frezik@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        33
        ·
        20 hours ago

        Because it’s true. Here’s an article from Tim Sweeney from 2001:

        https://web.archive.org/web/20010105180900/http://www.gamespy.com/legacy/articles/devweek_c.shtm

        Mainstream application programmers switched to C in the early 80’s. Game developers were slower to switch, because their small teams and focus on performance kept assembly language viable till the following decade. When id Software released DOOM, they surprised much of the industry by having no reliance on assembly code–despite excellent game performance, and by successfully cross-developing the game (in NeXTstep and DOS), then successfully porting it to an astounding variety of platforms.

          • NeatNit@discuss.tchncs.de
            link
            fedilink
            arrow-up
            5
            arrow-down
            1
            ·
            14 hours ago

            Performance is very much still a significant factor. At the end of the day, games are expected to run at certain FPS on certain machines. The machines have gotten better to the extent that unoptimized code can be used sometimes, but when competing for graphics, badly optimized games will have to sacrifice fidelity to hit performance targets, where well-optimized games can get squeeze out better graphics and hit those same targets.

            There’s plenty of tricks these days but optimized code will always have an edge.

    • Jessica@discuss.tchncs.de
      link
      fedilink
      arrow-up
      10
      ·
      1 day ago

      I will never not upvote an Ahoy video. The guy is a legend in video game documentaries. Check out his Monkey Island video as a follow-up

      • ProfessorProteus@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 day ago

        Another really good one that I’ve watched at least 4 times is his Polybius video. He’s an incredible documentarian and an equally great researcher.

        I’m sure some of the Polybius one was dramatized a little (apart from what was clearly labeled as actors reading the transcripts), but it makes for an unforgettable watch. And the music!!

        • zebidiah@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          1 day ago

          I can’t get enough of the Boxes video! … And the one about trackers was really good too!

  • SubArcticTundra@lemmy.ml
    link
    fedilink
    arrow-up
    37
    ·
    edit-2
    24 hours ago

    And most startlingly: no git

    Edit: y’all’re right, version control is for wimps. What’s life without some adrenaline?

    • PhobosAnomaly@feddit.uk
      link
      fedilink
      arrow-up
      45
      ·
      edit-2
      1 day ago

      Who needs git when you have a B: drive and a Save As command for tycoon43.asm

      Version control? You mean this?

    • potoo22@programming.dev
      link
      fedilink
      arrow-up
      12
      ·
      edit-2
      1 day ago
      ./src
      ./src_1998_11_05_added_people_swimming
      ./src_1998_11_06_added_death_mechanics
      ./src_1998_11_06_0_removed_swimming_lol
      
    • qjkxbmwvz@startrek.website
      link
      fedilink
      arrow-up
      10
      ·
      1 day ago

      Did the developer use any version control though? SCCS has been around since the early 70s, RCS and CVS since the 80s. The tools definitely existed.

      Also, it was a single dev, which makes SCM significantly simpler!

      • bandwidthcrisis@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        21 hours ago

        In my experience (some games in z80 and 68000 in the early 90s), version control wasn’t considered until mid-90s sometime, and at first wasn’t trusted. There were network backups, but I don’t know if they had revisions.

        Merging seemed like it couldn’t possibly work well, so we would try to have separate ownership of different files. Although there would be only a handful of programmers on a team, so that was easy.

        Prior to that, backup and versioning was manually handing a floppy or two to someone each week.

  • yucandu@lemmy.world
    link
    fedilink
    arrow-up
    18
    ·
    1 day ago

    Epic Pinball was another game that I recall was written in assembly. When your old 286 struggled to run games at a decent framerate, Epic Pinball would run in a smooth 75fps or whatever you set your CRT monitor to.

    • ZILtoid1991@lemmy.world
      link
      fedilink
      arrow-up
      12
      ·
      1 day ago

      Epic Pinball, if I recall correctly, also used some ModeX trickery, meaning it had most of the pinball table in VRAM, and then modified the VGA framebuffer pointer for scrolling, then only moving as much data as it was needed (ball, flippers, etc)

  • henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    24
    ·
    1 day ago

    This looks like a screenshot in the background of the C++ OpenRCT version because the resolution is too high and not supported by the original assembly release.

    • Kazumara@discuss.tchncs.de
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      19 hours ago

      The original goes to 1024 x 786 and has different zoom levels. I’ve played most of the original parks this year and that does not see to be too high res to me. Give me a sec I’ll take a screenshot of mine in a minute.

      Edit here it is. It’s the GOG version, which launches fullscreen, so the 1024 x 768 are stretched onto the center of my 1920 x 1080 screen.

    • Mobile@leminal.space
      link
      fedilink
      arrow-up
      4
      ·
      12 hours ago

      A little late to this comment but there are some assembly videogames out! They are puzzles and gives you the gist of how assembly works.

      I really enjoyed TIS-100. I just never got around to beating it.

    • addie@feddit.uk
      link
      fedilink
      arrow-up
      3
      ·
      16 hours ago

      I learned z80 assembly back when the cutting edge of technology was a ZX Spectrum, and 68k assembly when I upgraded to an Amiga. That knowledge served me quite well for my early career in industrial automation - it was hard real-time coding on eZ80’s and 65c02 processors, but the knowledge transfers.

      Back in the day, when input got mapped straight into a memory location and the display output was another memory location, then assembly seems like magic. Read the byte they corresponds to the right-hand middle row of the keyboard, check if a certain bit is set in that byte, therefore a key is held down. Call your subroutine that copies a sequence of bytes into a known location. Boom, pressing a key updates the screen. Awesome.

      Modern assembly (x64 and the like) has masses of rules about pointer alignment for the stacks, which you do so often you might as well write a macro for it. Since the OS doesn’t let you write system memory any more (a good thing) then you need to make system calls and call library functions to do the same thing. You do that so often that you might as well write a macro for that as well. Boom, now your assembly looks almost exactly like C. Might as well learn that instead.

      In fact, that’s almost the purpose of C - a more readable, somewhat portable assembly language. Experienced C developers will know which sequence of opcodes they’d expect from any language construction. It’s quite a simple mapping in that regard.

      It’s handy to know a little assembly occasionally, but unless you’re writing eg. crypto implementations, which must take the exact same time and power to execute regardless of the input, then it’s impractical for almost any purpose nowadays.

      • DonutsRMeh@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        10 hours ago

        Very interesting. Thank you. I may start looking into C instead. I’ll still watch a couple of videos on assembly, just for the hell of it.

    • peoplebeproblems@midwest.social
      link
      fedilink
      English
      arrow-up
      8
      ·
      23 hours ago

      Really? It was required when I was in college. We did MIPS, x86, and PIC.

      I like it because there’s no mysterious things happening to your bits. Every line is an instruction executed. You control the machine. It’s power. It gives you power over the machines.

      • DonutsRMeh@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        23 hours ago

        I went to college for Microbiology and became a programmer on my own after, so nope, never written a single line in assembly and never thought of checking it out either. Just never really crossed my mind. I might start messing with it soon.

        • peoplebeproblems@midwest.social
          link
          fedilink
          English
          arrow-up
          4
          ·
          20 hours ago

          I… Don’t recommend it. Rust if anything.

          It’s a neat party trick? Helps you understand how a processor works? But for anything modern, it’s way more work than it’s worth.

        • Redkey@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          20 hours ago

          Go for it, if it’s to satisfy your own curiosity, but there’s virtually no practical use for it these days. I had a personal interest in it at uni, and a project involving coding in assembly for an imaginary processor was a small part of one optional CS course. Over the years I’ve dabbled with asm for 32-bit Intel PCs and various retro consoles; at the moment I’m writing something for the Atari 2600.

          In the past, assembly was useful for squeezing performance out of low-powered and embedded systems, but now that “embedded” includes SoCs with clock speeds in the hundreds of MHz and several megabytes of RAM, and optimizing compilers have improved greatly, the tiny potential performance gain (and you have to be very good at it before you’ll be able to match or do better than most optimizing compilers) is almost always outweighed by the overhead of hand-writing and maintaining assembly language.

        • Klear@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          17 hours ago

          If you’re curious, I recommend this channel. It often delves deep into the code to explain stuff, as well as how the hardware works. Really fascinating!

      • expr@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        21 hours ago

        That wasn’t required in my CS program, though instead we had to design our own instruction set and assembler. Obviously it was an approximation, though.