DrawGen

Jolly good. I confess I got distracted by DrawBasic/DrawScript and I’ve not been paying attention. Sorry Jim.

No worries. :-)

The most basic (sorry but puns seem unavoidable!) question which I’d pose is:

Does it make more sense to try and add things to the existing ABC BASIC code for the DrawGen module, or to replicate what it does using ‘C’ to create a new module?

I’m now not capable of doing either, so its a starter question for those who want to try and carry this forward. I can see the advantages of it using ‘C’ for the future, but it means a complete re-write, whereas to add a few features whilst keeping to the ABC BASIC would be a shorter task for someone who knows the ABC BASIC.

I had a furtle and I think ‘ve found a number of example ’C’ programs that use the module. I’ve even found some ancient FORTRAN ones, which at least indicate DrawGen being ‘language agnostic’! Another advantage which I was made re-aware of today when writing the graphics program that prompted this is that the module approach means any floating point stuff can be done by the specific program and then just passes ‘instructions’ on to the module once that is done.

I have, however, also posted on the thread that was mentioned about the DDE to see if the new !ABC compiler is still available that way.

BTW anyone looking at the ‘C’ examples using DrawGen may find it handy to note that if you simply omit the DG_make() at the end you get left with the ‘script’ file in ram that DrawGen reads to actually build the DrawFile. So you can check what you’re generating for it.

FWIW I’ve now bodged a way past the limitation that prompted my deciding this should become ‘open’.(1) But I still hope people think it a worthwhile idea to develop DrawGen, and could see the point of it being able to do things like include sprites, etc, and offer more features than at present.

(1) if interested, you can see my ‘vertical text’ bodge here

http://jcgl.orpheusweb.co.uk/temp/vtext

But genuine 90 deg written text would be better in many cases.

OK, Jim, looks like I am the only volunteer. I’ll get in touch later for a quick discussion on things to do.

I am not sure if there are any other volunteers around

I was intrigued by the problem and I have done something already.

The intermediate data format seems to be only integers, so angled text is not feasible as it stands, but rightangle rotations are.

I have compiled it with ABC 4.18, the first time I have used ABC in a quarter of a century. Wow! Is it sloooow? Over 7 minutes for a 16k program on my mini.m.

There is a new command “textr” which takes two additional parameters after x and y. The first is the number of rightangles anti-clockwise, from 0 to 3. The second is the flags – bit 0 for kerning, bit 1 for reversed text, so usually 0.

I will tidy up and document this tomorrow, and upload it to my site.

Having never used ABC I’m surprised to learn that it can produce modules. (Surprised and horrified ;-)

I understand the format now. Can I suggest a “matrix” command that would apply thereafter – this would allow transformed text to be produced easily.

Steve, I presume you are centring the characters when plotting them vertically?

This is a quick and easy implementation of transformed text objects with the restriction to rightangle rotation. A little more thought should make a whole number of degrees a possibility, but Jim particularly wanted this text feature.

I used the transform matrix method you suggest in DrawIt.

I originally bought ABC with idea of producing modules. It does it, but is very inefficient with memory and in those days that mattered. Soon after I ‘mastered’ assembler.

I mastered assembler purely for speed back in the day – and I think I can fairly say I did master it, given that ARM employed me later to write their Assembler Guides – but I’ve never written a module, and although I surely mastered assembler in 26-bit days and understood later versions well enough to write the guides, I’ve not written more recent versions of assembler more than just enough to test that I’ve actually understood it. So I don’t know whether I’ll ever really write a module at all.

Wow! Is it sloooow? Over 7 minutes for a 16k program on my mini.m.

Something is horribly wrong.

I just built it with v4.14 (I guess I’ve neglected to update it, must fix that) and it took about six seconds on an original Pi2.

Edit: Found ABC 4.19 and installed it. It’s quicker. Maybe four seconds.

(Surprised and horrified ;-)

If I remember correctly, it has no “entry points”, so it can do commands or it can do SWIs, but not both. I guess it was seen as a way to allow those who only understood BASIC to be able to make modules, though the main reason I write modules is for interacting with service calls, events, etc. Can ABC do this?

So I don’t know whether I’ll ever really write a module at all.

