BBC BASIC
« BB4W vs BBCSDL speed differences »

Welcome Guest. Please Login or Register.
Jan 20th, 2018, 6:12pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: BB4W vs BBCSDL speed differences  (Read 397 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx BB4W vs BBCSDL speed differences
« Thread started on: Aug 23rd, 2016, 2:50pm »

If you have tried running the cross-platform (SDL 2.0) version of BBC BASIC - and if you haven't why not? - you might have noticed some interesting speed differences, even when running on exactly the same machine. A noteworthy example is the graphics example program fern.bbc: here are the execution times I measured on this notebook:
  • BB4W: 2.40 seconds
  • BBCSDL: 0.75 seconds
That's more than three times faster when running on the cross-platform version!

Of course the BASIC interpreter is exactly the same in each case, so the difference stems from the way the graphics are generated. There are two main issues at play: firstly BBCSDL uses OpenGL (which is GPU-accelerated) and BB4W uses GDI (which probably isn't). Secondly in BBCSDL the graphics rendering happens in a different thread (and therefore often on a different CPU core) from the interpreter's calculations, whereas in BB4W the rendering happens in the same thread (and hence on the same CPU).

That's not to say that BBCSDL will always be faster: using GPU-accelerated graphics may speed up rendering but it can slow down reading back from the 'screen'. As a result POINT() and TINT() are typically much slower and should be avoided when possible.

Richard.
User IP Logged

michaelgallup
Guest
xx Re: BB4W vs BBCSDL speed differences
« Reply #1 on: Aug 24th, 2016, 04:31am »

I tried the Fern example and it is very fast!

This program works well in BBCSDL (SDLIDE)
It doesn't function in Andy's version (black window, no action.. maybe because of the use of the palettes?)
I prefer your version SDLIDE because it has a more familiar editor. I made this program that tries to act like it is a sprite and it seems to work just as well as in BBC Basic.

I hope you like GETPIC and PASTEPIC and MOVEPIC
Code:
      REM ha ha ha !!! silly me!! If num is not defined then it just cant work
      N%=0
      N%=20
      REM       width;height;charwidth,charheight,number of colors,character set
      VDU 23,22,1024;600;8,15,16,1 :REM max width is 1920 and 1440 height
      OFF
      VDU 5
      DIM X(20),Y(20),H(20),V(20)
      PROCcolor("f","yellow")
      CIRCLE 100,100,50
      a=0:b=0:c=0:d=0:c=150:d=150:e=0:f=0:e=500:f=500
      REM RECTANGLE a,b,c,d TO e,f

      PROCgetpic(0,0,0,150,150)
      PROCmovepic(0,500,50)
      FOR X=10 TO 1000 STEP 5
        PROCpastepic(0,X,600)
        WAIT 1
      NEXT X
      FOR X=600 TO 1 STEP-1
        PROCpastepic(0,1000,X)
        WAIT 1
      NEXT X
      WAIT 1
      END
      REM getpic sorta functions like GET from the 80s but in this case it just assigns capture area information
      REM each getpic only needs to be called once, but you can reassign
      REM num refers to the variable arrays that will carry each image's capture point (it ranges from 0- 20)
      REM I guess h,v are the height and width of the image.
      DEFPROCgetpic(num%,xx,yy,hh,vv)
      N%=num%
      X(N%)=xx
      Y(N%)=yy
      H(N%)=hh
      V(N%)=vv
      ENDPROC
      REM Hmmm
      REM now that the image coordinates are stored, we can move it and redefine the borders
      DEFPROCpastepic(num%,nx,ny)
      LOCAL tx%,ty%,th%,tv%
      N%=num%
      tx%=X(N%)
      ty%=Y(N%)
      th%=H(N%)
      tv%=V(N%)
      RECTANGLE tx%,ty%,th%,tv% TO nx,ny

      X(N%)=nx
      Y(N%)=ny
      ENDPROC
      REM seems to work the same?
      DEFPROCmovepic(num,nx,ny)
      LOCAL tx%,ty%
      tx%=X(N%)
      ty%=Y(N%)
      RECTANGLE SWAP tx%,ty%,H(num),V(num) TO nx,ny

      X(N%)=nx
      Y(N%)=ny
      ENDPROC
      REM color "F"or"B", "color name number or R G B"
      REM this was created to manage special colors and to hold onto the original first 2 pallets (as I use them all the time)
      DEF PROCcolor(fb$,rgb$)
      IF rgb$="0" OR rgb$="black" THEN rgb$="000,000,000"
      IF rgb$="1" OR rgb$="red" THEN rgb$="200,000,000"
      IF rgb$="2" OR rgb$="green" THEN rgb$="000,200,000"
      IF rgb$="3" OR rgb$="yellow" THEN rgb$="200,200,000"
      IF rgb$="4" OR rgb$="blue" THEN rgb$="000,000,200"
      IF rgb$="5" OR rgb$="magenta" THEN rgb$="200,000,200"
      IF rgb$="6" OR rgb$="cyan" THEN rgb$="000,200,200"
      IF rgb$="7" OR rgb$="white" THEN rgb$="200,200,200"
      IF rgb$="8" OR rgb$="grey" THEN rgb$="056,056,056"
      IF rgb$="9" OR rgb$="light red" THEN rgb$="248,056,056"
      IF rgb$="10" OR rgb$="light green" THEN rgb$="056,248,056"
      IF rgb$="11" OR rgb$="light yellow" THEN rgb$="248,248,056"
      IF rgb$="12" OR rgb$="light blue" THEN rgb$="056,056,248"
      IF rgb$="13" OR rgb$="light magenta" THEN rgb$="248,056,248"
      IF rgb$="14" OR rgb$="light cyan" THEN rgb$="056,248,248"
      IF rgb$="15" OR rgb$="light white" THEN rgb$="248,248,248"
      PRIVATE assemble$,br%,bg%,bb%
      assemble$=rgb$
      br%=VAL(MID$(assemble$,1,3)):bg%=VAL(MID$(assemble$,5,3)):bb%=VAL(MID$(assemble$,9,3))
      IF fb$="f" OR fb$="F" THEN COLOUR 0,br%,bg%,bb% : GCOL 0
      IF fb$="b" OR fb$="B" THEN COLOUR 1,br%,bg%,bb% : GCOL 128+1
 
« Last Edit: Aug 24th, 2016, 05:05am by michaelgallup » User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls