Announcement

Collapse
No announcement yet.

SDL2 Upstreams OS/2 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Raka555 View Post
    To get X-Windows working, you had to get the specs of your monitor and VGA card and manually calculate the resolutions you wanted using the dot clock of the RAMDAC and sync timings of the monitor with a formula they provided. Put that in your XFree86 config file and cross fingers. Any mistake could cause permanent damage to your monitor.

    Good old days ...
    It still seems weird to me that I can do an install, start the desktop mananger, log in to the desktop session, and it all just magically works without configuring anything X-wise. I studied very, very thoroughly all about video timings and how to configure XFree86 correctly. I was NOT going to destroy my monitors!

    Comment


    • #22
      Originally posted by Raka555 View Post
      To get X-Windows working, you had to get the specs of your monitor and VGA card and manually calculate the resolutions you wanted using the dot clock of the RAMDAC and sync timings of the monitor with a formula they provided. Put that in your XFree86 config file and cross fingers.
      Oh! Oh!!! Remember the Ctrl-Shift-KP+/KP- magic key combination to cycle through the resolutions configured in the XFree86 config file? ... Wow. I'm old
      Last edited by cmsigler; 16 October 2020, 11:22 PM. Reason: Edit:  I finally remembered the keys were KP+ and KP-

      Comment


      • #23
        Originally posted by cmsigler View Post

        I must have been thinking about 386BSD. Maybe The Lawsuit was still getting in the way of wider adoption during my '94-'95 timeframe. I've dabbled with the three main BSDs although not for almost 20 years now. I used Net, then Open, for my home firewall. I sort of prefer the disk slice method of "partitioning" myself.... That's not very "Linux-y"
        Till this day I hate the disk labels and slices. Never made much sense to me. You may only use certain slices and had to leave others blank. (Maybe that 386BSD hex editor gave me a knock for life).

        Good information on that topic could have helped at the time. (You could not google anything as web browsers and webservers did not exist).
        Last edited by Raka555; 15 October 2020, 11:46 AM.

        Comment


        • #24
          Originally posted by cmsigler View Post

          I must have been thinking about 386BSD. Maybe The Lawsuit was still getting in the way of wider adoption during my '94-'95 timeframe. I've dabbled with the three main BSDs although not for almost 20 years now. I used Net, then Open, for my home firewall. I sort of prefer the disk slice method of "partitioning" myself.... That's not very "Linux-y"
          It's still around in OpenBSD although annoyingly, you can't have one slice for one OpenBSD installation and another for another on the same disk (for example, to run 6.7 which is the current release version, and 6.8-beta, which will soon become the latest release version). FreeBSD appears to have adopted GPT partitions wholesale, although I think BIOS disks still use traditional BSD partitions, within a "slice".

          Comment


          • #25
            Originally posted by Raka555 View Post

            Till this day I hate the disk labels and slices. Never made much sense to me. You may only use certain slices and had to leave others blank. (Maybe that 386BSD hex editor gave me a knock for life).

            Good information on that topic could have helped at the time. (You could not google anything as web browsers and webservers did not exist).
            I don't know about 386BSD, but I'm pretty sure you used to be able to dual boot FreeBSD and Windows, OS/2 and/or Linux on a BIOS disk. Since a "slice" was basically a primary partition, though, you could only have four unless one of them was an extended partition - and you couldn't use that for FreeBSD, IIRC. It was basically an attempt to shoehorn the traditional UNIX layout (where you'd have 8 partitions named "a" to "h" on a single disk, and couldn't share that disk with another OS) into an environment where you might also have DOS, Windows, OS/2, etc on the same disk. 4.4BSD and earlier assumed that if you wanted to run HP-UX, Solaris, etc. as well as BSD, you'd have the other OS on a separate disk, which probably wasn't an unreasonable assumption when you were already dealing with hardware costing thousands more than an IBM-compatible. Moving UNIX to the PC however inevitably meant you were dealing with lower-cost hardware and smaller budgets. I remember when you could shove a Linux rescue disk, and maybe a few command-line utilities, onto two floppies.

            Comment


            • #26
              Originally posted by schmidtbag View Post
              Makes me wonder if they'll re-introduce support, now that there is SDL2 support.
              DOSBox (vanilla, project hosted in SVN) will likely never move to SDL2; maintainers are determined to support running DOSBox inside Windows 9x (and even Windows NT 3.51) until the end of time seemingly... even when DOSBox no longer works correctly on new OSes (it already has severe problems running on Windows 10, macOS Catalina, or any modern Linux).

              DOSBox Staging project was created to fix this problem and support modern OSes. We dropped legacy cruft and moved on to SDL2 already It's unlikely we'll support OS/2 again (at least I won't hold my breath waiting for any PR reverting our purge of OS/2 ifdefs).

              Originally posted by schmidtbag View Post
              Also makes me wonder if DOSBox is the reason this was added in the first place. There must have been some need for SDL2 to be supported, because otherwise I imagine this is just going to burden the maintenance of the platform.
              Probably not. Almost all open source projects moved on to SDL2 already (there are few open source games still porting, and some abandoned projects that won't port); without SDL2 only old versions of those projects would work on ArcaOS.

              About maintenance burden: SDL has somewhat wide-reaching CI system - if someone donated them license for using ArcaOS, then maybe there's at least a protection from build failures. SDL was pleading OS/2 users to finish and upstream the port (previously it lived as several half-dead projects) - it's somewhat unexpected that someone actually pushed it through the finish line (kudos to dev anyway!).

              Comment


              • #27
                Originally posted by dreamer_ View Post
                it already has severe problems running on Windows 10, macOS Catalina, or any modern Linux)..
                If an install of Linux doesn't have SDL1.2 in its packages, it isn't exactly modern. It is broken.

                And if it is in packages; it probably works fine. SDL is tiny so there isn't much to go wrong (on Linux it is a thin layer around X11). It isn't like SDL2 where there is a lot of underlying complexity with i.e OpenGL underneath the SDL_Renderer cruft.
                Last edited by kpedersen; 16 October 2020, 12:49 PM.

                Comment


                • #28
                  Originally posted by kpedersen View Post
                  If an install of Linux doesn't have SDL1.2 in its packages, it isn't exactly modern. It is broken.
                  Oh, almost all Linux distros still provide SDL 1.2, but veeery few active open source projects use it - in Fedora IIRC there are exactly 3: DOSBox 0.74-3, Armagetron, and OpenTTD. I know 2 other open source ports still using it: OpenHeroes (transitioning to SDL2), and OpenXcom (not sure).

                  Originally posted by kpedersen View Post
                  And if it is in packages; it probably works fine.
                  No, it doesn't any more (speaking from experience here). SDL 1.2 is provided for backwards-compatibility only, no new fixes/patches are landing since 2013.

                  Examples of broken features in SDL 1.2 libraries:

                  - Multi-screen support (broken on X11 - test any game using SDL 1.2 - going fullscreen will result in resetting all your screens to "mirror" mode)
                  - Input support (depends on the game - some games are more affected than others - keep pressing same button for a long time (happens regularly e.g. in racing games) - after some time, input will be broken and it won't register any more)
                  - MP3 support in SDL_sound is generally broken
                  - No support for newer game controllers
                  - Mouse input problems with getting exclusive fullscreen when using native resolution on composited window managers
                  - Complete lack of Wayland support
                  - Whole bag of issues when using SDL 1.2 via XWayland

                  Linux userspace ecosystem advanced quite a bit over the last 10 years, and unfortunately it involved a fair amount of bitrot and breakage of old features. That is life, unfortunately.

                  Comment

                  Working...
                  X