Sprite Plotting in Window

I’m having difficulty in plotting a sprite in a window, I’ve done this before a long time ago and the C code is currently sitting on my mothballed RiscPC’s hard drive. My question is, is there any source where there is sample C code I can download and examine? I’m currently writing a DDE C++ application using a library I’ve also been writing using the DDE C++ compiler.

Basically, what I need to find is which fields do I need to use in the toolbox h.Wimp WimpRedrawBlock structure and the equations to work out the x,y values to plot the sprite?

I have an application working with a window but the sprite is being plotted erratically within it.

I’ve looked and tried to follow the PRM’s, I have the originals, but have not had any breakthroughs.

Thanks in advance

I’ve a (very) simple implementation of the game !centipede in C that runs in a desktop window, which you can find here:

https://github.com/usr-bin-gcc/Centibug

It doesn’t use toolbox though, just basic riscos_lib.

Thanks, I see from line 785 in main is the code I’m probably looking for. The inital settings of r.box, are they mode dependent?

I’m using the toolbox for the window but the wimp library is included in the toolbox as well, so all ok.

I’m sitting in the car right now (not driving!) so just a few thoughts.

Your sprite origin has to be worked out by determining where the window is relative to the screen. The x min y min stuff will tell you that.
If your window has scroll bars, you’ll need to take that into account to work out which part of the sprite is actually visible (just bodge the sprite origin so the right bit appears in the window).

A gotcha is that usually the window Y dimension is negative, and sort of goes backwards to what you might expect. I think in the Wimp, the position 0,0 is the top left of the screen, whereas for the VDU system (and sprite plotting) it’s the bottom left. So you’ll need to adjust for this.

When you have worked out the pixel position of where the sprite needs to be placed, you’ll then need to fudge the plot location by the eigen values (turning pixels into OS coords). If it’s appearing too far to the left/bottom, try pasting in << 1 to the plot X, Y. If that works, one of the ReadVDUVariables will tell you the current eigen values for X and Y (read both, they may be different).

Oh, and if the colours are coming out weird, look at Wimp_ReadPixTrans.

That’s all that comes to mind right now, I hope it’s useful in some small way.

Unless you’re looking for ultimate performance, let the Wimp do the mode-independent work for you: SWI Wimp_PlotIcon

Put it into an icon and plot it on demand during redraw? Oh, that’s devious!

Basically, what I need to find is which fields do I need to use in the toolbox h.Wimp WimpRedrawBlock structure and the equations to work out the x,y values to plot the sprite?

Curiously, I wrote some code to do that the other day… It’s not the toolbox (it’s OSLib), but you should be able to convert the fields fairly easily.

Here’s the redraw loop:

https://github.com/steve-fryatt/puzzles/blob/05c031097cdc6b9d7acf4b68852bcc8b8811091b/src/game_window.c#L1053

and the calls into the canvas_ code module are defined here:

https://github.com/steve-fryatt/puzzles/blob/05c031097cdc6b9d7acf4b68852bcc8b8811091b/src/canvas.c#L591

and here:

https://github.com/steve-fryatt/puzzles/blob/05c031097cdc6b9d7acf4b68852bcc8b8811091b/src/canvas.c#L621

I’ll now wait for people to review it and tell me what I’ve done wrong.

The inital settings of r.box, are they mode dependent?

No, they’re work area coordinates. They will depend on the size of your sprite when plotted in the window, but should not vary by mode unless you’re changing the size of the plotted area by mode (which I don’t think you should be doing, in most cases at least).

I’ll now wait for people to review it and tell me what I’ve done wrong.

While we’re here… one thing that I’m not 100% sure about. I’ve been assuming – since there doesn’t appear to be much in the API to allow the user to do it directly – that the OS will clip the sprite redraw down to fit in the clip window that the Wimp has set for redraw? Otherwise that redraw code is probably very inefficient. :-)

I think the Wimp just sets an OS clipping rectangle. It’s a shame there was never a SWI to plot a part of a sprite…

I think the Wimp just sets an OS clipping rectangle.

But surely¹ OS_SpriteOp isn’t daft enough to expend time on the areas outside the clipping rectangle, is it? So it will respect the Wimp’s clip area, and not waste time plotting outside of the redraw area?

