Tobias Fröschle wrote: > Folks, > > I am currently getting myself accustomed again to programming using the > pointer interface after years of inactivity. > I would like to hear how the cracks would tackle a problem I have where > I have some alternative solutions for. > (My programs are SuperBasic, liberated or Turbo-ed) > > How do you draw graphics in the pointer coordinate system (a typical > application would be things like rubber-banding or a shape drawing > program)? The options I currently see are as follows: > > 1. Use the Graphics coordinate system - Here I find it next to > impossible to find a perfect match between pixel coordinates and > graphic coordinates using SCALE (Or am I just doing something > wrong?). I'm doing something like SCALE #channel,windowHeight%, > 0, 0 and POINT x,y-windowHeight%. This (at least sometimes) hits > the spot, but not with acceptable accurracy - the point plotted is > always a bit off the pointer position. Advantage is, you can use > INK, PAPER, and he like and have all the graphics drawing for > circles and arcs available > 2. Use BLOCK - this hits the spot perfectly, because it uses pixel > coordinates. You can also take advantage of INK and PAPER and the > like, but need to write your own routines for drawing shapes, > rectangles, arcs, lines. This could end up in a huge pile of work, > the program could also tend to be slow with implementation of > these primitives in SuperBASIC. > 3. Use the "Draw line of blobs/sprite" functionality from PE. Uses > the pixel coordinate system, so we'd be safe with pixel accuracy - > Cannot use INK, PAPER and the like, because you define the colour > in the sprite. You'd need to have an assortment of pixel-sized > sprites in order to be able to draw in different colours. Shapes > like rectangles and circles are not available as well and need to > be emulated. > 4. Use own, machine code-based SuperBasic extensions to plot and draw > in the pixel coordinate system. Not sure whether I would want to > tackle this one, especially if I want my program to be able to run > both on "standard" QLs and GD2-Based systems (Or is there > something already available - I'm not aware of such an extension - > There was an article in an old QL world, part of the DIY toolkit, > but this would hardly work in a GD2-based environment. > > What's common practice? Like to hear some recommendations. > > Regards > Tobias > _______________________________________________ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm > > > > Now we have discussed this before - search the archive for SCALE.
Anyway, the main suggestion was: I will let you know how Q-Route does it (now here is a secret) - I rewrote BASIC versions of all the graphics commands I needed to allow access to them using the absolute co-ordinate system: The following takes absolute co-ordinates and converts them to the current graphics co-ordinate system: 2000 WINDOW #2,512,256,0,0 2010 graf_scale=100:SCALE #2,graf_scale,0,0 2020 window_x%=0:window_y%=0:window_h%=256:window_w%=256 2024 wind_scalex=(1/window_w%)*(graf_scale*(100/window_h%*window_w%/135.5)) 2028 wind_scaley=(1/window_h%)*graf_scale Now having set it up, we can convert absolute co-ords to graphics co-ords (remembering that one is upside down to the other), 3512 DEFine PROCedure RFLINE(linex1,liney1,linex2,liney2) 3516 LINE #2,linex1*wind_scalex,(window_h%-liney1)*wind_scaley TO linex2*wind_scalex,(window_h%-liney2)*wind_scaley 3520 END DEFine The constant 135.5 is close enough to the constant mentioned in the Reference Manual - it is just a matter of scaling the display to 512x256. In later versions of smsq/e the constant is not a constant anymore, but a variable, located in the CON driver linkage at position $14a and it's called pt_asprt. -- Rich Mellor RWAP Services URL:http://www.rwapsoftware.co.uk URL:http://www.rwapservices.co.uk _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
