DrawGen

keep all need for calculations that benefit from floating point to the calling program

Strongly disagree.
The module is intended as a method of allowing a program to create a ‘script’ that results in the creation of a DrawFile. The module does all the finickety stuff involved in the low level Draw behaviour. The application uses higher level commands akin to BASIC’s move, draw, circle, etc.

Offloading the complicated calculations to the caller not only flies in the face of that, it is also defying the point of a utility module that is supposed to simplify things. What I, as a user, would like is to say “I want a rectangle of this size, rotated 30 degrees clockwise, placed here” and DrawGen just “does it”. I don’t want to have to go Google to figure out what the hell a transformation matrix is, and how to use one.

Otherwise it will always be tied to requring the !ABC system

I don’t think this is anything you need to worry about. ABC is part of the DDE which means ROOL presumably have access to the sources, and it’ll be around as long as ROOL is.
A bigger existential issue is whether or not RISC OS itself will work on ever-newer hardware (and for how long the appropriate 32 bit world will continue now pretty much everybody else has gone AArch64). In this case, it doesn’t really matter what language the module is written in.

Ideally, it would transition to C because it could then be opened up further to applications in a way that ABC just cannot cope with – for example:

SWI "DrawGen_Start"               ; get a handle for an instance
SWI "DrawGen_ExFont", fontname    ; add a custom font
SWI "DrawGen_ExFont", fontname    ; and another
SWI "DrawGen_ExFont", fontname    ; and a third
SWI "DrawGen_Open", filename      ; begin creating a DrawFile
SWI "DrawGen_AddElement", script  ; interpret a line of script
SWI "DrawGen_AddElement", script  ; and some more, maybe a circle
SWI "DrawGen_AddElement", script  ; a rectangle this time
SWI "DrawGen_AddElement", script  ; and a line...
SWI "DrawGen_Close"               ; done, finish up the DrawFile and discard instance

Obviously it’s a little more complicated in reality, but by getting the caller to pass commands directly into DrawGen, there will be no need for this intermediate file business, it’ll just begin making a DrawFile right there, on the fly.

Now, wouldn’t that be useful? ;-)

Obviously it’s a little more complicated in reality, but by getting the caller to pass commands directly into DrawGen, there will be no need for this intermediate file business, it’ll just begin making a DrawFile right there, on the fly.

Now, wouldn’t that be useful? ;-)

Indeed. I had a module years ago to support my various graphical applications that did something very similar in essence to that. That module was written in Basic assembler, but became superfluous once I went through the process of converting all the apps to C and used a library to link with each app. That way used a bit more memory, but with modern hardware…..

Considering how simple and well-defined the DrawFile format is, I don’t know why a module is required to build one. The hardest bit is calculating the bounding boxes, and there’s existing calls for that (except for rotated sprites I grant you, rudimentary trig is required there), and if you feel lazy just set the bounding boxes to the size of the whole drawing – !Draw recalculates them anyway.

Should a collaboration be needed then I am in

I did a little more to see what would be required to do general transformations and I was reminded why I dislike the limitations of ABC so much – in this case the lack of array operations, the variable scoping and setting of local variables to null.

Add to that the weird refusal of ABC to run properly on my mini.m and I am afraid that I am now out. ;-(

The module does all the finickety stuff involved in the low level Draw behaviour.

That is what the BASIC in the ABC compiled module is doing, not the calling program. ;-)

I don’t know why a module is required to build one.

I think I agree, but libraries in BASIC, or in C, are a help.

!Draw recalculates them anyway.

Yes. It did seem a bit of an effort to do the calculations when I knew this, but it was satisfying to be ‘correct’. You never know what might happen in the future. ;-)

I don’t know why a module is required to build one.

Because when I wanted to design a chart to list all of the characters in my Kana font, and the attributes associated with each, I didn’t want to have to learn how to create a DrawFile. I wanted to simply say “it looks like this” and describe it in simple terms (annoyingly, using PRINT# style output instead of parsing text) and let DrawGen do the rest.

and I was reminded why I dislike the limitations of ABC so much

:-)

Add to that the weird refusal of ABC to run properly on my mini.m

Have you tried some basic (ho ho) test programs, like "10 PRINT "Hello" : END"?

but libraries in BASIC, or in C, are a help.

Certainly. It’s all about makinhg things simpler, not making everybody learn the specifics of a file format in order to make use of it. One doesn’t need to understand sprite files in order to create and use them, that’s what OS_SpriteOp is for. So one doesn’t need to understand Draw files – that’s what DrawGen (etc) is for.

and if you feel lazy just set the bounding boxes to the size of the whole drawing – !Draw recalculates them anyway.

