Announcement

Collapse
No announcement yet.

Glut/OpenGL example

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

  • Glut/OpenGL example

    hi,

    posted a 3d glut/opengl example on source forum. http://www.powerbasic.com/support/pb...ad.php?t=23281

    any feedback will be appreciated. mainly, i would like to know
    if you experience flicks.
    i would like to say thanks to the sublevel6 people.
    unfortunately seems that they stoped work with win/pb.
    i also would like to apologise. i know that my english language
    skills are very bad ...

    rvalois.


    ------------------


    [this message has been edited by roberto valois (edited january 05, 2002).]
    http://www.rvalois.com.br/downloads/free/

  • #2
    I ran your sample code on W2K with no problems (no flicks).

    Very impressive.

    And your english lanquage skills are quite good (at least as far as I can tell).



    ------------------
    Peter Amick
    Baybuild Solutions
    Peter Amick
    Baybuild Solutions

    Comment


    • #3
      Thanks Peter.

      Posted a new version; collision detection, timer control etc...

      RValois


      ------------------
      http://www.rvalois.com.br/downloads/free/

      Comment


      • #4
        Code runs nicely on Windows NT4 SP6 on a Pentium 350MHz using 1.
        Perhaps an idea to use integer/long calculations in stead of reals to really speed things up. Especially SIN and COS take relatively long. And with longs you can use a small table or array to have the results e.g. multipied by 1000 or so.

        BTW: the GLUT.DLL can be found at (my Opera is not compatible with that site, so might others):
        http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip

        Thanx Valois!

        Regards,

        Henk

        ------------------
        Henk Broekhuizen,
        [email protected]
        The Netherlands
        Henk Broekhuizen, PA3BLP
        powerbasicforum -at- doorhet.net
        Sexbierum, The Netherlands
        ========================

        Comment


        • #5
          Hi Henk !

          These real numbers scare, is not ?

          But that is part of OpenGL. Internally it works with floating
          point variables thus it is better to define the variables in the
          program in the same way to do not waste time with the conversion.

          Actually all the scene is built, compiled (by OpenGL) and stored
          internally during the initialization (display list). Therefore it
          does not do much difference.

          In the case of the camera, the gluLookAt function parameteres is
          all defined with doubles. That is comprehensible since the
          precision in this case is important. Create a sines and cosines
          table ? In fact I will partially eliminate it. We only need the
          Sin and Cos when the camera turns right or left. I will modify
          the code. Thanks to point it out.

          Do you think it is slow ? Actually I set the camera to move very
          slowly. I was thinking about doing a game similar to an old one
          made for a TRS-80, with the difference of being at 3D. That is a
          project for spare time, we will see what happens ...

          Posted a new version (1.2).

          Thanks Henk !

          RValois.

          ------------------
          http://www.rvalois.com.br/downloads/free/

          Comment


          • #6

            Nice work, Roberto! The first time I ran it the ground lines flickered, but it hasn't
            done that since then.

            It seems the frame rate is very low. I'm working on a PB OpenGL racing simulator that
            has far more graphics, but the frame rate is very high compared to this for some reason.
            I haven't used Glut before, that's neat to see how much simpler it makes setting up things,
            but is there much overhead? Instead of using GlutMainLoop, I use a standard PeekMessage pump
            that attempts to update the graphics as fast as possible. I'm not sure if this is a compatible
            approach, or maybe identical, however. Perhaps the timer function is causing the program
            to wait unnecessarily between screen refreshes. I can't say for sure, as I don't know how
            glutTimerFunc works.

            Have you tried NOT using display lists? From what I've heard, they're often overrated.
            I haven't used them yet so I can't tell from looking at your code, but make sure you aren't
            generating the display list every cycle. It seems that was a big "no no", but I could be
            wrong. Also, for another possible option, instead of GluLookAt, what I do in my racing simulator
            is use a series of glRotate calls. It seems you can do something like:
            Code:
            'DrawGlScene---Here you're in glMatrixMode %GL_MODELVIEW 
            glLoadIdentity
            glRotate3f CameraYawAngleInDegrees,0,1,0
            glVertex3f 0,0,0 'Or whatever, maybe call your display list
            This rotates the current matrix around the Y (vertical) axis the specified number of
            degrees. That's much faster than computing the actual view direction vector using Sin/Cos and
            calling GluLookAt, if I'm not mistaken. Plus, glRotate3f and other matrix functions *might*
            run through your 3-D accelerator card if there is one.

            %GL_LINES is extremely slow, it might be faster to draw very narrow triangle strips
            instead for the floor and borders, although I don't know how that would look. I tried
            running with nothing but the obstacles, and things seemed smoother, but then there is
            shearing and flickering then, maybe that's due to something about the Glut implementation?

            This could be seriously optimized:
            Code:
            SUB DrawObstacles()
              LOCAL x AS SINGLE, z AS SINGLE
            
              FOR x = -%SCENESZ TO %SCENESZ  STEP 10!
                FOR z = -%SCENESZ TO %SCENESZ STEP 10!
                  glPushMatrix
                  glTranslatef x, 0!, z
                  glBegin %GL_TRIANGLE_FAN
                    glColor3f   1!, 0!, 0!
                    glVertex3f  0!, 4!, 0!
                    glColor3f   0!, 1!, 0!
                    glVertex3f -1!,-0!,-1!
                    glColor3f   0!, 0!, 1!
                    glVertex3f  1!, 0!,-1!
                    glColor3f   1!, 1!, 0!
                    glVertex3f  1!, 0!, 1!
                    glColor3f   1!, 0!, 1!
                    glVertex3f -1!, 0!, 1!
                    glColor3f   0!, 1!, 0!
                    glVertex3f -1!, 0!,-1!
                  glEnd
                  glPopMatrix
                NEXT z
              NEXT x
            
            END SUB
            You're pushing and popping the modelview matrix 100 times here every graphics frame
            by default(right?), plus glBegin and glEnd'ing just as often. Perhaps it would be faster
            to glPushMatrix and glBegin before the FOR/NEXT loops, then figure out a way to do the rest
            with nothing but glTranslatef within the loops themselves (plus the color and vertex
            assignments, of course). That shouldn't be too hard as all the objects are evenly spaced
            across the grid, so you'll probably just keep calling something like glTranslatef 10,0,0
            when traversing the X axis, and glTrnaslatef 0,0,10 when traversing the Y axis. After the
            loops are finished, glEnd.

            It didn't make a noticeable speed difference on my end, but I think it will if you can
            figure out what is causing the hesitating movement and fix it first. It almost seems like the
            Glut function that handles the keyboard input only allows a certain number of inputs every
            second. In between this time, the camera doesn't move, so it appears to have a slow frame rate.

            I could be wrong, of course, but that's where I would look first. How is the keyboard
            input being handled by Glut? After that, the other optimizations should help further I think.




            ------------------
            Todd Wasson
            -------------
            Performance Simulations
            Drag Racing and Top Speed
            Prediction Software
            http://PerformanceSimulations.Com
            Todd Wasson
            http://PerformanceSimulations.Com
            PowerBasic Racing Simulator (October 2007 clip - 15.1MB wmv file) http:http://www.performancesimulations.co...m-GenIV-12.wmv

            Comment


            • #7
              Thanks Todd.

              quote--------------------------------------------
              It seems the frame rate is very low.
              -------------------------------------------------
              The frame rate is a parameter of the function glutTimerFunc. In the
              sample code it was established 30 fps but it is possible to increase. I
              tested with 40 fps without problems.

              Glut really does the OpenGL setup very simple. Moreover it is easily
              portable. Glut's idea is to be an interface to write independent windows
              systems. If there were a "PB/IX" would be enough recompile the
              program for Unix without modifications. In the case of the posted
              example, that is not true. I am using two MS's Windows functions. I
              should not do that, but I don't yet know how to end the program
              correctly without PostQuit. And I did not yet discover how to clear the
              mouse cursor. But, in fact, did not yet search too much...

              quote--------------------------------------------
              Instead of using GlutMainLoop, I use a standard PeekMessage pump
              -------------------------------------------------
              The peekMessage pump is similar to use glutIdleFunc. glutTimerFunc is
              similar to control the program by the Timer message of the Windows.
              The advantage of using glutTimerFunc is to know that the program will
              run in the same way in computers with different processing capacities.
              Obvious that it has a limit.

              quote--------------------------------------------
              but make sure you aren't
              generating the display list every cycle
              -------------------------------------------------
              The DisplayList creation is just called out once, during the initialization.

              quote--------------------------------------------
              Have you tried NOT using display lists?
              -------------------------------------------------
              The DisplayList, according to SGI, has the warranty of being alike or
              better than direct commands. In some cases displaylist is executed in
              the video board but that depends of the board. Certainly it is not the
              best option regarding execution speed. The best option with regard to
              speed would be to use the vertexarray SGI extension.

              quote--------------------------------------------
              instead of GluLookAt, what I do in my racing simulator
              is use a series of glRotate
              -------------------------------------------------
              The gluLookAt is a function that incorporates not only Rotate. It is
              something like Rotate+Translate. The problem is that is necessary
              move the camera in the direction that it is pointing to using the
              movement unit. The Sin/Cos is also used to do that. May be it is possible
              to do that in some other way. I don't know.

              quote--------------------------------------------
              %GL_LINES is extremely slow, it might be faster to draw very narrow triangle strips
              -------------------------------------------------
              The final version (what that means?) will not have lines, but triangles as
              you suggests.

              quote--------------------------------------------
              but then there is
              shearing and flickering then, maybe that's due to something about the Glut implementation?
              -------------------------------------------------
              Flick is what I worry most now. It should not happen but it is happening
              with my system (board+monitor). glutSwapbuffers should wait retraces
              but seems that it is not happening. May be a problem with my
              board/monitor/driver but I don't know. It can be Glut's problem. Well,
              may be something else too.

              quote--------------------------------------------
              plus glBegin and glEnd'ing just as often
              -------------------------------------------------
              I cannot place glBegin/glEnd outside the loop. I am using Triangle_FAN
              and it is necessary to indicate where each pyramid starts and where
              finishes.

              quote--------------------------------------------
              You're pushing and popping the modelview matrix 100 times here every graphics frame
              by default(right?)...
              ...just keep calling something like glTranslatef 10,0,0
              when traversing the X axis, and glTrnaslatef 0,0,10 when traversing the Y axis
              -------------------------------------------------
              The question with Push/Pop would be: which is faster, 121
              Push/Pop or 11 multiplications of two 4x4 floating point matrix? I am
              tempted to think that Push/Pop is faster but I am not sure. Anyway all
              this is somehow optimized by displaylist and is difficult to know what it
              would be the fastest generically, because the optimization of displaylist
              depends of the board.

              quote--------------------------------------------
              How is the keyboard
              input being handled by Glut
              -------------------------------------------------
              I do not know how glut manage the keyboard. But it is possible to know.
              Glut is distributed with the sources! Anyway I don't believe that camera
              does not move. Actually the program was built so that the camera only
              stops when the user releases the key.

              Thank you very much.

              RValois.


              ------------------
              http://www.rvalois.com.br/downloads/free/

              Comment


              • #8
                Hi Roberto

                Flick is what I worry most now. It should not happen but it is happening
                with my system (board+monitor). glutSwapbuffers should wait retraces
                but seems that it is not happening. May be a problem with my
                board/monitor/driver but I don't know. It can be Glut's problem. Well,
                may be something else too.
                I have not yet tested your code yet, but regarding flickering:

                This code should turn on "wait for vsync", if your driver/openGL implementation supports it.
                ( Though I don't think it will override "Allways Off" in your cards driver settings.

                'wglSwapIntervalEXT(0) - vsync off
                'wglSwapIntervalEXT(1) - vsync on
                'wglSwapIntervalEXT(2) - wait for 2 vsyncs
                ' etc...


                Declare Function wglSwapIntervalEXT(ByVal i As Long) As Long

                Local wSyncPtr As Dword
                wSyncPtr = wglGetProcAddress ("wglSwapIntervalEXT")

                If wSyncPtr<>0 Then Call Dword wSyncPtr Using wglSwapIntervalEXT(1)

                I use it with a value off 0 for framerate testing.




                ------------------
                Best Regards
                Peter Scheutz
                Best Regards
                Peter Scheutz

                Comment


                • #9
                  Thanks Peter.

                  quote----------------
                  if your driver/openGL implementation supports it.
                  ---------------------
                  Unfortunately not.

                  quote----------------
                  Though I don't think it will override "Allways Off" in your cards driver settings
                  ---------------------
                  Where I can find that ?

                  RValois.


                  ------------------
                  http://www.rvalois.com.br/downloads/free/

                  Comment


                  • #10
                    Originally posted by Roberto Valois:
                    Thanks Peter.

                    quote----------------
                    if your driver/openGL implementation supports it.
                    It depends on your graphics card and driver.
                    Some drivers don't have this option.
                    If your rendering without OpenGL hardware, "Wait for vsync" is not possible


                    On Nvida Gefore 2 drivers it's in:

                    Display properties ->
                    Advanced - >
                    Geforce 2 MMX - >
                    Additional Properties ->
                    OpenGL Settings - >
                    Vertical Sync:




                    ------------------
                    Best Regards
                    Peter Scheutz
                    Best Regards
                    Peter Scheutz

                    Comment


                    • #11
                      Hi Peter,
                      I was trying to say that my drive does not support the wglSwapIntervalEXT
                      extension, but I thought perhaps I could set wait for vsync "Always ON" somewhere.
                      Anyway, I got the idea. I am going to take a look in the utilities that
                      comes with the board and in the manufacturer's site. The hardware supports
                      OpenGL but the driver is an alpha version ...

                      Thanks again.

                      RValois.

                      ------------------


                      [This message has been edited by Roberto Valois (edited January 12, 2002).]
                      http://www.rvalois.com.br/downloads/free/

                      Comment


                      • #12
                        Roberto / Todd,

                        Have either of you got an example of putting the OpenGl window onto a dialog box instead of the full screen or as the whole window?

                        Regards

                        Andrew Lindsay

                        ------------------
                        --------------
                        mailto:[email protected][email protected]</A>
                        --------------
                        andrew dot lindsay at westnet dot com dot au

                        Comment


                        • #13
                          Originally posted by Andrew Lindsay:
                          Have either of you got an example of putting the OpenGl window onto a dialog box instead of the full screen or as the whole window?
                          Check out http://root.tty0.org/sublevel6/files/multiview.zip

                          This one is done with Glut, in can be done with plain Api too.
                          You need the headers too: http://root.tty0.org/sublevel6/?page=files

                          PS: Some (older) 3D graphics cards will not do OpenGL harware accelaration if you dont go full-screen, and some need 16 bit desktop color depth.



                          ------------------
                          Best Regards
                          Peter Scheutz
                          Best Regards
                          Peter Scheutz

                          Comment


                          • #14
                            Andrew,

                            Change the Sub SetVideoMode() on posted sample code (v1.2) by:
                            Code:
                            Sub SetVideoMode()
                            
                              glutInitWindowPosition 100, 100
                              glutInitWindowSize 640, 480
                              glutCreateWindow "PB/DLL 6.0 GLUT"
                             
                            End Sub
                            RValois


                            ------------------


                            [This message has been edited by Roberto Valois (edited January 16, 2002).]
                            http://www.rvalois.com.br/downloads/free/

                            Comment


                            • #15
                              Roberto,

                              Just to be clear: first of all: very nice code! It really demonstrates what one can do with less than 400k of total code (incl DLL).

                              The thing is what I also remember from my TRS80-model 1 days (1980-1990 mainly) is that using only integers really speed things up in calculations. Of course if the DLL uses reals than there is no real gain.

                              Also on the PC I have seen lightning code, even on 386 doing graphics where they did not use reals but integers.

                              So it is not that I'm afraid of reals really, but know what difference in speed they can make, especially if you have to calculate all positions for a single step or camera move.

                              I ran your code on a PII 350 MHz with a Matrox videocard, not a real 3D monster.

                              Regards and thanks again,

                              Henk

                              ------------------
                              Henk Broekhuizen,
                              [email protected]
                              The Netherlands
                              Henk Broekhuizen, PA3BLP
                              powerbasicforum -at- doorhet.net
                              Sexbierum, The Netherlands
                              ========================

                              Comment


                              • #16
                                Hi Roberto

                                I finally got around to testing version 1 of your code, it's works very well.

                                It runs at aprox 370-380 Frames per second (1024x768:16) using a Gforce2 with the latest Nvida drivers, and a fast cpu (Disabling "wait for vsync")

                                This just goes to show how important an OpenGL 3D card is for fast rendering.

                                I'll try to test and bechmark version 2 too...


                                ------------------
                                Best Regards
                                Peter Scheutz



                                [This message has been edited by Peter Scheutz (edited January 16, 2002).]
                                Best Regards
                                Peter Scheutz

                                Comment


                                • #17
                                  Hi Henk,
                                  Nice to talk with you again.
                                  It did not scare you ? Well, I got scared ...
                                  Do you belong to the time of TRS 80? You probably know the game
                                  that I am trying to do, but I am unable to describe it, besides the
                                  simplicity of the game.

                                  Peter,
                                  370-380 Frames per second (1024x768:16)? UUUUAAAAAAAAAAAAUUUUUUU!
                                  The second version (1.2) is limited by 30 frames per second. You can
                                  change that on glutTimerFunc first parameter.

                                  Andrew,
                                  Oops, sorry. I reread your post and realize that the modification
                                  that I sugest will only runs the program in a window and that is not
                                  what you want.
                                  Unfortunately I do not have one sample the way you want. But it is
                                  possible.

                                  RValois.


                                  ------------------


                                  [This message has been edited by Roberto Valois (edited January 16, 2002).]
                                  http://www.rvalois.com.br/downloads/free/

                                  Comment

                                  Working...
                                  X