WIMP Programming - Window Furniture

The compatible way for pre-Wimp 3.80 versions is to use Wimp_GetWindowOutine to retrieve the screen box of the window including furniture, then Wimp_GetWindowInfo to retrieve the screen box of the work area and push y1 of the work are into y0 of the window outline, then call Wimp_ForceRedraw with -1 as window and the updated outline screen box as parameters.

Are the titles indirected? And make sure that the indirected buffers are long enough for what you’re trying to write (including the terminator).

Yes, indirected. I’ve now tracked down the malloc/heap issue, it was somewhat unrelated.

I am still having issues though and I’ve been staring at it for a while now.

As you may know, I’m using OSLib and SFLib. This section of debugging code;

//    windows_title_strncpy(rkw[turn], name);
//    windows_get_indirected_title_length(rkw[turn]);
    if(debugg) debug_printf("The name is %s\n", plr_p[turn]->name);
    windows_title_printf(rkw[turn], "%s%s", plr_p[turn]->name, " - To Play");
    if(debugg) debug_printf("The name is %s\n", plr_p[turn]->name);

returns in Reporter;

The name is Mike
The name is Mike – To Play

Hopefully it’s obvious to somebody why? I mean, why is the string constant being concatenated to the struct pointer?

I mean, why is the string constant being concatenated to the struct pointer?

Without knowing anything about the makeup of your structs, it would be interesting to know what plr_p[turn]->name was pointing to at this point. Off the top of my head, and untested:

if(debugg) debug_printf("The name is %s, name=0x%x, title=0x%x",
    plr_p[turn]->name, plr_p[turn]->name,
    windows_get_indirected_title_addr(rkw[turn));

windows_title_printf(rkw[turn], "%s%s", plr_p[turn]->name, " - To Play");

if(debugg) debug_printf("The name is %s, name=0x%x, title=0x%x",
    plr_p[turn]->name, plr_p[turn]->name,
    windows_get_indirected_title_addr(rkw[turn));

Ok, that helped to point out a fundamental error on my part. Code that I had written way back when I started. Many thanks.

The compatible way for pre-Wimp 3.80 versions is to use Wimp_GetWindowOutine to retrieve the screen box of the window including furniture, then Wimp_GetWindowInfo to retrieve the screen box of the work area and push y1 of the work are into y0 of the window outline, then call Wimp_ForceRedraw with -1 as window and the updated outline screen box as parameters.

I’m using OSLib and I could never get ‘wimp_force_redraw’ to accept -1 in R0 rather than a window. Am I missing something or do I need to actually call the Wimp_ForceRedraw swi directly?

I’m using OSLib and I could never get ‘wimp_force_redraw’ to accept -1 in R0 rather than a window. Am I missing something or do I need to actually call the Wimp_ForceRedraw swi directly?

I have never used OSLib, too little added value. Perhaps they made an alternative function for that specific case, a wimp_screen_redraw or something like that. If not you will have to use swix(WimpForceRedraw, _INR(0,4), -1, x0, y0, x1, y1).

Might need -1 casting to whatever type they’re using in OSLib for window handles.

Hmmm… DeskLib…
Window_ForceWholeRedraw(mywindow);
and job done. ;)
(plus a regular ForceRedraw for parts of the window)

I’m using OSLib and I could never get ‘wimp_force_redraw’ to accept -1 in R0 rather than a window.

If you mean that it doesn’t like

wimp_force_redraw(-1, ... );

and raises compiler warnings or errors, then that’s because you need to cast -1 to the wimp_w type for window handles.

wimp_force_redraw((wimp_w) -1, ... );

Or, probably better, use an appropriate OSLib constant to say what the -1 actually means.

wimp_force_redraw(wimp_BACKGROUND, ... );

is probably what you want.

Am I missing something or do I need to actually call the Wimp_ForceRedraw swi directly?

You are calling the SWI directly – OSLib is just a set of SWI veneers.

Hmmm… DeskLib…

Sigh. OSLib isn’t a general purpose library: it’s a set of SWI veneers on which you build a general purpose library and other software. There’s no comparison to DeskLib because they’re very different things, as I’m fairly sure I’ve explained before…

Window_ForceWholeRedraw(mywindow); and job done. ;)

