G2D - 2D OpenGL library for PlayBASIC (WIP / BLOG / SCRATCH PAD)

[kevin]

G2d - Programmable Particles - 17000 thousand test scene.

       Well that was much ado about nothing,  as any fears that running particles through  our custom particle VM would be too slow, should now be completely and utterly smashed with the library returning better than expected performance.   The test scene bellow is shown in two states, the scene is made up of a number of elements again all cut and pasted together form the basic 2d demo that comes with the library.   So in this scene we have some sprites an mock up map and depending on how fast you can press the ENTER KEY anywhere between 5K->17K live particles...  Obviously the  demonstration is over the top, but it does prove how efficient the PB Compiler -> PB2DLL process actually is.   Which is VERY !

      Test Machine: AMD64 3000,  GF6600  ( 9 years old)

[kevin]

   G2D - Prototype # 9 Released  27th, Dec 2014

      Here's the latest build of the g2d library, this one is something of a catch up release addressing bugs and missing primitive commands that i've noticed through using the library.  The main fixes would be G2DDeleteImage failing and things like the Text command not responding to changes in the current font.    The library doesn't use the PB's current font settings, rather it tracks this internally. So whatever you set in G2DSetFont.  The same goes the GL ink colour.  So commands like G2dDOT, G2dBox will use the current G2d ink colour.  


      The library is of course built with the latest build of PB & PB2DLL for added performance

    Get Update

[kevin]

   G2D - Prototype # 10 - WIP

         Just stopping by to add a few more primitives to the library, namely circles and ellipses.   From memory the original D3D replacements has some extra fill mode flags for these, so the user could toggle if they wanted them to be span rendered or drawn as polygon batch.  The latter is less work for the run time and would generally give a reasonable result, but can get edgy without some type of sampling control.  Since the shape (the circle) is simply drawn a 360 degree ring of polygons.   The less steps in the ring, the faster/less polygons but less accurate the result would be the original shape.    The span version of the routines are integer only and use much the same logic the PB internal engine with the same precision.



  Idea Pad

         One of the ideas I've been kicking around in the down time is about introducing some type of FRAME settings to either PB sprites or just the G2D library.   The concept is that the frame list houses common properties together within it.    Those being the source texture ( image) as well as the coordinates within that image that a particular frame exists.  This would mean we could load an image that contains many frames and use the frame definitions to define individual images within the original image (aka a texture atlus).     Now this  could be part of the image, but then there's limitation on custom properties.   Like if you wanted the frames in a different palette you'd need to load a second copy of the texture.    

         Now of course i dunno what such a command set(s) would look like, but it could mean you'd simply use a SpriteFrame styled command to set a sprites, Image / UV's / colouring/handles/scales from that defined frame in one go.    So to make an animation, you step through the frame sequences you want.      Alternatively you load an image and tell it to define a sequential run of frames from it at some evently spaced interval,  Or just have that as separate command for that.

Code Select Expand


        ; normal image load as
         FrameSheetImage=LoadNewIMage("exploision.png")

       ; where in the global frame heap to store this set of frames
         FrameIndex = 100

       ; run through source image and make a frames from the source image.  
         FrameIndex=CreateFramesFromIMage(FrameIndex,FrameSheetImage, FrameWidth,FrameHeight)



       so a frame is really just a list of properties about a section of the source image,  and since groups of frames can be defined with a single or across images this is more optimal for hardware acceleration, as ideally then we can use large atlus textures with lots and lots of frames on them, rather than lots of seperate images.  Which is fine in direct draw/software rendering world, but not so for open GL.  Although even with separate textures it still works very well..  


      Edit: added screen shot of circles and ellipses

