PlayBasic V1.64M (Work In Progress) Gallery

Started by kevin, May 25, 2010, 01:37:57 AM

Previous topic - Next topic

kevin

#15
  PlayBASIC V1.64M  Beta #12 - Mapping Updates Continued..

    Still ticking away on the mapping library,  Doing some freshening up, while adding the odd bit of new functionality to the library.  Hopefully, closing down those remaining omissions.   One change is the new ability to select the type of blocks being created , when we use the CreateMapGFX command.  This command now has an optional format parameter.  You can select the regular Video, FX , AFX  modes with it.   It's a lot more efficient than the age old solution of creating a video bank of tiles and converting that to FX.      

    For example,  if we create a map with 1024 tiles with a block size 100x by 100 in 32bit.    Then converted this to FX format via PrepareFXmap, then this would takes over 13 seconds to process on my system.   However, if we create the blocks in FX format than grab them, it's all done in 1/2 a second.   Approximately 26 times faster.  

   If we push this further (example code bellow), it'll now handle importing up to 4096 FX tiles in about 1.5 seconds.  In 32bit, that's over 150 meg of gfx data... Not too bad at all...

PlayBASIC Code: [Select]
t=timer()
screen=newfximage(6400,6400)
rendertoimage screen
boxc 0,0,getsurfacewidth(),getsurfaceheight(),true,$ff0000
circlec 400,400,400,true,$ffffff

BlockWidth=100
BlockHeight=100

Map=Newmap(50)
createmapgfx Map,BlockWidth,BlockHeight,4096,$00ff0000,2 ; CREATE 4096 FX BLOCKS

; Makemapgfx Map,Screen,BlockWidth,BlockHeight,64,$000000ff

Level=NewLevel(Map,GetSurfaceWidth()/BlockWidth,GetSurfaceHeight()/BlockHeight)
leveltransparent Map,Level,200

For ylp=0 to GetLevelHeight(map,level)-1
Ypos=ylp*BlockHeight
if Ypos+BlockHeight<=GetSurfaceHeight()
For xlp=0 to GetLevelWidth(map,level)-1
Xpos=xlp*BlockWidth
ink $ffff00ff
text Xpos,ypos,Tile
ink $ffffffff
GetMapBlk Map,Tile,Xpos,ypos
PokeLevelTile Map,Level,xlp,ylp,tile
tile++
if Tile=>GetMapBlocks(Map) then exitfor ylp
next
endif
next

tt=timer()-t



rendertoscreen

cam=newcamera()
cameracls cam,off

c1=rndrgb()
c2=rndrgb()

Do
shadebox 0,0,getsurfacewidth(),GetsurfaceHeight(),c1,c1,c2,c2

capturetoscene
clsscene
drawmap map,Level,0,0

speed=2
if leftkey() then movecamera cam,-Speed,0
if rightkey() then movecamera cam,Speed,0
if upkey() then movecamera cam,0,-Speed
if downkey() then movecamera cam,0,Speed

; displa
drawcamera cam

setcursor 0,0
print "Built FX map"

Totalmem=Tile*(BlockWidth*BlockHeight*4)
print "Memory:"+str$(TotalMem)+" Bytes "+str$(TotalMem/(1024*1024))+" Meg"
print "Ticks:"+STR$(tt)
Sync
loop









kevin

#16
  PlayBASIC V1.64M  Beta #12 - Point & Ray Collision Methods

  Here's a couple of new collision tidbits that are on there way to an upgrade near you.   Namely PointHitMapPixels and it's friend ray hit map.   The first function lets us detect if a point (in level space) impacts on a pixel within the map, prolly should be LEVEL...   The other (still testing this) is a way to checking if a ray hits the level at pixel level.  

   Clearly, if we're going to be running pixel level comparison against the block data, then the most optimal format for these is going to be the FX formats, rather than video formats.    The retro method is to use a MASK version of the tiles to run collisions upon.  This way the mask can be tweaked (pixel by pixel).  Running collision against the actually gfx data  (the stuff we see) isn't very common.    You can do much the same thing in PlayBASIC by using two maps.    The masks don't even need to be the same resolution as the original.   Think about it :)  

   Anyway, here's a bit of piccy running pixel level collisions against the map.  

   


PlayBASIC Code: [Select]
 screen=newfximage(6400,6400)
rendertoimage screen
cls $ff0000
circlec 400,400,400,true,$ffffff
circlec 1300,400,400,true,$0fffaf


BlockWidth=100
BlockHeight=100

Map=Newmap(50)
createmapgfx Map,BlockWidth,BlockHeight,4096,$00ff0000,2 ; CREATE 4096 FX BLOCKS

Level=NewLevel(Map,GetSurfaceWidth()/BlockWidth,GetSurfaceHeight()/BlockHeight)
leveltransparent Map,Level,200

