Announcement

Collapse
No announcement yet.

At This Rate, Don't Be Surprised If You See Steam Soon

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

  • #46
    Originally posted by devius View Post
    Oh... ok then.

    I'm off to play some games on my NES software compatibility layer.
    That would be an actual emulator, as it emulates the actual hardware to allow the NES game code to run. There is a huge difference.

    Comment


    • #47
      Originally posted by Dragonlord View Post
      By the way... who needs a sucking steam client when there is Desura. Requires just the Linux client but they have it planed for once the client itself is stable.
      I'll believe when I see it. However, having said this, if ModDB's done what they're claiming, it'll be nice if they get around to a Linux client.

      Comment


      • #48
        Originally posted by Dragonlord View Post
        Not an emulator in the way a console emulator works. It though still hooks itself between the application and the OS providing wrappers for non-supported OS parts. It "emulates" windows as far as is required (including registry and libraries) to make the application work. I don't care what wine devs write on their software, an emulator stays an emulator no matter if it is a wrapper or all the way up to a full virtual machine.
        Heh... Beat me to it, you did.

        Folks, he's telling you the straight skinny there.

        WINE, the library, is true to it's eponymous acronym.

        WINE, the environment is NOT true to it's name. It is a framework to fake a Windows application out, thinking it's running against Windows. By definition, a virtual environment, and therefore emulation at several differing levels. Virtual machines like with VMWare or VirtualBox are high-performing emulations- but still emulations all the same. You're not native there, though you're close. The same goes for WINE. You're close in many ways, but you're still not native (Some things run faster under it, and others, nowhere near as fast, if at all...)- and you're at the whims of the vendor of your title as they don't officially support WINE (Except for a few notable exceptions like Eve Online...they just don't...not even Blizzard.) and they can apply a fix to some perceived problem and break your usage of the title under WINE- and then not shed a single tear for you. (Witness what happened with WoW and some of their "bot" prevention measures- if it wasn't for the massive uproar that ensued, they'd have written you off, guys...).

        In the end, you're sending a message. You're not interested in Linux gaming- and you're emulating things while doing it.

        Comment


        • #49
          Originally posted by Dragonlord View Post
          Doubt this as Desura is up for the cake too. And in is more open than Steam and thus caters better for the Indie titles which are on Linux more important at the time being (not in the future hopefully). Especially since Indie titles have a higher chance of getting a Linux client. Steam by itself is useless since the games you get on Steam nowadays are mostly all without a Linux client.
          Heh... I'd rather work with Greenhouse or someone like them than Valve, I know that much. I'm keen on seeing the AAA crowd begin to wise up here, but this stuff's not anywhere near as big a deal as what Wolfire's pulling as a PR stunt with the Humble Indie Bundle deal.

          Comment


          • #50
            Originally posted by aliendude5300 View Post
            That would be an actual emulator, as it emulates the actual hardware to allow the NES game code to run. There is a huge difference.
            Only in class. Even a Virtualization Environment (the first word should be a BIG hint...) has emulation pieces of hardware edges and WINE does similar things with it's stuff.

            Again...WINE the library, you're right on the money; WINE the application loader, you're not being honest by calling it an abstraction layer.

            Comment


            • #51
              Originally posted by Svartalf View Post
              I'll believe when I see it. However, having said this, if ModDB's done what they're claiming, it'll be nice if they get around to a Linux client.
              You mean now Desura itself or the client? I've been on the early public test phase when it had been still rough around the edges and it improved since then. Of course it's still beta and has some issues left so it's not officially released yet but you can download the client and login with your ModDB account. It has stuff like auto-detection to locate games which is a nice idea. Especially it doesn't lock your games into DRM-caged disk files which I appreciate a lot. Talked with Scott also about the Linux client. He's clear he wants it to have one but they don't want to do it before the app itself is officially released. In my opinion it's definitely a step in the right direction away from DRM riddled systems under the strict control of one deity.

              Comment


              • #52
                Originally posted by aliendude5300 View Post
                That would be an actual emulator, as it emulates the actual hardware to allow the NES game code to run. There is a huge difference.
                Actualy the difference isn't so big. A hardware emulator such as a NES or SNES or whatever emulator doesn't emulate the harware at all. That would be very difficult to do (impossible?). It only returns to the software the results (don't know how to call it) that the software would get if it was running on the real hardware. This isn't so different from what wine does, as it also returns what the software was expecting to get if it was running on windows. I could be completely wrong here, because I don't know that much about emulators though.

                Comment


                • #53
                  Originally posted by Dragonlord View Post
                  Especially it doesn't lock your games into DRM-caged disk files which I appreciate a lot.
                  Not sure what you mean here, I have Rainbow Six Vegas 2 purchased through Steam, it is by no means caged. The exe is tied into steam but it can be replaced with the official exe from the latest patch and will run with out steam. Same goes for every other third party game on steam, hell Valve is very proud of there anti piracy/cheating measures, and they should be, its not invasive and they allow for offline mode. they even place warnings about other manufacturers DRM.

                  Online Requirement

                  A PERMANENT HIGH SPEED INTERNET CONNECTION AND CREATION OF A UBISOFT ACCOUNT ARE REQUIRED TO PLAY THIS VIDEO GAME AT ALL TIMES AND TO UNLOCK EXCLUSIVE CONTENT. SUCH CONTENT MAY ONLY BE UNLOCKED ONE SINGLE TIME WITH A UNIQUE KEY. YOU MUST BE AT LEAST 13 TO CREATE A UBISOFT ACCOUNT WITHOUT PARENTAL CONSENT. UBISOFT MAY CANCEL ACCESS TO ONLINE FEATURES UPON A 30-DAY PRIOR NOTICE PUBLISHED AT http://www.splintercell.com/conviction/
                  Valves okay in my book.

                  Comment


                  • #54
                    Originally posted by GNU/Blind View Post
                    Not sure what you mean here, I have Rainbow Six Vegas 2 purchased through Steam, it is by no means caged. The exe is tied into steam but it can be replaced with the official exe from the latest patch and will run with out steam. Same goes for every other third party game on steam, hell Valve is very proud of there anti piracy/cheating measures, and they should be, its not invasive and they allow for offline mode. they even place warnings about other manufacturers DRM.
                    Nope, that's not the case. I know more than enough examples where the game ends up in a caged file, where the binary of non-steam patches are utterly incompatible with the steam-version and where games even fail to install through steam at all (sucks if you pay for a game and you can't install it since steam says it installed it but did nothing). Besides VAC does not work one inch. I see more cheaters on VAC servers than any other since it's so fun to mock with a non-working anti-cheat system.

                    EDIT: By the way, the last paragraph of yours is a total contradiction. If you consider them "being ok in your book" for that crap then you are brain-sick, sorry.

                    Comment


                    • #55
                      Originally posted by devius View Post
                      Actualy the difference isn't so big. A hardware emulator such as a NES or SNES or whatever emulator doesn't emulate the harware at all. That would be very difficult to do (impossible?). It only returns to the software the results (don't know how to call it) that the software would get if it was running on the real hardware. This isn't so different from what wine does, as it also returns what the software was expecting to get if it was running on windows. I could be completely wrong here, because I don't know that much about emulators though.
                      I hope you're joking, hardware emulators do emulate the hardware of a system - that's part of why they run incredibly slow unless you have a pretty nice box. Wine is more of a translator than an emulator, it has no code for a processor, an MMU, or any hardware devices like an emulator does. Both building an emulator and building something like Wine are incredibly difficult, but that's probably why a lot of people do it.

                      Comment


                      • #56
                        Does the registry exists natively under Linux? No? So WINE is an emulator.
                        Does DirectX work natively under Linux? No? So WINE is an emulator.
                        There are a bunch of other system parts that have to be emulated as otherwise windows apps do not run. The only difference to a console emulator is that wine (the emulator) does not have to emulate the command set as it matches the PC it runs on. Spares them from doing dyna-rec and other nasty stuff but in the end it's still emulating a system so you can run stuff like it runs on said system.

                        Comment


                        • #57
                          Originally posted by Dragonlord View Post
                          Does the registry exists natively under Linux? No? So WINE is an emulator.
                          Does DirectX work natively under Linux? No? So WINE is an emulator.
                          There are a bunch of other system parts that have to be emulated as otherwise windows apps do not run. The only difference to a console emulator is that wine (the emulator) does not have to emulate the command set as it matches the PC it runs on. Spares them from doing dyna-rec and other nasty stuff but in the end it's still emulating a system so you can run stuff like it runs on said system.
                          Sure, using the colloquial definition of emulation - from a technical standpoint these are very different things. For example, DirectX is a "standard" rather than a piece of hardware, so Wine can translate the instructions for the DirectX standard to the OpenGL standard. Wine doesn't actually implement DirectX in software (though, if you follow such things, there is some discussion about optionally doing this for a few select API calls).

                          You can't just use the colloquial term to define something, if that's how you see it then that's fine but there is different established technical terminology. The technical community considers Wine to be considered a "compatibility/translation layer," which they do not consider to be the same as an emulator.

                          Comment


                          • #58
                            Originally posted by Dragonlord View Post
                            Nope, that's not the case. I know more than enough examples where the game ends up in a caged file, where the binary of non-steam patches are utterly incompatible with the steam-version
                            Please provide examples, I have many games on steam and from what I can tell in the Steam/steamapps/common folder the games are completely the same as if they were installed from disk.

                            Comment


                            • #59
                              Myth 1: "Wine is slow because it is an emulator"

                              Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).

                              Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

                              Also, and that's what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it's just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.

                              But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).

                              Comment


                              • #60
                                Don't have the names in my head anymore as I send those buggers flying out of the window when they didn't work. Also some cases happened with others with games I don't own myself. But as far as I recall it includes AAA titles. Since some time I do not buy anything through steam anymore and it kept me rather sane. At last if it runs or not is then only the problem of the game developer no more a two-fold problem of steam messing up too.

                                Comment

                                Working...
                                X