DrawFile_Render / Draw Files / Fonts / Scaling

Call the X-form SWI and don’t have any errors while output is redirected to the sprite.

Makes sense.

Use save areas to preserve VDU context or things might go wrong if something wants to redirect to a sprite while you’re doing that (such as FontManager caching a character).

Ok, thanks.

Just a quick note to say that it appears I am wrong about the redraw being slow and ungainly with Drawfile_Render. As you know I still have my ‘L’ plates on.

It seems the redraw of the screen is laborious as soon as I turn off ‘Auto redraw’, even with just sprite icons. This may be a case of my environment so more experimentation needed.

The main thing you need to do to improve redraw speed is to look at the rectangle the Wimp is asking you to draw and make sure you only render the things that overlap that rectangle. Redraw can happen in two circumstances: something on top of your window is moved or removed, or you request that an area is redrawn because you want to change something. In the latter case, make sure you are really specific. If a new Scrabble tile has been placed, just tell the Wimp that the area of window where that tile is has to be redrawn.

It can be a bit of a struggle to get the sums right, but it’s well worth it for speeding up redraw.

Another tip is to enclose a lot of draw objects that affect the same area of the screen in a group object. Then they are all stepped over at once if outside the area of interest, using just a single comparison.

I am going to put my oar in again and ask why use DrawFiles at all?

A Scrabble board constructed of squares ¹ and moveable ² square tiles seems to lend itself completely to sprites.

I have a principle to put as much effort as possible into the data to reduce the amount of programming.

In this case I get the feeling that you want the benefit of outline fonts, but note that you are not going to be changing the size dynamically, or are you?.

You can have this by putting outine font images in your sprites just once – the data.

You might go over to ‘The Dark Side’ and use the Paint there, but equally, you can design all your squares and tiles in Draw and then convert them to sprites using DrawToSprite from Sine Nomine – thanks Matthew. ;-)

¹ The originals are not quite square
² Sprites are [easily] draggable

Sprites are draggable

So can DrawFiles be, if one forgoes DragASprite and does it all manually. ;)

KISS ;-)

It seems the options are boundless. Probably the reason I’m only making slow progress as I want to try as many options as possible.

I started with sprites and will no doubt go there again, with plotting Draw files to sprites for example. I will look at outline fonts there too.

I guess the biggest crutch is wanting to be compatible with RISC OS 3.1

I have the dragging, placing and redrawing of Draw files looking good now, albeit on the big screen with modern modes. Working out co-ordinates is job in itself, what with the screen going one way, the board going the other and a Westie that likes to bark alot, just for the halibut!

It seems the options are boundless.

Do not even consider this seriously, but a very long time ago I wrote an educational program that required a grid into which childeren could place different shapes. To do this, I drew the shapes in Draw and converted them to a font using Draw2Font – David Pilling, I think. Then the shapes could be placed in icons as a single character. This was limited to two colours per shape, but it was quick and simple to program. ;-)

Edit: Just to emphasise that this gave scalability and antialising without stroking draw objects. This was before DrawFile, or at least before I knew about it.

Then the shapes could be placed in icons

Uhm, 15×15 icons each holding a sprite …. Nah :-)

So, I’m stuck a my first obstacle with plotting to a sprite and then to the screen. As a means of testing I thought I’d plot the ‘rack’ containing the seven tiles. I’m not getting any errors but I’m not seeing the rack either!

My code so far, using Steve’s tutorial as a starting point and OSLib, creates a user sprite area and all that works. The Draw file rendering works too when plotting direct to screen.

What I am currently doing is this (relevant bits, errors are checked, none thrown);

osspriteop_area *sprites;  // created globally elsewhere

Byte *rk = &rack[turn][0]; // pointer to current player's rack.
char id=[] = "rack";
osspriteop_id sid = (osspriteop_id)id;
int sz;
int c0 = 0, c1 = 0, c2 = 0, c3 = 0;