For ylp=0 to GetLevelHeight(map,level)-1
Ypos=ylp*BlockHeight
if Ypos+BlockHeight<=GetSurfaceHeight()
For xlp=0 to GetLevelWidth(map,level)-1
Xpos=xlp*BlockWidth
ink $ffff00ff
text Xpos,ypos,Tile
ink $ffffffff
GetMapBlk Map,Tile,Xpos,ypos
PokeLevelTile Map,Level,xlp,ylp,tile
tile++
if Tile=>GetMapBlocks(Map) then exitfor ylp
next
endif
next


rendertoscreen

cam=newcamera()
cameracls cam,off

c1=rndrgb()
c2=rndrgb()

Do

shadebox 0,0,getsurfacewidth(),GetsurfaceHeight(),c1,c1,c2,c2

MouseWorldXpos=MouseX()-1+GetCameraX(Cam)
MouseWorldYpos=MouseY()-1+GetCameraY(Cam)

capturetoscene
clsscene

capturedepth 100

; draw the map level
drawmap map,Level,0,0

; DRaw the the Mouse pointer within the world space
capturedepth 10
dotc MouseWorldXpos,MouseWorldYpos,RndRGB()


RayStart=Timer()
CheckRays(Map,Level,MouseWorldXpos,MouseWorldYpos,300,64)
RayTime=Timer()-RayStart

; draw whatever the camera can see
drawcamera cam

setcursor 0,0

ink $ff0000ff

print "Ray Timer:"+STR$(RAYTIME)


speed=2
if leftkey() then movecamera cam,-Speed,0
if rightkey() then movecamera cam,Speed,0
if upkey() then movecamera cam,0,-Speed
if downkey() then movecamera cam,0,Speed

Sync
loop




Function CheckRays(Map,Level,Xpos,Ypos,RAdius,Rays)
AngleStep#=360.0/Rays

