SCREEN1 = SYSVAR @ JSROM

Anything QL Software or Programming Related.
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: SCREEN1 = SYSVAR @ JSROM

Post by dilwyn »

pjw wrote:If you can define a shape as a blob, theres an inbuilt routine to fill it with any colour or texture, in any mode. I dont know what limitations the routine has re size, memory or efficiency, but it might be worth investigating.
May be of interest - Silvester on here wrote a piece of code for SMSQ/E so that the pixel colour read should work in modes beyond 4 and 8, this should allow the equivalent basic functions in other toolkits such as RPXL% of Easyptr 4 to work now too.
(not tried it myself, and can't remember if it was just making the colour reading work, or or if it allowed the reference colour seeking up/down/left/right etc to work too).

The code was meant to be added to SMSQ?E at some fairly recent stage, but not go the documentation to hand to check


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: SCREEN1 = SYSVAR @ JSROM

Post by pjw »

tofro wrote:the above algorithm is (from a pure FILL perspective) actually one of the most efficient ones - It guarantees that every pixel to be filled is only visited exactly once.
Youre right: Its fantastic! No need to look further ;) To check out your claim that it visits each pixel only once, I did some (non-scientific) tests, and I have to agree with you. Thats like a Holy Grail of fill routines, if the discussions Ive seen on the topic are anything to go by.

I tried changing the newColor bit to take info from a bitmap graphic, a _pic, instead, and it filled any shape with the corresponding portion of the graphic. Very nice :) I havent tried any really complex shapes yet, but so far its not run out of stack on any shape Ive thrown at it.
The drawing could be made faster, though.
You mean things like drawing a line rather than a dot, for example?
(And the whole thing reminds me a bit of playing "The Hobbit" on the ZX Spectrum as a kid. I believe they used a very similar way of filling areas :) )
But hardly as efficient as this routine, which must be quite recent, unless they had some secret algos unavailable to the public.
What you're linking to seems to be more complicated because it wants to support a pattern fill.
This routine could be made to do that, AFAICS.


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: SCREEN1 = SYSVAR @ JSROM

Post by pjw »

dilwyn wrote:.. May be of interest - Silvester on here wrote a piece of code for SMSQ/E so that the pixel colour read should work in modes beyond 4 and 8, this should allow the equivalent basic functions in other toolkits such as RPXL% of Easyptr 4 to work now too.
(not tried it myself, and can't remember if it was just making the colour reading work, or or if it allowed the reference colour seeking up/down/left/right etc to work too).

The code was meant to be added to SMSQ?E at some fairly recent stage, but not go the documentation to hand to check
That would be great! Seems a bit silly to have the command dangling in there, when it doesnt actually work in GD2 colour modes.

Would be great if "someone" (probably better not me) could fix the FILL feature in SMSQ/E too, as it simply crashes the system on larger screen sizes. Possibly it could "just" be a matter of making the table and routines operate on long words instead of words.


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Post by tofro »

pjw wrote:I havent tried any really complex shapes yet, but so far its not run out of stack on any shape Ive thrown at it.
ATM, the routine uses an arbitrary value for the stack array (2048 FP numbers) - This is obviously pretty generous for simple shapes (the "ring" in the example uses as much as 4 entries in there...), but filling complex shapes with lots of edges (like a screenful of text) could outgrow this. That is why I was looking for a more dynamic data structure. Maybe pipes could be used, they can grow and shrink dynamically.
pjw wrote:
The drawing could be made faster, though.
You mean things like drawing a line rather than a dot, for example?
Exactly there I would start optimizing - simply needs another x1 variable to hold the starting x of the line that was found by leftLoop. Once the end x1 is found (in rightLoop), draw the complete scanline in one single BLOCK.

Other optimizations could be work as much as possible in integer variables. I was simply too lazy for that - It's hot round here this weekend.

@Tomas: How about translating this into assembler? ;)

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,
@Tomas: How about translating this into assembler?
Reading this, my confidence is getting higher, thank you.
I like your algo of `scan-flood' combined fill, using best of the both.

In fact, I am struggling with MODE 8 for BLOCK at the moment, as it is 4 pixels per word, I use MOD 4 to get lead and trail pixels, solid fill count, and 4 complement to get masks, then I double x, so I count pixels 0,1,2...256, instead of 0,2,...,512.

I am not happy with my coding, as it seems still need some more understanding, reason I share only small snipets, here.

Surely, people here are proficient coders, unlike me, but I will try as an exercise, too.
I am influenced by Oberon system, where I also spend some time, and I find easier to recode from, to QL assembly, along SuperBASIC structured as Wirthian language, too, than other languages.

Tomas


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: SCREEN1 = SYSVAR @ JSROM

Post by stevepoole »

Hi,
Back in the early eighties, there was some mention of sprites and vectorised text in QL magazines.

Intrigued, I wrote a few protoype programs to explore the field.
Sprites of any size, filled imbricated shapes and curves, outline-searching, etc. It all worked, albeit slowly, in standard superbasic (no PEEK or POKEing), from DATA.

I dropped the quest after developing vector fonts of ANY size, based on ANY QL fonts loaded in memory. But QL World weren't interested, so things stopped there.
Such vectorised fonts are now extensively used by general press magazines, so I guess they could have proved useful at the time...

If anyone would like any of these prototypes, I will let them have them... Machine-coded,they might have been very fast...
The filling routines worked by first searching for outlines, then filling inwards concentrically. This was necessary for imbricated designs.... such as an '8'.

Best Wishes,
Steve Poole.


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi Steve,
I dropped the quest after developing vector fonts of ANY size
Marvellous work, perhaps quite ahead of its time.

I was also thinking of vector fonts vs raster, as I toy with ZX font set on the QL. I remember hair vectors on early X workstations, no fills, only straight lines and arcs (possibly some curves).
`Combat Zone / Tank Duel 3D' ZX games had similar font, in my opinion.