In Mike’s case, since I believe he’s using SFLib on top of OSLib, he could do

windows_redraw(mywindow);

and job done (except that it won’t redraw the title, because it’s rare to need to do both the content and the title together all of the time)…

However, I think that redrawing the whole window in order to redraw the title is a bit wasteful, which is why I would tend to fall back on OSLib’s

wimp_force_redraw_title(mywindow);

to do what we’re discussing here. That’s Nested Wimp only, of course.

As all of my C applications rely on the Nested Wimp for doing nesty stuff, I’ve never had a need to implement a windows_redraw_title() in SFLib. However, if Mike writes such a beast and wants to feed it back, I’d be happy to incorporate it for others to use. :)

Might need -1 casting to whatever type they’re using in OSLib for window handles.

I must of tried everything else but that. Thanks, it did the trick.

Hmmm… DeskLib…
Window_ForceWholeRedraw(mywindow);
and job done. ;)
(plus a regular ForceRedraw for parts of the window)

A simple ‘wimp_force_redraw_title(win_handle);’ does the trick in OSLib, but only for RISC OS 3.8+

A simple ‘wimp_force_redraw_title(win_handle);’ does the trick in OSLib, but only for RISC OS 3.8+

Are you sure? Have you tried it on RO 3.10 + Netsted Windows Manager module (should be anything release 3.98 onwards). I am running my Launchpad on RISC OS 3.10 on an Archimedes and Launchpad requires the Netsted Window Manager (if you’ve seen some screenshots or videos you know it usues complex windows structure and a set of tricks that work only on the nested WindowManager).

Nested Window Manager is fine on archaic systems iff you have the spare memory!

Are you sure? Have you tried it on RO 3.10 + Netsted Windows Manager module (should be anything release 3.98 onwards).

No. Got the information from the OSLib documentation. It’s minimal extra code to use wimp_force_redraw.

Nested Window Manager is fine on archaic systems iff you have the spare memory!

As I said earlier, for useful new software (as opposed to stuff written for ‘fun’ to target retro systems), it comes down to ease of development and maintenance against how many users will care. How many people are likely to want to use Launchpad on an A5000?

Are you sure? Have you tried it on RO 3.10 + Netsted Windows Manager module (should be anything release 3.98 onwards).

It’s a Nested Wimp function, not a RISC OS function – specifically, it’s using this added functionality of Wimp_ForceRedraw.

All that wimp_force_redraw_title(wimp_w w) does in OSLib is call Wimp_ForceRedraw while passing w in R0. However, it also places &4B534154 into R1 and 3 into R2, which triggers the new behaviour of redrawing the title.

OSLib’s wimp_force_redraw(wimp_w w, int x0, int y0, int x1, int y1), in contrast, passes w in R0, but also passes x0, y0, x1 and y1 in R1, R2, R3 and R4 respectively.

I’m not sure how this can be made any clearer!

As I said earlier, for useful new software (as opposed to stuff written for ‘fun’ to target retro systems), it comes down to ease of development and maintenance against how many users will care. How many people are likely to want to use Launchpad on an A5000?

100% with you there regarding new, and reasonably modern software, Steve.

I just try to avoid adding too many new dependencies when updating software that was originally written way back then that can still be used on such ancient kit. It’s usually enough for me to test for new functionality and use that if present.

I’m not sure how this can be made any clearer!

Ermmm it was very clear for me from my first comment to help Mike ;) – You’ve got us confused with the story of RISC OS 3.8+… but glad you’ve rectified that, thx!

