Brandy BASIC V

[John]

Here is an FloodFill example from the RosettaCode site. (BBC BASIC)

A flood fill is a way of filling an area using color banks to define the contained area or a target color which "determines" the area (the valley that can be flooded; Wikipedia uses the term target color). It works almost like a water flooding from a point towards the banks (or: inside the valley): if there's a hole in the banks, the flood is not contained and all the image (or all the "connected valleys") get filled.

To accomplish the task, you need to implement just one of the possible algorithms (examples are on Wikipedia). Variations on the theme are allowed (e.g. adding a tolerance parameter or argument for color-matching of the banks or target color).
Unfilledcirc.png

Testing: the basic algorithm is not suitable for truecolor images; a possible test image is the one shown on the right box; you can try to fill the white area, or the black inner circle.

Note: BBC BASIC has a built-in flood fill statement, but to satisfy the terms of the task it is not used in this example.
 

Code: [Select]

REM FloodFill - RosettaCode BBC BASIC

t = TIME
MODE 32
GCOL 15
CIRCLE FILL 640, 512, 500
GCOL 0
CIRCLE FILL 500, 600, 200
GCOL 3
PROCflood(600, 200, 15)
GCOL 4
PROCflood(600, 700, 0)
PRINT "Time taken = ";(TIME - t) / 100;" seconds"
END
                                               
DEF PROCflood(X%, Y%, C%)
LOCAL L%, R%
  IF POINT(X%,Y%) <> C% ENDPROC
   L% = X%
   R% = X%
   WHILE POINT(L%-2,Y%) = C% : L% -= 2 : ENDWHILE
   WHILE POINT(R%+2,Y%) = C% : R% += 2 : ENDWHILE
   LINE L%,Y%,R%,Y%
   FOR X% = L% TO R% STEP 2
     PROCflood(X%, Y%+2, C%)
     PROCflood(X%, Y%-2, C%)
   NEXT
ENDPROC


[Mike Lobanovsky]

I'm not very sure but my speculation is that

Code: [Select]

MODE 32will only set the color bitness (32=True Color) within the window it draws to while

Code: [Select]

ORIGIN 800,600might set the [X,Y] point that drawing is supposed to start from.

I think these statements do not however account for why the [0,0] coordinate (point of origin) should be at the bottom left corner of canvas instead of its top left which is conventional for MS Windows graphics. This makes BB4W graphics code incompatible with other languages of the platform. Is there any way to tell the language to flip its axes before plotting?

Neither do they account for why the plot should be so small. Obviously BB4W uses some coordinate units other than pixels (perhaps twips?) or else applies scaling world transforms before actually plotting a point on the canvas.

Perhaps David can enlighten us on this subject? Graphics capabilities are my primary interest in a language. 

[Mike Lobanovsky]

John,

Thanks a lot for the effort of course but unfortunately this manual does not give a single answer to the questions I posed. It was top notch back in circa 1990 for 10MHz 8086 PC XT's with 10MB HDD's and color graphics adapters for some $1,300 apiece if you were lucky enough but it looks discouraging today with its incomplete support for 256 color palette graphics. Sorta counter-advertising, I'd say...

MODE 32 must have its own peculiarities this manual doesn't cover so my request to David still holds true.

[John]

100 Doors

