The Sinclair QL Forum

Posted: **Fri Jul 12, 2019 10:16 am**

Does the very same POKE, just hidden in a BASIC extension.

Tobias

Posted: **Fri Jul 12, 2019 2:44 pm**

tofro wrote:Does the very same POKE, just hidden in a BASIC extension.

And less flexible. It only allows for square-shaped pixels or the standard 512x256 on a 3:2 screen.
What if you have a Q68 with 1024x768 on a 16:9 monitor?
(the value to POKE can be calculated by dividing (Xresolution/Yresolution) by the width/height ratio of your monitor, so 1024x768 on a 16:9 monitor would yield 1.33/1.78 = 0.75).

Jan

Posted: **Mon Jul 15, 2019 11:21 am**

Hi,

I am thinking of some simple graphics format.

I have started with the one below, making use of the simple raster ops, I have coded so far. With a certain level of detail however, the data may become increasingly big. Then perhaps some RLE encoded bitmap image would be taking less space? Seeking advice.

Code: Select all

gfx_dta  dc.w     0,0               ;x,y offset
         dc.b     'f',1             ;fill on
         dc.b     'p',7             ;poly
         dc.b     40,54,20,60
         dc.b     40,66,60,60
         dc.b     40,54,-1
         dc.b     'f',0,7           ;fill off
         dc.b     'p',1             ;poly
         dc.b     40,54,20,60
         dc.b     40,66,60,60
         dc.b     40,54,-1
         dc.b     'f',1             ;fill on
         dc.b     'p',2             ;poly
         dc.b     40,20,36,60
         dc.b     40,100,44,60
         dc.b     40,20,-1
         dc.b     'f',0,2           ;fill off
         dc.b     'p',1             ;poly
         dc.b     40,20,36,60
         dc.b     40,100,44,60
         dc.b     40,20,-1
         dc.b     'a',40,20,5,'N'   ;alpha char
         dc.b     'a',35,90,5,'S'   
         dc.b     'a',20,50,5,'W'   
         dc.b     'a',52,64,5,'E'   
         dc.b     -1                ;gfx dta end

When processed in a loop (sort of simple gfx interpreter), it renders this. I try to keep in bytes (rather than words), and apply offsets during rendering which I hope can save on memory space. Looking for a better idea.

: graphics; gfx.png (9.44 KiB) Viewed 7097 times

Many thanks.
Tomas

Posted: **Tue Jul 16, 2019 7:43 pm**

Hi,

Testing the graphics interpreter, can now process all elements by definition, including new lines in strings, glad I have learnt how to add. I know, is not exactly a stunning hi-res image, but is best, I can do at the moment.

Code: Select all

         ...
         dc.b     's',72,20,7       ;string
         dc.b     'Compass rose',10,10
         dc.b     'bearings to North',10
         dc.b     'bearings to East',10
         dc.b     'bearings to West',10
         dc.b     'bearings to South',0
         ...

: compass rose

The `gfx_dta' is some 240 bytes for the above, sligthly bigger to teh earlier one with just 80 bytes. I wonder what it takes to make a simple editor, outputting `gfx_dta' format. Not sure I can do in assembly, but will try in SuperBASIC.

Tomas

Posted: **Sun Dec 22, 2019 5:57 pm**

Hi,

It's Xmas, pleasant time to do some QL coding. Trying to put together some basic routines to interface to assembly coded earlier. I keep drawing in a rather minimal window 128x128 pixels, that is 2048 bytes when stored as an image, or possibly even less when stored as `gfx' data as defined above.
Ideally providing sketched pictures, maps for adventure text games, that is my challenge currently. A game engine so far non-existent. But I like the idea of `Legend of the Sword' for ATARI ST.

: Simple Draw in SuperBASIC

Now I am thinking how to make the `Draw' prog, put out `gfx' format, or even allow editing it. `gfx' consists of series of elements. As the elements may be viewed as piled, one on top of another, some sort of list or an array may be needed in basic code to reference them?

Tomas

Posted: **Wed Jan 01, 2020 9:47 am**

: SnowMan 2020; snowman.png (11.36 KiB) Viewed 6261 times

Posted: **Fri Jan 03, 2020 10:12 am**

the elements may be viewed as piled, one on top of another, some sort of list or an array may be needed in basic code to reference them

For a start, I can think of this simple data abstraction. Keeping array of pointers allows undo, redo, `bring to top', operations to be easily implemented. I leave editing of elements for a moment.

: Array of element pointers; data_abstraction.png (19.01 KiB) Viewed 6190 times

Tomas

Posted: **Fri Jan 03, 2020 10:34 am**

Really nice work so far, Tomas!

Some comments (and maybe proposals you might want to consider):

Absolute pointers become meaningless when you are storing the picture to disk or move it about in memory - think about relative pointers (or "unique IDs" - see below).
You will be spending a byte for the graphics element type. Code more information into that byte other than "circle, block, polygon, point". Think of "filled circle", "pattern-filled block",... to waste less memory
Think of composite elements - Actually, a polygon is a list of points. Once you're there, you can define graphic elements much more sophisticated (and "group" and "ungroup" them).
Your "address pointer" array defines the z-order (i.e. what element draws on top of other elements). Be prepared to have routines that want to change the order of the pointers in there. That tends to become pretty tricky when working with relative pointers
It might be useful to seperate the graphic elements list - Instead of having a general list of elements, store circles, blocks and points (and whatever else) in separate lists. Memory management will be way easier.
You might want to assign a "unique ID" to each graphic element - That's much easier to handle than pointers.
Once you have an ID per element, that can be used as a key and opens up the way into hash tables for elements - That is going to be much easier and faster than messing with pointers on the presentation layer.
When you start coding such a thing in SuperBASIC, instead of using "traditional" variables to hold your elements, POKE and PEEK them to/fro ALCHPed memory blocks and code retrieval and setter functions - That makes it surprisingly easy to transform such a program from SuperBascic into Assembly

Tobias

Posted: **Fri Jan 03, 2020 3:48 pm**

tofro wrote:Really nice work so far, Tomas!
..

Agreed. Keep going!

Posted: **Sat Jan 04, 2020 1:39 pm**

Hi, Tobias, Per,

Thanks for encouragement and very helpful ideas to consider. Re pattern block fill, I can do this so far,

Code: Select all

; middle / left / right words - MODE 8 / 4 pixels per word
andi.w   #$3333,b8_mw(a4)  ;mw pattern
andi.w   #$3333,b8_lw(a4)  ;lw pattern
andi.w   #$3333,b8_rw(a4)  ;rw pattern

The above trails vertical stripes in foreground colour, I paint only foreground (logical OR) for simplicity.
I think other variants of so called stipples, may require to rotate #$3333 by 2 pixs on every scan line. Or leaving out odd scan lines with solid fill for horizontal stripe pattern.
Right?

: Stipples; stipple.png (6.12 KiB) Viewed 6103 times

EDIT 6/1/2020
I have added these lines to handle basic stipple patterns, in each scan line I logically AND pattern with colour, and optionally SWAP D0 register halves.

Code: Select all

         ; Patterns
p11      move.w   #$cccc,d0         ;chequered / or
         swap.w   d0                ;vert. stripes
         move.w   #$3333,d0
         bra.s    b8_hl

p22      clr.w    d0                ;solid / or
         swap.w   d0                ;horiz. stripes
         move.w   #-1,d0

Tomas

The Sinclair QL Forum

SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM

Re: SCREEN1 = SYSVAR @ JSROM