SCREEN1 = SYSVAR @ JSROM
Re: SCREEN1 = SYSVAR @ JSROM
Does the very same POKE, just hidden in a BASIC extension.
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
- janbredenbeek
- Super Gold Card
- Posts: 633
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: SCREEN1 = SYSVAR @ JSROM
And less flexible. It only allows for square-shaped pixels or the standard 512x256 on a 3:2 screen.tofro wrote:Does the very same POKE, just hidden in a BASIC extension.
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
Re: SCREEN1 = SYSVAR @ JSROM
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.
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.
Many thanks.
Tomas
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
Many thanks.
Tomas
Re: SCREEN1 = SYSVAR @ JSROM
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.
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
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
...
Tomas
Re: SCREEN1 = SYSVAR @ JSROM
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.
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
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.
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.
Re: SCREEN1 = SYSVAR @ JSROM
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.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:35 am, edited 1 time in total.
Re: SCREEN1 = SYSVAR @ JSROM
Really nice work so far, Tomas!
Some comments (and maybe proposals you might want to consider):
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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: SCREEN1 = SYSVAR @ JSROM
Agreed. Keep going!tofro wrote:Really nice work so far, Tomas!
..
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: SCREEN1 = SYSVAR @ JSROM
Hi, Tobias, Per,
Thanks for encouragement and very helpful ideas to consider. Re pattern block fill, I can do this so far,
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?
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.
Tomas
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
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?
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