struct osspriteop_save_area *sa = NULL;

error = xosspriteop_read_save_area_size(osspriteop_USER_AREA, sprites, sid, &sz);

sa = (osspriteop_save_area *)malloc(sz + 32); // is this word aligned?
sa->a[0] = 0; // Initialise save area?

error = xosspriteop_switch_output_to_sprite(osspriteop_USER_AREA, sprites, sid, sa, &c0, &c1, &c2, &c3);

for(int x = 0; x < tot; x++){   // tot in number of tiles
    char t = (char) *(rk + x);
    debug_printf("Tile is %c\n", t); // prints the correct tile character
    draw_tile_ltr((10 + (x * 104)), 26, t);  // routine that renders Draw files - Does work - numbers temporary.
    //             10 + (x * 104)) is the x coord within the sprite, 26 the y coord.
}

error = xosspriteop_unswitch_output(c0, c1, c2, c3);

win_open(rack_window);

and in win_open I do this after opening the rack window (relevant bit);

wimp_get_window_state(&wstate);
int posx = wstate.visible.x0;
int posy = wstate.visible.y0;
debug_printf("Attempting to plot %s at: %d/%d\n", sid, posx, posy);
error = xosspriteop_put_sprite_user_coords(osspriteop_USER_AREA, sprites, sid, posx, posy, os_ACTION_OVERWRITE);

Can anybody see what I’m NOT doing and of course what I am doing wrong?

Obviously ‘magic’ numbers and other aspects are temporary.

I knew as soon as I asked for help …..

I hadn’t implemented the redraw of the screen, only the initial plotting. oops.

This is probably a dumb question, highlighting my lack of understanding, but, is it possible to render a Draw file to a sprite, as I am above, but then render/embed that sprite into an icon without saving the sprite to file first.

Yeah, unlikely I know. Just running different approaches through my mind.

I don’t mean just render to screen at an icon’s location, I know I can do that.

You can set up each icon’s Icon Data with the appropriate Sprite Area address and Sprite name/address. See https://www.riscosopen.org/wiki/documentation/show/Icon%20Data

You can set up each icon’s Icon Data with the appropriate Sprite Area address and Sprite name/address.

Yeah, I can do that for pre-set sprites and icons but I was just wondering about sprites created on the fly but not saved to file.

I was thinking about DragASprite usage but with Draw files. What I have done, which works fine, is render the Draw file ‘Tile’ into a sprite and passed a pointer to the result to DragASprite and it’s happy.

but I was just wondering about sprites created on the fly but not saved to file.

Yes, because ultimately you’ll end up with a sprite area address, and the name of a sprite within that area.

So instead of loading a sprite into the area and using that, you can create it on the fly. The OS doesn’t care where the sprite comes from, only that it’s a valid sprite.

Yeah, I can do that for pre-set sprites and icons but I was just wondering about sprites created on the fly but not saved to file.

How is it any different?

I was thinking about DragASprite usage but with Draw files. What I have done, which works fine, is render the Draw file ‘Tile’ into a sprite and passed a pointer to the result to DragASprite and it’s happy.

Isn’t that what the osspriteop_id id bit of

struct {
        osspriteop_id   id;
        osspriteop_area *area;
        int             size;
} indirected_sprite;

is about? It can be a pointer to a name, but it can also be a pointer to a sprite. If you set size to zero, then the Wimp assumes that id is a pointer to a sprite and not to a sprite name. This is why id isn’t a char *.

See Indirected Sprite Icons here.

So, I can create another sprite by plotting to one already in my area, on the fly, not saving it anywhere, associate it with an icon in any of my windows and it will live happily ever after. I can delete the icon, show the icon, cover my window, uncover my window and this sprite will always be there as if I had created it before runtime? Interesting. The user sprite area can just keep growing automagically?

Ok. Lots more experimenting needed.

The user sprite area can just keep growing automagically?

