DrawFile_Render & eigen values

I don’t know if this is a RISC OS thing, a Draw thing, a hardware thing or a DrawFile_Render thing really so I’m asking here ….

Is there a way to handle the combination of rectangular pixel modes and DrawFile_Render’s handling of Draw files?

The scrabble board that I created is displayed rather poorly when attempting to use rectangular pixel modes, say Mode 15. See BOARD for a how it looks (ignoring everything other than the board lines).

It’s odd (to me) that not all the horizontal lines are doubled. The lines, both vertical and horizontal, are single pixel width and were created in Artworks.

The board displays fine in square pixel modes. The image was taken on an emulator but it looks the same on real hardware.

Is it simply a case that I should create the Draw file in a speccific way? Different line thickness? I tried playing around with ‘flatness’ (DrawFile_Render) but I don’t really know what ‘flatness’ means and it had no effect anyway.

It’s a Draw (module) thing. Try using Thin lines – any linear paths with non-zero with may display at one or two pixels thickness dependent on the screen mode and how the Draw path / file is being scaled. Draw paths can be positioned to sub-pixel positions by the creator and/or the transform matrix used to process the path; non-thin lines are then expanded to the given sub-pixel width about their centre line. You should be able to reason that when those eventual coordinates are downscaled to the screen pixels, some horizontal/vertical lines may live completely within one pixel height/width and others may span two (or more).

Try using SpecialFX to anti-alias vector graphics. Try using thinner lines. You seem to be using a very reduced screen resolution – try it ay 1920 × 1080.

Try using SpecialFX to anti-alias vector graphics

That’s good advice generally, but Mike is trying to make his game work on ancient systems!

Mike is trying to make his game work on ancient systems!

Yeah, that’s right. It’s the older systems/modes that are problemeatic. I’ll have a play with ‘Thin lines’, once I look up what the term means :-)

Thanks for the comments.

It’s odd (to me) that not all the horizontal lines are doubled. The lines, both vertical and horizontal, are single pixel width and were created in Artworks.

It’ll never look correct in MODE 15. This is because it’s a 2:4 mode, which means that the horizontal lines are always visually twice as thick as vertical ones.

Honestly, given the number of people liable to actually use such a low resolution mode (in emulators, one could use the 2:2 MODE 21…), I’d be inclined not spend too much time and effort on it.

Honestly, given the number of people liable to actually use such a low resolution mode (in emulators, one could use the 2:2 MODE 21…), I’d be inclined not spend too much time and effort on it.

If retro people are the target audience, supporting old 50Hz 15kHz rectangular pixel modes is a must. No matter if they are using something like MiST (did they ever fix 15kHz mode output though?) or their real hardware attached to an old Amiga monitor or RGB Scart TV. Only exception might be the two remaining A4s working, there you only have to cater for the lousy grayscale display :-)

If you want to target emulation users, you are going for RPCEmu/RO5 anyway (only zero-cost no-copyright-hassle RISC OS solution), so no point to even think about old stuff like Mode 21.

Honestly, given the number of people liable to actually use such a low resolution mode (in emulators, one could use the 2:2 MODE 21…), I’d be inclined not spend too much time and effort on it.

I think you are probably right. ‘Thin lines’ is a definite visual improvement but I guess, overall, my time could be better spent, especially if using ‘Thin lines’ adversely affects the code I’ve already written for determining where on screen tiles are.

If retro people are the target audience, supporting old 50Hz 15kHz rectangular pixel modes is a must.

Not the target audience, just wanted to have a wimp application that runs in those rectangular pixel modes and looks ok.

Unrelated to eigen values, I’m having problems with Drawfile_Render and grouped objects.

The problem is, now that I’m using one Draw file which includes the board squares AND the surround text all grouped together, not all of the file is rendered, all of the time following a redraw request.

When a render of the complete object is required, eg opening the window, all is good. If a small amount of the edge areas needs redrawing it’s left blank. But only around the edges of the surround.