Do you have the DDE? https://heyrick.eu/blog/index.php?diary=20150323

I was intrigued by the problem and I have done something already.

Just as well I held fire then 8)

The tricky thing with rotated text (apart from the easy 90, 180 and 270 degree rotations) is getting the bounding box correct.

The tricky thing with rotated text (apart from the easy 90, 180 and 270 degree rotations) is getting the bounding box correct.

Properly correct – yes, very tricky. Guaranteed big enough (almost certain to be somewhat bigger than necessary) by putting a box round the original bounding box, rotated – quite easy, and good enough really. It’s hard to imagine a situation in which that isn’t good enough: you can’t, after all, have a bounding box that’s a rectangle at an angle, so you’re (almost) always going to have a substantially bigger bounding box anyway.

Properly correct – yes, very tricky.

An accurate bounding box is not necessary to produce a working DrawFile here, so you can just have the maximum possible size. This is what DrawGen does and I did with DrawIt. Other systems may do likewise, and I might have got the idea from one of them. Where a bounding box is necessary the calculation can be tricky indeed.

I may well have not understood it, and that was why I failed to make it work. However IIUC the object 12 type (rotated text) lets you specify the text angle in a form of a 4-byte value which is essentially scales so the integer value 2*16 is then scaled to give ‘1’ in the transform matrix. Thus enabling (fairly) arbitrary rotations. However since I was unable to make it work, maybe this was my error! :-)

FWIW Here the existing module code compiles in just a few seconds using my ancient copy of !ABC on ARMX6.

The tricky thing with rotated text is getting the bounding box correct.

Font_ScanString with R2b18.