[kevin]

  G2D - Prototype # 11 - Mapping Fixes- Xenon 2000 Open GL

      Been fiddling with G2D a bit and figured I'd try and remake a openGL version of the original legacy Xenon 2000 tech demo.  For those that don't remember, that's one of the very first PlayBASiC demos ever made and uses the Bitmap brothers artwork form their Xenon reboot back into 2000.   The PlayBASIC tech demo wasn't a game, more a proof of concept and included a bunch of standard PB features some of which are G2d friendly and some that probably aren't, but the only way to find that stuff out is by actually doing something.  

      The first task was to create a new project and copy the media from the legacy demo across (just search for Xenon), next we copy the G2D files into the folder (Dll and bindings include) and we're done.   Once we've made a project ,  then we can kick on to show a  g2D represent get the map.  The original demo uses a couple of map layers for parallax backdrops,  so O simply skimmed  through the old code and pulled out the map loading code.   Jazzed the code up a little, since it was written back in the dawn of PlayBASIC and the mapping commands have changed somewhat over the past decade.   But really the changes are just simple things like using dynamic media allocations and building a FX map directly from the input image in memory, rather than the legacy method of from the video device (see slow, RTFM for why)

      So initially when using the prototype #10 of G2D, the code wasn't running the same as the internal PB command set, so the two would produce a different output completely, namely in what blocks  G2D library would treat as being transparent, solid or empty.   This turned out to be a by product of the per block transparency stuff that was added to PB a bunch of years ago which the G2D library wasn't bothering to utilize when the drawing a map/layer,  but after adding some tweaks we get the same output.  

      Bellow is the current code as well as the  standard testing screenshot for such demos.  So on top we see the OPEN GL version and bellow the DirectDraw version.   Since we're drawing both together,  it's impacting on the frame rate a lot,  as the GL demo runs about 550-600fps (10 year old system)  so it's inside a 2 millisecond refresh.    But it's handy for testing  stuff like this.  

PlayBASIC Code: [Select]

/* -----------------------------------------------------------------------------      
   -----------------------------------------------------------------------------      
       ----------------->> XENON 2000 mock up in G2D <<--------------------      
   -----------------------------------------------------------------------------      
   -----------------------------------------------------------------------------      

       This demo is another recreation of the Xenon 2000 demo but this time using the 
    G2D for the rendering.  The purpose of the demo si to wedd out as many differences
    in the library as possible.
    
   -----------------------------------------------------------------------------      
*/

      // include the G2D library 
      #include "G2D_Library.pba"

      // set the screen title
      TitleScreen "G2D - Xenon 2000"


      // First up, we open GL library.. With our screen size and
      Dim GL as tMyGL pointer
      GL=G2DStart(GetSCreenWidth(),GEtScreenHeight())
      if int(GL)   

            ; push the direct X screen to the bottom (almost off the screen)
;            ScreenLayout 0,GetSCreenHeight(),GetScreenWidth(),GetSCreenHeight()+1
            ScreenLayout 0,GetSCreenHeight()/2,GetScreenWidth(),GetSCreenHeight()+1

            // clear the OPenGL Screen
            g2dCls($304050)

            // flip GL buffer (back to front)
            g2dsync()


            // load the map and level raw level block data                                 
            ThisMap,XenonMapBlockImage=Load_And_Prepare_Map()




            // the maps are huge as set the offset to come place we can see something
            Global MapY_Starting_Position=1000*32

            local ypos#=(-MapY_Starting_Position)


            G2dLOadFont("Veranda",10, 24,0)

            setfont 10
            G2dSetFont 10


            // -----------------------------------------------------------------
            // -----------------------------------------------------------------
            // -----------------------------------------------------------------
            
            do

                  CurrentFPS=fps()

                  // ----------------------------------------------------------
                  ; clear Open GL screen
                  // ----------------------------------------------------------
                  g2dCls($304050)

                  ; draw thew map blocks to gl screen, mouse toggle transpraent/solid
                  g2ddrawimage XenonMapBlockImage,50,50,mousebutton()

                  ; draw the map level             
                  g2ddrawmap ThisMap,0,00,ypos#,XenonMapBlockImage

                  g2dprint(Str$(CurrentFPS))

                  g2dsetcursor 0,0
                  g2dprint("G2D display (OPEN GL)")            
                  g2dsync()


                  // ----------------------------------------------------------
                  ; draw direct draw version 
                  // ----------------------------------------------------------
                  cls $5544   
                  drawmap ThisMap,0,000,ypos#
                  print("Direct Draw ")            

                  sync
                  Ypos#+=1            
            loop

            sync
            waitkey

            g2dEnd()
      
      endif



      


   // --------------------------------------------------------------------------
   // --------------------------------------------------------------------------
   // --------------------------------------------------------------------------
   // --------------------------------------------------------------------------

