Screen Shots

[Charles Pegge]

Gaussian hump with height noise and texture noise:

[Charles Pegge]

Multiple Opengl child windows demo:
(you can edit the rotation speed for each window)






.

[kryton9]

Are these seperate windows or are they viewports Charles? Thanks for the update!

[Charles Pegge]

These are individual windows Kent.

Each has their own graphics context (hDC) but they share the rendering context (hRC). Each is rendered separately on the WM_TIMER after context switching (wglMakeCurrent hDCn, hRC).

Sharing the same hRC ensures that defined lists, textures etc are shared. I remember Petr warning me some graphics cards have problems deploying more than one hRC.

Charles

[kryton9]

Thanks for the clarification Charles.

[Petr Schreiber]

Hi Charles,

yes, some of the implementations of wglShareLists are perfect recipe for testing headache.
In following text: hRC = rendering contect, hDC = graphic context

Your solution "multiple hDC, single hRC" sounds great, but ... how did you managed that? The usual way to create hRC is something like:

Code: [Select]

hRC = wglCreateContext( hDC )

So if each window has its own hDC, how is it possible they can have the same hRC?


Petr

[Charles Pegge]

Hi Petr,

This is what I did:

Code: [Select]


            '
            'SETUP DEVICE CONTEXTS FOR EACH OPENGL CHILD WINDOW
            '
            for i=3 to 4
              '
              chw=hw[i] 'get child handle
              hDC=GetDC chw
              hD[i]=hDC
              '
              PixelFormat(hDC,0)
              finit 'reinitialise fpu after npixelformat
              '
            next
            '
            'create only one render context for several device contexts
            hRC = wglCreateContext(hD[3])

The whole demo piece:  examples\gui\OpenglChildWins.o2bas

Charles

[Charles Pegge]

I did some further tests to ensure the the Opengl Windows were truly independent in terms of viewport proportions and found there was no interference between them.

If the windows are of different size and shape then every time a window is rendered, the viewport and perspective must be respecified.

Charles

Code: [Select]

 '---------------------------
  sub PrepareRenderFor(sys n)
  '===========================
  {
    'GET CHILD HANDLE AND DEVICE CONTEXT FOR RENDERING
    '
    chw=hw[n] : hdc=hd[n]
    '
    wglMakeCurrent hDC, hRC
    '
    'SET THE VIEWPORT AND PERSPECTIVE
    '
    rect crect
    GetClientRect  chw,&cRect
    glViewport 0, 0, crect.right, crect.bottom
    double aspect=crect.right/crect.bottom
    '
    glMatrixMode   GL_PROJECTION
    glLoadIdentity
    gluPerspective 45, aspect, 1.0, 100
    glMatrixMode   GL_MODELVIEW
    glLoadIdentity
    '
    glClear GL_COLOR_BUFFER_BIT OR GL_DEPTH_BUFFER_BIT
  }

The example below should be placed in examples\gui


.

[Petr Schreiber]

Thanks Charles,

now it makes sense. The side effect of this is that any state changes you do while rendering to first window (such as last color specified, blending enabled, ...) will immediately "bleed" to other windows as well, which is given by the fact single rendering context is used. If this is something you dislike, that is exactly the point where separate rendering contexts could come in, but it is problematic. At least on ATi hardware, no OpenGL error specified, but it corrupted graphics of any window I dragged over such a multitarget area on Windows 7.


Thanks,
Petr

[Charles Pegge]

Yes exactly Petr, the entire scene has to be rebuilt from scratch and that includes setting the state variables. But sharing textures and compiled lists outweighs the disadvantages I think.

You can also be very selective with window refresh.

Charles

[Charles Pegge]

More Geometry (Alpha023)

[kryton9]

Thanks for the updates Charles.

[Charles Pegge]

Spirodome

The surface is made of flat diamond shaped panels. They all have the same length sides. Only the angles change.

This code demonstrates the spirodome geometry and will be included in the next release (>=alpha 024)