As I said earlier, for useful new software (as opposed to stuff written for ‘fun’ to target retro systems),

Not sure what is the difference between useful software and “stuff” written for fun on RISC OS. Kinda remind me of the time someone was kind of implying to use RISC OS as daily driver and madness like that. I know it’s not you, you (like me ) don’t use RISC OS as a daily driver, we use it just for fun/enthusiasm.

Beside of that, something written for fun can be useful, so not sure what do you actually mean Steve, sorry.

How many people are likely to want to use Launchpad on an A5000?

According to the actual user-base surely more than the number of RO 5 users. But I am not obsessed with “who’s going to use it” to be honest, don’t really care. Beside, do you know you can actually re-purpose Launchpad just with a config file to become things like a game launcher, a bookshelf for documents, an image collection, a music and mod collection etc.? (yup changing app name too etc.) – Oh and when compressed code is just like 90KB, so fairly usable on an A5000 if you ask me. Oh and a shell for tablets too, but that ain’t RO 3 stuff.

But again, who is going to use it is something I am not obsessed about, RISC OS for me is just for fun. If launchpad is useful to someone beside of me great, if it isn’t great :)

P.S. As a side note, coding on old hardware also helps improving code performance btw, so not necessarly an evil thing, given the “modern” side is still stuck at before 2004 when the world switched to multicore (not a complain against ROOL or the impressive work being done by Jeffrey, just mentioning that on RO, squeezing perfs is still an important activity).

Nested Window Manager is fine on archaic systems iff you have the spare memory!

Or RISC OS 3.20 maybe? Or ArchiEmu? Or 4MB expansion or 8MB expansion on real HW? Or VA5000? Or Arculator? I have probably forgot something else…

Or ArchiEmu? […] Or VA5000? Or Arculator?

Just wondering – what would be the use car of emulating an A5000 when RiscPC emulators exist and can run a more recent and featureful version of 26 bit RISC OS?

According to the actual user-base surely more than the number of RO 5 users.

Really? You might have an argument with RiscPC users, but A5000? I couldn’t wait to leave mine behind as running the stack and Fresco barely left room to do anything.
It’s why I wrote QuickVoy – it simply wasn’t possible to run the Argonet Voyager front end, a browser, and…

Just wondering – what would be the use car of emulating an A5000 when RiscPC emulators exist and can run a more recent and featureful version of 26 bit RISC OS?

Rick, in most cases it’s games (which in many cases runs better on RO 2 even!), then there is a portion of people that only saw Archimedes in their school times and wanted to own one (quite a bit of them doesn’t seem to be very interested in the RPC or RO 5). The A5000 is the best and most affordable machine in that retro area (until ebay scalpers will decide otherwise)

Really? You might have an argument with RiscPC users, but A5000? I couldn’t wait to leave mine behind as running the stack and Fresco barely left room to do anything.

It’s not just the A5000, is the whole lot of A3xx, A4xx, A540, A3000, A30x0, A4000, A5000 (I mean, I hope pedantry here doesn’t get as far as “we must list them all on every comment” right???? ;) ). Also, let’s not forget that 2 extremely popular devices in the retro community, the MiST and the MiSTer FPGA, reproduce the A3000 (including Virtual HD), then there are the various Archie (non RiscPC) emulators which are far more than the RPC emulators and some of them now runs even in a web browser!

Side note: With the introduction of Launchpad Game loader, the MiST and MiSTer will get a RO image that boots automatically in Launchpad pre-opened (so no need to play with the desktop) and they’ll be able to add all the games they want. The same will be made available for RO 5 btw where the game are pre-packaged in an emulation format, so you see the game icon on Launchpad and double click it from your RO 5, but that will run both emulation and game at once and you can quit a game at any time getting back to your RO 5 desktop without issues, I demoed this to a couple of ROUGOL meetings btw.