And in a few years from now: nemo: does NOBODY bother working out their bounding boxes?! it isn’t difficult.
:-)

I have no moral objection to having the DrawGen module calculate what users would find convenient, so if those of you doing the work are happy to impliment it generating transform matrixs, etc, that’s fine with me. I was just trying to KISS the module given my concerns about ABC BASIC.

Similarly, if a SWI interface for ‘direct’ calling would help, that’s OK, as well. But bear in mind that I’d also wish the ‘intermediate file’ method to go on working because many programs depend on it, and I’d not want to have to rewrite them all.

That said, for new programs a suitably altered DGLib would be easy enough to produce. Which should mean that older programs could be recompiled with that provided I can keep the ‘veneer’ of the Proc names and input value sequences the same. It would the go via SWIs rather than a file.

On the third hand… one use of an intermediate file is that it gives an output to examine when something went pear-shaped. Albeit one not much easier than a drawfile to read. 8-]

BTW Given how quickly I managed to generate ‘vertical text’ using the existing DrawGen module I’d hope it should be OK to generate the array required to display a font’s glyphs, etc, in a tidy manner.

Steve said

It did seem a bit of an effort to do the calculations

!Draw recalculates them but most things don’t. Best to get them right or, as I suggest, oversize them so the contents definitely get drawn.

This should have occured to me sooner. The DrawGen module provides just one star command, which runs a program that interprets an intermediate file. Why can one not just run the program without compiling it? To preserve the name “*DrawGen” it would need to be on the Run$Path, so perhaps in the Library, and there might be some small adaptations, but the API should be identical. Comments?

Why can one not just run the program without compiling it? To preserve the name “*DrawGen” it would need to be on the Run$Path, so perhaps in the Library, and there might be some small adaptations, but the API should be identical. Comments?

I had been wondering that myself, simply have it as a binary in Library.

I didn’t actually mean ‘binary’, since it would be a basic file (unless perhaps converted to C at some future time).

Why can one not just run the program without compiling it?

Well, given ABC is a subset of BASIC, I can’t think of any specific reason why it wouldn’t work, except you’ll need to fiddle around with OS_GetEnv in order to extract the filename. The current code uses filename$=LINE$ to have the command line tail passed to it by the ABC runtime.
For running from the command line, the first instance of PROCget_filename at the end of the program will ask for a filename. Not so friendly, so that’s where OS_GetEnv ought to go.

Off the top of my head, something like this:

DEFPROCget_filename
  LOCAL cmdline$, charpos%
  SYS "OS_GetEnv" TO cmdline$
  charpos% = INSTR(cmdline$, CHR$(34))
  IF ( charpos% = 0 ) THEN
    REM Couldn't figure it out, so ask the user
    INPUT "Filename? ",filename$
  ELSE
    REM Convoluted, because the command line is:
    REM   Basic -quit "<progname>" [<parameters>]
    charpos% += INSTR(MID$(cmdline$, (charpos% + 1)), CHR$(34))
    filename$ = MID$(cmdline$, (charpos% + 2))
  ENDIF
ENDPROC

Note, however, that this means one will need to take extra precautions to avoid running that overwriting your program. Easy enough from the Desktop, just Wimp_StartTask it and wait for the command to return. A little harder if in the command line…

I didn’t actually mean ‘binary’, since it would be a basic file

You aren’t wrong. A basic interpretation is that “binary” means a file that isn’t human readable (unless you’re nemo). Tokenised BASIC would fit that definition for most people.

“binary” != “executable” :-)

Apologies for slightly (cough!) diverting my own topic, but I’m having a problem and I can’t decide if it is because I’m still using ‘old’ versions of the ABCLib (4.14 from 2002), and the old ABC compiler.

It concerns my using the sequence which starts with a DG_path() proc, then does some DG_Draw() procs, and then a DG_end(). I know there is a flaw in whay I wrote as it uses (int) type for passing what should be an unsigned value. (This causes the error when compiling that was mentioned a while ago.) But in the past it always worked despite this.

However now, if I set the line and fill color values to anything other than 0,-1 (-1 means ‘no fill’) it compiles but sometimes give spectaular crashes, but shift the code somewhere else and it works. That makes me suspect it is hitting something like an alignment problem. But I’m currently clueless / baffled.

I have emailed David Feugey wrt the latest version, but not yet had a response. So I’m still using an ancient complier on my ARMX6. I’ll try modding the procs to using an unsigned int, but I’m not sure of that is the problem or not. So thought I’d raise it here in case this is obvious to someone else!

simply have it as a [BASIC file] in Library.

There is a weird alternative, but it would mean reviving a little project, BASMod, from over 20 years ago. ;-)