Problem: You have 100 doors in a row that are all initially closed. You make 100 passes by the doors. The first time through, you visit every door and toggle the door (if the door is closed, you open it; if it is open, you close it). The second time you only visit every 2nd door (door #2, #4, #6, ...). The third time, every 3rd door (door #3, #6, #9, ...), etc, until you only visit the 100th door.

Question: What state are the doors in after the last pass? Which are open, which are closed?

Code: [Select]

t = TIME
DIM doors%(100)

FOR pass% = 1 TO 100
  FOR door% = pass% TO 100 STEP pass%
    doors%(door%) = NOT doors%(door%)
  NEXT door%
NEXT pass%

FOR door% = 1 TO 100
  IF doors%(door%) PRINT "Door " ; door% " is open"
NEXT door%

PRINT "Time taken = ";(TIME - t) / 100;" seconds"

ScriptBasic

Code: [Select]

SPLITA STRING(101,"0") BY "" TO doors

FOR pass = 1 TO 100
  FOR door = pass TO 100 STEP pass
    doors[door] = NOT doors[door]
  NEXT door
NEXT pass

FOR door = 1 TO 100
  IF doors[door] THEN PRINT "Door ", door, " is open.\n"
NEXT door

jrs@laptop:~/sb/sb22/test$ time scriba doors.sb
Door 1 is open.
Door 4 is open.
Door 9 is open.
Door 16 is open.
Door 25 is open.
Door 36 is open.
Door 49 is open.
Door 64 is open.
Door 81 is open.
Door 100 is open.

real   0m0.005s
user   0m0.004s
sys   0m0.000s
jrs@laptop:~/sb/sb22/test$

FWIW The SB time is calculated starting from the load of scriba at the command line and ending when it exits back to Linux. The BBV version is only calculating the time it is executing the program.

I'm also thinking of extending the ScriptBasic SDL extension module I already have and piece meal in the BBV features. 

[David Burnard]

Thanks Mike,

I'll include the saucer in future releases of Napoleon Brandy.

To answer your points,

The Co ordinate system in BBC Basic is true Cartesian, so X & Y axes are as per graph paper, graphical units are logical , originally 1280 x 1024 on the BBC Micro so the same co ordinates were used irrespective of the actual resolution, the logical units used were double the maximum physical resolution possible (640 x 512) on the Acorn Archimedes. It has become a de facto standard to have a 2:1 ratio on resolutions higher than that - so 800 x 600 uses logical co ordinates of 1600 x 1200 for it's plotting commands (I don't know why this is so, and it is possible to force a one to one ratio with the newer form of the RISC OS , MODE command (this is not supported by the SDL version).

The problem with the SDL version of Brandy Basic is that the Graphics primitives are mapped to SDL drawing primitives, which appear to be very slow! for my DOS and Windows port I wrote my own graphics functions to act directly upon a bitmap. The Bitmap is then Blitted to the screen , by use of an interval timer (50Hz under windows, DOS timer tick interrupt under DOS). This also mean't I could implement more (eventually all) of the BBC VDU plotting codes, these are clearly defined in the RISC OS Programmers reference manual.


The SDL library appears to include a fast and efficient Bit Blit function, I already have linux code to start a thread and initialize a 50 Hz timer so by linking my code with the SDL library a fast linux version could also be produced by blitting the memory bitmap to the screen. Keyboard handling code for linux would also need to be added, the existing code understands keyboard scancodes so I have a windows function to convert windows keystroke messages to scancodes, a similar function would be needed for SDL, It may be possible to reuse the keyboard code from the existing SDL version.

 

[David Burnard]

Hi Mike,

Screen Modes themselves are provided by the operating system and are not technically part of BBC BASIC, they are so fundamental though that when porting to other systems they must be implemented, these evolved during the development of the BBC Micro, Acorn Archimedes, Risc PC and then when finally RISC OS was separated from the hardware a universal MODE command was devised.

The BBC BASIC pdf, John sent you was from 1999, at that time the hardware did not support a 256 colour palette, later hardware did! and RISC OS was updated to support it, the palette handling existed already in the form of VDU 19 which had thoughtfully been given additional parameters for future expansion in the original BBC Micro. The Risc OS Programmers reference manual v5 is the reference tome I use. Mode 32 is technically a 256 colour screen mode, which has a fixed default palette, hence the limited colours in johns mandelbrot demo. If you wish to use a palette use the MODE"X800,Y600 C256" command or use MODE"X600,Y600 C32K" or  MODE"X600,Y600 C16M" for true colour with no palette, the new form of the command is present a stub in the original version of the Brandy code, and is fully implemented in my Windows version. Also colours can be specified using R,G,B values -> GCOL 0,r,g,b

Palette changes can be effected with VDU 19,Logical colour number, 16, r,g,b

You might want to run up My basic and look at the mandelbrot demo from it.

BBC Basic for windows handles the palette/colour selection issue in different manner - INKEY(-256) gives a machine/OS number
87 indicates BB4W so I rewrote the demo from rosetta code to run on both.

[David Burnard]

Screen Modes defined in Brandy (derived from RISC OS screen Modes)


Mode 0  640 x 256  - 2   colours 1280 x 1024,  80  x 32  Chars
Mode 1  320 x 256  - 4   colours 1280 x 1024,  40  x 32  Chars
Mode 2  160 x 256  - 16  colours 1280 x 1024,  20  x 32  Chars
Mode 3  Text Only  - 2   colours            ,  80  x 25  Chars - > with gaps
Mode 4  320 x 256  - 2   colours 1280 x 1024,  40  x 32  Chars
Mode 5  160 x 256  - 4   colours 1280 x 1024,  20  x 32  Chars
Mode 6  Text Only  - 2   colours            ,  40  x 25  Chars - > with gaps
Mode 7  TeleText   - 8   colours            ,  40  x 25  Chars
Mode 8  640 x 256  - 4   colours 1280 x 1024,  80  x 32  Chars
Mode 9  320 x 256  - 16  colours 1280 x 1024,  40  x 32  Chars
Mode 10 640 x 250  - 2   colours 1280 x 1000,  80  x 32  Chars
Mode 11 640 x 250  - 4   colours 1280 x 1024,  80  x 25  Chars
Mode 12 640 x 256  - 16  colours 1280 x 1024,  80  x 32  Chars
Mode 13 320 x 256  - 256 colours 1280 x 1024,  80  x 32  Chars
Mode 14 640 x 250  - 16  colours 1280 x 1000,  80  x 25  Chars
Mode 15 640 x 256  - 256 colours 1280 x 1024,  80  x 32  Chars
Mode 16 1056 x 256 - 16  colours 2112 x 1024,  132 x 32  Chars
Mode 17 1056 x 250 - 16  colours 2112 x 1000,  132 x 25  Chars
Mode 18 640 x 512  - 2   colours 1280 x 1024,  80  x 64  Chars
Mode 19 640 x 512  - 4   colours 1280 x 1024,  80  x 64  Chars
Mode 20 640 x 512  - 16  colours 1280 x 1024,  80  x 64  Chars
Mode 21 640 x 512  - 256 colours 1280 x 1024,  80  x 64  Chars
Mode 22 768 x 288  - 16  colours 768  x 576 ,  96  x 36  Chars
Mode 23 1152 x 896 - 2   colours 2304 x 1792,  144 x 56  Chars
Mode 24 1056 x 256 - 256 colours 2112 x 1024,  132 x 32  Chars
Mode 25 640 x 480  - 2   colours 1280 x 960 ,  80  x 60  Chars
Mode 26 640 x 480  - 4   colours 1280 x 960 ,  80  x 60  Chars
Mode 27 640 x 480  - 16  colours 1280 x 960 ,  80  x 60  Chars
Mode 28 640 x 480  - 256 colours 1280 x 960 ,  80  x 60  Chars
Mode 29 800 x 600  - 2   colours 1600 x 1200,  100 x 75  Chars
Mode 30 800 x 600  - 4   colours 1600 x 1200,  100 x 75  Chars
Mode 31 800 x 600  - 16  colours 1600 x 1200,  100 x 75  Chars
Mode 32 800 x 600  - 256 colours 1600 x 1200,  100 x 75  Chars
Mode 33 768 x 288  - 2   colours 1536 x 1152,   96 x 36  Chars
Mode 34 768 x 288  - 4   colours 1536 x 1152,   96 x 36  Chars
Mode 35 768 x 288  - 16  colours 1536 x 1152,   96 x 36  Chars
Mode 36 768 x 288  - 256 colours 1536 x 1152,   96 x 36  Chars
Mode 37 896 x 352  - 2   colours 1792 x 1408,  112 x 44  Chars
Mode 38 896 x 352  - 4   colours 1792 x 1408,  112 x 44  Chars
Mode 39 896 x 352  - 16  colours 1792 x 1408,  112 x 44  Chars
Mode 40 896 x 352  - 256 colours 1792 x 1408,  112 x 44  Chars
Mode 41 640 x 352  - 2   colours 1280 x 1408,   80 x 44  Chars
Mode 42 640 x 352  - 4   colours 1280 x 1408,   80 x 44  Chars
Mode 43 640 x 352  - 16  colours 1280 x 1408,   80 x 44  Chars
Mode 44 640 x 352  - 256 colours 1280 x 1408,   80 x 44  Chars
Mode 45 640 x 200  - 4   colours 1280 x  800,   80 x 25  Chars
Mode 46 640 x 200  - 16  colours 1280 x  800,   80 x 25  Chars


I have defined additional screen modes for my own use in the Windows version ->

Mode PC Bios screen mode + 48 yields the matching BIOS screen mode

eg PC BIOS mode 0x12 -> 640x480 80x25 chars
eg PC BIOS mode 0x13 -> 320x200 40x25 chars
 
eg PC BIOS mode 0x8 -> 720x342 90x29 chars (when used with MSHERC.COM on DOS)

PS. if anyone has an MDA/Hercules monitor they could donate it would be appeciated

[David Burnard]

John,

You said you were not going to start a bit bucket project!  now you have !!!

How do you intend to implement Shadow screen modes?
and a working palette in non true colour modes?
and what about teletext (mode 7) ?

To select a shadow screen mode add 128 to the screen mode number. Then use *FX 113 and *FX 112 to select the Displayed screen bank and the screen bank to write to!! See my graphbank.nap example.

For Custom size screen modes use     

MODE "X600,Y600 C16M":MODE MODE+128

to set a Shadow mode. (replace the 600's with numbers divisible by 8 of your choice)

I really think you should consider starting from my code base for your linux version, unless you're aspirations are very limited.
Is it just that the linux build is broken at the mo? shouldn't take too much to get it to build again.

I think you'll come to appreciate the effort I have already put in when you get to start coding !!

Anyway you have my code to crib from if you don't want to use it as a start point -> have fun

[Mike Lobanovsky]

Thank you very much, David,

Your information is finely detailed and very well presented and tells me much more than the manual that John sent.

I'm pouring your Napoleon from SourceForge right into my PC now and I'll come back to you for more info as soon as I've tasted its flavor. 

Best regards,

[David Burnard]

John

Bit confused about the flood fill demo,

Colour/ GCOL format in MODE 32 (256 colour modes is)
BBGGRR


so
colour  0   is Black
colour  3  is Bright Red
colour  4   is Dark Green
colour  15 is Bright yellow

so your final image from this program should be red (colour 3) following the PROCflood(600, 200, 15) replacing the yellow with a dark green inner  from the PROCflood(600, 700, 0) -> your image is yellow with a green inner suggesting the  PROCflood(600, 200, 15) did not execute.

[David Burnard]

By the way mike

COLOUR Logical Colour,R,G,B

 is a synonym for

VDU 19,Logical Colour,16,R,G,B

it's detailed in the ref manual

if you change the C16M for C256 in the mandelbrot demo it will this thus still work

run it then

execute

VDU 20

 at the command prompt, this resets the palette to default.

[Mike Lobanovsky]

Thanks David,

I'm still playing back the samples (haven't looked into the sources yet) and I confirm it's very, very nimble.





I'm not yet ready to discuss but I certainly like what I see.

[David Burnard]

What OS are you using Mike?

You can edit a program be typing edit<return> at the prompt ,
this dumps the code into notepad, edit it there then save the changes as you exit
run the edited program from the prompt by typing run<return>

This worked from Win95 through to Windows 7 -> broken in windows 8

I think I've fixed the windows 8 issue ready for release in v0.00.10 but I don't have a copy of windows 8 to test it on!!

[Mike Lobanovsky]

My current dev platform is still 32-bit WinXP Sp3 Pro. It's very finely tuned to my needs and frankly I hate to see it die in a few months. I also own legit distros of 32-bit Vista Ultimate Sp1 and 7 Ultimate Sp1 as well as 64-bit 7 Ultimate Sp1 and 8 Consumer Preview and have them all installed and timely updated on my workstation on dedicated HD drives. My eldest son also owns a legit 64-bit 8.1 but we meet each other only about once a month.

So I have an opportunity to test and debug all my projects under any existing Windows environment in real time keeping my butt in my armchair. You can PM me your binary and test suite to try it under my 8 CP before you release it to public, if you like.

[David Burnard]

Thanks Mike,

Nice to meet someone who actually wants to help :-)

When I'm ready to release my next code I'll do just that, provided I still don't have a copy of 8 of course.

I'm using XP sp3  and VCC 6.0 myself, DJGPP for the DOS build on the same machine
running on a 2.1Ghz  athlon 64 - lol

My PC at uni runs Windows 7 enterprise ed.