Programming & Screen Sizes / Modes

Ah, but Zap has many benefits that make it worthwhile using (and learning to lean on the F3 key ;) ).

FormEd vs anything else is like Edit vs Zap/StrongEd. It’s functional, mostly ¹, but that’s about it.

¹ Did Edit’s screwy redraw bug ever get fixed? I don’t think I’ve used it in anger since RISC OS 3.6ish and it was still borked then.

I have to undelete them, then add the new ones, then delete them again.

Hmm, would it not be simpler to “delete” an icon by setting it’s X position to negative something to push it way out of the window’s visible work area? Then it can stay “created” but be inaccessible to the user.

unless it is the last icon when I think it is removed on deletion?

Yes. https://gitlab.riscosopen.org/RiscOS/Sources/Desktop/Wimp/-/blob/master/s/Wimp02#L4521

Back on the theme of screen sizes/modes, almost… As well as coping with rectangular pixels with different sprites (and maybe templates), I want to cope with RISC OS 3.1, since that’s where I did my original.

As I’m using this as a learning experience, I thought I’d employ a bit of conditional code execution, using DragASprite along with sprites for my tiles with 3.1 and DragAnObject and Draw files for my tiles with 3.6 and above. That’s based on the belief that DragAnObject didn’t exist before 3.6.

Does that make sense or am I barking up the wrong tree?

One option is to do everything with Draw graphics and fonts, either using calls like Draw_Stroke, or actually creating Draw files and using DrawFile_Render. Then you can scale the whole thing arbitrarily without it becoming pixelated.

Having created letter tiles in Draw format and got some code to do what I want, I find DrawFile_Render is not available in RO 3.1 (I want to make the app backward compatible). Back in the day I remember creating Draw files on the fly in BASIC, is that what I would be looking at doing? Or maybe reading the data from file and plotting each path etc to screen?

There’s a module for older machines. Probably in !System somewhere.

There’s a module for older machines. Probably in !System somewhere.

There is a module, filename DrawFile, in !System. *h. Draw reports ‘Module is: Drawing Module 1.05 (03 Mar 1992)’

Not sure what help that would be.

Just RMEnsure Drawfile 1.00 RMLoad System:Modules.Drawfile in your !Run file [Edit: not the Draw module]

Okay, just come home and put the kettle on (obviously!), and while that’s doing its thing, I had a quick look.

I have the DrawFile module in !System.310.Modules.

It isn’t part of the “Harddisc4” installation, nor is it likely to be on RISC OS Direct or anything, as it’s been built in since the RiscPC.

You’ll need the PlingSystem archive: https://www.riscosopen.org/zipfiles/platform/common/PlingSystem.zip

Then you’ll have the DrawFile module for RISC OS 3.10 machines…

*h. Draw reports ‘Module is: Drawing Module 1.05 (03 Mar 1992)’

No, wrong module. *h. on DrawFile reports no help!

Stuart… Draw != DrawFile

No, wrong module.

*Help Draw
==> Help on keyword Draw
Module is: Drawing Module  1.22 (08 May 2016)
*Help DrawFile
==> Help on keyword DrawFile
Module is: DrawFile        1.61 (06 Feb 2021)

Commands provided:
Render
*Help Render
==> Help on keyword Render
*Render displays the contents of a Draw file, using a transformation matrix.
Syntax: *Render [-file] <filename> [<m00> <m01> <m10> <m11> <m20> <m21>] [-bbox] [-suppress] [-flatness <flatness>]
-bbox           draw bounding boxes
-suppress       do not draw objects
-flatness       tolerance for curved paths
*

“Draw” is the low-level drawing system where you tell it each individual path you want to draw. It’s complicated, many pages in the PRM and I understand approximately none of it.

“DrawFile” is the later extension where you can say “this is a DrawFile, please do whatever is necessary to display it”. It makes it fairly simple to create content as a series of DrawFiles, which can then be rendered without pain.

Ok, apologies for my dimness. Things are starting to come back. Manually loading the DrawFile module in advance does indeed give me what I need.

