SCREEN1 = SYSVAR @ JSROM

Anything QL Software or Programming Related.
User avatar
tofro
QL Wafer Drive
Posts: 1919
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Postby tofro » Fri Jul 12, 2019 10:16 am

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

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
janbredenbeek
Gold Card
Posts: 381
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SCREEN1 = SYSVAR @ JSROM

Postby janbredenbeek » 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


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » 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.

gfx.png
graphics
gfx.png (9.44 KiB) Viewed 1849 times

Many thanks.
Tomas


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » 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
         ...

rose.png
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


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » 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.

leo.png
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
Last edited by tcat on Fri Jan 03, 2020 10:52 am, edited 1 time in total.


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » Wed Jan 01, 2020 9:47 am

snowman.png
SnowMan 2020
snowman.png (11.36 KiB) Viewed 1013 times


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » 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.

data_abstraction.png
Array of element pointers
data_abstraction.png (19.01 KiB) Viewed 942 times

Tomas
Last edited by tcat on Fri Jan 03, 2020 10:35 am, edited 1 time in total.


User avatar
tofro
QL Wafer Drive
Posts: 1919
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Postby tofro » Fri Jan 03, 2020 10:34 am

Really nice work so far, Tomas!

Some comments (and maybe proposals you might want to consider):
  1. 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).
  2. 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
  3. 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).
  4. 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
  5. 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.
  6. You might want to assign a "unique ID" to each graphic element - That's much easier to handle than pointers.
  7. 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.
  8. 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
Super Gold Card
Posts: 664
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: SCREEN1 = SYSVAR @ JSROM

Postby pjw » Fri Jan 03, 2020 3:48 pm

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

Agreed. Keep going!


Per
Be wary of large West-Coast corporations bearing gifts!
- Ancient Trojan proverb
tcat
Super Gold Card
Posts: 605
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » 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?

stipple.png
Stipples
stipple.png (6.12 KiB) Viewed 855 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



Who is online

Users browsing this forum: No registered users and 2 guests