Code: [Select]

 '-----------------------------
  sub Spirodome(single h, sys n)
  '=============================
  '
  'n sides eg: 10
  'h height factor eg: .3
  '
  double a,b,r,x1,x2,x3,x4,y1,y2,y3,y4,z1,z2,z3,z4
  double a1,a2,a3,a4,r1,r2,r3,r4
  double na,nx,ny,nz
  double ha,rd,w1,w2,l1,l2,s1,s2,h1,h2
  '
  sys i,j,k,alt
  '
  'PRELIM CALCULATIONS
  '-------------------
  '
  a=2*pi()/n          'panel step angle
  ha=a*.5             'half angle
  r=1                 'initial radius
  if h<=0 then h=.001
  h1=h                'first panel height contribution
  w1=sin ha           'intial pael half width
  s1=sqr(w1*w1+h1*h1) 'panel side constant
  rd=0                'radius step difference
  a1=-ha              'initial face-on displacement
  ny=0                'normal y components
  y1=0
  y2=y1+h1
  '
  'EACH TIER
  '---------
  '
  for j=1 to 7
    '
    'EACH PANEL
    '----------
    '
    x1=r*sin a1
    z1=r*cos a1
    '
    for i=1 to n
      a2=a1+a
      x2=r*sin a2
      z2=r*cos a2
      '
      'face normal
      '
      nx=sin na
      nz=cos na
      '
      'BASE QUAD
      '---------
      '
      '
      if j=1 then
        glbegin GL_QUADS
        glNormal3f nx,ny,nz
        glVertex3f x1,y1,z1
        glVertex3f x2,y1,z2
        glVertex3f x2,y2,z2
        glVertex3f x1,y2,z1
        glend
      end if
      '
      '
      'TIP TRIANGLE
      '------------
      '
      r3=r*cos(ha) -rd
      a3=a1+ha
      x3=r3*sin a3
      y3=y2+h1
      z3=r3*cos a3
      '
      glbegin GL_TRIANGLES
      glNormal3f nx,ny,nz
      glVertex3f x1,y2,z1
      glVertex3f x2,y2,z2
      glVertex3f x3,y3,z3
      glend
      '
      'TAIL TRIANGLE
      '-------------
      '
      x4=r4*sin a3
      z4=r4*cos a3
      '
      if j>1 then
        glbegin GL_TRIANGLES
        glNormal3f nx,ny,nz
        glVertex3f x2,y2,z2
        glVertex3f x1,y2,z1
        glVertex3f x4,y4,z4
        glend
      end if
      '
      '
      'ANGLES FOR NEXT PANEL
      '
      a1=a2 : x1=x2 : z1=z2
      na=a1+ha 'angle for next normal
      '
    next
    '
    'next tier
    '---------
    '
    'CALCULATIONS FOR NEXT PANEL SET
    '-------------------------------
    '
    w1=r3*sin ha        'panel half width
    l1=sqr(s1*s1-w1*w1) 'panel half length
    rd=r-r3             'inward step
    h1=sqr(l1*l1-rd*rd) 'half height given by panel
    ny=rd/l1            'normal y component
                        '
    r4=r                'for tail coords
    y4=y2               'for tail coords
    r=r3                'update radius
    y1=y2
    y2=y3
    alt=1-alt 'alternate starting angle for next tier
    if alt then a1=0 else a1=-ha
    na=a1+ha
    '
  next
  '
  end sub


Charles

[kryton9]

Will be a very helpful shape for making a hot air balloon in a game.

In other code Charles, I noticed you using macros instead of calling a sub. What is the reason for that?
I am guessing performance?

[Charles Pegge]

Hi Kent,

In PortViewer2 I use macros mainly for convenience to bring selected parts of the code to the main program file. All the other bits like the Windows API remain out of site.

This is one way to implement Aspect-Oriented programming.
http://en.wikipedia.org/wiki/Aspect-oriented_programming

Charles