For lp=0 to rays-1
angle#=lp*AngleStep#
x2#=cosnewvalue(xpos,Angle#,radius)
y2#=sinnewvalue(ypos,Angle#,radius)
Collision=RayHitMapPixels(Map,Level,xpos,ypos,x2#,y2#)
if Collision
hitx#=getINtersectx#(0)
hity#=getINtersecty#(0)
line xpos,ypos,hitx#,hity#
circlec hitx#,hity#,5,true,$00ff0000
else
line xpos,ypos,x2#,y2#
endif
next


EndFunction







 Download

 Get V1.64M Beta #12 (login required)


 

kevin

#17
  PlayBASIC V1.64M  Beta #13 - Map Spring Cleaning

  Spent the last couple of days doing something of a winter clean (it's winter here BTW)  of the core mapping commands, focusing upon the Block creation commands.   Found a number of little annoying tidbits while picking through it and have been able to reduce the foot print of the code just by better structure.  So that's a win! -  So far i've resisted the urge the remove the libraries memory manager (a first! :) ),  even thought i really, really want too ! :) - However, I can see some good opportunities for commands to help communication between programmers and the library a little better.    

  For example,  it'd be handy if the map library would import/export  a level to a  2D array.  Another thing that would in useful would an optional parameter on the PeekLevelTile function, to request the command resolve any animation peeks to the Block Index.

  I've got a number of ideas for rendering tweaks (and commands to help reduce rendering), but you'll have to wait and see on that one.



 PlayBASIC V1.64M  Beta #13 - Debugger - View Programs Memory Consumption

   This is a bit of kick back to the original debugger 'to do' list from years ago.  Which is a feature to give the user some idea of the amount of memory their program is using.    To do that, I've got to run through and query each command set.   So I decided to make a report out of it since it's not something you want to be doing real time.

   So basically this new feature allows us to dump the 'state' of the running program to the console as a text report.   The report,  allows us to look at the core libraries contain, so we can  get an idea of the overall applications resource usage and it's memory consumption at that time.  

   The report is nothing fancy, just simple text  dropped to the debugger console. It's broken up into sections, each section covers the state of the media within the command set with an approximation the memory consumption at the and of each section.  The report concludes with the tallied memory consumption.  

   Estimates ? - Yes, while the values are indeed accurate,  the calculation routine doesn't and can't see the fine details of the command sets from the debugger.   So the values returned are basically slight under estimates.  If it reports the program is using 100 meg, than that's a certainty! - However,  internally the engine might be using another couple of the meg for temp data.    So i'd suggest adding %5 to %10 to whatever values it returns.

   This feature should take the guess work out of recommending the system requirements for your completed games.  

  Here's an example of the report.  



[==================== START PROGRAM MEMORY USAGE ======================]


------------------------------------------------------------------------------------------------------------
[SCREEN SYSTEM]
------------------------------------------------------------------------------------------------------------
[
SCREEN #0
[
Width =1024
Height =768
Depth =32
]

Screen.Video Memory Usage =6291456 Bytes
Screen.System Memory Usage =80 Bytes
]




------------------------------------------------------------------------------------------------------------
[FONT SYSTEM]
------------------------------------------------------------------------------------------------------------
[
FONT #1
[
Name =Courier
Type =1 Windows GDI
ChrWidth =8
ChrHeight =13
]

Fonts.Video Memory Usage =0 Bytes
Fonts.System Memory Usage =98055 Bytes
]




------------------------------------------------------------------------------------------------------------
[IMAGE SYSTEM]
------------------------------------------------------------------------------------------------------------
[
IMAGE #1
[
Name =
Type =2 [FX]
Width =6400
Height =6400
Depth =32
Mask =00000000 A=0 R=0 G=0 B=0
]

Images.Video Memory Usage =0 Bytes
Images.System Memory Usage =163942000 Bytes
]




------------------------------------------------------------------------------------------------------------
[SPRITE SYSTEM]
------------------------------------------------------------------------------------------------------------
[
Sprite.System Memory Usage =336000 Bytes
]




------------------------------------------------------------------------------------------------------------
[MAP SYSTEM]
------------------------------------------------------------------------------------------------------------
[
MAP #1
[
Map(1).Blocks
[
Width =100
Height=100
Count=1024
]

Map(1).Level Quantity=50
[
Map(1).Level (0)
[
Width    =64
Height   =64
Drawmode =2
]

]

Map(1).Animation Quantity=20
[
Map(1).Anim (5)
[
Type   =1
CurrentFrame =0
Frames   =50
Sequence =-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
]
]

]

Maps.Video Memory Usage =0 Bytes
Maps.System Memory Usage =29676 Bytes
]




------------------------------------------------------------------------------------------------------------
[MEMORY CONSUMPTION SUMMARY]
------------------------------------------------------------------------------------------------------------
[
Program.Total Video Memory Usage =6 Megabytes (6291456) Bytes.
Program.Total System Memory Usage =156 Megabytes (164069811) Bytes.
]



[==================== END PROGRAM MEMORY USAGE ======================]











kevin

#18
  PlayBASIC V1.64M  Beta #14 - Debugger Cont..

  Haven't had that much hands on PlayBASIC time in the last couple of days, so i've only been doing the odd programming session here and there.  Mostly cleaning up some of the content output routines in the debugger. So it's formatting the text up a little better now.   Added the odd extra bit of info here and there, so it's easier to see what's going on..  

  Also been having a look see at the array dump routines trying to the write a quicker routine to dump the typed array state.   Lots of string and memory thrashing, so it can be pretty slow when look at the big arrays..  Could possibly give a warning when viewing really large one's as the it becomes a huge amount of the data..



 Edit: A few hours later

    As mentioned previously, i've been tweaking the array conversion to string functions, this process could really bog down on large typed arrays.  How much ? -  Well, in V1.64M Beta 12, if I run the code bellow and click upon the typed array in the debugger/variable view.  It takes a little over 4 minutes to dump the whole array to a string representation.    This same process only takes a couple of seconds in V1.64M Beta14  


PlayBASIC Code: [Select]
   Type Test   
b as byte
w as word
I
F#
s$
Ia(10)
Fa#(10)
Sa$(10)
Endtype

print sizeof(Test)

max=10000
DIm Cool(max)
DIm Cool#(max)
DIm Cool$(max)
DIm CoolTyped(max) as test

t=timer()
for lp=0 to max
Cool$(lp)="TEST"+str$(lp)
CoolTyped(lp).s$ ="Test"+Str$(lp)
next
t=Timer()-t
print t
Sync
WaitKey






   

kevin

#19
  PlayBASIC V1.64M  Beta #14 - MakeMapGFX

    Back tapping away at the guts of the mapping library.  Adding the odd optional parameter here and there and embedding from new functionality where I can and where it makes sense.    Previously i mentioned using a two maps, one for the display and one for collision.   Obviously the mask version doesn't need as many tiles, sow e can save memory by reducing the block set down.   However the block depth is still coming from whatever the depth of the screen is, unless we're loading (or making block from) an AFX surface.  In which case the blocks will always be 32bits deep.   But we really don't need alpha for the mask, since we never see it.  So to conserve memory i've add the ability to set the FX maps surface depth.      

    Using the example above, if we have 4096 blocks (100*100),  in 32bit that's around 156 meg of memory.   However, we can save 50% of that by using 16bit blocks for the map  data.    Which is likely (haven't checked) to aid in collision detection against the map.

  The example above creates the same boring scene as before, expect this time it forces PB to create 16bit blocks for the map data.



PlayBASIC Code: [Select]
   BlockWidth=100
BlockHeight=100


screen=1
sync

screen=newfximage(6400,6400)
; createfximageex screen,6410,6400,16
; createfximage screen,6400,6400

rendertoimage screen

TilesX=GetSurfaceWidth()/BlockWidth
If (TilesX*BlockWidth)<GetSurfaceWidth() then TilesX++

TilesY=GetSurfaceHeight()/BlockHeight
If (TilesY*BlockHeight)<GetSurfaceHeight() then TilesY++

; boxc 0,0,getsurfacewidth(),getsurfaceheight(),true,$ff0000
cls $f00000
circlec 400,400,400,true,$ff80ff
circlec 1300,400,400,true,$0080ff

; Number the blocks
Tile=0
For ylp=0 to tilesy-1
Ypos=ylp*BlockHeight
For xlp=0 to tilesX-1
Xpos=xlp*BlockWidth
ink $8fff00ff
text Xpos,ypos,Tile
ink $ffffffff
Tile++
next
next



;rendertoscreen

t=timer()

Map=Newmap(50)
; createmapgfx Map,BlockWidth,BlockHeight,4096,$f00000, 2 ;or lsl32(15,16) ; CREATE 4096 FX BLOCKS

MakeMapGFX Map,Screen,BlockWidth,BlockHeight,4096,$00f00000,2 or lsl32(15,16)

Level=NewLevel(Map,GetSurfaceWidth()/BlockWidth,GetSurfaceHeight()/BlockHeight)
leveltransparent Map,Level,200


; Create the level data to represent this the original image.
Tile=0
For ylp=0 to tilesy-1
Ypos=ylp*BlockHeight
if Ypos+BlockHeight<=GetSurfaceHeight()
For xlp=0 to tilesX-1
if Tile=>GetMapBlocks(Map) then exitfor ylp
; GetMapBlk Map,Tile,Xpos,ypos
PokeLevelTile Map,Level,xlp,ylp,tile
tile++
next
endif
next



MapAnimQuantity Map,20
CReateMapAnim Map,5,50

tt=timer()-t


rendertoscreen

cam=newcamera()
cameracls cam,off

c1=rndrgb()
c2=rndrgb()

Do

cls $00ff00

MouseWorldXpos=MouseX()-1+GetCameraX(Cam)
MouseWorldYpos=MouseY()-1+GetCameraY(Cam)

CaptureToScene
ClsScene
CaptureDepth 100

; draw the map level
DrawMap map,Level,0,0


; draw whatever the camera can see
drawcamera cam


if rightmousebutton()
EndX=MouseWorldXpos
EndY=MouseWorldYpos
endif

setcursor 0,0

ink $ff0000ff

Totalmem=Tile*(BlockWidth*BlockHeight*2)

Print "Memory:"+str$(TotalMem)+" Bytes "+str$(TotalMem/(1024*1024))+" Meg"
Print "Ticks:"+STR$(tt)



speed=2
if leftkey() then movecamera cam,-Speed,0
if rightkey() then movecamera cam,Speed,0
if upkey() then movecamera cam,0,-Speed
if downkey() then movecamera cam,0,Speed

Sync
loop










kevin

#20
  PlayBASIC V1.64M  Beta #14


     Here's the latest work in progress of the PlayBASIC V1.64M upgrade.    The changes mostly focuses on improving the Mapping library and some new features for the run time Debugger.  All that stuff is covered above..


 DOWNLOAD

  Download PlayBASIC V1.64M Beta14 (login required)




kevin

#21
  PlayBASIC V1.64M  Beta #14 - FlexiGUI Testing

    The past couple of days have been all about beta testing. For this session i've been using the FlexiGUI library (since it's huge).   The library was written some 5 years ago and it shows, so it's not really representative of the feature set of PlayBASIC today.  But there's not too much I can do about that really, as I'm just knocking up some usage examples to help newcomers wrap their minds around it.     There will be a tutorial to go with this, but that's about it for now.

    The following picture is of one of the examples.  It's showing how users can manage many windows, each with their own unique gadgets.   Understanding the  management  really comes down to how well you understand TYPES though.   So for those you've been putting off learning about TYPES, then there's no time like the present.  


   Edit

      Still tinkering around with some flexi examples. The last screenie (bellow) uses the LABEL, SCROLLERS and PICTUREBOX gadgets together.  It's set up to display a scaled picture (randomly) in the current window.  The user can scale it using the scrollers.  The only thing tricky about it, is you've got to careful when n refreshing the PICTUREBOX gadget.  The GADGET has it's own surface and the picture your displaying.  If you Render to the Gadget, then you're actually drawing to gadgets surface and not the picture you attached.    That one even had me stumped for a while :)...   