No, you have to have space in the area for the sprite. However, when creating your area with

/* Allocate the sprite area memory. */

size += sizeof(int);
area = malloc(size);

/* Initialise the sprite area. */

area->size = size;
area->first = 16;

size doesn’t have to be the size of the file to be loaded. It could be the size of the file plus the size of your extra sprites.

Or use different sprite areas.

No, you have to have space in the area for the sprite.

Yeah, fair enough.

When using OS_SpriteOP one supplies the area and the boiler plate sprite name, amongst other things, but you don’t get a name in return so I guess a pointer for each one that was created would be needed, possibly 27 :-) Is that fair to say? I’m just trying to understand the underlying mechanics.

Ah, there’s your problem.

Why would the OS tell you the name of your sprite? What you think is the boilerplate name is, in fact, the sprite name. “cutegirls”, “kittens”, “titlebar”, whatever. You create a sprite with the name that you choose, and it will become a part of the sprite area. You refer to it using that name. ¹

With something I wrote recently, the base name was “frame_” and it appended a to digit number afterwards (frame_01, frame_02, etc). Just created them on the fly in the sprite area.

¹ You can also use the direct address of the sprite, for speed, but let’s keep things simple for now…

You create a sprite with the name that you choose

The sprite in my case already exists, containing a background and of the correct size and shape etc. I use it’s name to identify it when plotting on top of it and then using it with DragASprite as the rendered Draw files in the rack are one big sprite :-) DragASprite then, according to the docs, forgets about my ‘copy’. I wasn’t aware that my original ‘boiler plate’ sprite was ‘added’ into the sprite area in it’s modified form.

As a matter of interest, how would you add a suffix to the name of this rendered on the fly sprite? Edited to say, bearing in mind that I am just using OS_SpriteOP and switching outputs.

I use it’s name to identify it when plotting on top of it

By that, you mean when you redirect screen output to sprite and draw something, yes?

Assuming this is the case…

I wasn’t aware that my original ‘boiler plate’ sprite was ‘added’ into the sprite area in it’s modified form.

The original sprite isn’t “added”, it’s simply updated. It’s like if you type CLS, the screen clears. Redirect output to sprite, do a CLS, the sprite clears. ;-)

As a matter of interest, how would you add a suffix to the name of this rendered on the fly sprite? Edited to say, bearing in mind that I am just using a OS_SpriteOP and switching outputs.

For me, it was simple a case of sname$ = "frame_"+RIGHT$("00"+STR$(framenum%), 2).

For you, I think the best approach (bearing in mind I’ve not seen the code!) would be SpriteOp 27 to copy the boilerplate sprite as a new sprite. Draw into that, and then you can use that.

It’s scrabble, isn’t it? If this is the case, then at the beginning you could create the boilerplate (blanc) tile and then make 26 copies (for A-Z) adding the appropriate letter as you go. Call them “a”, “b”, and so on so it’ll be simple to keep track of. Then, you can just use those as the program runs.

For my Hanafuda game, by the way, I didn’t bother with dragging animations. One just clicks on a card, and then on where it’s supposed to go.
The rules of the game are . . . fairly simple when you have the hang of it. ;-)

I use it’s name to identify it when plotting on top of it and then using it with DragASprite as the rendered Draw files in the rack are one big sprite :-)

So you’ve updated it.

DragASprite then, according to the docs, forgets about my ‘copy’.

DragASprite forgets your sprite. But your sprite doesn’t sound like a copy: it sounds like the original, which you have updated.

I wasn’t aware that my original ‘boiler plate’ sprite was ‘added’ into the sprite area in it’s modified form.

Again, it’s not. To copy the sprite, you need to call OS_SpriteOp 27, passing the name of the sprite to be copied and the name that you want to give to the new sprite. You can then write on the copy by using its new name, use the sprite, and then delete it afterwards using OS_SpriteOp 25.