Announcement

Collapse
No announcement yet.

A New Commercial Game For Linux That's Not An FPS

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

  • #21
    GNUStep has cocoa api compatibility as a stated goal for future versions. It doesn't have a mach-o binary loader though and isn't attempting to be binary compatible with OSX, just source compatible.

    Comment


    • #22
      The gameplay trailer reminded me of Megarace and the animation after falling off the track kind of resembled Stunt Car Racer, I think.

      What I am really waiting for is a racing game like Trackmania Sunrise Extreme (especially the Island Mode) running natively on Linux.

      Comment


      • #23
        Originally posted by russofris View Post
        Mike,

        Ask them to release a reduced functionality benchmark. Add the benchmark to the PTS. All it needs to be is a no-input timedemo.

        It's free advertising and testing for them. It's a free benchmark for PTS.

        Win win.

        Make it happen. Ready, set, go!
        we've just added functionality to control the following via the config file:

        1.) disable VBL (so that it actually renders at more than 60 fps)
        2.) print out the FPS every second
        3.) do a TimeDemo (i.e. camera is attached to AI controlled ship)

        so the final version should work fine for this purpose.

        Comment


        • #24
          Originally posted by DMJC View Post
          GNUStep is more about making the frontend pretty and making all the core API functions easily accessible to programmers so they can get more done with less code.
          I wouldn't characterize this as pretty:



          Functional, maybe.
          Pretty, no.

          Comment


          • #25
            getting the beta available on desura is taking ages....

            if any of you wants to do some beta-testing, here you go - 32 and 64 bit versions:




            have a look at the readme for the required dependencies.

            we'd like to know if the game starts and runs fine everywhere.

            there is probably no point bothering to try it out without up-2-date proprietary video card drivers and a dedicated video card.

            don't take this too much as a gameplay-preview - it may be difficult getting started (i.e. "why am i hitting the walls all the time?"). in the full game you progress from a slow ship on a slow introductory track that is focused more on combat towards faster and faster tracks and ships.

            Comment


            • #26
              Wow, that's very cool of you!

              Looks like you switched the URL around though, it should be corebreach.corecode.at no?

              Comment


              • #27
                you are right thanks, these are the correct URLs




                we are still investigating rendering problems on ATI cards (lowering resolution and updating drivers helps) and weird sluggishness on NVIDIA. disabling compiz helps in any case.

                Comment


                • #28
                  On my 32-bit Debian system, everything seems to be working fine right out-of-the-box. GUI, sound, controls, the game itself...

                  I've been running the game on a Radeon HD5670 with the Mesa r600g driver, and it seems to be working very well. So far the only exception is the post processing stuff, firing the guns or hitting the wall leads to an instant segfault. This is a driver bug, and filed as such upstream: https://bugs.freedesktop.org/show_bug.cgi?id=43341 Hopefully this can be fixed soon.

                  When/if I have more time I can try it out on my Intel G45, it might be below the requirements for the game but quite a lot seems to be shared in the intel driver so if it works on G45 chances are it works on the faster stuff too.

                  Anyway, from what I can tell it's a very cool, well designed game. I'm getting my ass kicked even on Easy, but that's something I'm used to

                  Comment


                  • #29
                    thanks very much for your test and the endorsement.

                    the driver bug sounds awful, the only good news is that you should be able to turn off all post-processing in the video-preferences to work around it. does this solve the segfault-issue? do you have any more information where this bug occurs - only mesa r600 driver? i'd like to add this to the "known issues" in the ReadMe.

                    as i said its much easier to get started gameplay-wise in the full version ;-)

                    btw i've just worked around an awful driver bug in the proprietary ATI drivers which could result in abysmal performance and ugly graphics corruption. new beta later today.

                    EDIT: ok i think i got the required information from the bug-report you filed (thanks!). i've added this to the readme:

                    * CoreBreach hits a driver-bug in the Mesa R600 ATI drivers, resulting in a game crash. Turn off "Post-processing" in the video-preferences to work around the issue or switch to the proprietary binary drivers (https://bugs.freedesktop.org/show_bug.cgi?id=43341).
                    Last edited by CoreCode; 29 November 2011, 02:38 PM.

                    Comment


                    • #30
                      Right, it seems to be specific to r600g, and turning of PP does work around the bug.

                      FWIW, LLVMpipe, the software rasterizer, does not segfault. I could probably also try it out on a X1950 Pro, that's using the r300g driver which is quite a bit more mature.

                      Comment

                      Working...
                      X