So, my experimentation with Draw files, as opposed to sprites has not gone the way I expected. The sprites look better in all modes, even rectangular pixel modes like 15 on the older hardware.

I expected Draw files to appear much better, sharper, when scaled.

I expected Draw files to appear much better, sharper, when scaled.

They do. However if they contain bitmaps then the bitmaps will look horrible when scaled.

However if they contain bitmaps then the bitmaps will look horrible when scaled.

No bitmaps involved in the Draw files and the sprites aren’t scaled. I have different sprites for different modes. The hope was to just have a single set of Draw files which I then scale as needed.

I need to look deeper at what I’m doing.

I don’t think that DrawFile module anti-aliases its lines?

Are you using a flatness argument? R5, and bit 2 of R0 set on entry? (Are you scaling up or down?)

I don’t think that DrawFile module anti-aliases its lines?

It seems you are correct. I was pointed towards AWRender, which apparently does, but I can’t find any documentation. I’m coding in C as opposed to BASIC which may not help in the case of AWRender.

Are you using a flatness argument? R5, and bit 2 of R0 set on entry? (Are you scaling up or down?)

I have not used a flatness argument thus far. I am learning as I go so I have to research everything as it crops up. I’m scaling down.

I’m thinking that based on my inexperience at this point in time, I should go with doing the extra manual work of creating extra resources and use the relevant ones at run-time. Alternatively, as someone else said, just go with one ‘general’ mode/size and let the user worry about it. I do at least though want it to be usable in RISC OS 3.1 so will need at least two sets.

Have a look in !Boot. Resources. !AWViewer. !ReadMeMW (removing spaces because this gets turned into a link).

Scaling down makes anti-aliasing more important, scaling up is where vector graphics shine: even without anti-aliasing, the lines never get blocky.

I’ve not tried using AWViewer on a DrawFile, other than dragging one to the viewer, which didn’t do anything. (AWViewer’s !RunImage is readable BASIC.)

Quick fiddle, and trying to open a DrawFile simply says “File is not an ArtWorks file”. Maybe you’ll want to buy a copy of ArtWorks?

Scaling down makes anti-aliasing more important, scaling up is where vector graphics shine: even without anti-aliasing, the lines never get blocky.

Ok, thanks. I will take a look at scaling up then.

Quick fiddle, and trying to open a DrawFile simply says “File is not an ArtWorks file”. Maybe you’ll want to buy a copy of ArtWorks?

I do own a copy of ArtWorks and the AWRender is free anyway but it is detailed documentation of its ‘api’ that I would need, especially from ‘C’, if any exists.

!ReadMeMW contains detailed documentation of its api. SWI based, of course.

I expected Draw files to appear much better, sharper, when scaled.

If you install SpecialFX then DrawFile_Render will use the ArtWorks rendering modules and anti-alias stuff (except for “thin” lines). This does mean requiring the user to install extra software so that your game looks good, which is not ideal. We recommend SpecialFX to improve the rendering in RiscOSM but I have no idea how many people actually install SpecialFX.

Perhaps I ought to add anti-aliased Draw file rendering to the wishlist!

want it to be usable in RISC OS 3.1 so will need at least two sets.

I’m intrigued as to why you are putting extra effort into supporting a version of RISC OS that the majority left behind a quarter century ago.

I’m intrigued as to why you are putting extra effort into supporting a version of RISC OS that the majority left behind a quarter century ago.

He said:

I want to cope with RISC OS 3.1, since that’s where I did my original.

Actually:

so will need at least two sets.

Three sets to do it “properly”. ;)

2:4 rectangular pixels for interlaced display modes ¹² → Sprites.
2:2 square pixels for most of us → Sprites22.
1:1 square pixels for people with enormous screens → Sprites11.

Oh, and then there’s alpha transparency and theming and…..

¹ While you’re aiming at RISC OS 3.1 with this, I think these sorts of modes might come into play if you use a Pi or Beagle (etc) with composite video?

² I don’t tend to bother making 2:4 sprites that often these days. I suck at drawing and since nobody has complained I can only surmise that nobody has noticed.