BlitzBASIC 2 PlayBASIC - Source Code Conversion WIP

[kevin]

BlitzBASIC 2 PlayBASIC - Source Code Conversion WIP



Releases


       Download Blitz 2 PlayBASIC V1.00 (8th May 2022)





Blog

Objective:

  Howdy, somehow you've found your way here at another development blog.   The goals of this project are to create a tool (in PlayBASIC) that does source level conversions of Blitz BASIC (for Windows)  source code to PlayBASIC.

  My ambitions for this project are pretty humble and as such you should temper any expectations for the quality of the output code being produced.     The conversion will be most syntax level adjustments, some direct command set mapping, but commands are expected to be emulated via wrapper.    




 
  Porting BlitzBASIC 2 PlayBASIC - First Look - (2022-02-20)


  During the process of porting XLnt GUI episode #8,  I talked a lot about the repetitive processes of code conversion.   In the context of our XLnt GUI conversion there's a bunch of common changes we're making that could better done with a tool.

 So here's our first look a our tool to convert BlitzBASIC to PLayBASIC..

 

 Script:

 -- Script On PasteBin

[kevin]

BlitzBASIC 2 PlayBASIC Conversion Tool WIP - Episode# 02

   This is the second look in our attempts to write a tool that can handle most syntax level conversion of Blitz BASIC code and convert it in to PlayBASIC syntax.

   Remapping common Blitz BASIC string functions for PlayBASIC


 

[kevin]

 BlitzBASIC 2 PlayBASIC Conversion:   Parsing Blitz Basic Types  - 24th feb 2022

  Been parsing BLITZ types this arvo and have even learned thing or two about blitz syntax Namely that it supports static typed arrays as fields within types. Didn't know that :)

 Currently my parser supports Integer / floats / strings in both variable and array form, but not nested types as yet. That's not to say it can remap the usages as they appear within the code, just that it understands the type well enough to get fields and data types that we want prior to parsing the code.

Example:

Code Select Expand


type Vector3
field x#,y#,z#
end type



Type cool
  Field a1,b1#,c1$ ` rem this is rem

` another rem on another line
  field IntArray[10000]
  field FltArray#[10000],StringArray$[10000],zzzzz
  field ccccc,AnotherIntArray[100]

  Field a2#[100],b2#[200],c3$[300*100]
  Field a,b,c

field pos.vector3

End Type




   Session #2


      So the decoder is now understanding the various valid syntaxes for Types in Blitz, or at least the ones I know.    The code bellow is a mash up of the field variations, with the code  bellow that being the is the PB conversion and the table of how the translated keeps this data.

Code Select Expand


type Vector3
field x#,y#,z#
end type



Type cool
  Field a1,b1#,c1$ ` rem this is rem

` another rem on another line
  field IntArray[10000]
  field FltArray#[10000],StringArray$[10000],zzzzz
  field ccccc,AnotherIntArray[100]

  Field a2#[100],b2#[200],c3$[300*100]
  Field a,b,c

field pos.vector3
field pos2.vector3 , pos3.vector3

field pos4.vector3[123]
field pos5.vector3[234],pos6.vector3[666],xyz

End Type




     Here's the PlayBASIC version of this TYPE.   Mind you this doesn't compile in PB as there's some syntax that PB doesn't like, but for simpler TYPES it's basically working.

PlayBASIC Code: [Select]

         Type Vector3
             x#,y#,z#
         EndType



      Type cool
          a1,b1#,c1$ ` rem this is rem

` another rem on another line
          IntArray(10000)
          FltArray#(10000),StringArray$(10000),zzzzz
          ccccc,AnotherIntArray(100)

          a2#(100),b2#(200),c3$(300*100) 
          a,b,c 
      
          pos.vector3
          pos2.vector3 , pos3.vector3
      
          pos4.vector3(123)
          pos5.vector3(234),pos6.vector3(666),xyz

      EndType
      

Code Select Expand


 Parsed Structures

TYPE Vector3

Src Position:6 - 23

#00  x---------------  Type:2 Src POS:13
#01  y---------------  Type:2 Src POS:16
#02  z---------------  Type:2 Src POS:19

EndTYPE


TYPE cool

Src Position:31 - 176

#000  a1--------------  Type:1 Src POS:38
#001  b1--------------  Type:2 Src POS:40
#002  c1--------------  Type:4 Src POS:43
#003  IntArray--------  Type:257 Src POS:54  [ 55 - 57 ]
#004  FltArray--------  Type:258 Src POS:62  [ 64 - 66 ]
#005  StringArray-----  Type:260 Src POS:68  [ 70 - 72 ]
#006  zzzzz-----------  Type:1 Src POS:74
#007  ccccc-----------  Type:1 Src POS:79
#008  AnotherIntArray-  Type:257 Src POS:81  [ 82 - 84 ]
#009  a2--------------  Type:258 Src POS:90  [ 92 - 94 ]
#010  b2--------------  Type:258 Src POS:96  [ 98 - 100 ]
#011  c3--------------  Type:260 Src POS:102  [ 104 - 108 ]
#012  a---------------  Type:1 Src POS:114
#013  b---------------  Type:1 Src POS:116
#014  c---------------  Type:1 Src POS:118
#015  pos------------- of vector3  Type:8 Src POS:126  UDT POS:128
#016  pos2------------ of vector3  Type:8 Src POS:133  UDT POS:135
#017  pos3------------ of vector3  Type:8 Src POS:139  UDT POS:141
#018  pos4------------ of vector3  Type:264 Src POS:148  UDT POS:150  [ 151 - 153 ]
#019  pos5------------ of vector3  Type:264 Src POS:158  UDT POS:160  [ 161 - 163 ]
#020  pos6------------ of vector3  Type:264 Src POS:165  UDT POS:167  [ 168 - 170 ]
#021  xyz-------------  Type:1 Src POS:172

EndTYPE




[kevin]

  BlitzBASIC 2 PlayBASIC Conversion:   Parsing Blitz Basic FUNCTIONS  - 25th feb 2022

   Today was about getting the parser to the pick and up start having some understanding of Function declarations.   It's early days, so we're just picking out where the declarations are and the name of the functions to start with.,  will look at deciphering the input and return parameter stuff over the weekend. 

   For now, here's a simpler example of what the conversion pass is doing for us.   Syntax wise we're got some issues with stacked arrays (declarations on one  line) within TYPE blocks,  as well as no support for Type variables   so those are passed straight for the time being.   But many other changes are being made for us,  it's not there yet though.   


   Input Code:

   

Code Select Expand




type Vector3
field x#,y#,z#
end type


Type cool
   Field a1,b1#,c1$ ;` rem this is rem

;` another rem on another Line
   Field IntArray[10000]
   Field FltArray#[10000],StringArray$[10000],zzzzz
   Field ccccc,AnotherIntArray[100]

   Field a2#[100],b2#[200],c3$[300*100]
   Field a,b,c



Field pos.vector3
Field pos_1d_array.vector3[10]
; Field pos_2d_array.vector3[10,20]    <- Blitz DOESN"T SUPPROT more than 1D arrays
; Field pos_3d_array.vector3[10,20,30] <- Blitz DOESN"T support this either .. yay
End Type







me.cool = New cool
me\a=125
me\b=200
me\c=333


Print me\a
Print me\b
Print me\c




s$="Yeah Cool"

Print Mid(s$,2)
Print Mid(s$,2)
Print Mid$(s$,2)
Print Mid$(s$,2)

Print Left(s$,4)
Print Left$(s$,4)
Print Right(s$,4)
Print Right$(s$,4)


    If a=1
Print "YEAH"
EndIf

    If a=1
Print "YEAH"
Else If a=3
Print "a=3"
Else
Print "Nah"
End If


Select a

Case 1
Print "A=1"
Default
Print "A<>1"
End Select


Const Cool1= 45
Const Cool2= 45
Const Cool3= 45
Const Cool4= 45


While A>0
A=A-1
Wend




function TestMyFunction(Param1,Param2,Param3$)


end function

function TestMyFunction2(Param1,Param2#,Param3$)

end function


   



   Output Code:

   

PlayBASIC Code: [Select]

         Type Vector3
             x#,y#,z#
         EndType


      Type cool
          a1,b1#,c1$ ;` rem this is rem