Anyway, maths says that the potential user-base for an Archimedes system (either real, FPGA based or Emulated or web based) is far wider than the RiscPC potential user-base (real or emulated) which is wider than the active potential user-base for RO 5 (real hardware, emulated on RPCEmu). It’s just a matter of accessibility, that’s all.

Also, before some fanatics gets activated, this analysis is also based on observing the internet activity about the various OSes, RO 5 has a very low internet activity compared to the retro scene in general. The saddest part is that as an active OS RO 5 has a very very little software pubblication per year, which is why I started to encourgae people to share their projects and code on GitHub, started the social media things with code being released and trying to help more people to get into coding on RO 5.

Just a side note: Funnly enough, by encouraging people to share their code on GitHub, the social media activities etc. that has given RO 5 a bump in the overall internet activity, so fanatics you’re welcome ;)

Beside of that, something written for fun can be useful, so not sure what do you actually mean Steve, sorry.

In my mind, at least, there’s a fuzzy distinction between:

• Setting out to write something that will be used for a purpose whilst being fun to put together. I use CashBook for all of my accounts. PrintPDF is used for producing The WROCC. Locate is used for finding things on my hard disc. Launcher is used for starting to do anything (that I don’t do on Linux). ProcText is used for processing incoming articles for The WROCC. And so on. These need to run on the range of RISC OS 4 and 5 systems that I use, but my priority is ease of development and maintenance and the fun is in coming up with something to do the thing that needs to be done.

• Writing something where the fun is more in the challenge of writing the thing than the use that it will be put to. I get the sense (and hopefully I’m not putting words into Mike’s mouth) that this is the case in this thread: the challenge is writing a game that will run on old systems as well as new, so doing things in a way that doesn’t rely on modern additions is where much of the fun is and ease of development isn’t the main concern.

My software mostly falls into the first category: I’m happy if what I produce is useful to others on modern machines, but I won’t lose sleep if an enthusiast can’t run them on an A305 unless the fix is simple and low maintenance. If I need the Nested Wimp for nesting windows, I’m happy to use it for that because it’s a lot cleaner than the DIY approach; after that, I’m happy to say “sorry, it won’t run on your system” for anyone that this inconveniences.

On the other hand, some of the tools that I use to build my software (and very possibly writing a Wimp library from scratch) fall well into the second category.

Does that make any more sense? As you say, this is RISC OS, so it’s arguably a very fine distinction… :)

Well for me this project started as a excercise in learning which I intended to be fun and in the most part it has been. Additionally, I wanted to produce a piece of software, a game, that would be enjoyed, by both myself and others.

My original intention was (and still is) to make it compatible with the earlier RISC OS versions, partly because it was on RISC OS 3 (having upgraded my A310) that I wrote the single tasking version.

Because I have tried many different approaches and ideas since I started this learning curve, the current state of the clone is a bit of a meander. I used, for example, DrawfileRender and so it’s not compatible with the earlier versions of RISC OS as things stand.

Having learned how to do things in one way that works, I intend to redo it in such a way as to be compatible.

I’m extremely grateful for all the help I have received here, without which I would probably have given up long ago.

Anyway, I have a working game. At least it works here on my installation of rpcemu (RISC OS 5) on a linux VM on large monitors. Thank you all for your help.

I need to now make sure it will run on various screen and mode combinations and real hardware. There are a number of tips about this already in this and other threads so I’ll get on with that before I tackle things like difficulty level. Currently it’s pretty damm good at scrabble but I guess it should be really :)

Does that make any more sense? As you say, this is RISC OS, so it’s arguably a very fine distinction… :)

Indeed, thx for the clarification :)

I guess it’s part of the way of tryign to communicate over a digital text forum, not always the best way to actually communicate!

My original intention was (and still is) to make it compatible with the earlier RISC OS versions, partly because it was on RISC OS 3 (having upgraded my A310) that I wrote the single tasking version.

Mike, as long as you’re having fun, keep going, and hopefully a new RO game will be out soon! :)