I suppose I could just look at the code, but it’s probably impenetrable assembler with numeric labels and few, cryptic comments.

It’s a shame there was never a SWI to plot a part of a sprite…

Indeed. It was the lack of one that started this train of thought the other week as I wrote the code linked in above.

¹ I’d like to assume it couldn’t be, but the PRMs don’t seem to say that it isn’t.

But surely OS_SpriteOp isn’t daft enough to expend time on the areas outside the clipping rectangle, is it? So it will respect the Wimp’s clip area, and not waste time plotting outside of the redraw area?

OS_SpriteOp certainly used to efficiently reject sprite rows above and below the OS clip area, working out the offsets to the start and end data once per plot, applying those to each row.

It’s a shame there was never a SWI to plot a part of a sprite…

Indeed, but for other reasons.

OS_SpriteOp certainly used to efficiently reject sprite rows above and below the OS clip area, working out the offsets to the start and end data once per plot, applying those to each row.

That’s great – thanks for confirming that it does!

Indeed, but for other reasons.

Although it can be achieved with a clip rectangle, presumably, so it’s “just” a nice API that’s missing.

redrawWindowRequest() is an overloaded member function, WimpRedrawWindowBlock is the standard structure for a redraw, getPollBlock() does what it says, again a member function of the tasks object. tools->spriteArea->putSprite("newsprite", x, y, 0); plots the sprite at x,y.

I know the following lines are incorrect as I get the problems I’m having:
int x = wimpRedrawBlock->redraw_area.xmin + (wimpRedrawBlock->xscroll - wimpRedrawBlock->visible_area.xmin);
int y = wimpRedrawBlock->redraw_area.ymax + (wimpRedrawBlock->yscroll - wimpRedrawBlock->visible_area.ymax);

The bits which are wrong I think are wimpRedrawBlock->redraw_area.xmin and wimpRedrawBlock->redraw_area.ymax

The PRM’s show:
work area x = screen_x + (scroll_offset_x – visible_area_min_x)
work area y = screen_y + (scroll_offset_y – visible_area_max_y)   (corrected, was scroll_offset_x in the PRM’s)

void SpriteTest::redrawWindowRequest() {
   int more;
   WimpRedrawWindowBlock *wimpRedrawBlock = (WimpRedrawWindowBlock *) this->getPollBlock();
   wimp_redraw_window(wimpRedrawBlock, &more);
   while (more) {
     int x = wimpRedrawBlock->redraw_area.xmin + (wimpRedrawBlock->xscroll - wimpRedrawBlock->visible_area.xmin);
     int y = wimpRedrawBlock->redraw_area.ymax + (wimpRedrawBlock->yscroll - wimpRedrawBlock->visible_area.ymax);
     tools->spriteArea->putSprite("newsprite", x, y, 0);
     wimp_redraw_window(wimpRedrawBlock, &more);
   }
}

What is it I have to replace those two lines with?

What is it I have to replace those two lines with?

I think you have the wrong direction. The lines that you show are for converting from a screen coordinate (eg. a mouse click) to a work area coordinate. You need to go the other way: from the work area to the screen. In the example that I linked above, the lines are

ox = redraw->box.x0 - redraw->xscroll;
oy = redraw->box.y1 - redraw->yscroll;

which I think in your library is

int x = wimpRedrawBlock->visible_area.xmin - wimpRedrawBlock->xscroll;
int y = wimpRedrawBlock->visible_area.ymin - wimpRedrawBlock->yscroll;

Your window is not moving around during redraw, so the screen origin for its work area will not vary depending on the bits being redrawn. Your sprite’s corner will always be at the same place on the screen, but (as discussed in my tangent above) the bit being redrawn will shift around. That “shifting around” is handled by the OS only plotting the bit of the sprite that falls within the clip window set by the Wimp on that iteration of the redraw loop.

On a separate note, should that final line be a call to wimp_redraw_window()? I’d expect that to be called once at the entry to the while loop, followed by a call to wimp_get_rectangle() when you’re in the loop itself and deciding whether to do another iteration or not.

For comparison, here’s the code that I linked in above (with the irrelevant stuff removed):

int ox, oy;
osbool more;

more = wimp_redraw_window(redraw);

ox = redraw->box.x0 - redraw->xscroll;
oy = redraw->box.y1 - redraw->yscroll;

while (more) {
  canvas_redraw_sprite(ox, oy - WINDOW_HEIGHT_IN_OS_UNITS);

  more = wimp_get_rectangle(redraw);
}

Note that I’m calculating X and Y once, before entering the loop, as they don’t change once the redraw has started – they can’t, unless the window moves or scrolls. And the window can’t move or scroll while you’re redrawing it.

Edit For clarity, if you do the conventional "origin at the top left of the window’s work area, with Y coordinates negative, the Y origin is at the top left of the window when you calculate it. So you have to subtract the window height in OS Units, as OS_SpriteOp is expecting the coordinates of the bottom left corner. WINDOW_HEIGHT_IN_OS_UNITS is a fake constant to avoid having to explain where that’s coming from in my code, as that’s not really important here.

(canvas_redraw_sprite() is effectively just a wrapper around a call to one of the sprite-plotting OS_SpriteOp reason codes, which can only plot one specific sprite.)

Thank you, I’ll investigate further tomorrow. I see what you mean about x & y not changing.

Just tried the following outside the loop
int x = wimpRedrawBlock->visible_area.xmin - wimpRedrawBlock->xscroll;
int y = wimpRedrawBlock->visible_area.ymin - wimpRedrawBlock->yscroll;
Just get the window edges drawn within the window when scrolling or resizing.
I’ll relook at it later, got invigilation to do now.

Found the following worked, 1440 is twice the value of the current display mode for the Y direction at 720, so each pixel is 2×2 units.

void SpriteTest::redrawWindowRequest() {
   int more;
   WimpRedrawWindowBlock *wimpRedrawBlock = (WimpRedrawWindowBlock *) this->getPollBlock();
   wimp_redraw_window(wimpRedrawBlock, &more);
   int x = wimpRedrawBlock->visible_area.xmin - wimpRedrawBlock->xscroll;
   int y = (wimpRedrawBlock->visible_area.ymax - wimpRedrawBlock->yscroll) - 1440;
   while (more) {
     tools->spriteArea->putSprite("newsprite", x, y, 0);
     wimp_redraw_window(wimpRedrawBlock, &more);
   }
}

Now to find out how to calculate the 1440 value from the current mode. Thank you for the pointers.

Now to find out how to calculate the 1440 value from the current mode.

Like I said, eigen.

Get the screen X and Y.
Then the eigen X and Y.

Then screenX = (Xpixels +1) << Xeigen and the same for the Y.

Try OS_ReadVDUVariables…

Here’s the SWI:
https://www.riscosopen.org/wiki/documentation/show/OS_ReadVduVariables

Here are the numbers of interesting things:
https://www.riscosopen.org/wiki/documentation/show/Mode%20Variable%20Numbers

SWI OS_ReadVduVariables is your friend.

See YWindLimit and YEigFactor in https://www.riscosopen.org/wiki/documentation/show/Mode%20Variable%20Numbers

Get the screen X and Y.
Then the eigen X and Y.

If we’re talking about the sprite dimensions here, then is this necessary?

First, the dimensions will be the dimensions of the sprite, and not the screen, so there’s no need to read those back. You just need to know (or look up using OS_SpriteOp and/or poking in the sprite definition) the size of the sprite.

Then, depending on where the sprite comes from, the mode may be already defined and so the eigenvalues will also already be known. For example, in Puzzles (the code I’ve quoted above), I know that the sprite will be Mode 21 (because that’s what I will be creating it as), so I know that there are two OS units per pixel in each direction. But if the sprite mode isn’t known, then you do need to pass its mode to OS_ReadVduVariables and read the units-per-pixel back.

Edit Oh, Textile.

All sorted earlier, I used OS_ReadModeVariable, to work out the information I needed, and OS_SpriteOp to get the size and mode of the sprite.
Thank you.

If we’re talking about the sprite dimensions here

Generally you don’t need to worry about the sprite plotting as the OS knows its modes and colour depths so can tell how big the sprite is.

But you do have to jump through all of these hoops if you want to draw it in the right place on the screen, especially given as all of the placements are OS units rather than pixels.