;` another rem on another Line
          IntArray(10000)
          FltArray#(10000),StringArray$(10000),zzzzz
          ccccc,AnotherIntArray(100)

          a2#(100),b2#(200),c3$(300*100) 
          a,b,c 
      
         
      
          pos.vector3      
          pos_1d_array.vector3(10)      
      ;   Field pos_2d_array.vector3[10,20]      <- Blitz DOESN"T SUPPROT more than 1D arrays
      ;   Field pos_3d_array.vector3[10,20,30]   <- Blitz DOESN"T support this either .. yay
      EndType
      




      

      me.cool = New cool
      me\a=125
      me\b=200
      me\c=333
      

      Print me\a
      Print me\b
      Print me\c
      
      


      s$="Yeah Cool"

      Print Mid$(s$,2)
      Print Mid$(s$,2)
      Print Mid$(s$,2)
      Print Mid$(s$,2)

      Print Left$(s$,4)
      Print Left$(s$,4)
      Print Right$(s$,4)
      Print Right$(s$,4)
      

       If a=1
      Print "YEAH"
      EndIf

       If a=1
      Print "YEAH"
   ElseIf a=3
      Print "a=3" 
   Else   
      Print "Nah"
   EndIf


      Select a
      
         Case 1
            Print "A=1"
         Default
            Print "A<>1"
      EndSelect
      

      Constant Cool1= 45      
      Constant Cool2= 45      
      Constant Cool3= 45      
      Constant Cool4= 45      


      While A>0
         A=A-1
      EndWhile




Function TestMyFunction(Param1,Param2,Param3$)


EndFunction

Function TestMyFunction2(Param1,Param2#,Param3$)

EndFunction


   

[kevin]

 BlitzBASIC 2 PlayBASIC Conversion:   Parsing Blitz Basic DIM statements - ARRAYS  - 28th feb 2022

  The last couple of sessions has been about trapping DIM / LOCAL / GLOBAL statements but mainly DIM statements first.    Here's a bit of a look at the conversion progress,  so far we can catch and remap various types of DIM statements and output them in a more PlayBASIC friendly fashion.   What it can't do yet is understand arrays() that appear with expressions.   But first we need to find their declarations, then we'll worry about catching their usages through the code..  

   

 

  Input Code:

 

Code Select Expand



Type MY_TYPE
Field x#,y#,z#
End Type

Type MY_TYPE2
Field x#,y#,z#
End Type



Dim iTable1d(100)
Dim iTable2d(100,200)
Dim iTable3d(100,200,300)


Dim iTable1d%(100)
Dim iTable2d%(100,200)
Dim iTable3d%(100,200,300)

Dim fTable1d#(100)
Dim fTable2d#(100,200)
Dim fTable3d#(100,200,300)

Dim sTable1d$(100)
Dim sTable2d$(100,200)
Dim sTable3d$(100,200,300)

; Arrays are global by default
;  Stacked DIMS on one line
Dim Array1(100), Array2(200)

;  Dim Typed Array
Dim Array3.MY_TYPE(100) ,  Array4.MY_TYPE(400)

;  Dim Typed Array
Dim Array5.MY_TYPE( iTable1d(100)+ 100) ,  Array6.MY_TYPE( Val(sTable1d$(100))+400)








  Output Code:

 

PlayBASIC Code: [Select]

   Type MY_TYPE
          x#,y#,z#
   EndType
   
   Type MY_TYPE2
          x#,y#,z#
   EndType
   
   
   
   Dim iTable1d(100)
   Dim iTable2d(100,200)
   Dim iTable3d(100,200,300)


   Dim iTable1d(100)
   Dim iTable2d(100,200)
   Dim iTable3d(100,200,300)

   Dim fTable1d#(100)
   Dim fTable2d#(100,200)
   Dim fTable3d#(100,200,300)

   Dim sTable1d$(100)
   Dim sTable2d$(100,200)
   Dim sTable3d$(100,200,300)

   ; Arrays are global by default
   ;  Stacked DIMS on one line
   Dim Array1(100):DIM Array2(200)
   
   ;  Dim Typed Array
   Dim Array3(100) as MY_TYPE :DIM  Array4(400) as MY_TYPE

   ;  Dim Typed Array
   Dim Array5( iTable1d(100)+ 100) as MY_TYPE :DIM  Array6( Val(sTable1d$(100))+400) as MY_TYPE

   

   Video Script:
   

Code Select Expand


hello welcome back we're outside again

so it's a bit noisy um

it's a beautiful day so i'm outside

that's why i'm recording outside as well

just easier for me

where are we with blitz basic to play

basic well we've been working on the

dimensioning support here in magpie in

the background

so i'll give it a

run debug mode

so

information is a bit different than i

was before but not much all that

interesting

this is our resulting code

so i'll sort of pick through this

well actually i'll pick through the

original code and we'll go through what

the converter supports

but that actually does compile now in

play basic

here's the original blitz code

so in blitz

our main changes are going to be we

the field

keyword here is obsolete so we don't

need that

and we

we have an n-type keyword rather than

end-end type keywords so those changes

have been made for us

the dimension statements are basically

the same there's nothing different about

those

well there is but we'll get to that in a

second

in blitz we also have a thing

an integer

postfix

which is the percent symbol

so in pv we don't have that so we have

to remove those

which is what we do in our translation

floats the same strings the same now

blitz has a support for stacked arrays

and i thought i added this

well

this came up during the amos conversion

stuff because amos supports the same

thing

but haven't and you can also do it with

typed arrays notice the different syntax

here

this inverted syntax

and here i'm just testing whether you

can have complex expressions inside the

dimension statement

for the

field size

if i just grab these couple lines here

which the ones we want to look at really

the rest of it's all pretty much for

matches

we go to the translated

one which is

this is the one yeah

so you can see what the converter's done

is it's looked at this

first line i'll put the original lines

beside them

so this was the input line sorry

this was the original input line

this one was the

other original input line

the one at the bottom there was the

other one as well

let's comment them out

so

in the first case we've got a stack

dimension

a stacked array dimension we've got uh

array one integer type and then we've

got a second dimension on the same line

to do that in pb we've got to substitute

this comma with a dim colon

so we keep the things on the same line

but we're inserting the statement um

to allow us to phrase this and act the

same

when we have a type we've got a

rearranged expression

so

when we find this this declaration here

we're going okay array three all right

cool

as of of this type

and we've got these brackets here so we

need to rearrange these back into here

and replace our dot syntax with as

which is what pv accepts and because

they can be stacked we need to do the

same thing through here

and the last one has an expression

inside those things to show that we can

we can unlink these tokens

from in here

more sort of complicate sorry a more

complex expression

and move them back without damaging it

i hope not anyway um

let's try and run this one here and

debug

without getting output because there's

just nothing it's doing but we can see

what a race we have an array one which

is our integer array array two is fine

typed array

[Music]

yeah

we're getting now our arcade types

because the array has been declared but

the individual types within it are not

created until we actually

do a new of them

our flight array looks good and our

integer arrays look good as well so it's

all

working

so i've been doing this smaller subset

testing

to these larger ones i haven't tried the

bigger source code for for a few days

actually

this won't produce anything that's

useful like at the moment

uh

our converter is catching these

dimension statements and phrasing out

what arrays we need

are within them but it's not storing

this in in a list

we need that because as we go through

the code

like these are the declarations but when

something's been used like we go print

um

was it a rate one or something uh l5

position five or something

plus uh i think it was

i used i in front of

10 let's say let's say

um

at the moment when it's phrasing through

and it'll pick up these statements but

won't understand what these keywords are

so

if it's an integer array like that

no dramas it'll get spelled out the same

way it went in

because there's no translation required

but if that's obviously uh

one of these float arrays for example

or the inter ray up here that was

declared with the

oh it's been removed in this example

with a symbol added to it

and that keeps popping up later on in

the code we'd have to remove those

during our translation so we have to

skim through find this keyword and go

all right what's this word mean

look it up within our current scope

which is what we also need to do is keep

track of

are these arrays global are they local

so we sort of have to do that

and once we do that we should be able to

get a pretty good

you know not a great translation well

i think i think pretty good is about the

best we hope for

it'll be better than doing replacements

but it won't

give you

full out working code

out of the blocks

you'll find some expressions that white

that it won't understand or

or that i've not considered

it just has no clue about what to do

with them

you know to make this line here pb

compatible would have to remove these

percentage symbols

uh

or as we're saying before if if you go

dim you know

my strings

maybe a size 100 of them or whatever

in blitz you you don't have to use that

the perfect symbol so it's not baked

into the name

with pva it kind of is baked into the

name so we

it's okay to do stuff like this

in blitz

you know run through and grab

print out all the strings or whatever

you want to do

when we look through this to convert it

we'd have to

look for my string

check is my string declared within our

current scope if it is

then we look at the symbol

following that and we go okay

this was originally declared as a string

array and we're not using the string so

we better output this to make it

compatible with pba otherwise people

would just assume that that was

and we'll just assume this is an integer

version of that array

which is going to cause problems

but hopefully if we can catch

that kind of stuff

catch a lot a lot of the tight film

you know the um backslash stuff and

types won't work out of the box but

we'll get

a lot of the clunky syntax stuff work

and hopefully you get these variable and

array problems solved and that'll

actually go a long way

to you having a working program

when i started this the other day i

thought well if we get to a point where

it can solve you know

50 of your problems

that's pretty good because on these

large co-bases that's hours and hours of

work

and for some programs if they don't use

things outside of what it what

understands how to solve that'll be fine

they'll you better pace them in convert

them and

get something that's probably 90

ready to run

um

that's what we are at the moment anyway

we'll just give it a go that uh the

longest source code

to see how long it takes should be a lot

slower now

should be um

this is the gy code

just wrote

not in debug but right straight out

well a fair bit slower so phrase times 3

325 and the convert times about half a

second so we're almost at a second to do

a pretty full-on

uh

we're not fully compiling the code

obviously we're kind of picking through

and looking for things that we're

interested in and then when we find them

we're replacing those things

all right again to see if we're under

stress doing that

yeah i

thought as much

so about half a second to to load it and

tokenize it and output it

that's pretty acceptable for a 9000 line

9000 lines of code

87 000 tokens to run through

in just

pv

now that's not going to produce working

code

it will take ages we'll try and debug

mode but i've got a lot of debug dumps

at the moment so we might get stuck here

for a little while

um

so it took a lot longer because we've

got a lot more stuff being spat out to

the console

uh every time it finds a variable what

it thinks is a variable it's going to

speed up this little message

because also doing

it's a very preliminary version of

detecting variables but it's not

remembering them at the moment

so just look at the start of that

function we'll just see if we we've done

some

replacements of that

well there you go

so we've actually made a working

replacement this is the menus gy that

was

uh it was in

now we've converted something that's

compiles and will run straight out of

the box in play basic

those five lines there have been

converted perfectly

these lines here won't be that's our

next port of call with arrays is to

catch these

situations here and then

rearrange the expression suitably

[Music]

we might have to put warnings on some of

those there too

like if we know something's not gonna

not not being converted

uh correctly then we should warn you

know the end user that hey this line's

broken come and fix it

um

we've got some chicken before the egg

stuff here as well we've got

arrays with the typed been declared

before the types have been defined

you can do that in blitz you can't do

that in play basics that that code won't

build anyone

but syntactically we're closer

to something that's um

that will work

we haven't even started you know once we

get

and we get variables done means that

programs that just use arrays and

variables will will port

with a high degree of certainty

but we have to have you know emulations

of bullets functions so

this uh

well in our gy example

we've got this wrapping code where is

the code going there is

sorry

this thing called blitzwrapper which is

a list of just functions i'm emulating

uh in play basic code they do what blitz

does

sometimes they're just namesake wrappers

like that one there

we could substitute this for that and

life would go on straight away

these won't be so i know blitz has

different ideas about how images work

but for the most part we'll be able to

build a build a wrapper of these

commonplace functions and

commonplace

stuff will work straight out of the box

well

has a high degree of

possibility of working

it's the best we can hope for

all right thanks for listening to this

and thanks sorry for all the the car

noise in the background

uh i'll catch you next time bye


   

    --  Script on Paste Bin

[kevin]

 BlitzBASIC 2 PlayBASIC Conversion:   Parsing Blitz Basic DIM statements - ARRAYS  - 28th feb 2022

 This is the 4th look at writing a tool that can handle most syntax level conversions of Blitz BASIC code and convert it in to PlayBASIC syntax.

   In this episode we cover recent works that handle variable/array (keyword really) level scope  detection and type matching in the output.   This means the translation can detect variables and arrays and export them with the correct type symbols.  

  EG.   Blitz BASIC

    Dim MyString$(100)
    For lp% =0 to 100
        MyString(lp) = "Hello World"
    next

 Exported PlayBASIC

    Dim MyString$(100)
    For lp =0 to 100
        MyString$(lp) = "Hello World"
    next

   Simple yes, but these are important changes for the conversion to not only compile, but functoin the same in PlayBASIC

    Check the development blog for more interesting examples


 

  Input Code:


 

Code Select Expand




Type POS
Field x#,y#
End Type

Global iVar2,fVar2#,sVar2$
Global MyList2.Pos
global GUI_SCREENW = 800



Local iVar,fVar#,sVar$
; Local MyList.Pos



; Type

; Dim iTable(1)
; Dim fTable#(1)
; Dim sTable$(1)
; Dim Aliens.pos(10)



Function MY_Function1()

local MyFloat#,myString$

for lp% = 1 to 100
a%=lp*100
b%=a
c=a+b

This$=MyString +"aaasss"
print myFloat * a / c
next

Dim Strings$(100)
for lp =0 to 100
print Strings(lp)
next


print GUI_SCREENW

End Function



Function MY_Function2()

local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,Pi#
width=800 : Pi = 3.14159
cx = width / 2
ax = cx: ay = 50    ' apex
ex = cx: ey = 330   ' ellipse
xr = cx * 0.7 : yr = 0.33 * xr
do
cls
   x1 = ex + xr * Cos(a)            : y1 = ey + yr * Sin(a)
   x2 = ex + xr * Cos(a + Pi * 0.5) : y2 = ey + yr * Sin(a + Pi * 0.5)
    x3 = ex + xr * Cos(a + Pi)       : y3 = ey + yr * Sin(a + Pi)
    x4 = ex + xr * Cos(a + Pi * 1.5) : y4 = ey + yr * Sin(a + Pi * 1.5)
    fcolor 220,200,100
    line x1, y1, x2, y2
    line x2, y2, x3, y3
    line x3, y3, x4, y4
    line x4, y4, x1, y1
   line x1, y1, ax, ay
   line x2, y2, ax, ay
   line x3, y3, ax, ay
   line x4, y4, ax, ay
   a = a + 0.01    ; use 0.01 if is slow
   swap
loop


End Function


 

   Output Code:

 

PlayBASIC Code: [Select]

      Type POS
             x#,y#
      EndType

      Global iVar2,fVar2#,sVar2$
      Global MyList2.Pos   
      Global GUI_SCREENW   = 800



      Local iVar,fVar#,sVar$
;     Local MyList.Pos  



      ; Type 

;     Dim iTable(1)
;     Dim fTable#(1)
;     Dim sTable$(1)
;     Dim Aliens.pos(10)



Function MY_Function1()

      Local MyFloat#,myString$

      For lp = 1 To 100
         a=lp*100
         b=a
         c=a+b

         This$=MyString$ +"aaasss"   
         Print myFloat# * a / c   
      Next

      Dim Strings$(100)
      For lp =0 To 100
         Print Strings$(lp)
      Next         


      Print GUI_SCREENW

EndFunction



Function MY_Function2()

   Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
   Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,Pi#
width#=800 : Pi# = 3.14159
cx# = width# / 2
ax# = cx#: ay# = 50     apex
ex# = cx#: ey# = 330    ellipse
xr# = cx# * 0.7 : yr# = 0.33 * xr#
   do
      Cls 
       x1# = ex# + xr# * Cos(a#)            : y1# = ey# + yr# * Sin(a#)
       x2# = ex# + xr# * Cos(a# + Pi# * 0.5) : y2# = ey# + yr# * Sin(a# + Pi# * 0.5)
       x3# = ex# + xr# * Cos(a# + Pi#)       : y3# = ey# + yr# * Sin(a# + Pi#)
       x4# = ex# + xr# * Cos(a# + Pi# * 1.5) : y4# = ey# + yr# * Sin(a# + Pi# * 1.5)
       fcolor 220,200,100 
       Line x1#, y1#, x2#, y2#
       Line x2#, y2#, x3#, y3#
       Line x3#, y3#, x4#, y4#
       Line x4#, y4#, x1#, y1#
    Line x1#, y1#, ax#, ay#
    Line x2#, y2#, ax#, ay#
    Line x3#, y3#, ax#, ay#
    Line x4#, y4#, ax#, ay#
    a# = a# + 0.01    ; use 0.01 if is slow
    swap
   loop


EndFunction


   

   Video Script:
 

Code Select Expand


hello welcome back here we are looking

at another one of these blitz to play basic translation videos

so today i was working on the identification of variables uh

the implicit ones in particular

so it'll pick up dim statements it'll

pick up global and local statements

but also has to pick up

variables throughout the code

just pull up this

pretty rudimentary example so we've got

our global statements we can phrase

those

uh i don't think we've got list support

at the moment but i think we're picking

up the keyword

and just storing this for later

locals the same

we just want to raise as well but i'm

not working on those at the moment

just

been working on variables

so i've got global scope which is this

initial part of the program they'll be

all tagged as global scope

and

a function here

and we've got a

bit of code inside here we've got some

array stuff there we'll just pull it out

so we don't confuse ourselves


now things here to notice really are

our usages of our variables so i've got

local

declared here my float my string

my float has the hash symbol on it my

string

it's the first usage

so it has dollar sign at the end of it

and a loop here has

the integer

tag which is the percent symbol

input

but as we move through you'll notice

that uh

i've tagged a as an integer

i've used loop without its

postfix without

suffix b the same these are all used

without them

and down here we've got a string

and then we're using my string

without its

dollar sign

and same goes to float so previously i

was talking about wanting it to pick

these up

and do those translations for us and so

which is something you really can't just

do with like a replacement

things like the percent sign here

if you just pull in a bunch of code

into you know notepad or whatever just

and just do a raw replacement

that would probably get you a long way

to fixing those problems but um

you have a you'll have collisions as

well inside strings and comments etc but

but for the most part you wouldn't no

one would care

here's another bit of code which

actually dragged across from

from facebook just before

to demonstrate this in a broader

spectrum so we've got

in that language all variables were

inherently float

so here i've just added a local

statement with the variables in it

but left all of the occurrences

throughout the program

and without the

hash symbol on them

i've done that intentionally because i

want the converter to pick them up and

and do that work for us

so i'll just hit save on that and close

it

go back to here back to play basic now

this is an example we're loading and

running

running debug so we can see the output

you know in debug is taking 91

milliseconds

most that's just text airport to the

console

here's the function that's that's output

for this last piece here

just send that in a little bit

you can use the scroll function too with

text boxes


you'll notice that all of the variables

that follow

here

so after a declaration up here

the original code hand

was just width etc

all of these are now

read and read and run pretty much in pv

which is pretty good

that saves a lot of messing around

i won't say it's going to be perfect

there's probably some situation where it

will do the wrong thing or whatever

at the moment that's more likely than

not but

that will give us curry that we almost

run in pv as it stands

almost

[Music]

this is actually using radians rather

than angles so we have to convert these

two

that might be something we need to do

um

in blitz as well i'm not quite sure if

the cos and sine functions are actually

if we need to wrap them or not

i haven't tried this wasn't blips code

by the way this was on something else

but

i use that as a good example of

how we can get to

add the postfix symbols do our variables

for us

on mass

uh this is the code that was that's the

converted code so this is a

it won't

probably won't compile in pv we'll

probably get some functions in there

that we're not using

but we should come pretty close um

up here

this is the list of

scopes we've found so we found

what we're kind of like calling global

scope

which is the

the entire program that's not inside a

function

from top to bottom

and this is my function which is

the source position there is wrong

but these are the variables that are

known to be inside it

um some of these are getting or

incorrect is picking up some common

commands that it shouldn't

um

we might do a secondary search on those

and make sure that they're

they're

blips keywords they should already be

classified but i think there's

i think that classification's not quite

working probably

anyway so

you know a function that we dragged

across before we've got all of these

variables widths etc

and they're all tagged as

being a type 2 which is a float and it

gives us an indication of how frequently

the variables are used

and that's kind of that's handy because

we might be able to

use that to give hints about

uh

you know in certain scopes there are

variables that are only used once

that you're not you know maybe it's a

typo maybe it's something else

give warnings possibly

so you could add you can insert a bit of

a header in front of a function let's

say

that's it with a comment that says you

know this variable is not used

more than once or something like that

possibly even remove it

the problem with that would be of course

is is if we've misclassified something

and it turns out to be a constant

somewhere else or something like that

which we don't actually support at the

moment

come to think of it

so we'll have to add

support for constants to make sure and

they'll have precedence over uh

variables as well

the variables are kind of the lowest

thing on the pecking order

but our output here so

this just gives me a bit of idea of what

variables that's found inside the scope

they all seem to be okay if you look

down the bottom here what's

in this scope here

it's picked up things like swap

do

ellipse it thinks they're variables

they're not

of course not

but you know

we're getting somewhere

uh

i'm getting somewhere with this

at the top here

pick up us

our skypes i'm not sure if our

about searching is uh

our scope searching it's working

as per blitz

but i can update that later if it's not

quite quite correct

as we're inside a function is going to

work out what version of a variable

you're using

um

you know if the thing's declared

that's global uh above it

then we need to go okay use the global

occurrence of this so if the global was

declared

let's say it was a floating point

variable and then later on using it

without the hash symbol it must update

that as well

rather than think that's a new variable

inside the scope

but i think actually

even though we're not doing a full

compile

we're just picking through with this

logic we should be able to get a lot of

that stuff done

um

to be horrified if we run it in

on the on the large code base

this takes about 10 seconds to run this

well i'm sorry i can pull compile and

run it to straight

with no debug

so

this is the

9206 line

block of code

so it's been converted in about 900

milliseconds just under a second

that's pretty good i'm actually

i'm happy about that i wasn't expecting

it to do that well

i thought it might take you know five

ten seconds or something for code bases

that were large

run debug this takes a while because

it's dumping all of that crap to the

console and the console is just a

buffered window

so the thing looks like it's died

as you can see it's a long

lot of code

yeah now i can

pick through the scopes and and see what

um

what we've uncovered so this function

gy wind but skin

has these variables in it

some of these might not be variables

because it at the moment doesn't

understand types and the field uh

separators and types so might be picking

up field field separators as variables

here we've got some

references to these things here we're

looking for that in the code base

let's find the global scope

all right that's global scope there

got a bunch of just gar materials at the

front

gui screen width

see that's surprising

saying that screenwrites is only used

once the skin variables are used

that one's used 10 times

so that includes its initial occurrence

so it's declaration

i wonder if that's true

gee i scream with hmm

i don't believe that for a second

so gy screen

width

occurs

yeah it's more like it

was gonna say that that can't be right

so clearly we're not we're not fetching

um

hmm

we're not skipping over something there

we're not searching and finding those

correctly for us

good

what have you learnt well we're kind of

working we're kind of not working so

that's pretty much what we expect to

find isn't it

uh if i try this array thing actually i

might try the array

one here function scopes

so dimension

uh

dim

and i call it uh strings

a hundred

i'll use the example always do it the

other day so four

from the pickles naught to 100

i just want to see if it picks that up

actually sorry print

string

no

dollar sign

loop

thank you let's go

and we didn't pick that up

oh

yeah i know why there's no

trapping of the bracket

if it sees

this keyword and then a bracket

following it

you might know what to do and just

assume that's an integer

and strings without that will just be

integer so

in that scope

my function one there should be a thing

called where are we

yes yet

hmm

that's some some more oranges there

we're not getting both of those we

should have two strings if that's how it

was to seeing it

i had some really weird problems with

this this afternoon actually

weird is not saying the least and i was

at the point where i thought oh no

i found another weird bug in pv

it was right at that moment where i

uncovered oh hang on

it's not a bug in pb it's just i haven't

initialized

okay so we've opened

yeah

uh here's the logic here so if we scan

through we find a word

which is just any group of characters

that's been classified

so we'll see a block of character like

that

there is no white space the block of

characters is alphanumeric so you can

have lowercase uppercase and

numbers

and lower score character as well but i

think it can it has to start with it

with a underscore or

has to start with a

letter

anyway so we're skimming through we find

our word

we go okay

grab the token that's our variable name

we'll

need that to search for it in a second

we grab

whatever's after this thing

if this is an open bra which means that

the character after this so i just

just here for example

um

with the actual card again

so if we go let's zoom off a bit

so we're looking at this

keyword here

uh

it'll grab the token next to it which is

going to be the bracket token now what i

can actually do and get away with is you

have white space between these things

i think in pb generally it doesn't like

the white space to be there but in a lot

of languages that are pre

tokenized and then translated

which means that the white space can

just be thrown away so it doesn't matter

if there's white space between stuff

which is kind of weird

if people can't really do that well

i'm not sure enough to talk ahead but

anyway so we said this keyword here this

strings keyword

and since the next token is an unknown

stop character it's not a hash it's not

it doesn't know what to do if this is

presenting as an integer array

that's why it's failing so

what do here

sounds pretty crazy it's just um

just

jump to check this variable

that's how lazy i am yep

so look

and there we go we fixed our fix one

little shortcoming so

strings has been picked up as being

that is the array because it's saying

the next character is here or that's the

assumption it's going to make

it's pretty good assumption

um

and we're looking for that in the

current skype and found it so it's happy

to to promote it

here we have

we've got our strings array

and we found two occurrences of it

that's what we wanted

happy days

isn't that terrific so it's pretty much

just bumbling logic to fall through and

go okay this is our best guess for what

this keyword is

uh if we were building a full-on

compiler we actually have

as i was saying before you

you grab

as you found each keyword you then

dissect what the keyword actually is if

is it a

structural statement like a for

statement or a go-to or you know or a

compare you know where it's going to be

and then

uh they all have a certain pattern

so a for loop has okay after the full

statement we have a declaration then we

have

an assignment and then we have an

expression

a two statement and an expression

that's that's the pattern that i have

and if statement has

you know it's just an if and it's an

expression

uh

what we have to do is we have to break

the code down

at least then if we did that we could be

type aware this is not type aware

what i mean by that is is it

is it's not aware if you

like if you go hey here's my string

right here and i add

an integer value to it

pv is going to go what the hell are you

doing you know it might have a clue

but if we

wrote this as a true compiler we could

run through here

uh

promote this is to be the correct array

we wouldn't even need to do that

actually

uh and then we have a string we have

this replacement

we have um

conceptually half we've seen the

expression the first time

we pull the fullest result see it we end

up with like result

string plus this integer then we have a

bit of logic there going okay

you

since it's a string mixed with integers

we're going to want to treat the string

like an and a number so i have the value

of the string

yeah you could do that stuff

in a translator for you

and life would go on but in our version

here we can't do that

because i don't know

what this is

right or what the parameters in here are

i have no idea

i'm not matching types i'm not matching

the patterns of expressions nothing

so

so we can get you know get away with a

very preliminary um

comparison comparative sort of

replacement but we're not going to have

things that are

you know if your input code makes no

sense and your apple code won't make any

sense and in places

the output code here white making sense

in pb because you'll have

i noticed there's a thing in blitz where

you can do you can do type conversions

like

you know

a equals

so you have a literal string

and have it converted for you to an

integer value

um

yeah it just saves having you know a

function

val for example

you know

this is a shortcut they've added

anyway

is the this is the basic logic we're

just picking through here

um

just to select a slight case

with if the next the character after our

current current word is this

and it's most likely this thing

yeah so i have an example statement eg

this word bracket

if for the percent

it would be this word

percent

hash dollar sign etc

um there should be a you know

another version here that handles um

the trapping of

fields within types

but that's not something it even looks

at the moment

we'll try and get this to work pretty

well and then we'll worry about

stepping up for types

make sure it can pick up the

blitz commands correctly output them you

know into a

wrapped function a format and

then try and

make some simple programs

in blitz and try and get them to run

so

isn't that fun

anyway uh thanks thanks for hanging

around and listening to me ramble on

and i'll see you next time bye


 

   -- Script On PasteBin

[kevin]

BlitzBASIC 2 PlayBASIC Conversion:   It's Alive  - Blitz Wrapper - 7th Mar 2022

  This is the 5th look at writing a tool that can handle most syntax level conversions of Blitz BASIC code and convert it into PlayBASIC compatible syntax.

   In this episode we take giant leap forward by implementing implicit variable and array name detection as well command set emulation with our simple Blitz BASIC wrapper of blitz commands.   This results in our first 99% translation and execution of that code in PlayBASIC.  



 

  Input Code:

 

Code Select Expand



MY_Function2()



Function MY_Function2()

Graphics 800,600,32,2

Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#
width=800 : myPi = 3.14159
cx = width / 2
ax = cx: ay = 50    ; apex
ex = cx: ey = 330   ; ellipse
xr = cx * 0.7
yr = 0.33 * xr
While GetKey()=0
Cls
   x1 = ex + xr * Cos(a)           : y1 = ey + yr * Sin(a)
   x2 = ex + xr * Cos(a + 90) : y2 = ey + yr * Sin(a + 90)
    x3 = ex + xr * Cos(a + 180)     : y3 = ey + yr * Sin(a + 180)
    x4 = ex + xr * Cos(a + 270) : y4 = ey + yr * Sin(a + 270)
    Color 220,200,100
    Line x1, y1, x2, y2
    Line x2, y2, x3, y3
    Line x3, y3, x4, y4
    Line x4, y4, x1, y1
   Line x1, y1, ax, ay
   Line x2, y2, ax, ay
   Line x3, y3, ax, ay
   Line x4, y4, ax, ay
   a = a + 0.1    ; use 0.01 if is slow

   Flip

Wend

EndGraphics


End Function





  Output Code:

 

PlayBASIC Code: [Select]

;--------------------------------------------------------------------------------
   #include "--->PATH OF LIBRARY<--\BlitzWrapper.pba"
;--------------------------------------------------------------------------------

   MY_Function2()
   


Function MY_Function2()

   BB_Graphics 800,600,32,2
   
   Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
   Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#
width#=800 : myPi# = 3.14159
cx# = width# / 2
ax# = cx#: ay# = 50    ; apex
ex# = cx#: ey# = 330   ; ellipse
xr# = cx# * 0.7 
 yr# = 0.33 * xr#
   While BB_GetKey()=0 
         BB_Cls 
       x1# = ex# + xr# * Cos(a#)           : y1# = ey# + yr# * Sin(a#)
       x2# = ex# + xr# * Cos(a# + 90)       : y2# = ey# + yr# * Sin(a# + 90)
       x3# = ex# + xr# * Cos(a# + 180)     : y3# = ey# + yr# * Sin(a# + 180)
       x4# = ex# + xr# * Cos(a# + 270)    : y4# = ey# + yr# * Sin(a# + 270)
       BB_Color 220,200,100 
       BB_Line x1#, y1#, x2#, y2#
       BB_Line x2#, y2#, x3#, y3#
       BB_Line x3#, y3#, x4#, y4#
       BB_Line x4#, y4#, x1#, y1#
       BB_Line x1#, y1#, ax#, ay#
       BB_Line x2#, y2#, ax#, ay#
       BB_Line x3#, y3#, ax#, ay#
       BB_Line x4#, y4#, ax#, ay#
       a# = a# + 0.1    ; use 0.01 if is slow

       BB_Flip

   EndWhile

   BB_EndGraphics
   

EndFunction

  

   Blitz Wrapper:

      Attached bellow

[kevin]

    Tackling FUNCTION input and Return Parameters

    Last night I build in support Input parameter and return parsing fro the function header.   Today the focus is getting the convertor to build a return expression for our ENDFUNCTION prototype.  

    The current parser detects the return type, scans the scope for RETURN statements and if none are found exports the appropriate null to EndFuntion so the PB parser can detect the return type.



   BlitzBASIC input code:

Code Select Expand



; Empty Function shell, returns NULL and No return type specified

Function Test1()
End Function



; Returns INTEGER,  but not return statement, so returns NULL

Function Test2%()


End Function



; Returns Float,  but not return statement, so returns NULL

Function Test3#()


End Function


; Returns String,  but not return statement, so returns empty string
Function Test4$()


End Function



; Returns MyVector,  but NO return .. so should return NULL
Function Test5.MyVector()


End Function




   PlayBASIC output code:

PlayBASIC Code: [Select]

   ; Empty Function shell, returns NULL and No return type secified

Function Test1()
EndFunction 0  // Assumed Integer return



   ; Returns INTEGER,  but not return statement, so returns NULL

Function Test2()


EndFunction 0



   ; Returns Float,  but not return statement, so returns NULL

Function Test3#()


EndFunction 0.0


   ; Returns String,  but not return statement, so returns empty string
Function Test4$()


EndFunction "" 



   ; Returns MyVector,  but NO return .. so should return NULL
Function Test5()


EndFunction <FIXME:  RETURN PROTOTYPE MISSING> 

[kevin]

Promoting User Defined Type Variable and Array Fields

     Today we've made our way through to one of the last remaining issues; which is catching those pesky implicit typed variable declarations as well as those back slash characters used throughout the program.

     Here's tonight's result..   


    BlitzBASIC input code:

Code Select Expand





Type MyVector
Field x#,y#,z#
End Type

Dim Verts.MyVector(10)

For lp =0 To 9
Verts(lp)= New MyVector
Verts(lp)\x = lp
Verts(lp)\y = lp
Verts(lp)\z = lp

Next



Function Test14.MyVector()
cool.MyVector = New MyVector

cool\x =111.1111
cool\y =222.2222
cool\z =333.3333

Return Cool
End Function




   PlayBASIC output code:

PlayBASIC Code: [Select]

   Type MyVector
          x#,y#,z#
   EndType

   Dim Verts(10) as MyVector

   For lp =0 To 9
      Verts(lp)= New MyVector
      Verts(lp).x = lp
      Verts(lp).y = lp
      Verts(lp).z = lp

   Next   

   

Function Test14()
       Dim cool as MyVector Pointer : cool = New MyVector

      cool.x =111.1111
      cool.y =222.2222
      cool.z =333.3333

      ExitFUNCTION Cool
EndFunction Cool as MyVector Pointer 

       This compiles and runs..  It's not functionality identical mind you, but the objective here is to get it as close to compiling as possible and then  YOU pick up the slack....  :)

[kevin]

BlitzBASIC 2 PlayBASIC Conversion Tool WIP - Episode 06 - 3D Gouraud Shaded Torus  - 14th March 2022

  This is the 6th look at writing a tool that can handle most syntax level conversions of Blitz BASIC code and convert it into PlayBASIC compatible syntax.

   In this episode we convert some software 3D rendering code from 2001.  The code renders a light sourced gouraud shaded spinning 3D torus.    To convert the program we first pass it through our convertor then make the final adjustments on screen.   Once the code is up and running; we optimize it for best performance from PlayBASIC.  

   Performance wise we found something that you might not be expecting,  the converted PlayBASIC code runs on par with the original Blitz BASIC code (on the same system).   This is surprising as Blitz BASIC is natively compiled language (compiles to machine code) while PlayBASIC compiles to it's own run time.    The gap widens further by implementing GouraudStrip and GouraudTri into the mix, but i'm stunned at the performance of PlayBASIC V1.65 runtime and even come close to Blitz in the first place..

    The resulting code is attached to this post bellow !


   

[  Links:   ]
   
   BlitzBASIC 2 PlayBASIC - Source Code Conversion WIP
   
   XLNT GUI - Porting Blitz Basic GUI to PlayBASIC (Is it possible?)

   Visit PlayBASIC.com
   
   Script
   https://pastebin.com/CbXbvGHK


   

Code Select Expand


hello and welcome back here we are

tackling this blitz basic to play basic

converter in today's episode we're

actually going to look at

the lovely taurus that's spinning around

on the screen

the current level of the build pretty

much puts us at a workable state now it

doesn't produce working code for this

example

but i'll put it on screen

for you

and we'll write and it's pretty cool

okay let's take a look at the original

blitz code

it was written in 2001 this example and

it's quite a nice example when running

as you've already seen

but the whole thing is

all in software there's no hardware

acceleration no internal polygon

rendering in it

all the poly rendering is done

uh

well brute force really

it's drawing a batch of polygons doing

this stuff here trying out vertices

sorting the faces etc

so a lot of work has been done

that's my key point here that's the the

takeaway point is that there's a lot of

work being done

until we come right down to the software

rendering this example is doing groud

shaded polygons and they're also light

source which just makes it look a bit

more interesting

what i've actually done is i've taken

the original code

and attached the data statements because

it was selectable in the original

our translator at the moment doesn't

understand include statement so we

couldn't have that

set up this way

this way we can just pass it through as

one big blob and get a blob out

back to the translation

so let's run the translator now we'll

write in normal mode so we can see the

the speed of the conversion

uh it's about a thousand lines i think

no sorry it's 2000 lines but most of

those data statements so don't get too

excited

so we're doing our conversion in about a

hundred and you know i'll be generous

say 150 milliseconds not bad

if we run into bug mode it'll take a lot

longer so it's spitting out a lot of

data to the console

we've got about half a second there all

up so the console is over here

that's our code

that's been translated

the data statements didn't need to be

translated at all so they've just passed

through

uh where are we our program code up here

has been converted

we go up the top we can see that's the

start of our code and

sorry above this is the information

about the scopes what local variables

there were

how many times they were used etc some

are used very frequently some are used

hardly ever

so we i think we'll be able to use that

to our advantage and give tips about the

conversion

uh for each scope

yeah you know

let's not get him ahead of ourselves

let's just get this thing converted

so let's grab all this

head down the bottom yeah okay grab that

thing

and uh quit out of this

okay i've already set up a

an empty project for us to paste into so

let's paste our code

from our conversion across

so we're getting 2

700-ish lines of blitzcode

now we've got an include file up the

front here sorry let's grab that before

we've inserted an include file this is

coming from our my own wrapper at the

moment to emulate blitz functions

um let's kind of see how we go

uh see how far we get without

our dying

i know some functions here we're going

to need to remap like this read

statements here

pb has a different syntax for data

statements

i've got some collisions there too but

we'll go through them so we can you can

sort of follow what's happening with

this stuff we compile

right so our first

first problem is this read statement

uh

reading traditional basic is is a

command

and we don't support that we actually

have a read data function

to grab the next uh bit of data off of

the data

we can think of a data like a stack

can't you

now

it's really just like an index to it

to a table but

so branch ahead

uh vertex signal vertex we've got some

data statements there put those there

get rid of those thanks

i can see some problems with this

already

and they're not to do with the

translation they did to do with

differences in

well

how one language

likes to use keywords in one one uh

doesn't oh undo that thing so what i'll

just do then

delayed that terrible

some dummy reads there so that day has

got some empty stuff in it

don't need the reed stavens there of

course

pull them out

quick save

let's just see what the next thing is

doesn't like about this is

uh yeah i thought it would like this

actually see how we've got a type name

called vertex and an array called vertex

now

it can't really distinguish between the

two

obviously in blips you're allowed to do

that

oh in pv you can't so what we'll do is

we'll

put like a lowercase t in front of the

type names

and

so

it's in front of vertex

i thought a poly was another one as well

poly was one

and

all light source was one

okay

so like south park there yeah eric you

know there you go

that was my mistake terrell

ah here we go so this is a byproduct of

the wrapping pepe likes that it's um

functions to have

a pair of brackets on them

okay

this is something that popped up when i

was doing the a monster truck a most to

play basic conversion

in blitz um it's valid to have a

variable called fps

in pb that's the name of a function

so

the error is going

hang on what are you trying to do with

fps you can't do that with this so we

have to rename this um

when i did the amos converter it would

just put a prefix in front of these ones

that's what we'll do now we'll just go

yep

anything that's fps

just call it local fps yeah

i'm going to call it anything we want to

do there's ones over there too

hidden away anymore

can't see any more of those so let's

just compile and see how we go

oh text yeah text is a bit of a pain

because of the conversion

i've got a version of text that'll do

strings but here we've got a combination

of

string data and integer data so we have

to have like a string wrapper around

this

for the amos converter i did

actually

that's actually what i did is it went

through it it

did a rough reese

a rough sort of bracketing of these

these things here just assuming that

they're integers or whatever

i might just get rid of the wrapping for

this

command

because text is pretty much text there's

not much we're just drawing stuff in the

current font

i will have to actually put strings

around these

isn't that terrible oh good goodness

goodness gracious

uh

put the closing bracket on

yeah it's definitely something we should

definitely try and tackle

and then the variable collision stuff

too that could be a problem with big

code bases

um i forgot about that one

next one let's just hit compile again

see how we got

that flip need some brackets

flip is basically sink

you know

places plays in play basic lands just

flipping the back buff for the front

buffer

hey

that's a long way through

lock buffer

i think it blitz it requires a parameter

and we'll let's set up to

set up so that surface 0

is the screen so we'll just put lock

buffer 0

for that and there's another collision

there see how it's got rgb equals

this

expression wow i'm surprised it's done

like that

um

we'll leave that there

just to show you that that's going to

upset play basics see how this variable

name here it's going hey you've got a

function

using the function name in some wacky

way what are you doing

ah we'll just call it

put l in front of it for local or

something

you can so how far we get

right pixel

uh

oh it's got a surfacing on the end

point zero for surface

you know

pretend like we know what we're doing

unlock buffer no

zero for surface yep good on you

fantastic no no

oh man so on

so the functions ex

yeah okay

so the bottom there we're exporting a

integer which is a assumed return from

from the translation

um so for this exit function here we

have the same

same response

otherwise you might just get some stack

misalignment

um there is an error for that actually

if you get one

press on dudes let's go

yeah oh

yeah

yeah some basics will allow you to do

if expression and then then and then as

long as there's nothing following them

then you can you can use an end if

statement we don't do that

i must trap this one and cut it out or

just add it to the phrase at some point

lock buffer it's going to be screen

isn't it

unlock's going to be the

screen right pixel

one two three

pv

back buffer same collision

issue there

so that we're constructing a color and

then running it to the screen so i've

got a lot of work to draw a pixel

yeah so it's going to run pretty pretty

terribly initially but um i know we can

speed it up

when we get this thing going

same drama

don't need the then statements thanks

hit save

ah we've got through the code that's

cool

got a die in front of the label anymore

what else we got

chords

you can pile again

one more

surely that must be the end of the data

let's hit run

wow it's running

and it

actually is running but there's some

problems with it

as you can see

and one of the problems is not what you

what you're expecting

i did put this the other day and ran

into the same same drama so

i know roughly what the what this issue

is going to be

so before we tackle that i'll just

demonstrate we're working

why is working up front

so

we won't draw um the polygons as groud

we'll just draw them as a set of

vertices

the function's already in here

hopefully it should work there you go

in other words the code that handles the

rotation uh projection etc and

the polysorting that's all actually

working

what's not working is this drawing this

draw polygon function

uh

if we cut poly out

put one of these line savings in now

this has the old syntax see how it's got

the the backslash

that's the blitz syntax

because this code was inside a comment

and this wasn't converted

um quick save

let's hit

run

hmm so we are actually working

that's pretty cool i like that

and the rate's not too bad either we're

getting you know 10s and 15s etc

uh

we can do better now

sorry

i might just put a space bar

on this main loop where are we really

i've set an exit time there so if it

runs for a number of frames it'll exit

by itself i might drop that down to 50

frames

um

it sounds like a short time but

uh when we get this we start tackling

this um

this poly rendering routine it's very

slow initially because of all the

wrapping

it has a few bugs in it too that we've

got to actually track down

so it'll run for 50 foot and i'll run

for

200 frames 250 frames okay

or until hit the space bar all this guy

all the escape go

spacebar good

right let's tackle this draw polly

go to

the groud poly function

um

i think what we'll do is

so we'll actually have a look at this uh

oh are we drawing the lines

or not what are we drawing

all right that's a little

that's the x

for this row

it's the x from the next row and we'll

draw it in like a

green maybe

so i should draw a strip for where the

hot each horizontal strip of the

the polynomial's drawing is

um

should

now clearly the lines are outside of the

polygons because the polygons are these

white lines here

and our lines are way outside that so

something's not right

i do know what the problem actually is

so i'll talk you through it this one

here

it's in this edge function

where we're lying on

well

let's go back a bit you might have

noticed that all of the values here

for coordinates

uh see how we've got x1

and then we've got rgb coordinates for

it we've got x2 rgb coordinates

uh these are to draw

down the edge of the polygons as it's

being scanned converted

now when we have a triangle we we work

out what's the top point

and we work out what edges we need to

draw and we draw

ideally from the top to the bottom you

can actually draw in any whatever your

order you like

as long as you end up with a bunch of

lists bunch of spans

that represent the shape

now this doesn't work

because here we've got a translation

where we're going

we're subtracting x1 from x2 and then

shifting it up 8 bits

if x1 x2 are positive

that's fine

and it's the same goes for y1 y2 if

that's positive that's fine

but at any point

we end up with something that's that's

negative

we're mixing signed arithmetic with

bitwise arithmetic

so something between how the shift

operator works in blitz and how the

shift operator works in pv is different

here i'm just moving the bits just going

hey

shift the bits up who cares about the

side of it

so we've actually got to do a division

here or sorry multiplication

so so

if we shift something

if we shift something up eight bits

i'll just call it scala i guess

so we're just going

um

we can do it like this

we can compute that scala

that's the level of precision

which is going to be an integer value of

256.

so we could substitute in here

we're multiplying this sorry wrong

operator

now because pv is interpreted

the cost of having in an integer mold or

an integer shift is not that great

to be honest

it's really almost nothing

well actually i wonder there too see how

we've got

we've got a shift and then in addition i

wonder if the precedence

of this is actually a problem

let's just check that

hey we're here now let's just do it yeah

come on

i know you're bored i know you want to

see it running fantastic yeah

this is computing our edges if our

engines look normal then that's our

problem that it's not

there's not a difference between the

shift it's a difference between the

precedence of the operators

i don't know

let's find out together

hey that's the problem

that's nice to know

yeah all right

just to check that

that means we can get away with we don't

need to do

those modifications we can just go yeah

all right do your thing dude

do this that's very good do this thing

very good

lovely long as it still works

the slide performance is actually

a common problem with direct draw

applications all right so that that's

actually solved

our problem so

if we go back

that's our pixel rendering loop

that's our line rendering rendering loop

now if we do

something

simple like we go a lock buffer here

so we're drawing all of these lines

batched up with and we're locking the

surface

that should

make people a lot happier when we're

doing this job

should

yeah it's much happier with that

cool

now we know the the

vertex locations are accurate we know

that our

they're all the same so now we need to

tackle this in a loop and i know this

three slides could take you know

quite a while to render so i'll put that

abort case

back into the code

of you know

i have it be uh

20 frames

see how bad we get how bad it runs up

from up front

about a frame a second

but

it is running

can we improve on this you better

how we're going to do it well the same

old way we always do it

like in the buffers dude

so we know it works and all of our

efforts there have been have not been in

vain so

get rid of the line drawing stuff there

for a second

go up to

and draw a polygon and go have a look at

the draw

oh

that's right below it

right

now

right pixel is pretty much a wrapper

around

the

the dot function so we can substitute

right pixel

with dot we don't need to know the

buffer all the time we don't

people work that stuff out for us so we

could just do this

dot c which is the colored version

for the lrgb and that should help us out

a lot

doesn't seem like it has though does it

and

the main reason for that is that we are

drawing

500 polygons in every scan line of those

polygons which is going to be let's say

each polygon's got 20 scan lines so

that's

570 times 20.

that's how many times we are locking and

unlocking the surface

that's a lot

uh so what we need to do what we should

do really is that rather than lock the

buffer

every time we draw a strip draw one one

span

which is how this is has provisioned for

it before

go up to the

animal drawer these four those

so here we go

would you look at that

so we're running actual translated blitz

basic code

uh it's drawing every polygon dot by dot

we've got some buffer management control

in there

we're drawing lots of extra dots there

too so i bet they they don't have great

uh buff sorry

buffer management stuff in them as well

but we're still doing something that's

not great though isn't it we're locking

the buffers

every time we draw a polygon so if we

draw the more polygons we draw

in this case here if we if

we have 500 polygons and half of those

polygons are visible

so let's say 250 on average

then

we're going to be drawing attempting to

lock the buffer and unlock it

250 times so we want to actually

probably a better solution would be to

lock the buffers

at the start of the polygon batching and

then release it at the end

let's try that then so let's draw a

polygon routine here

we're running through and doing all this

good stuff so we'll just do the locking

it at this level

and strip out the other stuff we added

before

where are we there we are there we are

so it locks the current surface by the

way if you're not familiar

uh draw vertices

there's no buff although there is some

there that's not too bad

sorry

let's go to grab polygon find that thing

we don't need to lock the buffer in here

so

we can do our strip

render our strips

and the buffer state is being managed on

a higher level so we don't need to have

all this pleasing thank you with those

that there's this low level here

that shouldn't make it perform much

better

should

and does

now we're capturing the screen we're

drawing a bunch of dots as well so you

know

it's not bad

it's just a complete translation of the

same application

uh clearly the inner loop here has some

things there we could probably get rid

of

like

if we know we're never drawing outside

of the display

constraints

we can swap dot with uh fast

fast dot

and we probably should do

here i think we're always rendering to

the same surface

so that would mean our our lock would be

appropriate for the for the same surface

all the time

but you've got to be careful with that

stuff

one way to ensure that's never going to

was going to work as we can read

if you ask

us pb to read a pixel from the surface

it will see the locking every time so we

read one pixel at the start of the batch

of all the polygons then we never needed

to do it again

if you're jumping around changing images

you're rendering to locking something

unlocking it

the

the optimizations that track the lock

state can

can you know they can work against you i

know

i'm a terrible person

should be the same

cool

that's pretty good some stuff in here

too yeah i could grab the

grab this thing here

um

just call it

this is your index

grab your index from there

save reading that array three times

so i'll read it once and then just throw

it away

those kind of you know there's micro

optimizations you can run through and do

those things yourself

um

you probably probably always treat your

colors separately and have the light

source computed

or you've got more actually

you can clip the range there's for

example c2 equals

clip range

c2

north of 255

you know

that sort of thing

um you're probably not really winning

back any performance by doing those

things but it can just reduce your code

it's pretty cool i like it

i like it a lot ah right

that's our translation for you um hope

you enjoyed that

let's say we wanted to push this a bit

further we could we could make this a

bit more play basic friendly

get rid of the dot rendering stuff

draw vertices get rid of that

don't really need it let's check this

thing out

that's nice

uh one thing we could do is obviously

since we're in pv land

now draw a polygon

now

let's head down to

our draw a line where are those

this particular section of code here

that's it's forming an rgb color

what we couldn't do is we could of

course

use the rgb function

rgb

was it rt

uh gt and then bt

we don't have to do this in software so

we you know we're two function calls

that approximate

this is

we get rid of a shift a shift and two

additions

but we substitute them for one function

call

let's try it

it's pretty hard to know

if if we've won much back in that i

would say we probably have

obviously the best way to do this in pv

is actually to do this

let's draw a groud strip from x1

from r1 g1

b1

to x2 rgb

it's going to be

r2

blue 2

and green two and

on the y row so we can just get rid of

all of that really

yeah

it's pretty comfortable now it's

obviously we're switching a lot of the

the runtime dependency to command set

dependencies

uh which is because the built-in

function for drawing a grad strip is

pretty much

well it's pretty optimal you know

compared to

i don't know how many cycles this takes

to

to execute through the through the

runtime but

every single pixel is doing that

i guess what you could do is you could

use some of the

[Music]

the paired pixel optimization stuff

where you

you know when you draw

you unroll the this inner loop a bit

further you draw pairs of pixels you

know in one pass compute them etc and

that actually works pretty well to be

honest

and you draw a pair of dots

at one time rather than a single lot

that makes that can be beneficial

because you're drawing

or you're saving

some overhead from calling a function

which in the runtime is quite expensive

so even though this is relatively fast

you know this is the fully

fully interpreted rendering loop

so we're probably somewhere in that you

know in the

between 30 to 60 frames per second

which is stunning to me

while it's been captured or

now this is going to be you know

comparing to the

the native loop that draws ground pixels

it's not that much detriment it's

probably twice as fast let's say

if i converted the whole thing to use

the groud polygon

it would be much faster again

but i want

i'll

just revert the code back to how it was

and you can

tackle this yourself

what if we avoided drawing the line at

all and just drew

a ground line in here

so we computed the start of the line

x1 yep go for it

x2 is going to equal

it's the here

so we just need these

rgb

values here

and that function should pretty much

work the way it was working before

we've got x y x one y is the same

let's try her out

i think for this approach we're pretty

much um

at maximize our throughput for it

to draw strips

to get quicker we're gonna have to go to

drawing polygons

just draw the whole thing

um

grab triangle x1 y1

rgb

one x2 y2

rgb2

x3

y3 rgb3

exit function to avoid all that other

stuff at the bottom there

you know

uh so rgb one equals rgb rgb

g1 b1

because the command expects uh the

parameters to be fed to it

as colors

um

that are compressed

so they're packed together as

rgb rather than separate rgb

fields

all right

let's give it a go

goodness gracious

oh

i've got a return to zero

yeah no surprises there

is you can see it kind of peaking at a

few hundred frames per second

what if we just keep those in the code

or have uh

i'll make three different versions of it

so version two

which will just be the

the line optimization and version three

will be the full polygon rendering

thing so we'll just

cut all of that out

so version three of the

function will be this

don't need anything below that

version two will be the

so doing all this work here great all

going well and then we're doing this

so we

using ground strip to do for this

version

uh

where are we and

for the original version we just you

were doing

as it was the stock version

uh

just

restore that to how it was cut all that

stuff there out again

excuse this video for being so long

so the inner loop no we want the actual

pixel rendering

run it give it a test

we're back to the normal software

rendering

which is still pretty good

cool

what if we put a switch in there

to choose which rendering method we

wanted

to

[Music]

global uh render

random method equals zero by default

uh at the bottom here we'll just

display this to the user

i don't draw up there actually

so i'll come down about

that lori 60 random method

random

random method

and

just call it render

yeah i'll do that

everything on the end here render

sorry method

come on

i know it's light it's not that light

add a bit of crappy logic up front you

know

all the good stuff

select

uh render

method

case zero

top

this is the fast dot

in a loop

then select

a couple of those

two

this is the

ground

strip

round triangle

um

so we'll just have a

bit of a check here um

i don't know if the answer is press or

something

whatever

uh this bump that

bigger than two

making it a zero it's kind of a default

case

i couldn't be bothered

isn't that terrible

now i could use like

call function in this and do some

as9

kind of crap

uh we we'll just have the polygon

rendering stuff wherever that's going to

uh draw a poly

select random method

have a select case

very old school

all right so we were method one method

two i'll make this correlate here

actually method one

method two um

uh sorry i didn't think this was

going what

what the hell

all right so method one is the

ground strip version and polygon

2 is the full blown polygon version

let's try it out so we can check them

side by side

all right so looking at the the fast dot

which is the original emulation of the

blitz code

we're switching to ground strip mode

which is we're drawing the inner strips

with our groud strip command

we're peaking at 125 frames per second

we're averaging around over 60 frames

per second now

all in software

on the interpreter so with polygon

we're hitting 250 frames per second

the average is coming up and up and up

now of course that's going to be

quickest because we're doing the

we're passing control from the

interpreter

to machine code to fill the triangle and

come back

i hope this was insightful have you

learned something hope you've interested

in something

thanks for watching i'll see you next

time

bye



   



READ DATA parsing and remapping to ReadDATA() statements

     Here's an input-> output example from todays conversion engine.  This one focuses on the REAd data command and attempts to remap those commands to PlayBASIC's various readData() / ReadData#() / ReadData$()  functions.  

Code Select Expand


Dim iarray(100)
Dim farray#(100)
Dim sarray$(100)

Read a
Read b#
Read c$
Read iarray(0)
Read farray#(0)
Read sarray$(0)

Print a
Print b
Print c
Print iarray(0)
Print farray(0)
Print sarray(0)


Print "Stacked "

Read x,y
Print x
Print y

Read x,y,z
Print x
Print y
Print z


Read iArray(0),iArray(1),iArray(2)

Print iArray(0)
Print iArray(1)
Print iArray(2)



Read fArray#(0),fArray(1),fArray(2)

Print fArray(0)
Print fArray(1)
Print fArray(2)


Input



Data 100
Data 123.456
Data "Hello World"


Data 200
Data 222.222
Data "Hello World2"



Data 111,222

Data 111,222,333


Data 1111,2222,3333

data 1111.23 , 2222.23 , 3333.23




    Converted code ...  only one change and it runs

PlayBASIC Code: [Select]

      Dim iarray(100)
      Dim farray#(100)
      Dim sarray$(100)
      


       a = ReadData()  
       b# = ReadData#()  
       c$ = ReadData$()  
       iarray(0) = ReadData()  
       farray#(0) = ReadData#()  
       sarray$(0)       = ReadData$()  


      Print a
      Print b#
      Print c$
      Print iarray(0)
      Print farray#(0)
      Print sarray$(0)

      
         Print "Stacked "

       x = ReadData() : y = ReadData()  
      Print x
      Print y   

       x = ReadData() : y = ReadData() : z = ReadData()  
      Print x
      Print y   
      Print z


       iArray(0) = ReadData() : iArray(1) = ReadData() : iArray(2) = ReadData()  

      Print iArray(0)
      Print iArray(1)
      Print iArray(2)



       fArray#(0) = ReadData#() : fArray#(1) = ReadData#() : fArray#(2) = ReadData#()  

      Print fArray#(0)
      Print fArray#(1)
      Print fArray#(2)


      BB_Input



   Data 100
   Data 123.456
   Data "Hello World"
   
   
      Data 200
   Data 222.222
   Data "Hello World2"
   
   

      Data 111,222

      Data 111,222,333
      
      
      Data 1111,2222,3333
      
      Data 1111.23 , 2222.23 , 3333.23

Download:

       Attached 3D Torus code bellow

[kevin]

BlitzBASIC 2 PlayBASIC:  Labels and Include Statements  (19th March 2022)

    After making Blog 22 (login required) I sat back down to wrap this thing up; adding support for LABELS, which are stored with a dot prefix in Blitz and then tackling the bigger issue of the Include statement.  

    The Include functionality is an interesting problem, I think i've tackled this in about every variation know to man and never felt good about it.  Generally When I parse stuff and hit an Include statement,  it means loading that file into memory and doing a manual insertion at that position;  So it's a brute force operation.   But, this time we have linked tokens in our document so the data doesn't need to be physically inserted,  rather we can load the tokenized document and link the new token stream into the old stream.     This is a bit tricky in PB when your trying not to use pointers.  So it requires a bit of magic to merge of pair of lists, but all in all it seems to work fine now. 

    Initially though it was making all sorts of strangeness occur,  I kept getting a bizarre error from PlayBASIC about an array not existing.    Which I took as a given, but it turned out to be PlayBASIC was returning the wrong error massage,  throwing me off the rather obvious scent.   Which was as simple as an index being out of bounds.   Once that was corrected, it actually worked.  Although then I ran into another drama; where the convertor would hang if a file was included twice.  Which turned to be nothing about the inclusion process, but another function that searched for Local variables could fall into an infinite loop if there was two functions of the same name.   

  #indiedev #gamedev #programming #coding #coder #convert #sourcecode #blitz #bltzbasic #blitz3d #basic #conversion #programmer #howtoprogram #learntcode


   
   BlitzBASIC input code:

Code Select Expand

 



Dim iarray(100)
Dim farray#(100)
Dim sarray$(100)

Read a
Read b#
Read c$
Read iarray(0)
Read farray#(0)
Read sarray$(0)


Print a
Print b
Print c
Print iarray(0)
Print farray(0)
Print sarray(0)

function Stuff()
;Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
;Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#
End Function

function Stuff()
;Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
;Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#

End Function



Print "Stacked "

Read x,y
Print x
Print y

Read x,y,z
Print x
Print y
Print z


Read iArray(0),iArray(1),iArray(2)

Print iArray(0)
Print iArray(1)
Print iArray(2)



Read fArray#(0),fArray(1),fArray(2)

Print fArray(0)
Print fArray(1)
Print fArray(2)




Type dude
Field x,y#,z$
End Type
me.dude = New dude


Print "TYPE FIELDS:"


Read me\x , me\y, me\z

Print me\x
Print me\y
Print me\z

Input




Data 100
Data 123.456
Data "Hello World"


Data 200
Data 222.222
Data "Hello World2"



Data 111,222
Data 111,222,333
Data 1111,2222,3333
Data 1111.23 , 2222.23 , 3333.23

; type field data
Data 9999,9999.123,"This is a type"

.MyLabel1
Data 10,20,30,40,50

.MyLabel2

.myLabel3

include "Pyramid-Demo.txt"

; This is a comment between includes
include "Pyramid-Demo.txt"

; Last LIne of code in file
 


   PlayBASIC output code:

PlayBASIC Code: [Select]

      Dim iarray(100)
      Dim farray#(100)
      Dim sarray$(100)
      
       a = ReadData()  
       b# = ReadData#()  
       c$ = ReadData$()  
       iarray(0) = ReadData()  
       farray#(0) = ReadData#()  
       sarray$(0)       = ReadData$()  


      Print a
      Print b#
      Print c$
      Print iarray(0)
      Print farray#(0)
      Print sarray$(0)

Function Stuff()
   ;Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
   ;Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#
EndFunction 0

Function Stuff()
   ;Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
   ;Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#

EndFunction 0


      
         Print "Stacked "

       x = ReadData() : y = ReadData()  
      Print x
      Print y   

       x = ReadData() : y = ReadData() : z = ReadData()  
      Print x
      Print y   
      Print z


       iArray(0) = ReadData() : iArray(1) = ReadData() : iArray(2) = ReadData()  

      Print iArray(0)
      Print iArray(1)
      Print iArray(2)



       fArray#(0) = ReadData#() : fArray#(1) = ReadData#() : fArray#(2) = ReadData#()  

      Print fArray#(0)
      Print fArray#(1)
      Print fArray#(2)



   
      Type dude
          x,y#,z$
      EndType 
       Dim me as dude Pointer : me = New dude


      Print "TYPE FIELDS:"


       me.x  = ReadData() :  me.y = ReadData() :  me.z = ReadData()  
      
      Print me.x
      Print me.y
      Print me.z
      
      BB_Input


   

   Data 100
   Data 123.456
   Data "Hello World"
   
   
      Data 200
   Data 222.222
   Data "Hello World2"
   
   

      Data 111,222
      Data 111,222,333
      Data 1111,2222,3333
      Data 1111.23 , 2222.23 , 3333.23
      
      ; type field data
      Data 9999,9999.123,"This is a type"

MyLabel1:
      Data 10,20,30,40,50

MyLabel2:

myLabel3:

   /* Include "Pyramid-Demo.txt" */ "Pyramid-Demo.txt"
   MY_Function2()
   


Function MY_Function2()

   BB_Graphics 800,600,32,2
   
   Local  x1#,y1#,x2#,y2#,x3#,y3#,x4#,y4#
   Local ax#,ay#,cx#,ex#,ey#,xr#,yr#,a#,width#,myPi#
width#=800 : myPi# = 3.14159
cx# = width# / 2
ax# = cx#: ay# = 50    ; apex
ex# = cx#: ey# = 330   ; ellipse
xr# = cx# * 0.7 
 yr# = 0.33 * xr#
   While BB_GetKey()=0 
         BB_Cls 
       x1# = ex# + xr# * Cos(a#)           : y1# = ey# + yr# * Sin(a#)
       x2# = ex# + xr# * Cos(a# + 90)       : y2# = ey# + yr# * Sin(a# + 90)
       x3# = ex# + xr# * Cos(a# + 180)     : y3# = ey# + yr# * Sin(a# + 180)
       x4# = ex# + xr# * Cos(a# + 270)    : y4# = ey# + yr# * Sin(a# + 270)
       BB_Color 220,200,100 
       BB_Line x1#, y1#, x2#, y2#
       BB_Line x2#, y2#, x3#, y3#
       BB_Line x3#, y3#, x4#, y4#
       BB_Line x4#, y4#, x1#, y1#
       BB_Line x1#, y1#, ax#, ay#
       BB_Line x2#, y2#, ax#, ay#
       BB_Line x3#, y3#, ax#, ay#
       BB_Line x4#, y4#, ax#, ay#
       a# = a# + 0.1    ; use 0.01 if is slow

       BB_Flip

   EndWhile

   BB_EndGraphics
   

Login required to view complete source code

[kevin]

BlitzBASIC 2 PlayBASIC Conversion Tool WIP - Episode 07 - Sneak Peek - Syntax Highlighted View  - 23rd March 2022


     This sneak peek gives us a glimpse at a syntax highlighted view of the freshly converted blitz basic code,   But more on that later ! :)


   

[kevin]

 BlitzBASIC 2 PlayBASIC:  Variable Collisions + Print & Text Remapping  (26th March 2022)


   Added a pass to check if variable names collide with known PLayBASIC function names.  If they do those variable end up with an underscore stock in front of them.  

  The other addition tonight has been some support for detecting and replacement of string additions between literal strings an Integers & Floats.  Don't get too excited it's pretty dumb and anoything more complex then "String"+Variable isn't likely to work ..  But it's better than nothing :)

    Here's the main loop from the torus demo,  which includes both problems.  It uses a variable called FPS and the TEXT function needs it's parameters mapped into strings..

Code Select Expand



While Not KeyDown(1)
 rotate_transform_vertices(x_angle,y_angle,z_angle)
 sort_polys()
 Cls
 draw_polys()
;  draw_vertices()
 fps=(1000/(MilliSecs()-t))
 t=MilliSecs()
 Text 10,10,"Current FPS : "+fps
 Text 10,30,"Highest FPS : "+hfps
 Text 10,40,"Average FPS : "+afps#
 Text 10,50," Lowest FPS : "+lfps
 Text 210,10,"  Points : "+numvertex
 Text 210,20,"Polygons : "+numpoly
 If hfps=0 Then hfps=fps
 If lfps=0 Then lfps=fps
 If afps#=0 Then afps#=fps : afpscount=1
 If fps>hfps Then hfps=fps
 If fps<lfps Then lfps=fps
 afps#=((afps#*afpscount)+fps)/(afpscount+1)
 afpscount=afpscount+1
 Flip
 x_angle=x_angle+1
 y_angle=y_angle+2
 z_angle=z_angle+4
 If x_angle>360 Then x_angle=x_angle-360
 If y_angle>360 Then y_angle=y_angle-360
 If z_angle>360 Then z_angle=z_angle-360


quittime=quittime+1
If quittime> 500 Then End
Wend




     


       Which is converted into this for you;

PlayBASIC Code: [Select]

While Not BB_KeyDown(1)
  rotate_transform_vertices(x_angle,y_angle,z_angle)
  sort_polys()
  BB_Cls
  draw_polys()
;  draw_vertices()
  _fps=(1000/(BB_MilliSecs()-t))
  t=BB_MilliSecs()
  Text 10,10,"Current FPS : "+str$(_fps)
  Text 10,30,"Highest FPS : "+str$(hfps)
  Text 10,40,"Average FPS : "+str$(afps#)
  Text 10,50," Lowest FPS : "+str$(lfps)
  Text 210,10,"  Points : "+str$(numvertex)
  Text 210,20,"Polygons : "+str$(numpoly)
  If hfps=0 Then hfps=_fps
  If lfps=0 Then lfps=_fps
  If afps#=0 Then afps#=_fps : afpscount=1
  If _fps>hfps Then hfps=_fps
  If _fps<lfps Then lfps=_fps
  afps#=((afps#*afpscount)+_fps)/(afpscount+1)
  afpscount=afpscount+1
  Sync
  x_angle=x_angle+1
  y_angle=y_angle+2
  z_angle=z_angle+4
  If x_angle>360 Then x_angle=x_angle-360
  If y_angle>360 Then y_angle=y_angle-360
  If z_angle>360 Then z_angle=z_angle-360


   quittime=quittime+1
   If quittime> 500 Then End
EndWhile

[kevin]

BlitzBASIC 2 PlayBASIC Conversion Tool WIP - Episode 07 -   Syntax highlighting - Variable Collisions

 This is the 7th look at writing a tool that can handle most syntax level conversions from Blitz BASIC into PlayBASIC compatible syntax.

   In this episode we recap current additions, namely support for variable collisions / simple Print/TEXT expressions and Syntax Highlighting.    Visually the tool now has a syntax highlighted view to make it easier to see each alternation.    

   Since the conversion tool has progressed as has the Blitz command set wrapper, we do another live conversion of the 3D Torus code.   This time, we're left with only a hand full of changes before it's up and running in PlayBASIC.

 Remember the goal here is not necessarily to build a BlitzBASIC 2 PlayBASIC transiler; rather a tool that can perform the majority of the tedious changes for us systematically.   So you should as assume the converted code will need to be manually tweaked.


    Check the development blog for more interesting examples


     

---[  Links:   ]---------------------------------------------------------------------------------------------

   BlitzBASIC 2 PlayBASIC - Source Code Conversion WIP
   https://www.underwaredesign.com/forums/index.php?topic=4625.0

   XLNT GUI - Porting Blitz Basic GUI to PlayBASIC (Is it possible?)
   https://www.underwaredesign.com/forums/index.php?topic=4620.0

   PlayBASIC
   http://playbasic.com

[kevin]

  BlitzBASIC 2 PlayBASIC Conversion Tool WIP - Episode 08 -   Code Optimizations - Variable Shortcuts


    This is the 8th look at writing a tool that can handle most syntax level conversions from Blitz BASIC into PlayBASIC compatible syntax.

    In this episode we take a quick look at the results of the optimization pass applies to the freshly converted BlitzBASIC code.   In this video; the code is set up to perform the optimization pass upon pressing the enter key.  We test various source codes from one with than  less than a hundred lines through to the Xlnt GUI source code which is over 8500 lines and it barely impacts the frame rate.

     Check the development blog for more interesting examples