Function Load_And_Prepare_Map()

   ` *========================================================================*
   `                 CREATE And LOAD MAP GFX / level Data
   ` *========================================================================*

      ; ===================================================
      ; CReate Map & And MAP Levels/Layers      
      ; ===================================================

      ThisMap=NewMap(2)

      ThisImage=Loadnewimage("Media\Blocks.bmp",2)
      
      MakeMapGFX   ThisMap,ThisImage,32,32,1024,$ff00ff,2

         ; ===============
         ; Create Layer #1
         ; ================
      
         CreateLevel ThisMap,0,20,2000
         LevelTransparent ThisMap,0,000 
         LoadLevelTiles("Media\Levels\Xenon2000_layer1.Mar",ThisMap,0,20,3000)

         ; ===============
         ; Create Layer #2
         ; ===============

         CreateLevel ThisMap,1,20,1000
         LevelTransparent ThisMap,1,000
         LoadLevelTiles("Media\Levels\Xenon2000_layer2.Mar",ThisMap,1,20,3000)


         
         
            // since this image used mask colour transparency, we we'll need this image is 
            makealphachannel(THisImage,$00ff00ff)

            // make this image into a parallel Open GL texture for G2D output

Login required to view complete source code

[kevin]

  G2D - Prototype # 11 - Map fixes + few missing commands

         So in release 11 of G2D, we've tweaked up map rendering somewhat they should generally behave much the same as regular (cough) built in maps,  plus there's a sprinkling of missing commands and a few little back end behaviors aligned with the core command set.   For example previous if you used g2dCLS()  is didn't reset the cursor position.

     So if you had a look like,

PlayBASIC Code: [Select]

      Do 
           g2dCLS 255  
           g2dPRINT "stuff"  
           g2dPRINT "stuff"  
           g2dPRINT "stuff"  

           g2dsync
      loop

       The text would move off the screen, so you'd have to reset the g2dcursor position.

[kevin]

   G2D - Prototype # 12 - Map Clipping

       Most of the coding time recently has been writing a math library to help out with clipping/interesections in G2D, some stuff I can use build in commands for, but I can't access all the internal lowlevel functions  from an external DLL so I've got to build versions of the functions in PlayBASIC.   Given that all the PB is translated to machine code via PB2DLL it's boarding upon irrelevant now in terms of performance. 

        Much of the library at this point is pretty vanilla, by that i mean, the code is simple and straight to the point, so it's easy to change without having to sift through a mountain of abstract optimizations.  For maps, we need to made sure we're no creating meshes for the parts of the map level that are impossible to see. For example in both camera modes, the view can rotate.  Now normally we can just clip the blocks scanning to the nearest bounds of the viewport,  effectively skipping 99.99% of stuff that's outside of the frame.   When things rotate we need to first do some high clips to see if the level needs to be drawn as it might completely outside of the view,  if it passes that initial test we work out the region of the map that camera is looking at and build a mesh from it.

      Alternatively it could use the size of the viewport and map block sizes to compute potentially visible zones, so it'd break into 32*32 tile meshes..  even so it's still possible for the mesh generation to build polygon lists of rects that aren't visible.  Which would have negative impact on the performance of the rendering, but would be quicker than the current 'render everything' implementation when drawn through a camera     You could this manually,   just by  breaking big levels down into a smaller grids of 'display levels' which would do much the same thing.   So if you have a level that's 1000 tiles wide by 50 tiles high or something, then you cut up the big level into smaller chunks of say 50 by 50 tiles.   You'd still run collision on the bug map, just draw the smaller chunks, if that makes any sense.. 


     

[kevin]

   G2D - Prototype # 12 - Xenon Mock

            So far I've been most playing with the library rather than writing anything with it,  so tonight's session has been get some of the xenon demo up and running.   The original code supports various cameras this version doesn't,  so I've been dragging the code over and making some mods to remove the camera stuff..   So far we've the maps loading/ backdrop and the aliens which are just randomly shoved into the scene in the original demo and are here as well..  

            The pics show us the scene with and without programmable particles in the scene.   The stock scene in a window runs at 600 fps on my 9 year old althon system, so in other words it's a sub 2 millisecond refresh.     Since the GPU is doing the blending in the background to the primary surface you can blend particles too, which comes at cost but even with completely over the top numbers of particles it's still well inside 16.7 millisecond refresh in a window.  

 

[kevin]

  G2D - Prototype # 12 - Xenon Mock - Player + Bullets + collisions

        Here's tonight's little 'as is' screenie,  this one is actually used the G2dDrawAllSprites() function to draw the sprite scene, where as yesterdays was manually drawing the sprite images, which isn't a huge difference, appear from the fact that we lose draw modes.  unfortunately we can't replicate all PB draw modes in GL or D3D without moving to shaders, since we're trying to stay GL1.0.     The only area where this impacts this demo is the use the colour addition mode.  Which takes the input texture RGB colours from the sprites image and adds the user defined colour as it's output to the screen,  which is handy when creating coloured flashes on objects when there's an impact.    You could emulate it, but I can't think of way without using a second grey scale texture for the time being. 

        In the screen we see the samey scene with random asteroids, the player and bullets with pixel level collisions.    We don't need to write G2D versions of the collision stuff for sprites/map commands, we just use the built in stuff on FX surfaces and we can run collisions as per normal..  The particle stuff is still included in the demo but isn't used in this shot,  but what I think I'll do is attach an emitter to the explosion to throw a bunch  fugly junk on screen.    The code is basically dragged directly from the original demo (dunno what version of it) and stream lined a little, there's one strange error with that's not reclaiming sprites that leave the screen though, which ends up in crash. The crash is prolly some missing code that's no resizing a buffer correctly, but i'm bit suss about the sprite clipping though, dunno why that's happening.


     

[kevin]

 G2D - Prototype # 13 - Xenon Mock - Player + Bullets + collisions + Micheal Bay Explosions yarda yarda

     Slowly wading through tweaking the library and demo in turn, the demo was crashing again drawing sorted sprite scene and I couldn't work out why for most of the day.  After some back tracing it turned out to be that PB2DLL wasn't passing a pointer parameter correctly to the internal command set call when calling the GetSpriteRect command, making it do some odd stuff from crashing immediately through to some bizarre clipping.  Which I guess was just pot luck data on the system stack..

     So in this scene we have working player / bullets / aliens and explosions (with attached PB particle generation) running with depth sorting.  The frame rate is more than ample even on this old clunker.  

   

[kevin]

  G2D - 2D OpenGL library for PlayBASIC V1.64P3 Beta 5 and above

  PROTOTYPE #12

  Release Date:  25th,  May, 2015



Download

   Old release deleted, newer versions bellow

[kevin]

 G2D Xenon 2000 Mock Up Version 001

     Here's the current build of the xenon 2000 mock up that uses G2D as the display library.    The demo includes maps/sprites/collisions and particles.  The demo is running upcapped (no vsync here),  but it actually depends on what your driver is set to,  most drivers will default to a capped vsynced refresh.   So you'll have to turn that off to get some idea..


Video

Old Video

 

Download

 G2D Xenon 2000 Mock Up Version 001 (login required) (25th,May,2015)

[kevin]

 G2D - Prototype # 14 - Map Clipping Updates

      With the various tweaks being made to PlayBASIC lately i've been tweaking the G2D libraries also.  One thing i noticed a while back was some strange slow down when rendering map levels to cameras.   Which initially I assumed was the cost of overdraw, but when timing the routine it seemed to bounce around a lot more than one would expect.   Not 100% sure on why,  but it's probably a combination of overdrawing and over rotation of the mesh (pre-cache hits when fetching memory) when it's being set up, due to lack of any real clipping.

     ok now the scene is set, so about a month ago I started coming up with different ways to improve the clipping for those meshes, which was somewhat more challenging than i'd expected.    The initial test was done in plain old PlayBASIC when the scene was drawn from an imported image which you could project and rotated.  The result being drawn as a polygon mesh via drawing QUADs.   Initially it'd choke regardless of how much of the scene was on screen running about 1fps or less.   Then as the clipping got better, the performance started to shoot up, now ranging between 200fps dropping down to 60fps (on the 10 year old althon).   Means the clipping cost has been largely removed and the bottleneck is now the software rendering behind QUAD.    If you have 1000's of quads that's a huge amount of edge translation/clipping etc and final rendering of then spans.

     So last night's little task was to convert the new logic into the G2D, which meant rewriting the Map rendering functions.    The result so far is the map rendering cost in the test scene doesn't seem to have the same impact on frame rate running from standard PB (the library is written in PLAYBASIC btw).   Hopefully, that speed up will translate into the final machine code version also, but I can't see why not at this point.  

     

    (Added later on - just testing video)

 

[kevin]

G2D - Prototype # 15 - Rotated Map Support 2D Cameras.

    It's taken a few extra sessions to get this working, but g2d cameras now support Map rotation with clipping.  Rotation is supported in both camera modes (flat & perspective) without breaking the clipper, which was the reason for the delays.   The clipping worked fine in the mock up, but there was some order of operation issues when dropping it into the library,  which took some time to weed out where the difference was coming from.   But that's done now.     

    anyway, here's the standard Xenon 2000 map layers drawn from a camera. In previous editions of the library would drop down into about 100fps (so a 10millisecond refresh), where it'll now draw in 450fps (2.2 millisecond refresh) with  backdrop on the Athlon 3000 system (10 year old system)

    The current build of the library only supports rotated maps from cameras in flat camera modes,  in the process of tweaking the sprite rendered to rotate also.    Making it bit more flexible.

[kevin]

  G2D - Prototype # 15b - Updating Sprite Rotation in 2D Camera modes.
   
        In the original release the G2D cameras have two modes, one was a clone of the PB camera so you can view the scene from a point of view, but the view can't rotate.  The other is perspective mode with supports zooming/rotating, so if you alter the Z that alters the projection of the sprite when in perspective mode.

       Using OpenGLL, we're pushing the rendering off the CPU/system memory onto the video card so there's less noticable difference in render performance,  making it more viable to post rotate/zoom a scene.     Therefore in the newer version of camera code both modes can rotate what's in view.   Unlike PB internal command sets, there's no high level scene collection mechanic so you have to construct the scene yourself.  But given most people tend use sprites for everything in the scene  (if you don't, you should.. ie RTFM for why)   

       So this afternoons annoying little task has been to tweak up the sprite rendering routines so they work in both camera modes.  Which means updating the clipping and state management.   The clipping is working well now and those little math difference between the sprites/maps seem to now have been ironed out.   There's a bit of strange crash in the tests at the moment, but hopefully that be ironed over the weekend so we can get a new version of thise thing out.

[kevin]

  G2D - 2D OpenGL library for PlayBASIC V1.64P3 Beta 18 and above

  PROTOTYPE #15

  Release Date:  15th,  Nov, 2015



Download

  Get current version from Release Area





 
 G2D Xenon Camera Perspective Camera Test 15th,Nov,2015

    This short video (no music) shows the perspective 2D camera mode in the G2D (open GL) graphics library for PlayBASIC. The mock up scene consists of a mix of elements mostly from Xenon 2000.    In view is 2000 rotating sprites and the various map layers with filler backdrop.

    The capture of the demo is rather awful (very framey), but it actually runs 200fps plus on the 10 year old althon 64 test system with 6600 gpu.