Author |
Topic: 'Bouncy Balls' (BB4W/BBCSDL) (Read 559 times) |
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
 |
'Bouncy Balls' (BB4W/BBCSDL)
« Thread started 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%
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #1 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.
--
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #2 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.
--
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #3 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.
--
|
|
|
|
michael
Senior Member
member is offline
Posts: 335
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #4 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. :(
|
|
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
meneer
New Member
member is offline
Posts: 5
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #5 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?
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #6 on: Feb 21st, 2017, 1:11pm » |
|
on Feb 13th, 2017, 8:41pm, David Williams wrote:
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.
--
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #7 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.
--
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #8 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.
|
|
Logged
|
|
|
|
meneer
New Member
member is offline
Posts: 5
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #9 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
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #10 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.
--
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #11 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.
--
|
|
|
|
meneer
New Member
member is offline
Posts: 5
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #12 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
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #13 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.
--
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: 'Bouncy Balls' (BB4W/BBCSDL)
« Reply #14 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.
--
|
|
Logged
|
|
|
|
|
