Announcement

Collapse
No announcement yet.

New Ryan Gordon Game Port Goes Into Beta

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

  • #16
    It means to always use indirect rendering. i.e. use glx to send all the OpenGL commands to the X server and let it render them, or something like that.

    Comment


    • #17
      Originally posted by bridgman View Post


      Any error messages that might give a clue ? If it runs OK on a 3200 it should run *really* OK on a 4850...


      Code:
      *********************************************************
      *********************************************************
      *********************************************************
      *********************************************************
      *********************************************************
           Warning: This is a beta version of AQUARIA.
      *********************************************************
      *********************************************************
      *********************************************************
      *********************************************************
      *********************************************************
      
      
      
      WARNING: no AL_EXT_vorbis support. We'll use more RAM.
      That's what the game itself spits out.
      I'm using the xorg-edgers packages, which haven't had a good upgrade in a while, so I'm not surprised if the code not being up to date is causing the problem.

      Comment


      • #18
        Well I found the culprit for my problem. I ran the game without kms and everything was visible with direct rendering, so I went back to kms and disabled the GL_EXT_framebuffer_object extension in r600_context.c and bingo now also everything is visible with direct rendering under kms.

        So there's something broken in the fbo code.

        Comment


        • #19
          Originally posted by bridgman View Post
          Nightmorph, monraaf, did either or both of you have the experimental GLSL flag enabled in your mesa build ? Wondering if that explains the difference in your experiences.
          Uh, possibly not. Here are some snippets from the compile log:

          Code:
          ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
          --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
          --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-driver=dri 
          --disable-glut --without-demos --disable-debug --disable-glw --disable-motif 
          --enable-glx-tls --enable-xcb --with-dri-drivers=,swrast,radeon,r200,r300,r600 
          --disable-gallium --enable-asm
          and:

          Code:
                  prefix:          /usr
                  exec_prefix:     ${prefix}
                  libdir:          /usr/lib64
                  includedir:      ${prefix}/include
          
                  Driver:          dri
                  OSMesa:          no
                  DRI drivers:     swrast radeon r200 r300 r600
                  DRI driver dir:  ${libdir}/dri
                  Use XCB:         yes
          
                  Gallium:         no
          
                  Shared libs:     yes
                  Static libs:     no
                  EGL:             yes
                  GLU:             yes
                  GLw:             no (Motif: no)
                  glut:            no
                  Demos:           no
          This is after I disabled support for Gallium, just to see if it would make a difference. Previously, I compiled a 12-14 git checkout with Gallium, as per usual. After the dismal results, I wondered if any experimental Gallium code was affecting it. Since removing Gallium had no effect, the problem is likely elsewhere.

          Would enabling GLSL give better performance, or worse? How can I check for GLSL support in the configure options? I don't see anything like it in the configure log, either enabled or disabled.

          Comment


          • #20
            I think the GLSL support is still so experimental that the only way to enable it is to go into the code manually and delete the comment around the relevant #define. So if you aren't sure whether it's on or not, then it's definitely not.

            Comment


            • #21
              Exactly. The GLSL code is still being written so enabling it by default would probably be a Bad Thing.

              Comment


              • #22
                I got some more interesting results:

                I ran the game with LIBGL_ALWAYS_INDIRECT=1, and suddenly it was playable. Framerates still sucked; it wasn't even close to smooth. Also, there's quite a bit of graphical corruption in some of the backgrounds, and in some of the popup menu dialogs. What are probably big images appear as large white rectangles.

                Despite these issues, I was able to put in a solid hour of playtime. Man, this is a beautiful work of art. I'm liking it -- but in order to stick with it, the display and performance issues have to be fixed. They're somewhere in my graphics stack . . . but where?

                Comment


                • #23
                  Originally posted by nightmorph View Post
                  Would enabling GLSL give better performance, or worse? How can I check for GLSL support in the configure options? I don't see anything like it in the configure log, either enabled or disabled.
                  Aquaria doesn't use GLSL. It's all fixed-function, immediate mode (gasp!).

                  It _does_ use FBOs for some of the effects, which explains why there was a visual improvement for disabling them...driver bug, I guess.

                  --ryan.

                  Comment


                  • #24
                    I can't wait for this game to be released.
                    I gave the beta a try and so far have encountered no problems, except that, contrary to what the tutorial tells you, the left shift button does not let you look around.
                    There's one question I have btw: From the games website I can see that the windows-version is 20$ while the Mac-version still is at its original price of 30$. How much will the Linux-version be? I wouldn't mind to pay 30$, but it's kinda annoying to know you're paying more than the windows users.

                    Comment


                    • #25
                      Originally posted by Zhick View Post
                      I wouldn't mind to pay 30$, but it's kinda annoying to know you're paying more than the windows users.
                      While I sort of see your point, I don't agree with this. Linux is a far smaller market, so certain costs have to be paid by smaller groups. Essentially, if we want Linux games, we will have to pay more because there are less of us.

                      Once we have enough games, hopefully our numbers will grow, and than the price of the games will drop, but for now I am happy to pay a premium for a Linux version (so long as it IS a Linux version and not just a "windows + other platforms" version)

                      Comment


                      • #26
                        Originally posted by Zhick View Post
                        There's one question I have btw: From the games website I can see that the windows-version is 20$ while the Mac-version still is at its original price of 30$. How much will the Linux-version be? I wouldn't mind to pay 30$, but it's kinda annoying to know you're paying more than the windows users.
                        We haven't talked about pricing at all yet, or even how/where to sell it. We'll be sorting that all out soon.

                        --ryan.

                        Comment

                        Working...
                        X