AmigaBASIC to QB64pe question out of left field

[CharlieJV]

I somehow manage to lose my evening by getting transfixed on AmigaBASIC's "AREA" statement.

Anybody have enough AmigaBASIC experience to let me know if I have it straight in my head what AREA does and how it would be translated to QB64pe?

Here's my guess on a couple samples:

Code: (Select All)

<<AREA "(25,10) - (50,20) - (0,20)">>
PSET (25,10) : AreaStartX = POINT(0) : AreaStartY = POINT(1)
LINE - (50,20)
LINE - (0,20)
LINE - (AreaStartX, AreaStartY)

<<AREA "(50,25) - STEP (20,15) - STEP (-10,15) - STEP (-10,-10)">>
PSET (50,25) : AreaStartX = POINT(0) : AreaStartY = POINT(1)
LINE - STEP (20,15)
LINE - STEP (-10,15)
LINE - STEP (-10,-10)
LINE - (AreaStartX, AreaStartY)

I did some shorthand there.  In AmigaBASIC, the first example would look like 

Code: (Select All)

AREA (25,10)
AREA (50,20)
AREA ( 0,20)
AREAFILL 0

The AreaStartX and AreaStartY stuff, that's in case the first set of coordinates are prefixed by STEP.

[mnrvovrfc]

http://www.pjhutchison.org/basic/graphics.html

Heads up! It's not a secure site.

This "AREA" seems to be like "LINE" giving one coordinate at a time, but one doesn't have to offer the first point again for the polygon, before using "AREAFILL".

[RhoSigma]

As old Amiga user still until today I can tell your workaround is good for drawing the shape of a polygon.

However, the AREA statements were not to draw a shape but a filled polygon using the "Blitter" (abrev. for "Block image transferer") which was at that time (late 80s) blazingly fast processing upto 80 million pixels per second. So to emulate that you would also need a PSET anywere into the drawn shape and then do a PAINT. I tried that once too, but often had problems that PAINT was leaking over the shape and flooding the whole screen, so I was looking for an alternative.

The alternative I found was this http://alienryderflex.com/polygon_fill/

From the theory and sample described there I created my polygon.bm library which is part of my "Libraries Collection" here https://qb64phoenix.com/forum/showthread.php?tid=1033

[CharlieJV]

As old Amiga user still until today I can tell your workaround is good for drawing the shape of a polygon.

However, the AREA statements were not to draw a shape but a filled polygon using the "Blitter" (abrev. for "Block image transferer") which was at that time (late 80s) blazingly fast processing upto 80 million pixels per second. So to emulate that you would also need a PSET anywere into the drawn shape and then do a PAINT. I tried that once too, but often had problems that PAINT was leaking over the shape and flooding the whole screen, so I was looking for an alternative.

The alternative I found was this http://alienryderflex.com/polygon_fill/

From the theory and sample described there I created my polygon.bm library which is part of my "Libraries Collection" here https://qb64phoenix.com/forum/showthread.php?tid=1033

Thank-you much!

Yeah, I decided to componentize AREA into the two parts: the shape, the filling.

I just wanted to make sure I fully understood the shape part first before diving into the filling.  (Divide and conquer, 'cause trying to process all of it is way too much for this kid.)

Now I feel okay looking into the filling part.  Thank-you much for the resource !  I look forward to diving into it.

[bplus]

So the "Areas" are border lines to an enclosed polygon? Is that basically it? So Areas must close itself by drawing a line from last to first?

Polygon filling without Paint is interesting subject, I think you can do it with filled triangles.

[CharlieJV]

http://www.pjhutchison.org/basic/graphics.html

Heads up! It's not a secure site.

This "AREA" seems to be like "LINE" giving one coordinate at a time, but one doesn't have to offer the first point again for the polygon, before using "AREAFILL".

Too funny!

That's the web page I stumbled upon (I have no idea how I got there) and got me so interested in AREA that looking into the statement largely consumed my Friday evening.

[RhoSigma]

@bplus
Each AREA statement defines exactly one corner point of the polygon and you don't return to the startpoint, that's implied to close the polygon.

Then optional a PATTERN statement can define a fill pattern and finally AREAFILL triggers filling of the polygon and by that resets the entire AREA point sequence.

AREA/AREAFILL
https://archive.org/details/Amiga_BASIC_...ew=theater
PATTERN
https://archive.org/details/Amiga_BASIC_...ew=theater

[CharlieJV]

@SMcNeill
Each AREA statement defines exactly one corner point of the polygon and you don't return to the startpoint, that's implied to close the polygon.

Then optional a PATTERN statement can define a fill pattern and finally AREAFILL triggers filling of the polygon and by that resets the entire AREA point sequence.

AREA/AREAFILL
https://archive.org/details/Amiga_BASIC_...ew=theater
PATTERN
https://archive.org/details/Amiga_BASIC_...ew=theater

Ooooo, that is good info.  Such good stuff.

Thank-you for taking the time!

[CharlieJV]

All of this got me thinking about metaprogramming macros to help convert statements/functions from one BASIC implementation to code that is GW-BASIC/QBasic/QB64PE (and BAM) compatible .

That's really out of QB64PE-focused topic, so I dropped that in a place that is more appropriate.  If you are interested in that kind of stuff: Metaprogramming in BAM: a code generation example

[Kernelpanic]

All of this got me thinking about metaprogramming macros to help convert statements/functions from one BASIC implementation to code that is GW-BASIC/QBasic/QB64PE (and BAM) compatible .

It nothing really has to be compatible with GW-Basic and QBasic (beyond the compatibility of QB64pe). Maintaining compatibility with QuickBasic and QBasic is OK, but it really doesn't need to be more.

It reminds me of Netscape. Websites should also be compatible with Netscape, although its market share lay been around 1%. Pointless work for people who were unable to break away from outdated ideas but still demanded an "extra soup".