Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
And this is a shame, although I would agree the image on screen may not benefit a great deal from the increased colours it would be nice to be able to print out to a printer that can use 24 bit colour and I'm not sure we can do this if we can't display them ( I'm not sure we can do this even if we could display them). Well, I personally have never seen a printer language supporting more than eight distinct colours. Thene again, I never saw command sets for dye subblimation printers or newer inkjets. Joachim
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
I disagree that 24bit colour precision is not necessary. Many file formats support that and it would be best if we could be compatible. Not to mention ported applications ;-) There has been extensive reseach about the number of colours man can see. If I remeber correctly, 16 bits was enough to cover this. Whether the colours we can see match the 16bit palette is something different though. In any case compatibility is not the problem as the colours can be converted. Also, the quality of many monitors is not quite high enough to accurately display colours, not to mention the problems with matching colours between different screens and printers. Joachim
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Joachim Van der Auwera wrote: And this is a shame, although I would agree the image on screen may not benefit a great deal from the increased colours it would be nice to be able to print out to a printer that can use 24 bit colour and I'm not sure we can do this if we can't display them ( I'm not sure we can do this even if we could display them). Well, I personally have never seen a printer language supporting more than eight distinct colours. Thene again, I never saw command sets for dye subblimation printers or newer inkjets. Joachim Well I suppose the point could be made that printers get along by mixing up three to five colours anyway, the results though are good enough for most people's eyes. My Epson 740 can turn out onto photo paper stuff from my Kodak digi that is as good as anything your going to get from Boots and definitely better than Trueprint. I can now download and store images from my digi camera to my Q40 ( thanks Simon ) I'm not sure I can load the file into a Q40 program and print it out to the same standard as using Paintshop pro or something on my PC, but I would dearly love to. Having said that I do have Paragraph would that do it I wonder?. I do need to get down to using the Q40 more than I do, the last two years have been so hectic with one thing and another I have lost touch, haven't made the subgroup for four months now. Speaking of Paragraph, it has gone a little quiet, does anyone know if Francios is still working on this? all the best - Bill
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
On 11 Nov 2001, at 16:04, Phoebus R. Dokos wrote: 1. I remember Marcel saying something about the x87 code being added and there might be an incompatibility with my AMD Hmm, I use it with 3 amds (2 athlons, 1 K6) and no problem. 2. The other one is maybe the DirectX in conjunction with my graphics drivers might be corrupting QPC and 3. My SMSQ.bin file might be corrupted (I don't have a way to test that) Get a fresh copy off jochen's website wolfgang - www.wlenerz.com
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
On 9 Nov 2001, at 10:12, Phoebus R. Dokos wrote: Good :-) Then half the work I thought was needed is done :-) I am still though continuing my quest to get a 100% definite answer on the modes of the QPC/QXL/Aurora/Q40 and how colours are coded on the screen memory. That is if they use the same way to calculate RGB values on the same colour depth modes? Probably not. I've started to have a look at this. QPC (in 65536 colour mode, i.e. Mode32) stores the colour values in the screen memoey as follows: 16 bits per pixel gggrbggg Apparently, QPC doesn't (yet?) have a true 24 bit mode. I haven't had time to check for the Q40/QXL. Wolfgang - www.wlenerz.com
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
At 11:00 ðì 10/11/2001 +0100, you wrote: On 9 Nov 2001, at 9:29, Phoebus R. Dokos wrote: Hello again and thanks for everyone that responded to my previous question. The question now is: Is it possible to place the text cursor ABSOLUTELY according to a given window or the screen (that is without using @#!@$~~!@## SCALE) Sure, just use Cursor CURSOR CURSOR allows the screen cursor to be positioned anywhere in the window attached to the specified or default channel. CURSOR uses the pixel coordinate system relative to the window origin and defines the position for the top left hand corner of the cursor. The size of the cursor is dependent on the character size in use. If CURSOR is used with four parameters then the first pair is interpreted as graphics coordinates (using the graphics coordinate system) and the second pair as the position of the cursor (in the pixel coordinate system) relative to the first point. This allows diagrams to be annotated relatively easily. syntax: x:= numeric_expression y:= numeric_expression CURSOR [channel,] x, y [,x ,y] example: CURSOR 0,0 CURSOR 20,30 CURSOR 50,50,10,10 wolfgang Well it DOESN'T WORK ! At least NOT for me for some reason. The problem with Scale is NOT THE vertical, that is correct. The problem is the horizontal. It doesn't provide precision. If you want I can send you my code to see for yourself Phoebus - www.wlenerz.com
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
At 12:45 ìì 10/11/2001 +, you wrote: Joachim Van der Auwera wrote: I've started to have a look at this. QPC (in 65536 colour mode, i.e. Mode32) stores the colour values in the screen memoey as follows: 16 bits per pixel gggrbggg On the Q40, it is grbl where l is a luminance value, You in fact use 6 bits for each of the colours, and when the lower bit is set on two or three of the colours, then l is true. Then build the colour using the most significant five bits only (for some demo code, look in the PROforma sources, pf_driv_QVME_c and the the ColourNearest routines. I personally don't think there is any point in having 24 bits colour precision except for some applications. We don't come near to having anything which properly uses 16 bit colour. And this is a shame, although I would agree the image on screen may not benefit a great deal from the increased colours it would be nice to be able to print out to a printer that can use 24 bit colour I do not agree with you Bill :-) Extra colours usually make up for loss in resolution. (ie they fool the eye). The more precisely you can get to a shade, the most the human brain tends to disregard deficiencies in resolution. (A good example is sub-pixel (AND whole pixel) Anti-Aliasing where by using extra shades you make up for jagged edges etc) Additionally we DO have apps that use properly 16 bit colour. Jerome's SpriteED, PovRay, Claus' 3D editor/viewer, Photon, PhotoQL, and of course ProWesS :-) (And that's not counting my crappy software I currently make :-) and I'm not sure we can do this if we can't display them ( I'm not sure we can do this even if we could display them). Yes we can. Linedesign for example already allows this and there's no problem with PovRay either for example (allthough to print you have to get through a different platform in order to achieve nice results...) But nonetheless, it is feasible. IIRC RWAP are doing something about Epson high colour/resolution drivers. Rich is probably working on some magic again :-) Of course I could be talking a lot of bull hear, if so feel free to say so - I can take it (;-) al the best - Bill Phoebus
Re: [ql-users] Here I go again with my absolute coordinates :-)(And something for the Q40 too)
On Sat, 10 Nov 2001, Phoebus R. Dokos wrote: Additionally we DO have apps that use properly 16 bit colour. Jerome's SpriteED, PovRay, Claus' 3D editor/viewer, Photon, PhotoQL, and of course ProWesS :-) The 3D modelling software (with Adobe Illustartor and SVG output) is by Mark Swift! Phoebus Claus __ powered by Q60 * Motorola 68060 / 80 MHz * 80 MB RAM * 30 GB Hard Disk
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Phoebus R. Dokos wrote: I see, however do the colour codes from S*Basic create the same results for comparable modes in Q40 and QPC? (ie is there a translation table of sorts INSIDE SMS? Yes, I think so. Additionally do COLOUR_PAL in its default setting display the same colours from 0-255 for all Platforms supporting colour drivers? As these colours are defined in the GD2 specs I'd say yes again. I disagree that 24bit colour precision is not necessary. Many file formats support that and it would be best if we could be compatible. Not to mention ported applications ;-) 16bit colours is already a big strain to the memory consumption (the PE was not designed for things like that). Having 32bit colour (for performance reason one'd better use 32 instead of 24bit) would be even more devastating. Marcel
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
At 04:44 ìì 10/11/2001 +0100, you wrote: Phoebus R. Dokos wrote: try to place the @$!!@@$! graphics cursor in the middle (works ONLY with SCALE 100) and then move 1 just ONE pixel to the right and see what happens. Then please try to put text on the ABSOLUTE coordinates 350,98 (Absolute memory address: SCR_BASE+((800*98)*2)+(350*2)) and PLEASE tell me if you did it HOW the hell you did it. I really don't know where your problem is, this just works as expected. The only thing I had to change was to do a border #0,0,0 in advance as the default #0 has a border width of 1 which would make the text appear at 352,99 instead of 350,98. Then do the same on a WINDOW of 800x600 on a different size screen (1024*768) and again if you do it (which I doubt it) tell me how you did it. open#3,con_1024x768a0x0 cursor#3,350,98 paper#3,3 -- so that really the pixel at 350,98 will be filled print#3,X Works fine. Marcel Well it doesn't work for me... Maybe my QPC is shot? My QPC btw does other weird things like refusing to load Turbo and switching numbers like 10 or 25 to Exponential form etc. etc. etc. Phoebus
[ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Hello again and thanks for everyone that responded to my previous question. The question now is: Is it possible to place the text cursor ABSOLUTELY according to a given window or the screen (that is without using @#!@$~~!@## SCALE) And a question about SMSQ/E on Q40. Do the COLOUR_QL, COLOUR_PAL, COLOUR_24 etc commands exist for the Q40 as well? If yes, do they (especially the COLOUR_PAL one) use the same colour codes for both QPC and Q40 Phoebus
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
At 03:42 ìì 9/11/2001 +0100, you wrote: Phoebus R. Dokos makes some magical things to make me read } Hello again and thanks for everyone that responded to my previous question. } The question now is: } Is it possible to place the text cursor ABSOLUTELY according to a given } window or the screen (that is without using @#!@$~~!@## SCALE) ?? AT ?? or you want 'pixel' precision ? PIXEL precision :-) I'm sending you something via private email for you to see what I mean :-) } } } And a question about SMSQ/E on Q40. } Do the COLOUR_QL, COLOUR_PAL, COLOUR_24 etc commands exist for the Q40 as } well? If yes, do they (especially the COLOUR_PAL one) use the same colour } codes for both QPC and Q40 Yes, they exist on Q40. And they probably have the same default colours (I remind you that the palette colours CAN be redefined by the user !) (That's remind me that I need a new keyword/extension to reset the palette to what it is at startup..., when I've finished changing the most important entry)
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Phoebus R. Dokos makes some magical things to make me read } } Is it possible to place the text cursor ABSOLUTELY according to a given } } window or the screen (that is without using @#!@$~~!@## SCALE) } } ?? AT ?? } or you want 'pixel' precision ? } } PIXEL precision :-) Shortest way is to have a sub-window (coordinate relative to the application, not the screen, under PE), in which you can for instance then use the AT, if you really want AT. You only need that sub-window at (re-)draw time, so you may use one for multiple texts. For the screen relative, as long as your primary is big enough if you are under PE, any open#6,scr_XXxZZaAAxBB should do. You may want to considere con_ instead of scr_ Beware of the various screen size (Q40 can be 512x256 or 1024x512, QPC has a lot of standard variants) The colour coding is the same for the commands from S*Basic, but the pixel coding is differents in the screen memory. } } I'm sending you something via private email for you to see what I mean :-) } Interesting picture...
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Jerome Grimbert wrote: Beware of the various screen size (Q40 can be 512x256 or 1024x512, QPC has a lot of standard variants) With QPC you have to expect everything from 512x256 to (IIRC) 4096x4096, the only limitation being that the x-resolution is guaranteed to be dividable by 32. Marcel
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Phoebus R. Dokos wrote: Hello again and thanks for everyone that responded to my previous question. The question now is: Is it possible to place the text cursor ABSOLUTELY according to a given window or the screen (that is without using @#!@$~~!@## SCALE) For a given window, simply use CURSOR #channel,x,y This positions the cursor like AT #channel,y,x (note reversed x,y values, and use of PIXELS rather than character squares) A second version of CURSOR is very useful, since it allows you to specify text to be placed using graphics co-ordinates and offset by a given number of pixels. This lets you place text using the same co-ordinates as LINE, POINT, ARC, CIRCLE etc. So if you are using SCALE to create graphics, this is the best way to ensure text and graphics are placed in the same positions. CURSOR #channel,x,y,x_offset,y_offset If you have a POINT 50,50: LINE TO 100,100 then CURSOR #channel,50,50,0,0:PRINTText would position text at the 50,50 point. To avoid overwriting the point, move the text a few pixels with something like CURSOR #channel,50,50,10,10:PRINTText I'm not sure if this is what you meant, hope it helps anyway. One final point - this version of cursor does not always work in SuperBASIC on Sinclair ROMs. I think Turbo and QLiberator compile this and fix the problem and it's also fixed in SBASIC (not sure about Minerva BASIC) -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
Phoebus - I've just had a quick look at the notes I have for my program launcher and broadly this is how it worked. I gave up on this partly due to lack of time at the time and partly because of hearing about the Jim Hunkins QDT Desktop system (anyone heard any more about that?) Set up Easyptr menus for the screen sizes it is designed to handle. In the case of my program, it was QL screen, EGA, VGA, SVGA and 1024x512 (my system at the time wouldn't go beyond 800x600 but I hacked a menu using a routine borrowed from Rich Mellor's BASIC Reference Guide) Check screen size in use and draw appropriate menu (using eithe SCR_XLIM, SCR_YLIM etc or my DISPLAY_CDE from QL Today). The menu had basically 3 little iconsprites on the top line, move+redraw+esc/X and an info window with the title. The diagram below tries to show what I mean. The [ ] bits are loose items defined in Easyptr - to add a program you simply defined a loose item with the name text (loose items -1, -2 and -3 had sprites for move/resize/exit and -4 to -something along the bottom for shortcuts to other desktop menus) +--+ | [MOVE] [RESIZE] DJ DESKTOP [X] | | | | [] [] [] [] []| | [] [] [] [] []| | [] [] [] [] []| etc as far as the window menu size allowed, then at the bottom a separate set ofloose items for menus etc. Easyptr allows info windows and loose items to overlap if required, this could sometimes (with care) be used to provide separate backgrounds if really required. Obviously, the 'menu' loose items strip could go at the top Win3.1 style if required. | | +--+ | [menu1] [menu2] [menu3] etc | +--+ The program basically sat there reading mouse and keyboard and waited for a loose item to be hit, when it looked at the setting for that loose item if defined (if not, ignored). Right click (DO) brought up a Windoze style context menu offering to add new button settings, change settings, delete, move setting to different loose item and so on. Clicking on resize cycled through the different menu sizes, drawing the next size up until that wouldn't fit then back to QL screen size. I appreciate this is probably not what you really want to do, as I guess you will want to do something more graphical like a real GUI, and this provides only a fixed format program list, no drag 'n' drop etc but this seemed quite easy to code for someone like me whose requirements weren't really that complex and the idea was to create something passable which was quick and easy to program and gave me a 'sort of GUI' better than the old DEV Manager program. Now I'm between jobs it might be a bit of a brain-stimulator to keep me occupied at home for a little while. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Here I go again with my absolute coordinates :-) (And something for the Q40 too)
At 12:20 ìì 9/11/2001 -0500, you wrote: At 04:43 ìì 9/11/2001 +, you wrote: P.S. QPC is still making graphical windows side by side with WindoZe :-) ONLY in BASIC: 1000 Graphic Windows in 24 secs and 90/100 Cool ain't it? Phoebus