I’m sure someone will pick holes in my method:

   60729 : DEF PROCmdTextTran(x, y, t$, r)
   60730 : REM if r=0 no rotation, positive clockwise
   60731 : REM Hence r=PI/2 -> then rotate 90deg clockwise
   60732 : PROC_mdContext("Text", %1010)
   60733 : IF _mdTrace% THEN PRINT "<Text(";x;",";y;",""";t$;""")>";
   60734 : LOCAL txptr%, x%,y%,xx%,yy%,g%
   60735 : txptr%=_mdBufPtr%
   60736 : PROC_mdIncBufPtr(28+52+LEN(t$)+1)
   60737 : PROC_mdAdjustXY(x,y, x%,y%)
   60738 : IF _mdFLPtr% AND _mdTSty%<>0 THEN
   60739 : _mddd%=_mdFLPtr%
   60740 : _mddde%=_mddd%+_mddd%!4
   60741 : _mddd%+=8
   60742 : _mdi%=0
   60743 : REPEAT
   60744 :   _mddd%+=_mdi%
   60745 :   _mdi%=0
   60746 :   REPEAT
   60747 :     _mdi%+=1
   60748 :   UNTIL (_mddd%?(_mdi%-1)=0 AND _mddd%?_mdi%<>0) OR _mddd%+_mdi%>=
           _mddde%
   60749 : UNTIL (?_mddd%)=(_mdTSty%) OR _mddd%+_mdi%>=_mddde%
   60750 : SYS "Font_FindFont",,_mddd%+1,_mdTSzX%/40,_mdTSzY%/40 TO _mdf%
   60751 : ELSE
   60752 : SYS "Font_FindFont",,"System.Fixed",_mdTSzX%/40,_mdTSzY%/40 TO _md
           f%
   60753 : ENDIF
   60754 : SYS "Font_StringBBox",,t$ TO ,_mda%,_mdb%,_mdc%,_mdd%
   60755 : REM SYS "Font_LoseFont",_mdf%
   60756 : txptr%!0=12
   60757 : txptr%!8=x%
   60758 : txptr%!12=y%
   60759 : txptr%!16=x%
   60760 : txptr%!20=y%
   60761 : xx%=x%+(_mda%*256/400)*COS(r)-(_mdb%*256/400)*SIN(r)
   60762 : yy%=y%+_mda%*256/400)*SIN(r)+(_mdb%*256/400)*COS(r)
   60763 : IF xx%<txptr%!8 THEN txptr%!8=xx%
   60764 : IF yy%<txptr%!12 THEN txptr%!12=yy%
   60765 : IF xx%>txptr%!16 THEN txptr%!16=xx%
   60766 : IF yy%>txptr%!20 THEN txptr%!20=yy%
   60767 : xx%=x%+(_mdc%*256/400)*COS(r)-(_mdb%*256/400)*SIN(r)
   60768 : yy%=y%+_mdc%*256/400)*SIN(r)+(_mdb%*256/400)*COS(r)
   60769 : IF xx%<txptr%!8 THEN txptr%!8=xx%
   60770 : IF yy%<txptr%!12 THEN txptr%!12=yy%
   60771 : IF xx%>txptr%!16 THEN txptr%!16=xx%
   60772 : IF yy%>txptr%!20 THEN txptr%!20=yy%
   60773 : xx%=x%+(_mda%*256/400)*COS(r)-(_mdd%*256/400)*SIN(r)
   60774 : yy%=y%+_mda%*256/400)*SIN(r)+(_mdd%*256/400)*COS(r)
   60775 : IF xx%<txptr%!8 THEN txptr%!8=xx%
   60776 : IF yy%<txptr%!12 THEN txptr%!12=yy%
   60777 : IF xx%>txptr%!16 THEN txptr%!16=xx%
   60778 : IF yy%>txptr%!20 THEN txptr%!20=yy%
   60779 : xx%=x%+(_mdc%*256/400)*COS(r)-(_mdd%*256/400)*SIN(r)
   60780 : yy%=y%+_mdc%*256/400)*SIN(r)+(_mdd%*256/400)*COS(r)
   60781 : IF xx%<txptr%!8 THEN txptr%!8=xx%
   60782 : IF yy%<txptr%!12 THEN txptr%!12=yy%
   60783 : IF xx%>txptr%!16 THEN txptr%!16=xx%
   60784 : IF yy%>txptr%!20 THEN txptr%!20=yy%
   60785 : IF _mdGroups%>0 THEN
   60786 :   FOR g%=1 TO _mdGroups%
   60787 :     PROC_mdBBoxUnion(_mdGrPtr%(g%)+8,txptr%+8)
   60788 :   NEXT g%
   60789 : ENDIF
   60790 : PROC_mdBBoxUnion(_mdFHPtr%+24, txptr%+8)
   60791 : REM transformation matrix
   60792 : txptr%!24=(1<<16)*COS(r)
   60793 : txptr%!28=(1<<16)*SIN(r)
   60794 : txptr%!32=-((1<<16)*SIN(r))
   60795 : txptr%!36=(1<<16)*COS(r)
   60796 : txptr%!40=0
   60797 : txptr%!44=0
   60798 : txptr%!48=0
   60799 : :
   60800 : txptr%!52=_mdTCol%:txptr%!56=_mdTBak%:txptr%!60=_mdTSty%
   60801 : txptr%!64=_mdTSzX%:txptr%!68=_mdTSzY%
   60802 : txptr%!72=x%:txptr%!76=y%
   60803 : $(txptr%+80)=t$:?(txptr%+80+LEN(t$))=0
   60804 : PROC_mdAlignBufPtr
   60805 : txptr%!4=_mdBufPtr%-txptr%
   60806 : _mdContext%=%1000
   60807 : ENDPROC

From David Feugey assuming the offer is still on

It is.

I will tidy up and document this tomorrow, and upload it to my site.

I have how upload my modified DrawGen module. I have not included source, because I am not sure how Jim wants to play this.

Something is horribly wrong.

Yes it is. I tried it on a Pi and it did compile in seconds. What is up with my mini.m? Unfortunately, all my work is there and transfering back and forth is a bit of a pain. ;-(

Just as well I held fire then 8)

Sorry, Chris. I had already done it by the time you posted. Should a collaboration be needed the I am in, if I can sort out what is up with ABC. ;-)

you can just have the maximum possible size … I did with DrawIt.

I lied. I have checked and I used Font_ScanString, but that must have been quite late in the development.

From my POV I’m happy for people to co-operate and do this in whatever way suits them all. Discussion / communication via the forum seems OK to me. But if something else is more convenient, just say and I’ll follow on.

When someone puts up something like a provisional new version of the DrawGen module/code my main interest is to know what I’d need to write as a ‘way in’ as a new ‘C’ proc for the DG library I have thus far, so it can accessed with that ‘h’ library via a simple call to a proceedure.

I only have to glance at Chris’s code above to see that the actual code others can produce is way above my ‘pay grade’ to comment on. 8-) I can make tea, but I’m a bit far away.. (Have some nice single estate FF darjeeling, though…)

FWIW just tried Steve’s version ‘textr’ and it worked nicely via a DG_lib.h proc. :-)

One suggestion: When putting up a modified version, it would be good to alter the text printed by ‘DrawGen help’ to show what version it is, who modified it, and a date, perhaps. Make it easier to keep track of which version is being tried/used. By all means remove the stuff I put there which no longer applies!

If nothing else, I ‘retired’ in about 2005!

I’m sure someone will pick holes in my method

Yes, me.

Don’t use StringBBox, use ScanString like I said an hour earlier.

StringBBox has been deprecated since RISC OS 2.50 and cannot, due to rounding errors, be relied upon to cover every pixel.

And also, almost everything else you’ve written is unnecessary too. Just create the matrix, get the parameters for ScanString right, and it’ll return the bounding box which you then scale to draw units (*256/400) and that’s it. It’s about four lines of Basic.

Sorry, Chris. I had already done it by the time you posted. Should a collaboration be needed the I am in, if I can sort out what is up with ABC. ;-)

OK, no worries. I will wait a day or so and then liase with Jim to see what else could be done, and whether more could be added. I have plenty to do on updates to some of my own apps in the meantime.

The only specific thing I wanted for my own use was the ability to generate the ‘vertical’ (i.e. 90 rotated) text strings. Which Steve’s module now provides. However..

1) If arb rotation angle text is practical, it makes sense to me to include it for when someone needs it.

2) The one thing that people have asked me to add in the past has been the ability to include sprites and/or jpegs in the created drawfile. This isn’t something I’ve ever needed, but looks useful.

Indeed, having written (2) I recall a while ago when I produced an animated graphic by starting off with a set of drawfiles it might have been useful to be able to include a sprite/jpeg. Didn’t occur to me at the time as I’ve been used to not having the option! However it isn’t something I really need for myself, but suspect other users might.

The bigger question is the one I raised early on. Would it make more sense for the longer term for the module to be based on ‘C’ and not depend on the continuing availability of an ABC compiler that can be run as the OS and hardware develops and changes?

Don’t use StringBBox, use ScanString like I said an hour earlier

I corrected the routines to calculate the bounding box of text sometime between 1992 and 1995 and it was originally intended to be compatible with RISC OS 2. It works well enough so I have left it alone.

The one thing that people have asked me to add in the past has been the ability to include sprites and/or jpegs

MakeDraw now allows the following:

PROCmdJPEG(x,y,filename$,width,height)
--------------------------------------

Plot a JPEG with its bottom LH corner at (x,y) and its height and width 
as specified. A height of 0 means that the width is taken as a scale factor. A negative 
height causes both height and width to be scaled so that the draw file 
will cause a sprite to be created by !PhotoDesk of the correct pixel size 
from the draw file.

PROCmdTextTran(x,y,t$,r)
------------------------

Positions a transformed text object at (x,y) using the current text style 
and colour. The coordinates define the position of the left-hand end of 
the base line of the text - any descenders will extend below this position.     

PROCmdSprite(x,y,filename$,width,height)
----------------------------------------

Plot a sprite with its bottom LH corner at (x,y) and its height and width 
as specified. A height of 0 means that the width is taken as a scale factor. 
A negative height causes both height and width to be scaled so that the draw 
file, if dragged onto PhotoDesk, will cause a sprite to be created of about 
the correct pixel size.


PROCmdTextArea(x,y,wid,ht,strptr%,colptr%)
------------------------------------------

Create a text area object containing the zero-terminated string pointed to 
by strptr%. This string may contain escape sequences such as '\AD' (which 
turns on full justified text) but will appear (by default) in the current 
font (as set by SetTextStyle) and size (as set by SetTextSize. 

The text area object occupies the rectangle width wid and height ht with
its bottom LH corner at (x,y). If colptr% is non-zero it points to two 
or more 4-word blocks, terminated by a four word block containing all 
zeroes. Each block is column coordinates (x,y,wid,ht) and each must lie
within the bounds of the containing text area.

FNmdText(string$)
-----------------

This function calculates the bounding box of the string and allows them
to be read back, as offsets from the nominal position of the string in
internal variables bottom left: (_mda%,_mdb%) and top right: (_mdc%,_mdd%).
These values are as returned by Font_StringBBox and are thus in millipoints.
To convert to draw units multiply by 0.64 and to convert to user units multiply
by 0.64/_mdUnits%. The function returns the width of the string in user units.
Versions prior to 2.53 returned TRUE.
For a string consisting of a single space character versions 2.53 to 2.55
returned zero but for the same string, versions 2.56 onwards will return the 
version number, e.g. 2.58.

PROCmdInclude(t$)
-----------------

This procedure allows an existing drawfile to be extended so that the
draw buffer will contain all of the objects in the file specified
(including an options object, if present) and allow extra lines, 
shapes and text to be added. It will check to ensure that the font 
table you have created includes all of the named fonts in the 
specified file, with the same font handles so that any text in the 
specified file will render correctly. If the two font tables do not 
match, a warning will be issued. This allows any fonts in the 
specified file to be substituted by fonts present on the machine 
being used simply by ignoring the warning. The bounding
box of the new file will be updated as objects are added.

An example of the use of this routine is given below:
      10 : LIBRARY "<MD$Dir>.MakeDraw"
      20 : PROCmdInitialise(8228192,0)
      30 : PROCmdSetUnits(mdMM%)
      40 : REM The draw file uses font02% and font01% so these must
      50 : REM be defined to match before including the existing draw file
      60 : font02% = FNmdDefineFont("Homerton.Medium.Oblique")
      70 : font01% = FNmdDefineFont("Homerton.Medium")
      80 : REM Now add the fonts I need
      90 : font03% = FNmdDefineFont("Trinity.Medium")
     100 : PROCmdStartGroup:REM This line is optional
     110 : PROCmdInclude("Wiltshire")

PROCmdQuadrantA(x1,y1,x2,y2)
----------------------------

This draws a quarter circle from (x1,y1) to (x2,y2) in an anti-clockwise
direction. It is similar to PROCmdCircle(x,y,r) but draws only a
quadrant. The approximation to a circle is quite close, with an error
of only about one part in 4000, the best that can be achieved by a
Bezier curve.

PROCmdQuadrantC(x1,y1,x2,y2)
----------------------------

This draws a quarter circle from (x1,y1) to (x2,y2) in a clockwise
direction. It is similar to PROCmdCircle(x,y,r) but draws only a
quadrant. The approximation to a circle is quite close, with an error
of only about one part in 4000, the best that can be achieved by a
Bezier curve.

PROCmdQuadrantATo(x2,y2)
------------------------

This creates a curved line segment in the current path from the current 
position to (x2,y2).  The control points for the beginning and end of the 
line are placed so that a quarter circle is drawn anti-clockwise.

PROCmdQuadrantCTo(x2,y2)
------------------------

This creates a curved line segment in the current path from the current 
position to (x2,y2).  The control points for the beginning and end of the 
line are placed so that a quarter circle is drawn clockwise.

From my POV I’d say that, in terms of strategy, it probably makes most sense to:

1) try to keep all need for calculations that benefit from floating point to the calling program that constructs the file which DrawGen then reads, interprets, and uses to build the DrawFile. e.g. when a transformation matrix is needed, allow the calculation of the six 4-byte values to be done by the calling routine and then have it poke the relevant series of values into the file DrawGen reads. Thus not needing any complicated calculations in the module.

2) In the long term, I suspect developing and maintaining DrawGen would benefit from it being re-written in ‘C’. Otherwise it will always be tied to requring the !ABC system and someone who can write the ABC BASIC required. (My main worry there is ensuring that !ABC was developed to continue to work on ever-newer hardware and OS versions.)

More tactically/personally, I’m quite happy to see additions provided I can work out how to write a ‘C’ proc for the h library that I or others can then use. And appreciate any help with developing or maintaining. It is now ‘open’ so I don’t think my opinions carry more weight than anyone elses from this time on. :-)