Programming & Screen Sizes / Modes

What’s the considered approach to dealing with the potentially different screen sizes/modes when writing an app? Do you guys decide on a mode and stick to it or try and facilitate as many as possible? New to wimp programming so would just like opinions.

I’m doing a scrabble clone and I need to deal with the pointer and it’s position on screen for various things, such as dragging tiles (sprites) etc. My first thought (and current situation) was to create two sizes of everything in the templates file, one large, one small, but is that a sensible approach?

This approach works fine on my main box and on old Acorn hardware if I’m in the right modes.

As I type this I think maybe I’m fussing. Two mode options should be fine. It’s not as if I’m dealing with a plethora of phones or such like.

Any thoughts?

Sorry, I can not post any code next few days.
I use OS_ReadModeVariable to find the actually screenmode and use this information to create an own window or preselect one from various templates.

With Wimp_GetWindow_State, Wimp_GetIconState and Wimp_GetPointerInfo you have the information you need but you have to note the different orientations.

I use OS_ReadModeVariable to find the actually screenmode and use this information to create an own window or preselect one from various templates.

Ok, thanks for that. So, have multiple templates, with the contents named the same, and load the best one for the current screen size. Makes sense.

How are you rendering the board?

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.

Take a look at SuperDoku for an example of a game with this sort of rendering. (Sorry, no source code.)

How are you rendering the board?

The board, rack & tiles are sprites. I’m new to RISC OS wimp programming, I’m re-doing a single tasking BASIC version I did way back in the day, for which I used sprites. Didn’t think about Draw graphics but it certainly sounds like a great idea.

I’ll see what I can find on that approach. Many thanks.

In addition to my first post…

SYS “OS_ReadModeVariable”,-1,11 TO ,,xscreen%
SYS “OS_ReadModeVariable”,-1,12 TO ,,yscreen%

… for the resolution (starts with 0 so for HD it gets 1919 insteed of 1920)

or

screen_width% = (VDU 11) << (VDU 4)
screen_height% = (VDU 12) << (VDU 5)

for the OS-Units.

I generally assume a minimum screen resolution of 1024×768 when designing applications, but rarely want to take over the full screen when doing so. You could argue 800×600 or even 640×480 (which is technically lower than MODE 12’s 640×256 due to rectangular pixels) but the reality is that even a small LCD will likely be 1024×768. If you design to fill 800×600, then it’ll looks nice on 1024×768. Worth noting that 540 is half of 1080, though, when considering heights.

However, 1920×1080 will likely be the most common resolution. My suggestion if using sprites would be to do what you have done – have two sizes of tile graphics (and templates) – and use Raik’s code to choose which set to use (and offer option in settings). Larger monitor owners will enjoy the option of using larger “HD” tiles whilst smaller monitor owners can use the original, smaller tiles from your older application.

PS, you may also wish to check eigenvalues when reading mode properties. Default is 1, but “Big Mode” on Pinebook uses 0 (effectively halves the visible resolution, for double detail/size), and it is useful on 4k displays too. You can probably ignore this, as the wimp generally handles things automatically, but worth at least testing in EX0 EY0 mode to see how it looks.

You might want to download one of my games from :-

www.mbelect.co.uk/RISCOS

These games use a technique where all graphics are drawn to a single sprite and then the sprite is rendered to the screen, one advantage that may be of use to you is you only need to scale the one sprite to enable different screen sizes. The games use this techinque to have a window size of 640 × 480 or 960 × 720

The games run in the desktop but you could use the technique in full screen, In theory you could download !Invaders and remove the contents of DEFPROCDraw_Main_Screen and replace with your own graphic routines and you would have a desktop application.

Anyway it may be of help just to have a look at something like !invaders as it is supplied with source code, good luck

Thank you Andrew and Terry for your useful tips and comments, I’ll certainly take them on board.

I’ll also take a look at !invaders for sure. Any code I can peep at will be helpful as the wimp is proving much more intriguing than I had imagined, before I really started to look.

I’m also looking at Draw graphics as an option now, following Mathew’s comments.

I’m enjoying just learning all this new stuff.

Again, if you’re using SFLib, you’ll find that the calls referred to by Raik are packaged up in the general_mode_width() and general_mode_height() functions.

PS, you may also wish to check eigenvalues when reading mode properties. […] You can probably ignore this, as the wimp generally handles things automatically, but worth at least testing in EX0 EY0 mode to see how it looks.

It depends on what you’re doing. The Wimp will sort out anything loaded into the Wimp sprite pool with *IconSprites, so long as you supply the correct sets of sprites in the location that you point to. You really need three sets these days, identified by suffixes on their filenames: see the section on ‘An Application Sprite’ here for details. These will give a good display on square pixel, rectangular pixel, and “Big Mode” displays.

However, sprites used solely within the application should not be loaded into the Wimp pool, as it’s just for those used in shared locations like the Filer. For the application’s internal sprites, you’ll need to create a user sprite area and handle the filename suffixes when loading files for yourself: I wrote about that here. The resources_load_user_sprite_area() function from SFLib which is dissected there does the suffix stuff for you; it was pointed out by Gerph that the code there is probably sub-optimal, but it will do fine in most cases¹.

