BBC BASIC for Windows
Programming >> Graphics and Games >> 'Bouncy Balls' (BB4W/BBCSDL)
http://bb4w.conforums.com/index.cgi?board=graphics&action=display&num=1486539277
'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 8th, 2017, 06:34am

Code:
      REM "Bouncy Balls" // v1.00 (08-Feb-2017)
      REM Tested with BB4W, BBCSDL (Win32), BBCSDL Android (ARM).
      REM Not yet tested with BBCSDL under Mac OS-X or Linux.

      REM There is currently no VSync ("Vertical Synchronization"),
      REM so the animation is unlikely to be as smooth as it could be.

      REM +-------------------------------------------------------------------+
      REM |                                                                   |
      REM |  This code is experimental and is not intended to be instructive  |
      REM |                                                                   |
      REM +-------------------------------------------------------------------+

      ON ERROR PROCerror

      HIMEM = LOMEM + 2*&100000 : HIMEM = (HIMEM + 7) AND -8

      Balls% = 50

      Wait% = TRUE : REM Setting to FALSE may improve performance (results in higher CPU usage)

      REM -------------------------------------
      BB4W% = (INKEY(-256) == &57)
      IF BB4W% THEN
        GetTicks$ = "GetTickCount"
        SetWindowText$ = "SetWindowText"
      ELSE
        GetTicks$ = "SDL_GetTicks"
        SetWindowText$ = "SDL_SetWindowTitle"
      ENDIF
      REM -------------------------------------
      REM This code segment is the work of RTR:
      p = PI
      CASE !^p OF
        WHEN &2168C235: cpu$ = "x86"
        WHEN &54442D18: cpu$ = "ARM"
        OTHERWISE: QUIT
      ENDCASE
      REM -------------------------------------

      WinW% = 640
      WinH% = 480
      VDU 23,22,WinW%;WinH%;8,16,16,0 : OFF

      DIM bmp{a%, w%, h%}
      bmp% = FNCreateBMP_RGB565(WinW%, WinH%)
      bmp.a% = bmp% + 70
      bmp.w% = WinW%
      bmp.h% = WinH%

      S% = FNmalloc(2000)

      CASE cpu$ OF
        WHEN "x86":
          $S%="60C7401CFFFFFFFF8B78143B78040F8DC00000008B70183B70080F8DB40000008B480C8B501083F9007D03F7D99083FA007D03F7DA90F7D93BF90F8E94000000"
          $S%+="F7DA3BF20F8E8A000000F7D9F7DAC7401C00000000C7402000000000C7402400000000C740280000000089482C8950308978348970388BEF03E93B68047E0D2B"
          $S%+="680429682CC74020FFFFFFFF83FF007D1429782801782CC7403400000000C74020FFFFFFFF8BEE03EA3B68087E0D2B6808296830C74020FFFFFFFF83FE007D14"
          $S%+="297024017030C7403800000000C74020FFFFFFFF61C3"
          ClipBitmap%=FNmcode(S%)
          $S%="608BF88BC325FFFF00008BD8C1E3100BC3B900580200FCF3AB61C3"
          Clr16_640x480%=FNmcode(S%)
          $S%="6083EC208B53048B7B088950048978088B51048B790889500C8978108B510C8B7910895014897818FF10F7401CFFFFFFFF0F85530000008B1B8B098B7804893C"
          $S%+="24D124240FAF7838037834D1E703FB8B700C89742404D16424040FAF7024037028D1E603F18B502C8B683033C9668B044E66A9FFFF74046689044F413BCA7CED"
          $S%+="033C24037424044D75E183C42061C3"
          Plot%=FNmcode(S%)
          $S%="608BF88BF30FAFD133ED0FB604AF0FB65CAF010FB64CAF0269C01F1F000069DB3F3F000069C91F1F0000C1E81083D000C1EB1083D300C1E91083D100C1E305C1"
          $S%+="E10B0BC30BC16689046E453BEA7CBB61C3"
          ConvBmRGB565%=FNmcode(S%)
        WHEN "ARM":
          $S%="FF5F2DE900C0E0E31CC080E504B080E27E009BE8010055E1FF9FBDA8020056E1FF9FBDA8030075E1FF9FBDD8040076E1FF9FBDD894D08FE594E08FE500D0A0E3"
          $S%+="00E0E0E31CD080E520D080E50070A0E30080A0E30390A0E104A0A0E103B085E001005BE101B04BC00B9049C020E080C5000055E3058048B0059089B00050A0B3"
          $S%+="20E080B504B086E002005BE102B04BC00BA04AC020E080C5000056E3067047B006A08AB00060A0B320E080B5247080E5288080E52C9080E530A080E5345080E5"
          $S%+="386080E504D09FE504E09FE5FF9FBDE80000000000000000"
          ClipBitmap%=FNmcode(S%)
          $S%="FF5F2DE9BCD08FE5BCE08FE50118A0E12118A0E1011881E10120A0E10230A0E10240A0E10250A0E10260A0E10270A0E10280A0E10290A0E102A0A0E102B0A0E1"
          $S%+="02C0A0E102D0A0E102E0A0E11E1EA0E3FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8"
          $S%+="FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC7FA0E8FC03A0E8011051E2E4FFFF1A04D09FE5"
          $S%+="04E09FE5FF9FBDE80000000000000000"
          Clr16_640x480%=FNmcode(S%)
          $S%="FF5F2DE9044091E5085091E5046092E5087092E50C8092E5109092E5044080E5085080E50C6080E5107080E5148080E5189080E500C090E53CFF2FE11CC090E5"
          $S%+="00005CE3FF9FBD18001091E5002092E5245090E5287090E52C8090E5309090E534A090E538B090E550D08FE550E08FE59BA42AE08A1081E0957627E0872082E0"
          $S%+="FFC0A0E30CC48CE10030A0E3B35092E10C0015E1B3508111023083E2880053E1F9FFFFBA862082E0841081E0019059E2F4FFFF1A04D09FE504E09FE5FF9FBDE8"
          $S%+="0000000000000000"
          Plot%=FNmcode(S%)
          $S%="FF5F2DE9930202E00030A0E3FFA0A0E354B09FE554C09FE5035190E725680AE025740AE005800AE09C0606E09C0707E09C0808E02668B0E10060A6E22778B0E1"
          $S%+="0070A7E22888B0E10080A8E2878288E1868588E18340A0E1B48081E1013083E2020053E1EBFFFFBAFF9FBDE81F1F00003F3F0000"
          ConvBmRGB565%=FNmcode(S%)
        OTHERWISE: QUIT
      ENDCASE

      REMbinpath$ = @dir$ + "binaries/" + cpu$ + "/"
      REMClipBitmap%    = FNLoadData( binpath$ + "clipbitmap_"            +cpu$+".dat" )
      REMClr16_640x480% = FNLoadData( binpath$ + "clr16_640x480_"         +cpu$+".dat" )
      REMBPlot%         = FNLoadData( binpath$ + "bplot16_"               +cpu$+".dat" )
      REMPlot%          = FNLoadData( binpath$ + "plot16_"                +cpu$+".dat" )
      REMConvBmRGB565%  = FNLoadData( binpath$ + "convbmrgb8888torgb565_" +cpu$+".dat" )

      DIM ball{(Balls%-1) x, y, dx, amp, theta}
      DIM ballBm{a%, w%, h%}
      REMballBm.a% = FNLoadData( @dir$ + "ball_64x64_32bpp.bmp" )
      ballBm.w% = 64
      ballBm.h% = 64
      ballBm.a% = FNmalloc( 4 * ballBm.w% * ballBm.h% )
      x0% = ballBm.w% / 2
      y0% = ballBm.h% / 2
      maxD_sq% = x0%^2 + y0%^2
      maxR_sq% = (ballBm.w%/2 - 1)^2
      FOR Y% = 0 TO ballBm.h%-1
        FOR X% = 0 TO ballBm.w%-1
          d_sq% = (x0%-X%)^2 + (y0%-Y%)^2
          IF d_sq% <= maxR_sq% THEN
            k = 1-(d_sq%/maxD_sq%)
            R% = k * &FF
            G% = k * &B0
            B% = k * &30
            !(ballBm.a% + (Y%*ballBm.w% + X% << 2)) = &10000*R% OR &100*G% OR B%
          ENDIF
        NEXT
      NEXT
      A% = ballBm.a% : REM source 32bpp bitmap
      B% = A%        : REM dest 16bpp bitmap buffer
      C% = ballBm.w%
      D% = ballBm.h%
      CALL ConvBmRGB565%

      FOR I% = 0 TO Balls%-1
        ball{(I%)}.x = RND(WinW% - ballBm.w%) - 1
        ball{(I%)}.dx = (0.05 + 0.2*RND(1)) * SGN(RND(1)-0.5)
        ball{(I%)}.theta = 2*PI*RND(1)
        ball{(I%)}.amp = 100 + RND(WinH%)
        ball{(I%)}.y = 0
      NEXT I%

      clipVars% = FNmalloc( 64 )
      bfVars% = FNmalloc( 16 )
      bmVars% = FNmalloc( 32 )
      clipVars%!0 = ClipBitmap%
      bfVars%!0 = bmp.a%
      bfVars%!4 = bmp.w%
      bfVars%!8 = bmp.h%
      bmVars%!0 = ballBm.a%
      bmVars%!4 = ballBm.w%
      bmVars%!8 = ballBm.h%
      pass% = FALSE

      REPEAT
        SYS GetTicks$ TO t0%
        A% = bfVars%!0
        B% = &188E : REM dark blue (RGB565)
        CALL Clr16_640x480%
  
        IF pass% THEN
          A% = clipVars%
          B% = bfVars%
          C% = bmVars%
          FOR I% = 0 TO Balls%-1
            bmVars%!12 = ball{(I%)}.x
            bmVars%!16 = ball{(I%)}.y
            CALL Plot%
          NEXT I%
        ELSE
          pass% = TRUE
        ENDIF
  
        OSCLI "MDISPLAY "+STR$~bmp%
  
        IF Wait% THEN WAIT 1
  
        SYS GetTicks$ TO t1%
  
        dt% = t1% - t0%
  
        FOR I% = 0 TO Balls%-1
          ball{(I%)}.x += dt% * ball{(I%)}.dx
          ball{(I%)}.y = ball{(I%)}.amp*ABSSINball{(I%)}.theta
          ball{(I%)}.theta += dt% * 0.001
          IF ball{(I%)}.x < -32  THEN
            ball{(I%)}.x = -32
            ball{(I%)}.dx *= -1
          ENDIF
          IF ball{(I%)}.x > WinW%-32 THEN
            ball{(I%)}.x = WinW%-32
            ball{(I%)}.dx *= -1
          ENDIF
        NEXT
  
      UNTIL FALSE
      END

      DEF PROCerror
      CLS : ON : SOUND 1, -15, 200, 3
      COLOUR 15, 255, 255, 255 : COLOUR 15
      PRINT '" " + REPORT$ + " at line " + STR$ERL
      COLOUR 15, 200, 200, 200
      PRINT ''" Closing in 3 seconds...";
      WAIT 300
      QUIT
      ENDPROC

      DEF FNCreateBMP_RGB565(W%, H%)
      LOCAL A%, S%
      S% = 70 + 2*W%*H%
      DIM A% S%+15
      A% = ((A% + 7) AND -8) + 2
      A%?0 = ASC"B"
      A%?1 = ASC"M"
      A%!2 = S%
      A%!10 = 70
      A%!14 = 56
      A%!18 = W%
      A%!22 = H%
      A%?26 = 1
      A%?28 = 16
      A%!30 = 3
      A%!34 = 2*W%*H%
      A%!38 = 11808
      A%!42 = 11808
      A%!54 = &0000F800
      A%!58 = &000007E0
      A%!62 = &0000001F
      = A% : REM Bitmap data starts at A%+70

      DEF FNLoadData( f$ )
      LOCAL A%, F%, S%
      F% = OPENIN( f$ )
      IF F% = 0 THEN PRINT "Can't load "+f$ : WAIT 200 : QUIT
      S% = EXT#F%
      CLOSE#F%
      DIM A% S%+15
      A% = (A% + 7) AND -8
      OSCLI "LOAD """ + f$ + """ " + STR$~A%
      = A%

      DEF FNmalloc( N% )
      LOCAL A%
      DIM A% N%+15
      A% = (A% + 7) AND -8
      = A%

      DEF FNmcode(S%)
      LOCAL A%, I%
      A%=FNmalloc(LEN$S%)
      FOR I%=0 TO LEN$S%DIV2-1
        A%?I%=EVAL("&"+MID$($S%,2*I%+1,2))
      NEXT
      =A%
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 8th, 2017, 3:49pm

An attempt at 16bpp RGB565 colour blending to draw semi-transparent bitmaps/sprites. Works with BB4W & BBCSDL:

http://pastebin.com/2p3GpPM6

http://pastebin.com/kYJXKvwv


EDIT 1: The ball sprites look 'greener' under Android (ARM), probably due to a bug in the ARM version of the RGB8888-to-RGB565 conversion routine.

EDIT 2: Aforementioned bug now fixed.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 9th, 2017, 05:01am

Some (unscientific) speed comparisons between BB4W on Intel Celeron-based laptop vs. BBCSDL on ARM-based Moto G4 smartphone.

Bitmap buffer dimensions and colour depth: 640x480 16bpp (RGB565)

Clear 640x480 bitmap/frame buffer:
x86: 12655 clears per sec.
ARM: 10436 clears per sec.

(I was rather surprised by that result, although I was even more surprised by the next result):

Write a 640x480 bitmap to buffer:
x86: 2447 writes per sec.
ARM: 3082 writes per sec.

This is the last time ARM beats Intel in these tests.

Plot semi-transparent 64x64 bitmaps, random opacities:

x86: 34010 per sec.
ARM: 14600 per sec.


Actually displaying the 640x480 bitmap buffer via *MDISPLAY:

BB4W: 324 per sec.
ARM: 111 per sec.
BBCSDL (Win32): 24 (!) per sec.


UPDATE: *MDISPLAY (via SDL) renders around 200 320x256 RGB565 frames per second on my Moto G4, and looks pretty good too. Of course, no one wants to actually display 200 frames/sec (it should be limited to 60 Hz, typically), but it indicates that there's a fair amount of headroom for sprite plotting and calculations, etc.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 13th, 2017, 8:41pm

My final offering:

"Vector Balls" - BB4W regulars will have seen this all before, but I've been experimenting a lot with BBCSDL Android (ARM). This animation works very nicely on my Moto G4.

http://pastebin.com/usZSyDb8

Scroll down the page to the 'RAW Paste Data' section, then be sure to select ALL of the program, copy and paste into the BB4W/BBCSDL IDE.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by michael on Feb 14th, 2017, 02:28am

Very cool. I installed the arm version of bbcsdl on my samsung Galaxy, but when bbc starts it shows a light screen then stops. Perhaps my samsung is too old. :(
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by meneer on Feb 17th, 2017, 12:32pm

This was fun and running fast enough to make some sort of scrolling game.
Through my work phone ( Moto G4 play ) is a bit slow.


David,
Do you have something to make readable bitmap files?
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 21st, 2017, 1:11pm

on Feb 13th, 2017, 8:41pm, David Williams wrote:
My final offering:


For a game project, I needed a fast-ish filled circle plotter, so I wrote one in x86 and ARM assembly language. Still a lot of room for improvement as far as code efficiency is concerned, but this will have to do for now. Here's a demo of it (it performs pretty well on my Moto G4)...

EDIT (1): Oops. Code didn't work when copied & pasted. Will attempt to re-post it here again later. Sorry for any inconvenience caused.

EDIT (2): Pastebin link (scroll to bottom of page to the 'RAW Paste Data' section then select ALL of the code in the box, then copy and paste it into the BB4W/BBCSDL IDE:

http://pastebin.com/39TeLRbP (link dies after 1 month)


Meener asked: "Do you have something to make readable bitmap files?"

All I have is a bit of code for loading a 32bpp BMP image and converting it to the 16bpp RGB565 (or, oddly, 32bpp ARGB8565) format required by my sprite plotters.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 21st, 2017, 3:14pm

Speed comparison between "CIRCLE FILL" and my filled circle plotting routine. Same sets of random positions, radii and colours. I have tried to keep the test(s) as fair as possible.

Laptop PC (Intel Celeron) Windows 10

BASIC's "CIRCLE FILL" command:
Constant colour : 2189 circles/sec.
Random colour: 1973 circles/sec.

Custom routine:
Constant colour : 5592 circles/sec.
Random colour: 5517 circles/sec.




Motorola Moto G4 (Android)

BASIC's "CIRCLE FILL" command:
Constant colour : 266 circles/sec.
Random colour: 10 circles/sec. (!)

Custom routine:
Constant colour : 4258 circles/sec.
Random colour: 4324 circles/sec. (slightly weird result, but it varies somewhat)


The reason for the miserable figures on Android for "CIRCLE FILL" is that rendering of large circles is VERY slow. In this test, the radii vary randomly from 1 to 500 pixels.

On Intel/Windows, the custom routine is about twice as fast, whereas on Android (ARM), it is many times faster.

Hence the need for my own filled circle plotting routine!



Here's a link to the speed test program for those interested:

http://pastebin.com/a2VQuq17


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 21st, 2017, 7:11pm

With a constant radius for all circles (48 pixels), and the circles constrained such that they all fit inside the 360x640 program window, I get the following timings:

Laptop PC (Intel Celeron) Windows 10

BASIC's "CIRCLE FILL" command:
Constant colour : 7685 circles/sec.
Random colour: 7170 circles/sec.

Custom routine:
Constant colour : 38919 circles/sec.
Random colour: 37765 circles/sec.


Motorola Moto G4 (Android)

BASIC's "CIRCLE FILL" command:
Constant colour : 321 circles/sec.
Random colour: 41 circles/sec. (!)

Custom routine:
Constant colour : 20299 circles/sec.
Random colour: 19573 circles/sec.


With better programming, including a vastly improved horizontal line filler (the current one is hugely suboptimal on both x86 & ARM architectures), one could perhaps double (at least) the throughput of the custom routine.

Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by meneer on Feb 22nd, 2017, 07:25am

David,

The G4 values are quite different than my Moto G4 play variant.
(whis is logical as the G4 play is based on the G3 hardware)

CIRCLE FILL command
Constant Colour : 262 circles/sec
Random colour : 1 circles/sec

Custom filled-circle route
Constant Colour : 3295 circles/sec
Random color : 3314 circles/sec


My Sony Xperia does it slighty better.

CIRCLE FILL command
Constant Colour : 283 circles/sec
Random colour : 23 circles/sec

Custom filled-circle route
Constant Colour : 4905 circles/sec
Random color : 4855 circles/sec

I have tried to load an 32bpp BMP file including the alpha channel using the FNloaddata included in the examples but it doesn't display correctly.



Jeroen
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 22nd, 2017, 12:22pm

on Feb 22nd, 2017, 07:25am, meneer wrote:
The G4 values are quite different than my Moto G4 play variant.
(whis is logical as the G4 play is based on the G3 hardware)

[...]

My Sony Xperia does it slighty better.

[...]


Thanks for running the test program on your mobile devices.

I should explain that the main purpose of making the filled circle plotter, and the triangle plotter that I will be coding tonight at work, is so that my programs can generate their own simple graphics more efficiently. Although my circle plotter seems faster than BASIC/SDL on Android, it is actually intrinsically very slow for large and partially clipped circles! This is mostly because of the simplistic clipping that it performs; it calculates all the points along the circle edge, even if those points lie outside the viewport. This is very wasteful for large circles. For a circle of 500 pixels radius, it calculates and individually clip-tests all 2*PI*r (3142) points around the circle's edge, whereas a more sophisticated algorithm just 'processes' the visible points of the circle. My triangle/quad plotter will suffer from a similar problem.


Quote:
I have tried to load an 32bpp BMP file including the alpha channel using the FNloaddata included in the examples but it doesn't display correctly.


Most of those sprite/bitmap plotters of mine (which are only experimental), only handle RGB565 bitmaps, so you would load in your 32bpp BMP image using (for example) FNLoadData, and then convert it to the required RGB565 format (which ignores your alpha mask!), or to 32bpp ARGB8565 (8 bits alpha, 5 bits red, 6 green, 5 blue) which can be plotted using PlotAlphaBlend (which I haven't yet released). I will post some example code in a few hours.

I should point out that my little graphics library, aimed primarily at Android, is an absolute pig to use, and I really don't recommend it unless you have masochistic tendencies. I couldn't figure out how to pass parameters to my ARM machine code routines using BASIC's CALL command, as in:

CALL PlotSprite, bufVars%, bmAddr%, bmW%, bmH%, x%, y%

I know it must be possible, because that's how the ARM binary version of SORTLIB works.

I'm not having much luck with SYS either!

I know it's early days, and perhaps documentation will come our way at some point, although some of the signals coming from Richard recently in regard to the future development of the Android edition of BBCSDL makes me wonder if it's worth continuing my own explorations with it.

I'll post some code shortly.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 22nd, 2017, 1:51pm

Jeroen,

Here is some example code for loading in a BMP32 bitmap image (with alpha mask), and plotting it using 'PlotAlphaBlend':

http://pastebin.com/uukx85QJ

You will need the 72x72 BMP32 test image:

http://www.proggies.uk/temp/ball72x72.zip

The Zip folder also contains the example program and the original PNG image that I converted to BMP32. The PNG image came from openclipart.org .

As you can see, quite a bit of faffing around is needed just to plot some sprites. Sorry about that!


BTW, I should have mentioned in the program somewhere, that the width and height of a BMP image can be obtained by reading the 32-bit values at offsets 18 and 22 in the BMP header. In the case of the example program:

ballW% = ball%!18
ballH% = ball%!22


EDIT: Here's a slightly modified version of the example program which plays around with the BMP's alpha mask to produce a 'fuzzy' effect:

http://pastebin.com/c8Z7tJLH



David.
--


Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by meneer on Feb 23rd, 2017, 12:38pm

David,

I have succesfully managed to read 32bit BMP files with Alpha values.
Thanks.

I will make some demo to see if I can make a scrolling gaming field filled with tiles.

Cheers,
Jeroen
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 23rd, 2017, 8:26pm

Demo of filled triangle plotting routine, intended for BBCSDL (Android), but works with BB4W:

http://pastebin.com/h2m70R9Q

Compare performance (especially on Android) with this version which uses BASIC's PLOT 85 to draw the triangles:

http://pastebin.com/xp89yEgs

In the case of BBCSDL (Android), my plotter seems hundreds of times faster (at least on my Moto G4), even though it's actually very inefficient.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 24th, 2017, 4:44pm

Semi-transparent triangles (random opacities):

http://pastebin.com/JMCjPtUZ


To do: quad poly plotter, thick line plotter, bitmap supersampling code, image blur, and lots of other bits and pieces.

Hopefully Richard will at some point implement SYS for the ARM variant of BBCSDL for calling machine code routines, so that parameters can be pulled off the stack as with the x86 version of BB4W. In ARM BBC BASIC V (etc.), the SYS statement loads parameters directly into selected registers, which is usually very convenient.


David.
--
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 24th, 2017, 8:37pm

Semi-transparent triangles & circles over a colourful background. Works nicely on my Android phone (Motorola Moto G4).

http://pastebin.com/cK3GMipJ
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 25th, 2017, 12:53am

Same program as previous, but now with an FPS indicator.

http://pastebin.com/ZKnKBjaR

I get 32 fps (average) on my Moto G4, which isn't bad considering that all the graphics is software-rendered (no hardware acceleration) on a relatively slow processor. More efficient colour-blending code (for both x86 and ARM architectures) ought to at least double the speed of the rendering.


David.
--


Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Feb 28th, 2017, 1:26pm

Thick lines with round endpoints:

http://pastebin.com/zvUAwMG8
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Mar 3rd, 2017, 11:17pm

Rotating blue flowers (x86 & ARM bitmap rotation test):

http://pastebin.com/uS3Yqvgs


Tested under BB4W, BBCSDL Win32, BBCSDL Android (ARM).
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Mar 6th, 2017, 03:25am

http://pastebin.com/2Wvzr1ZW
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Mar 6th, 2017, 07:44am

http://pastebin.com/80JPHQUs

http://pastebin.com/Fqu1E6Km
Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Mar 9th, 2017, 08:39am

Continuing my development of a little software graphics library for a possible Android game project, here's a flood fill demo (the 'flower' shape is flood-filled in real-time). Very sub-optimal (especially for ARM processors), but fast enough for my needs.

http://pastebin.com/keXeYHs4

Re: 'Bouncy Balls' (BB4W/BBCSDL)
Post by David Williams on Apr 11th, 2017, 12:35am

The following YouTube video is a summary of my experiments with BBCSDL on an ARM-based Android device. Something seems to be messing up the colour gradients (possibly with the video capture software which I downloaded minutes before making the video!). There is some inevitable 'colour banding' due to the reduced colour bit depth imposed by SDL (16bpp as opposed to the usual 24- or 32bpp), but something went very wrong and the colour banding/quantization problem isn't actually as bad as what is portrayed in the video.

https://youtu.be/C2vl-bN5OnE