kevin

#22
  PlayBASIC V1.64M  Beta #14 - Minor Update For FlexiGUI

     Been working on the GUI tutorial most of the day, what fun :(... Anyway, previously I mentioned that due to the age of the library, it's missing some of the newest compiler & command set (graphical) features.   So i've taken this brief opportunity to tweak the code up a bit.   The main changes to the library  so far would be the addition some  optional parameters/wrapper functions plus  support for  dynamic function calling.   Two subtle changes, that make make some interesting things possible.

    The dynamic function calling allows us to make the flexi main loop that little bit simpler upon the programmer.   In older versions of the library, the user manages events by calling the libraries event update function, then looping through and catching any user event. Once that's done we reset the event stack for the next update.   This process is still how the library works, we can reduce the code to single function call.    All we have to do is write a function to process the user event we want to handle,  then tell the Flexi what this function is called.    When we call the FlexiUpdate() function it gets user input/processes the SYSTEM AND USER events and reset the event stack for the next frame.  

    So Inside FlexiUpdate function, the library is dynamically calling the users event handler.    A small change, but one that'll help clean up the handling and encourage people to more away from single scope programs to a more function based design.  


   Another new feature is the ability to create a window and nominate the type of the image buffer this window will use.  By default the library creates images in Video memory, but now we can force them to be FX or AFX even (untested !).  If you create an FX Window then any gadgets will inherit this state also.  Which means you can use a micture of surface types.   Useful if you need to do blending in a window.


   Bellow is one of the examples from the Flexi Example pack.. It shows some of the new design features.  I'm tempted to the expand the FlexiUPDATE() function a little more.   For example, you could just pass the function the name of the your handler, as well as some parameters to tell it to render the scene also.    I know this might sound tempting to some people to make that how it works, but forcing such behavior would make programming other interactions with the gui scene awkward..  Like drawing your own stuff in side the scene.

PlayBASIC Code: [Select]
; *=-----------------------------------------------------------------=*
;
; >> Flexi (GUI) Example #6 <<
;
; By Kevin Picone
;
; (c) copyright 2010 by Kevin Picone, All Rights Reserved
;
; *=-----------------------------------------------------------------=*
; www.underwaredesign.com - www.PlayBasic.com
; *=-----------------------------------------------------------------=*
;
; In this example we're going to add the task bar to the previously demo.
; The task bar is basically a docking bar for minimized windows. Normally
; if we minimize a window, the window is no longer drawn. SO it's hidden,
; except when task bar is active. Now when we minimize the the window will
; auto dock on the bar. You to restore the window by clicking it's name
; on the task bar.
;
; If you run the example you'll see the task bar across the bottom of the
; screen. If you click a minimize gadget on a window, it's NAME will appear
; on the bar.
;
; *=-----------------------------------------------------------------=*

; ---------------------------------------
; Include the GUI library in our program
; ---------------------------------------
#include "FlexiGUI"


; ---------------------------------------
; Create & Set up our window.
; ---------------------------------------

; create the task bar window. This window will hold minized
; windows for use.
TaskBarWindow=FlexiCreateTaskBar()


; create an array that'll hold our ten windows for this example
Dim Windows(10)

For lp=1 to 10

; create a window that's a random width and height
Width=RndRange(100,500)
Height=RndRange(100,500)
Title$="I'm Window #"+Str$(lp)
ThisWindow = FlexiCreateWindow(Width,Height,title$)


; Set the position of this window to random location on screen
Xpos=RndRange(0,GetScreenWidth()-width)
Ypos=RndRange(0,GetScreenHeight()-Height)
FlexiPosition(ThisWindow,Xpos,Ypos)


; Tell flexi to open the window. This initializes the window
; (and any attached gadgets) for drawing.
FlexiOpen(ThisWindow)

; Store the Handle of the thisWindow in our Windows array
; so we can remember them later on.
Windows(lp)=ThisWindow

next

; tell Flexi What function to call when it see's
; a user event during FlexiUpdate() function
FlexiSetUserEventhandler "User_Event_Handler"

; ---------------------------------------
; Program Main Display Loop
; ---------------------------------------

setfps 60


Do

; Clear the screen to the default colour black (rgb(0,0,0))
cls

; Call the FlexuUpdate to get user input, process SYSTEM and USER
; events.
FlexiUpdate()


; redirect all rendering back to the screen
rendertoscreen

; Call the Flexi Render Function to draw the GUI windows
FlexiRender()


; Call sync to show the drawn screen to the user
Sync

loop esckey()=true


; Tell PlayBASIC To END
end




Function User_Event_Handler(EventIndex)


; Read what GUI Object this event came from
ThisObject=FlexiEvents(EventIndex).ThisObject


; Read the type of event
Select FlexiEvents(EventIndex).EventType

; Catch the various USER events. A user event is an
; event the GUI expects the USER to take care of.

; -------------------------------------
case FlexEvent_UserOpenWindow
; -------------------------------------
; Run through and find what Window posted this event
; When we find it, we call the DRaw_Main_Window() function.
; this will initialize the windows graphics content for us.
; So the windows will all have the shade box with the
; HELLO WORLD in the center of them.
For lp=1 to Getarrayelements(Windows())
if ThisObject=Windows(lp)
Draw_Main_window(ThisObject)
endif
next

; -------------------------------------
case FlexEvent_UserCloseWindow
; -------------------------------------
; The user Clicked the CLOSE Gadget, so here we'll remove
; this Window Handle from our Windows() array.
For lp=1 to Getarrayelements(Windows())
if ThisObject=Windows(lp)
; remove this flexi window
FlexiDelete ThisObject
; delete this cell within the array
Windows(lp)=0
endif
next
Login required to view complete source code


   

 PlayBASIC V1.64M  Beta #14 -  FlexiGUI Window Alpha Level

   The attached picture show Window Alpha control, which is by product of the ability of creating FX windows.  So we create FX surface, then draw the Gui onto it.. hey presto alpha.

   See Alpha Windows Demo on youtube.

 





kevin

#23
  PlayBASIC V1.64M  Beta #14 - FlexiGUI Possible Event Attachments ?

     One of the big features additions to PB in the last year, has been the ability to call functions/psubs dynamically.  This is one of those features that is used to overcome very specific problems.    A common one occurs where we have to write  dispatch style routines, where the code is working out what function to call from a hard code list of options.    If such a problem occurs, you could use CallFunction to look up the function to call and then just react to it.   the interesting thing about this version of the dispatch routine is that we don't really have to update it when we add more possible options, like we would if using a Select/Case state or if/thens

    I mention this, as when programming a GUI based application, a lot of the code goes into working out what GUI element the user interacted with and then calling our reaction code.   Now some high level languages address this for the user, but they're often specifically built to hide this process away from the programmer.  So it's building it's own dispatch routines underneath.  Where we have a routine that gets the event and calls the handler for us.   We can't really do this is PB today, but we could do something similar.  By setting up some way of attaching the reaction code, during the creation process.  

    Imagine if you create a window,  then Flexi places the UserCreateWindow event on the event stack.  We can then react to it this event during our event processing loop.  But what if we could do attach some generic handlers to the window when  creating it.   Which could look something like this.

  (Sample Only)

PlayBASIC Code: [Select]
     MyWindow=FlexiCreateWindow(width,height,title$)

Event$ ="CreateWindow=FunctionToHandleThis"
Event$ ="ONLick=FunctionToHandleThis"
Event$ ="ResizeWindow=FunctionToHandleThis"
Event$ ="Redraw=FunctionToHandleThis"

MyWindow=FlexiAttachEventHandlers(MyWindow,Event$)




 
  The idea being that we could setup what functions (if any) FLEXI calls when a certain event is processed.     Now, we're not really saving ourselves much code here.  We're opening up the door making the program code more generic.   So we can drop in new functionality and not have to maintain the overall event processing ourselves.    Although, I suspect there would be times where that would be favorable.    But we'll see how it goes..



 PlayBASIC V1.64M  Beta #14 - FlexiGUI Now Supports Attachable Event Handler
   
     Well, in a few hours this idea has gone from one of those "wouldn't it be nice things" to brand new feature of the FlexiGUI library.    As suggested above, the library lets users attach their own event handler functions to FlexiGUI  WINDOWS or GADGETS.    This is done in two ways, you can either attach each and every handler individually (using a function called FlexiAddEventHandler() ) or you can prepare a string with the event name and the function names they each call in them.     The latter is probably the easier of the two.  The event names are the same as the event constants.  Without the 'FlexEvent_User' part.    

      Here's what the event attachment part looks like when you build the event list string and attach it to a window.  

PlayBASIC Code: [Select]
               ; Create the Event Handler string, this string is parsed by
; flexi. The string contains the event name and the function
; that should be called when that user event occurs.

Event$ ="OpenWindow & Resize & Maximize =Draw_Window_EventHandler,"
Event$ +="CloseWindow =Delete_Window_EventHandler"

FlexiParseEventHandlerList(ThisWindow,Event$)






   This bit of code traps 4 different events from this window.  Those being OpenWindow, Resize, Maximize and CloseWindow.   The first three event all trigger the same handler function, which is the Draw_Window_EventHandler.   You provide this function for the purpose of drawing the window.   The other event is CloseWIndow, that one calls the Delete_Window_EventHandler function.   So when the user clicks [ X ] button,  Flexi calls  your deleter during the next event update loop.    All of which occurs virtually transparently to the user.  

    Here's the revised version of the Example #6 (compare older version in previous post).   The new version is certainly shorter and hopefully a bit easier for new comers to get up and running.  


PlayBASIC Code: [Select]
; *=-----------------------------------------------------------------=*
;
; >> Flexi (GUI) Example #6 (Event Handler Version) <<
;
; By Kevin Picone
;
; (c) copyright 2010 by Kevin Picone, All Rights Reserved
;
; *=-----------------------------------------------------------------=*
; www.underwaredesign.com - www.PlayBasic.com
; *=-----------------------------------------------------------------=*
;
; In this example we're going to add the task bar to the previously demo.
; The task bar is basically a docking bar for minimized windows. Normally
; if we minimize a window, the window is no longer drawn. SO it's hidden,
; except when task bar is active. Now when we minimize, the window will
; auto dock on the bar. You can restore the window by clicking it's name
; on the task bar.
;
; If you run the example you'll see the task bar across the bottom of the
; screen. If you click a minimize gadget on a window, it's NAME will appear
; on the bar.
;
; *=-----------------------------------------------------------------=*

; ---------------------------------------
; Include the GUI library in our program
; ---------------------------------------
#include "FlexiGUI"


; ---------------------------------------
; Create & Set up our window.
; ---------------------------------------

; create the task bar window. This window will hold minized
; windows for use.
TaskBarWindow=FlexiCreateTaskBar()


; create an array that'll hold our ten windows for this example
Dim Windows(10)

For lp=1 to 10

; create a window that's a random width and height
Width=RndRange(100,500)
Height=RndRange(100,500)
Title$="I'm Window #"+Str$(lp)
ThisWindow = FlexiCreateWindow(Width,Height,title$)


; Set the position of this window to random location on screen
Xpos=RndRange(0,GetScreenWidth()-width)
Ypos=RndRange(0,GetScreenHeight()-Height)
FlexiPosition(ThisWindow,Xpos,Ypos)


; Tell flexi to open the window. This initializes the window
; (and any attached gadgets) for drawing.
FlexiOpen(ThisWindow)

; Store the Handle of the thisWindow in our Windows array
; so we can remember them later on.
Windows(lp)=ThisWindow

; Create the Event Handler string, this string is parsed by
; flexi. The string contains the event name and the function
; that should be called when that user event occurs.

Event$ ="OpenWindow&Resize& Maximize =Draw_Window_EventHandler,"
Event$ +="CloseWindow =Delete_Window_EventHandler"

FlexiParseEventHandlerList(ThisWindow,Event$)

next


; ---------------------------------------
; Program Main Display Loop
; ---------------------------------------

setfps 60


Do

; Clear the screen to the default colour black (rgb(0,0,0))
cls

; Call the FlexuUpdate. This function collects user and
; processed SYSTEM and USER events.
FlexiUpdate()

; redirect all rendering back to the screen
rendertoscreen

; Call the Flexi Render Function to draw the GUI windows
FlexiRender()

; Call sync to show the drawn screen to the user
Sync

loop esckey()=true

; Tell PlayBASIC To END
end



Function Delete_Window_EventHandler(ThisWIndow,EventIndex)

; The user Clicked the CLOSE Gadget, so here we'll remove
; this Window Handle from our Windows() array.
For lp=1 to Getarrayelements(Windows())

if ThisWindow=Windows(lp)
; remove this flexi window
FlexiDelete ThisWindow
; delete this cell within the array
Windows(lp)=0
endif
next

EndFunction


Function Draw_Window_EventHAndler(ThisWindow,EventIndex)

; Redirect All Rendering to this WINDOW
flexirenderto ThisWindow

; Get the Size of the render area of this window
x1,y1,x2,y2=FlexiGetViewport(ThisWindow)

Width=x2-x1
Height=y2-y1

; clear it to a RED/PurPle colour
c1=rgb(200,0,100)
c2=rgb(50,20,60)
shadebox x1,y1,x2,y2,c1,c1,c2,c2

; Set the ink colour. You never know what it was before
; this function was called
ink argb(255,255,255,255)

; draw the message on it
Login required to view complete source code


  Attached is piccy of the example running.  As you can see, it gives a simple scene made up of a group of unique windows.




 
 

kevin

#24
  PlayBASIC V1.64M  Beta #14 - Screen Support for  FlexiGUI


    Up till now Flexi has supported two basic types of elements,  WINDOWS and GADGETS.   Each element has various types.    However, the original source includes the start of (but not fleshed out) support for a third type called a screen.  If memory serves me correctly this was to represent the PB screen within the GUI environment.   Clearly it was deemed as future since it's wasn't implemented.   After playing the library a bit over the past week, there's certainly need for such a control.

    What the SCREEN does is it lets us create a window that presents the PB display screen.  The main advantage of this is that we can now react to user clicks & key strokes upon the screen surface.  For example, if you wanted to draw on to the screen with the mouse, then previously you'd have to work out if the mouse is over a Flexi window, is it dragging a window ?  etc etc.   No longer, now we just create the Screen window and the  attach the message handlers to react to user clicks.   So the GUI does the work for us.

    In this example i've add the screen window to the existing example.  The screen reacts to the click events, so when a click occurs, FlexiUpdate calls our Mouse Click function.   Which in this cases draw a randomly coloured circle upon the Screen window.  

PlayBASIC Code: [Select]
; *=-----------------------------------------------------------------=*
;
; >> Flexi (GUI) Example #6 (Event Handler Version) <<
;
; By Kevin Picone
;
; (c) copyright 2010 by Kevin Picone, All Rights Reserved
;
; *=-----------------------------------------------------------------=*
; www.underwaredesign.com - www.PlayBasic.com
; *=-----------------------------------------------------------------=*
;
; In this example we're going to add the task bar to the previously demo.
; The task bar is basically a docking bar for minimized windows. Normally
; if we minimize a window, the window is no longer drawn. SO it's hidden,
; except when task bar is active. Now when we minimize, the window will
; auto dock on the bar. You can restore the window by clicking it's name
; on the task bar.
;
; If you run the example you'll see the task bar across the bottom of the
; screen. If you click a minimize gadget on a window, it's NAME will appear
; on the bar.
;
; *=-----------------------------------------------------------------=*

; ---------------------------------------
; Include the GUI library in our program
; ---------------------------------------
#include "FlexiGUI"


; ---------------------------------------
; Create & Set up our window.
; ---------------------------------------

; create the task bar window. This window will hold minimized
; windows for us.
TaskBarWindow=FlexiCreateTaskBar()

; create an array that'll hold our ten windows for this example
Dim Windows(10)

For lp=1 to 10
New_window()
next


Screen=FlexiCreateScreen()
FlexiOpen(Screen)
Event$ ="Mouseclick=ClickScreen"
FlexiParseEventHandlerList(Screen,Event$)


; ---------------------------------------
; Program Main Display Loop
; ---------------------------------------

setfps 60


Do

; Clear the screen to the default colour black (rgb(0,0,0))
; cls

; Call the FlexuUpdate. This function collects user input then
; processes SYSTEM and USER events.
FlexiUpdate()

; redirect all rendering back to the screen
rendertoscreen

; Call the Flexi Render Function to draw the GUI windows
FlexiRender()

; Call sync to show the drawn screen to the user
Sync

loop esckey()=true

; Tell PlayBASIC To END
end





Function Delete_Window_EventHandler(ThisWIndow,EventIndex)

; The user Clicked the CLOSE Gadget, so here we'll remove
; this Window Handle from our Windows() array.
For lp=1 to Getarrayelements(Windows())

if ThisWindow=Windows(lp)

New_window()

; remove this flexi window
FlexiDelete ThisWindow

; delete this cell within the array
Windows(lp)=0
endif
next

EndFunction


Function Draw_Window_EventHAndler(ThisWindow,EventIndex)

; Redirect All Rendering to this WINDOW
flexirenderto ThisWindow

; Get the Size of the render area of this window
x1,y1,x2,y2=FlexiGetViewport(ThisWindow)

Width=x2-x1
Height=y2-y1

; clear it to a RED/PurPle colour
c1=rgb(200,0,100)
c2=rgb(50,20,60)
shadebox x1,y1,x2,y2,c1,c1,c2,c2

; Set the ink colour. You never know what it was before
; this function was called
ink argb(255,255,255,255)

; draw the message on it
centertext Width/2,Height/2, "HELLO WORLD"
EndFunction



Function New_window()

; Find a free position with this array
Index=getfreecell(Windows())

; create a window that's a random width and height
Width=RndRange(100,500)
Height=RndRange(100,500)
Title$="I'm Window #"+Str$(Index)
ThisWindow = FlexiCreateWindow(Width,Height,title$)


; Set the position of this window to random location on screen
Login required to view complete source code




   

kevin

#25
   PlayBASIC V1.64M  Beta #16 - Download

    The latest beta of the V1.64M upgrade is on the server and ready for testing..  
       

 Download

   deleted

kevin


  PlayBASIC V1.64M  Beta #17 - Build Process Hiccups

     With most of the recent headaches seemingly out of the way for the time being,  my focus is shifting back to V1.64M.   First port of call is to update the runtime build process. Unfortunately the cascading issues a few months back, have meant that the runtime builder is now incapable of creating working runtimes. 

    So  this morning i've been working my way through the issues,  which is a slow and tedious process.  Some progress is being made though, as the current version now boots without crashing (always a plus) , but it halts soon after with inexplicable fault.   Which just means more good old fashion tracing to find it...  I do feel like the back of the problem has been broken though, and can't imagine this persisting beyond tomorrow.   But you never know :)


kevin


    PlayBASIC V1.64M  Beta #18 - Running Runtimes Again

           Took a bit longer than i'd hoped but the Vm builder can once again build the working runtimes.  Most of the issues were fairly easy to pickup, but the main problem turned out to the be a situational issue with the replacement string library function.    Which would stop t5he built runtime dead in it's tracks.   But both version are now up an running again. So we work towards a release build (the actual upgrade version).  However I feel it's probably best to beta this prior to that.  Since making such low level changes tends to stir up sediment on the bottom of the pond, making app's that would once build correctly, potentially  fail.



kevin

#28
     PlayBASIC V1.64M  Beta #18 - Beta

        This version includes newly built Compiler and Runtimes for BETA TESTING...   I HIGHLY RECOMMEND  trying your project in this edition, not just from the ide / runtime but from a built EXE.


       Download
   
        deleted  



kevin


  PlayBASIC V1.64M  Beta #19 - Booter Problems
   
     Back working away on the V1.64M upgrade after noticing a few issues with the beta 18's boot process, which is basically none existent.   Currently i'm just testing beta #19 across the machines here with the slightly tweaked version of the Word Zap game (two birds, 1 stone), and it all seems to be working as expected, so hopefully that's one stumbling block out of the way.    Should be able to get back to the final push to the final of the V1.64M upgrade pretty soon.