I’m not fully sold on using different templates for different screen modes myself, although I’m not going to say “no”. However, if you are, remember that the user can change mode whilst your application is running. You must listen for Message_ModeChange being broadcast, then re-load and re-position everything sensibly in the event that you see one.

¹ And patches to SFLib are always welcome if anyone wishes to fix it. I’ve got a long backlog of development things that I must do first, unfortunately.

Oh, and one other thing… Due to the eigenvalue issue, you should design your window templates such that every icon is placed on a four OS Unit grid: this way, whatever screen mode is in use, things will line up with whole pixels.

WinEd will enforce this unless you tell it otherwise, and some other template editors (TemplEd for one?) will too. I don’t know what FormEd does, but no-one uses that… do they?

I don’t know what FormEd does, but no-one uses that… do they?

I do. I don’t understand why it is fashionable to put FormEd down. I get on with it better than all the alternatives.

I hve a slightly modified version that allows me to type in numbers for the positions and sizes.

I don’t understand why it is fashionable to put FormEd down.

Dave wonders why people think FormEd is rubbish…

I have a slightly modified version

…after modifying it to be slightly less rubbish…

FormEd is a badly designed editor from the RISC OS 2 era, barely changed since then, with a dreadful UI that makes simple tasks difficult. It is, likely, also the reason why everything else (especially stuff written in C) jumps through hoops to use &0D termination on strings. The Wimp is perfectly happy with nulls (the docs say “control terminated”), but IIRC FormEd poops itself given such a template file.

It’s not “fashionable” to bash FormEd, it’s just honesty.

Again, if you’re using SFLib, you’ll find that the calls referred to by Raik are packaged up in the general_mode_width() and general_mode_height() functions.

I am and I have used those functions thus far.

However, sprites used solely within the application should not be loaded into the Wimp pool, as it’s just for those used in shared locations like the Filer. For the application’s internal sprites, you’ll need to create a user sprite area and handle the filename suffixes when loading files for yourself: I wrote about that here.

Ok thanks.

I’m not fully sold on using different templates for different screen modes myself, although I’m not going to say “no”.

Currently I’m using one but with two sizes for each window within it.

Oh, and one other thing… Due to the eigenvalue issue, you should design your window templates such that every icon is placed on a four OS Unit grid

I am using WinEd but I have tweaked positions manually so thanks for that heads up.

On the subject of WinEd, I seem to be chasing my tail in my attempts to create windows for the different screen sizes and pixel shapes.

I have four group boxes, one for each player, which contain within, 3 other icons, plus the comment icon for the name. However, one of the group boxes stubbornly sits in front of it’s ‘children’, blocking from sight half of the name icon. It does not block from sight the three icons at it’s centre but it does prevent ‘access’ to them when running.

How do I send the group box to the back? This doesn’t happen in other templates and deleting and recreating the group box does not help.

I think that Riscos bases the icon front/back on the icon numbers. You may have to renumber the icons such that they appear at the correct level.

Icons are plotted as they appear in the template – ie by icon number 0,1,2,… So group boxes must be a lower icon number than anything within.
If you create Group Box before icons within, all is well.
Otherwise, you may need to use the Icon → Renumber facility,
Note that renumbering 4 as 2 will also change icon 2 (to 4, I think).

If you have many icons you will find the N validation useful, as it enables names to be added that can then be exported by WinEd and used in your program, which makes changing existing templates much easier and less error prone.

If you have many icons you will find the N validation useful, as it enables names to be added that can then be exported by WinEd and used in your program

This topic that I started a year ago is tangentially relevant.

Yup – I have modified my WinEd export for BASIC to include LET so the source auto-changes after template changes and is readable. Then I use Crunchie to convert them back to constants for execution if required.

Thank you everybody. It must have been a ‘renumber’ that I did that caused the problem, i.e. it was fine, I then renumbered 5 icons and at that point, without realising, the issue must have occurred.

It must have been a ‘renumber’ that I did that caused the problem

Renumber is tricky. With WinED, you need to start with the lowest number that you want to change – i.e. the icon which will be the lowest numbered after renumbering. Then go through every remaining icon in ascending number order.

Any other strategy runs a risk of unexpected resulting numbers.

Renumber is tricky. With WinED […]

It has nothing to do with WinEd (not “ED”). The Wimp won’t allow missing icon numbers, because they’re just an index into the array of icon definitions¹ associated with a window, so any changes will by definition involve the recycling of icon numbers.

It’s why naming icons using the N validation string where possible² and exporting the numbers into your program as a set of constants is a very good idea. It saves a lot of anguish.

¹ You can flag an icon as “deleted”, but in template files it’s mainly used for hiding icons, not removing unused ones.

² SFLib will use the N names directly for Interactive Help, for example.

You can flag an icon as “deleted”, but in template files it’s mainly used for hiding icons, not removing unused ones.

If I remember correctly, if you flag an icon as deleted, then use Wimp_CreateIcon, it will overwrite the deleted icon. When I add icons to one of my windows, where there are icons hidden with the deleted flag, I have to undelete them, then add the new ones, then delete them again. Doing all this between Wimp_Polls, means that they don’t appear to the user.

Icons deleted are just flagged (and can be re-used by CreateIcon) … unless it is the last icon when I think it is removed on deletion?

FormEd poops itself

On those grounds, we wouldn’t use Zap. As I was reminded a few minutes ago, when it crashed again, losing some of my work.