Ungrouping some of the objects changes the behaviour but doesn’t cure the problem completely. Ungrouping all objects cures the problem and also, a single filled rectangle behaves perfectly.

Any ideas? Is this some kind of winding, odd/even, zero/non zero voodoo at play?

Your bounding box dimensions are wrong.

Your bounding box dimensions are wrong.

Only real explanation, isn’t it. Yet surprising, if the file has come out of Artworks. But it’s surely worthwhile loading it into Draw and saving it from there as that will recompute the bounding boxes.

I learn something new everyday.

Your bounding box dimensions are wrong.

it’s surely worthwhile loading it into Draw and saving it from there as that will recompute the bounding boxes.

That has done the trick and yes, the original was created in Artworks.

Thanks Guys.

It’ll never look correct in MODE 15

Not true.

The issue of uneven line thickness is caused by rounding Draw Unit coordinates to physical pixels on screen. You can place your Draw Units at a resolution of 46,080 dpi (subject to the usual FontManager settings – no, I’m not going to explain that here) whereas low-res scanlines are 45dpi.

If you position your Draw Unit coordinates correctly, this quantisation variability will not occur. This is why programs such as Vantage allow you to specify the exact parameters of the grid.

You want all your line edges to have coordinates that are a multiple of 1024 Draw Units. (Or, if drawing lines of an odd multiple of 1024DU, 1024n+512).

I for one would love to see a new 32 bit version of vantage to take me into my retirement or am I just dreaming

FTR Vantage was the first third party application to be demonstrated running 32b native on the Iyonix when that was first revealed to the public at the South West show (IIRC) – there were only two working prototypes and one started the show on my stand running V, til Castle came and asked for it back!

Vantage is retired, and it’s a very long way down my ToDo list. There are more valuable things taking my time. For example, here’s Vantage displaying and separating a number of embedded files of which it has no understanding, via IFRv2:

[Neat technical detail: My Clear renderer supports 32K and CMYK variants, so Vantage’s separation of the CMYK star is perfect – that’s not an RGB separation. I know no one cares.]

You may notice that the separation of the TSV file (tab separated value text file) reveals it to be treated as RGB black (hence the ‘rick black’ separation), which is not ideal for this kind of object. There is a direct solution to that, but it has just occurred to me that there is already enough information for V to use a different separation strategy for that object.

TSV report themselves as 1bpp vectors, so V could be more pragmatic about what ‘black’ means in that case. However, IFRv2 is highly extensible, as this demonstrates:

Some GIF artefacts in there

I’ve moved those GIFs to a different host because KeyBase was behaving very strangely. Let me know if they appear, disappear or turn to cheese.

They disappeared.

nemo, I am also speaking up to say how welcome it is that you share your knowledge and experience with us, and to ask you to visit here often.

Hear, hear!

Paul exclaimed

They disappeared

I swear they’ve very nearly improved the internet to the point it does nothing at all. Third time lucky (they were visible for me of course, thanks Google).

{kind words}

I shall try to keep my temper when faced with overwhelming daft.

I shall try to keep my temper when faced with overwhelming daft.

Sadly the world is full of it. Every time it appears that there couldn’t possibly be any more daft, some more turns up.

We all have to develop a coping mechanism.

We all have to develop a coping mechanism.

Dropping a dud printer from a height, and then smacking it with a pickaxe was quite cathartic. ;)

Otherwise my coping mechanism is gothic metal and Maltesers.

Would you ever think of open sourcing Vantage or releasing a 32bit version for the community?
I would not mind paying for it.

I shall try to keep my temper when faced with overwhelming daft.

Apologies if any of that was me. AFAIK my overwhelming daftness is only intentional and intended as humour, very possibly OTT, and very sorry about that. What I possibly don’t know is when something I intend to be serious might be daft, and sorry about that, too. In either case, I won’t take it badly if it’s pointed out.