Then came, type setting founts for newspapers, as you say.

Tomas


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,

I have consolidated my coding, so I now have this, leaving filled CIRCF, ELIPF, in favour of common FILL. It is not much, but can possibly become a basis of something more interesting. Still cannot rotate ellipse nor do arcs. I can observe that circles in MODE 8 become ellipses, right?

Code: Select all

; Simple graph primitives mode 4/8
; ===================================
; (c)2019 tcat <thomas.kral@email.cz>
; version 1.0

; From CALL in SuperBASIC

; PLOT    - CALL [start],[x],[y],[col]
; MODE    - CALL [start+2],[mode]
; FILL    - CALL [start+4],[on/off],[col]
; BLOCK   - CALL [start+8],[x],[y],[col],[w],[h]
; LINE    - CALL [start+12],[x],[y],[col],[x0],[y0]
; POLY    - CALL [start+16],[col],[adr=[x,y]..,-1]
; CIRC    - CALL [start+20],[x],[y],[col],[r]
; ELIP    - CALL [start+24],[x],[y],[col],[w/2],[h/2]
; CHAR    - CALL [start+28],[x],[y],[col],[ch]
; on entry        D1,D2,..D5
;                 mode - 0/8 (bit3)
;                 x,y,x0,y0 - coords
;                 w,h - width, height
;                 col - colour, r - radius
; on exit         [start+32].L=debug output

; NOTE
; QL screen is organised by words in 4/8 modes
; 512x256, 8 pixels per word, 128/64 bytes/words per line
; 256x256, 4 pixels per word, ditto
; Routines tested under SuperBASIC, to be later run without QDOS
;  making use of 2nd VRAM, requires real QL h/w, may not work emulated

start    bra.s    plot              ;$00
         bra.s    mode              ;$02
         bra      fill              ;$04
         bra      block             ;$08
         bra      line              ;$0c
         bra      poly              ;$10
         bra      circ              ;$14
         bra      elip              ;$18
         bra      char              ;$1c
out      ds.l     1                 ;$20
dctl     dc.b     %00000000         ;Display control copy
         ;bit7= $20000/$28000
         ;bit3= mode 4/8
         ;bit1= blank
         ;bit0= fill 0/1
White curve is meant a circle radius of 50.
Circle is Elliipse
Circle is Elliipse
Tom


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: SCREEN1 = SYSVAR @ JSROM

Post by RWAP »

Cicrles should appear as circles in both mode 4 and mode 8.

However, you have to bear in mind that the number of X pixels in mode 8 is half that of mode 4 which is probably what is causing the issue.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Post by tofro »

What might be a bit confusing is that SuperBASIC actually hides this fact in its pixel coordinate system - It still appears as if the QL had 512 pixels in x in mode 8 - SuperBASIC just halves the x coordinates before drawing, so if you want to mimic this behavior you should do as well.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply