Programming & Screen Sizes / Modes

Three sets to do it “properly”. ;)

Yeah, I didn’t put that very clearly at all. I do have the 3 sets of Sprites which include the original rectangular ones I made back in the day.

Having got to the point of a working game, at least on my setup here, I’m tackling the issue of screen sizes and modes.

Currently, the game uses DrawFile to render Draw files and I can scale to fit my needs. I intend to use multiple Templates to best suit the situation met. Thinking large, medium, small plus one for rectangular pixel modes. I know I can’t cater for all scenarios.

Using WinED, it doesn’t scale down icons with underlying sprites very well, such as option and radio icons. Is this expected and therefore down to me to create smaller sprites for them? The same applies to text icons so is there anything to be aware of if I use the outline fonts option with those? Trinity should be available across the board but I seem to remember outline fonts not looking good on screen back in the day.

Finally, colours. Is it advisable to use as small a palette as possible, as in 16 colours rather than 256 for example with the older modes? Pink here looks grey in Virtual A5000 in a 16 colour mode with a 256 colour palette.

It’s suprising how much stuff you forget!

Any hints and tips welcome.

Normally the templates stay the same and the sprites change.
34×17 rectangular (MODE 12) will be the same size as 34×34 square (MODE 27), for example.

Normally the templates stay the same and the sprites change.

Not sure I understand that. If the wimp scaled things automatically, yes. :) Unless I design a template for the smallest screen, how can they stay the same? Afterall, there are more OS units on a big mode than there are on a small one.

Hang on, you mean rectangular vs square? Ok, sure.

I was querying the issue of a large screen template, a large board (1600 units sq), large tiles and rack etc. Ideal for my eyes. If, for smaller screens, I scale down the board by 50% and leave any surrounding icons at the same size (44 units high for radio/option) it’ll look kinda odd!

I guess I’ll suck it and see.

You can use Wimp_ReadPixTrans to see how the Wimp would plot any given icon in the current screen mode.

As for adapting to the current mode, you’d need to look at the scaling factor you want to apply to your window in order to draw it as you want, and then in order to keep track of where everything is in the window, divide/multiply the offsets as necessary.

That way, you can plot the icons at 50%, 100%, and 200%.
Personally, I’d have a try with simple resized plotting first, before looking at swapping the actual sprite set used. Get the mechanics going, then add the embellishments. ;)

Hang on, you mean rectangular vs square? Ok, sure.

People on this forum are making reference to those still using Mesolithic hardware, so you know somebody is going to be rocking MODE 15 like it’s 1987!

Well, this isn’t going to be as easy as I had hoped.

On 3.1 I’m getting an ‘Internal error: address exception at &03815CC8’ thrown by ‘xosspriteop_switch_output_to_sprite’ (OSLib).

I don’t get this error on 3.7 but the scaled down graphics don’t look great. I might have to recreate the graphics (board, tiles, rack etc) at the smallest size and scale up. Somebody mentioned that scaling up would produce better results.

What parameters are you passing to xosspriteop_switch_output_to_sprite and what sort of sprite are you trying to switch into?

The older machines of the 3.1 era only understand the built-in numbered modes, so if you have any other sort of sprite (bpp, dpi, peculiar palette or mask) then it’ll fail.
Can you open and edit the sprites in Paint on that machine?

Can you open and edit the sprites in Paint on that machine?

Yes. The sprites22 file contains a mixture of sprites, with & without mask and palette. They all open in paint.

The older machines of the 3.1 era only understand the built-in numbered modes, so if you have any other sort of sprite (bpp, dpi, peculiar palette or mask) then it’ll fail.

I have removed the mask & palette to no avail. Probably my code.

What parameters are you passing to xosspriteop_switch_output_to_sprite and what sort of sprite are you trying to switch into?

The sprite being plotted to is a 90×90, Mode 21, no mask, no palette. I’m rendering tile Draw files to it. The preceding code I’m using is as follows;

 
    struct osspriteop_save_area *sa = NULL;

    int sz, q;
    char id[7], t;
    snprintf(id, 6, "%srack", ppref);
    sid = (osspriteop_id)id;
    int tot = rk->tiles_held;
    int c0 = 0, c1 = 0, c2 = 0, c3 = 0;

    error = xosspriteop_read_save_area_size(osspriteop_USER_AREA, sprites, sid, &sz);
    if (error != NULL){ if(debug) debug_printf("Error from ORSAS: %s\n", error->errmess); return FALSE;}
    sa = (osspriteop_save_area *)malloc(sz);
    sa->a[0] = 0;
    error = xosspriteop_switch_output_to_sprite(osspriteop_USER_AREA, sprites, sid, sa, &c0, &c1, &c2, &c3);
    if (error != NULL){if(debug) debug_printf("Error from OSOTS: %s\n", error->errmess); return FALSE;}

As I say, this code works with 3.7 and 5.xx but could of course still be junk.

I’m suprised by the amount of hassle that sprites between different OS versions are causing me. The area of issue is with plotting to sprite. The sprites in question open fine on my other hardware but display as near garbage from my game, even if I create the sprite on said hardware. The display is fine on RISC OS 5.

Anyway, I can ditch the plotting to sprite of the racks in favour of a staight Drawfile_Render to screen, as I’m doing in the main for the rest of the plotting. One effect I’m seeing though is that when I open a rack and I plot my tiles to the screen, my tiles are immediately overwriten, i.e. wiped out and replaced by the window background without any apparent reason.

So, when a window is initially opened is it normal that it be cleared immediately? That seems odd to me.

Obviously I can use the redraw routine to redraw the tiles but that’s daft and will be apparent on slower hardware.

Obviously I can use the redraw routine to redraw the tiles but that’s daft and will be apparent on slower hardware.

Are you saying that you have different routines for plotting the window contents the first time around, compared to servicing Redraw Window Request events? If so, then: no! Don’t do that.

You should never plot to the desktop outside of a call to Wimp_RedrawWindow or Wimp_UpdateWindow, as you don’t know anything about the positions of other windows. You call Wimp_RedrawWindow in response to a Redraw Window Request event arriving.

/* The Redraw Window Request handler. */

private void redraw_window_request_handler(wimp_draw *redraw)
{
  os_bool more;

  more = wimp_redraw_window(redraw);

  redraw_rectangles(redraw, more);
}

To force a redraw, you call Wimp_ForceRedraw, which will force a redraw when the Wimp next gets around to raising a Redraw Window Request event and triggering the routine above.

If that’s not fast enough, you call Wimp_UpdateWindow and then redraw immediately.

wimp_draw redraw;
os_bool more;

redraw.w = window_handle;
redraw.box.x0 = <min X of work area to be redrawn>
redraw.box.y0 = <min Y of work area to be redrawn>
redraw.box.x1 = <max X of work area to be redrawn>
redraw.box.y1 = <max Y of work area to be redrawn>

more = wimp_update_window(&redraw);

redraw_rectangles(&redraw, more);

In both cases, we can share the same rectangle plotting code…

private void redraw_rectangles(wimp_draw *redraw, os_bool more)
{
  while (more) {
    /* Redraw the current rectangle. */

    more = wimp_get_rectangle(redraw);
  }
}

So, when a window is initially opened is it normal that it be cleared immediately?

Yes, pretty much. It’s cleared to the background colour, then the wimp will plot the icons into it. If “needs help” is set, then it will also raise a Redraw Window Request event for you when appropriate. If the window is opening from scratch, at the top of the stack, then the Wimp will almost certainly give you a single rectangle covering the whole of the visible area and there should be no speed penalty for a well-written redraw routine.

If you really don’t want the window clearing, then you can set the background colour to “transparent”. However, I’m getting the impression that this isn’t what you really want to do in this case…

[All code if off the top of my head and untested.]

Are you saying that you have different routines for plotting the window contents the first time around, compared to servicing Redraw Window Request events?

No, it’s the one routine.

You should never plot to the desktop outside of a call to Wimp_RedrawWindow or Wimp_UpdateWindow, as you don’t know anything about the positions of other windows. You call Wimp_RedrawWindow in response to a Redraw Window Request event arriving.

Yep, I understand that. My confusion arose from rejigging my code to replace the plotting to sprite routines and spending too much time at the keyboard without a break.

Once again, thank you very much for your help and taking the time to put down examples. Much appreciated.

On the subject of confusion, I can’t seem to work out how to manually clear something from a window that I plotted, rather than replotting something.

I thought I would simply (though I’m quickly learning nothing turns out as simple as I expect) call wimp_update_window with a wimp_draw containing the rectangle to clear and then not replotting the graphic. Expecting that the wimp would clear said rectangle back to the background. That doesn’t work.

    osbool more;
    wimp_draw wdr;

    wdr.w = pointer->w; // wimp_pointer passed in
    wdr.box = bbox; // previously setup osbox representing the rectangle to clear

    more = wimp_update_window(&wdr);
    draw_redraw_all_windows(&wdr, more); // routine that plots my graphics

more returns zero immediately so the call into draw_redraw_all_windows exits immediately. The rectangle within the wimp_draw is not cleared.

I’m clearly misunderstanding the exact procedre required here. According to the docs, Wimp_UpdateWindow exits via Wimp_GetRectangle so do I need to somehow invalidate the rectangle first? I thought wimp_update_window would do that.

Ok, my appologies, please ignore this noise. I think I’m losing my marbles. My interpretation of the docs AND my arithmetic are clearly pants!

Not withstanding the ‘Style Guide’, how important is the positioning on icons, their size and the size of windows in general?

I think Steve Fryatt stated that it was important for icons to be positioned on 4 os unit boundaries and WinED does this by default. Why is that important?

Is the same true of the windows themselves? If I have an object (Draw file) that acts as a background and will be scaled to suit the current screen size, if the object is scaled other than by a power of 2, it may be over or under the size of a window sized to be on a 4 os unit boundary.

As an example, a Draw file of size 432×72 os units scaled down by 0.75 will not land an said boundary. Is there an issue having a window 2 os units off that boundary so that it and the scaled image are the same size? This may seem petty but I’m curious as to the importance/reasoning and 2 os units sticks out visibly :)

It’s important when designing window templates to position your icons so that they always line up, independent of the screen mode that they’ll be displayed in. It won’t go wrong, but will look a little untidy, if you have something positioned to a 2 OS unit grid but not 4 OS unit grid in a window template when it’s displayed in a 2 OS unit mode. This was all too easy to muck up with the archaic Acorn template editor.

As for window position and extents – very old versions of the Window Manager used to get upset if the window coordinates and/or extents were not a multiple of the current screen mode’s pixel size, ISTR.

It’s important when designing window templates to position your icons so that they always line up, independent of the screen mode that they’ll be displayed in. It won’t go wrong, but will look a little untidy

Ok, I can see the ‘grid’ issue. So with a window, devoid of icons, it’s actual size is irrelevant?

So with a window, devoid of icons, it’s actual size is irrelevant?

Yes, if you’re happy that the Wimp won’t necessarily give you what you ask for. I’m fairly sure you’ll get a round number of pixels, so if that means accepting that the Wimp may round your request up (or down?) by up to 3 OS units, then so be it. If you’re concerned about things looking untidy at the edges, then those stray OS units at the extremities will be important.

Oh, and what Stuart said in his second paragraph.

Ok, so actually, the widow size is relevant.

Assuming that Drawfile_Render is accurate, scaling my draw file by 0.75, with the aim of filling the work area, gives me a size which is in the middle. So the Wimp could/would give me a work area upto 2 os units either side of my requested window dimensions.

And this could/would differ each time the window is opened?

I guess I’ll suck it and see. I’m still pllaying around with the approach to take with differing screen sizes so it’s al good experience.

Thanks to all for your help and comments so far.

Rather than keep plodding along changing this bit and that bit, I’d be grateful if anybody would be willing to give the game a play, as it stands, and let me know what they think about the UI, what problems they find, any suggestions , tips etc, etc.

I haven’t got to the rectangular pixel mode yet but I guess, it’s probably only me that cares about that. It isn’t anywhere near finished, but it is fully playable in three screen sizes, at least it is here under emulation and real hardware.

The code is extremely scruffy at the moment, due to the learning curve and having no real plan in place at the start. I will set about rejigging it shortly, but first I thought I’d get the thoughts of others, especially about the UI.

Dawggle

Comments please.

Suggest you do a new topic in the Announcements section as people may not be reading this thread because it started as a programming query!

Additionally… if you get a blank window on NetSurf, simply edit the end of the URL. Change the ?dl=0 to be ?dl=1 and it’ll offer a file called “RISC_OS”.

You might want to rename that. ;-)

Suggest you do a new topic in the Announcements

Not actually announcing anything. Just want comments on the UI/usability at this point.

You might want to rename that

Done :-) Plus added a bit about ‘blanks’ that I had omitted in the ReadMe.

Okay, so…

• Too small! My Pi is driving an LCD panel that is 1024×600 and your program has (correctly) selected the 800×600 size window.
  However, loading up the Templates file suggests that the 1024×768 size fits perfectly well and doesn’t even cover the iconbar. The work/visible area Y of that window is 960 OS units, which in a 2:2 mode will be 480 pixels. By contrast, the small size Y is 720 OS units, or 360 pixels.
  If you’re a game, don’t be afraid to take up some screen space!
  Screenshot of how it looks.

• Clicking Select on the iconbar opens the play window, but nothing works and the menu options are greyed out.
  In this instance, it might be worth switching the regular play window menu for one that simply says “New game” with the ‘n’ human submenu.
  Alternatively, don’t open the window at all but instead prompt for how many players?

• If one human is playing against the computer, the tile rack probably shouldn’t open with “Blur” selected, it makes no sense and it’s another thing to have to figure out before playing.

• Might be an idea to have a shortcut of clicking Adjust on one of the letters you’ve just placed ends your turn, instead of going via the menu?

• Didn’t know “Ed” meant that! 🤣

• Ultimately, the game isn’t actually that much fun because the computer player always picks the best words from it’s many possibilities. Well done for coding that, but when I’ve played a few turns (54 tiles in the bag) with the aid of an online word finder and I’m 33 points to the computer’s 177… it needs different skill levels so as not to be offputting for those who just want to play with the equivalent of a person, and not a genius.

• To give an idea… ataxies, ebonized, qua, ef, liroth… 🤯
  I just kept on hitting “Pass” and ended up with 15 points to the computer’s 651.

• The blank tile doesn’t work correctly. The “OK” button doesn’t, and while pressing Enter makes the window go away and the tile be placed, the word (“DOUGHT”) was rejected.

• During a setup, I pulled out an ‘E’ and so did the computer. Why did we not do it again?

• My initial letters are “ABEJNRR”.
  New game, 1 human. I pulled an ‘I’. So did the computer. My initial letters are “ABEJNRR”.
  New game, 1 human. I pulled a ‘D’. The computer pulled ‘Z’ (finally!). My initial letters are “ABEJNRR”. 🤔

• 1 tiles in the bag? Grrr… This isn’t El Reg!
  It’s not hard to do something about that. Like…

  ; assumes char strbuf[BUFLEN] exists, and in_bag is count of letters in the bag.
  snprintf(strbuf, BUFLEN, "Dawggle (%d tiles in the bag)", in_bag, ((in_bag == 1) ? "" : "s") );
  ; then wang strbuf in as the window title

• Actually, my game just ended with 1 tiles in the bag, and one remaining for the computer. A blank tile. Could have placed it below an ‘I’ and called it a ‘D’. ;-)
  Me? I scored -32 to computer’s 660. 😂

• Hahahaha! Yes! New game after that. One human. My initial letters are “ABEJNRR”. Sound familiar?

Alright, I think I’ve tortured this enough.

Thanks Rick for taking the time.

I’ve had nightmares over the size issue. The size of the windows, the template icons etc, etc. To be honest, I didn’t test enough on differnt hardware. I will now.

The strength of the PC play is obviously an issue and I’m putting levels in place at the moment.

The lack of randomness when re-starting a new game was though an oversight on my part. That was rectified in the copy I placed when changing the ‘RISC OS’ folder name on Dropbox. You had already downloaded it though :-)

When pulling equal tiles I just haven’t got around to redrawing .

I’ve never experienced the issues of the blank tile problems or finishing with tiles in the bag and I’ve played (and lost) alot of games. I did win once though.

Thanks again. Very useful feedback. Oh, and don’t ever let anybody call you pedantic(s). :-)

Still haven’t been able to replicate issues with blank tiles or the game finishing incorrectly.

I did find a bug the would, in some circumstances, cause a word played by a player (not the computer) to be rejected. You may have come across it when continally selecting PASS. Continually choosing to pass will likely result in the computer having to exchange tiles due the board becoming compressed. Two consequtive passes by all players will end the game.

The game is beatable see here, GameOver , but I’m making some changes to make it easier if players so wish. That was always the plan.

Edited to say;

I’ts difficult to alter the playing strength of the computer without affecting the dynamic of the game. The ways I see are (only affecting the computer play);

1. Use different lexicons per level.
2. Limit the length of words allowed to be used.
3. Limit the use of blanks.
4. Limit score per turn.

The algorithm I’m using makes it complicated to limit the depth of search to achieve some of the above.

The use of different lexicons nakes it easy but uses more memory.

Apart from the lexicon approach, which I haven’t tried, the game board seems to get compressed using the other methods. Maybe that’s partly my play.

Gonna go with simply limiting the search depth.

All pretty irrelevant in the scheme of life!

Ok, so reducing the search depth seems to work well, if making things easier is required. See GameOver