This put BASIC programs into a module, from where they can be run by star command or SWI. Of course the programs actually run in application space, but that can be kept very small by using the !RunLink method.

Note, however, that this means one will need to take extra precautions to avoid running that overwriting your program

Aye. There’s the rub. You cannot do this as simply from another program as my method suggested. Time for a re-think.

There is a weird alternative, but it would mean reviving a little project, BASMod, from over 20 years ago. ;-)

Wow, that’s a reminder – I wrote the same thing for the BBC Micro sideways RAM many years ago and sold it via Micronet/Prestel. I even think I used the same name (edit: wrong, it was called BASROM).

Time for a re-think.

The re-think I came up with was to have the source BASIC set the filename in a system variable and then have the BASIC drawgen, in Library as drawgen2 to to avoid confusion with the module call, read the variable. This less than brilliant ruse was just intended to show that drawgen as BASIC worked just as well as compiled BASIC in a module. Obviously as it should.

Except it didn’t! No matter how I tried this the DashDemo demo failed with the Library drawgen2 but worked with the module. There were no error messages, just the data file left open. It is the "line" command that trips something up. The other examples were fine.

is the “line” command that trips something up.

As I said 22 hours ago when I gave an alternative function that should do the job…
https://www.riscosopen.org/forum/forums/11/topics/14877?page=3#posts-97123

As I said 22 hours ago when I gave an alternative function

That has nothing to do with this.

The issue here is not the passing of the filename but this code in Examples.BASIC.DashDemo

PRINT# file%,"line",x0%+200,y0%,x0%+280,y0%+80
PRINT# file%,"line",x0%+200,y0%+80,x0%+280,y0%
PRINT# file%,"line",x0%+350,y0%+40,x0%+550,y0%+40

With an unmodified drawgen in Library this fails on manually entering the filename.

Sorted it!!!

On error the file remained open because the error handler was closing file handle i% but the file was opened as in_file%.

Line 25 in_file%=OPENIN(filename$)

but

REM error trap
DEF PROCerror
REPORT
IF ERR=1234 THEN PRINT ELSE PRINT;" at line ";ERL
IF c%<>0 THEN CLOSE#c%
IF i%<>0 THEN CLOSE#i%
ON
ENDPROC

The fixes

Line 313 in_file%=0:c%=0

Line 378 IF in_file%<>0 THEN CLOSE#in_file%

The error DashDemo fell into was missing variable rec_col%.

DEF PROCdecode_line
PROCdecode_vals(4)
PROCscale_xy
PROCscale_dim(3)
PROCscale_dim(4)
PROCpath_start(v%(1),v%(2),def_size%,colour_now%,rec_col%)
PROCpath_draw(v%(3),v%(4))
PROCpath_end
ENDPROC

The fix

Line 261 PROCpath_start(v%(1),v%(2),def_size%,colour_now%,path_style%)

Why it worked in the module instance will have to remain a minor mystery for now, possibly ABC’s error handling is rather more relaxed than BASIC’s.

I’ve now got the current !ABC, etc. My thanks to David Fuegey :-)

I’m not sure, but I’ll mention it in case it is relevant for the above. I think now that the odd behaviour I reported a while ago may be due to the way colours are specified as being the top three bytes of a 4-byte int. I’ve simply used (int) type in ‘C’ for passing ints. But since the colour spec uses the top three for the colours some of them become a ‘negative number’. Hence the warning when compiling some programs. IIRC the lowest byte was reserved as zero or something so as to be available for an extension like DrawFile transparency… which never happened. But if this is correct the result seems to give ‘confusing’ results. Seems to work if you keep down the top colour level, but can fail for other values. I guess the relevant procs should be using an unsigned int.

@SteveDrain I’ve got the version of the DrawGen module you generated that includes the ‘textr’ proceedure which allows N*90deg rotate text. It works, but I’d like to add the source code for it to the source code I have so I can then release a new version of the module as ‘standard’. Can you let me have the code for the proc, please?

Also, I saw a mention of adding jpegs (sprites?) but couldn’t see it being in the form used in the module at present. Has that been done in a form of a proc which I can then call via an added DGlib.h proc? If so, I can also add that.

I’ve been also thinking that it might be good if the response to “DrawGen help” from this point on listed ‘new’ features like the above and names of people who created them. Do people think that is a good idea?

BTW I’ve now written a few more procs. Mostly for a planned DGgraphs.h library to allow easier drawing of graphs. But because of the flaw I mentioned earlier I’ve also written a simple convertor for allowing the user to specify RGB as three 0-255 values and which then shuffles them into the required 0xBBGGRR00 form. I’ll make a copy of the test program I’ve written thus far to test these so anyone interested can have a look and laugh/sigh at my clumsy programming. :-)