Should I initialise claimed memory blocks?

I’m attempting to write a wimp application in bbc basic. If I run the application by double clicking its icon a few times or via double clicking !runimage the menu either repeats the same menu items with a test time prefix the same for that instance of the application (how’s that even possible I only set each menu item once?) or the data block appears corrupt, random text or icons. Running via f10 in stronged I think is okay as the bug is very intermittent. I think I’m either making a memory leak via my structured routines or not doing the wimp apis correctly. Before I spend hours on that particular aspect though I was wondering if I allocate a block of memory like dim illu% 500 does riscos guarantee all allocations are set to zero? I absolutely don’t mind doing that myself if I know that is the case, but I don’t want to initialise memory, clean if it’s just gonna mask an issue with my code more.

Before I spend hours on that particular aspect though I was wondering if I allocate a block of memory like dim illu% 500 does riscos guarantee all allocations are set to zero?

No… no, it doesn’t. You get whatever was in them after something else handed them back (possibly your own application).

I think I’m either making a memory leak via my structured routines or not doing the wimp apis correctly

If you’re struggling, you may find this example application useful, at least in order to see how the APIs are called. It’s a fully-working BASIC application shell, and you don’t need to go on to the later chapters of the tutorial that it’s the start of. It’s also MIT licenced, so feel free to pinch anything that helps.

As Steve implies, you must always ensure any DIMd memory is initialised before reading it. Memory that is only written does not need to be initialised.

[plug]
If you have not come across my Reporter I recommend you give it a go. Among many other things it has

• a *ReportDump (address) (length) command that displays memory in hex and character from within BASIC.
• a *ReportMem command which displays BASIC memory usage – useful for spotting memory leaks.

I find it invaluable for debugging programs, especially BASIC.

Please contact me if you have any questions.

As Steve implies, you must always ensure any DIMd memory is initialised before reading it. Memory that is only written does not need to be initialised.

Unless of course you want to investigate what was left in it…which might break security, but then that’s down to whatever program left it there…

As a fundamental part of the WIMP relies on being able to read or write to another tasks memory (the data transfer protocol) it’s hard to imagine any form of interprocess security ever being implemented on RISC OS, so zeroing memory before it is allocated to a task is pretty pointless.

it’s hard to imagine any form of interprocess security ever being implemented on RISC OS

Indeed. But a process that didn’t want anyone else looking at its data could zero it before releasing it if it wanted to.

I’ve installed reporter and downloaded the sample app. Both look good thanks. Quick question, which icon resolution sprite files should I include. I noticed some modern apps don’t include !sprites22?

Quick question, which icon resolution sprite files should I include.

As many as you want to, really. There should always be a !Sprites file, but !Sprites22 is pretty much a “must” these days, too, since almost everyone will be using a “square pixel” mode. !Sprites11 is a courtesy to Pinebook users, too (and anyone else who chooses to use “BigMode”¹).

I summarised all of this in my Wimp C tutorial, in the section on application directories (there’s no C present in this bit, honest).

I noticed some modern apps don’t include !sprites22?

It’s possible to just put the 90dpi square pixel images in !Sprites, and forget about supporting rectangular pixel modes: the Wimp will just try file suffixes in order until one exists. However, given the ease with which ChangeFSI will convert from the files in !Sprites22 into those needed by !Sprites, I don’t see much point in not providing both.

¹ Any mode where the mode string contains “EX0 EY0”.

It has been gently pointed out to me (thanks, Sprow) that the sprite sizes given in the tutorial above were not quite correct… this has now been fixed.

(For now, the actual sprites in the download archives remain incorrect — I’ll try to fix that as soon as I get a spare half hour to rebuild them all Edit – now sorted).

I don’t know how I missed your website, the information on sprites were very useful. I tried Inkscape on Linux but it looked like a steep learning curve and is probably for serious artists. I couldn’t get grid lock on, then I vaguely remembered, oh yeah !Draw used to be able to do that I wonder if it still does. What !Draw wasn’t able to do though was save as a sprite, the option was greyed out. Quite worrying after having spent an hour discovering geometric shapes and outlines seemed to be the key to drawing stuff, with no ability to save as a sprite, I looked at !dpscan, !intergif, !changefsi preferring to use drawtosprite from sinenomine. That has antialias options, scale and dpi in one dialogue box. Excellent really, thanks. They all are but I was in a rush. I am not sure if this workflow is the correct way to do icons but I thought a set of primary vector files for scaling and generating sprites wothout losing resolution was probably the way to go? I appreciate now the work that must have gone into the RO icon sets, things like graduated fills and detail in such tiny icons. I also followed SF recommendation and instructions to register the app and that came back really quickly from riscos open thanks. The application is with someone who can hopefully take a look at it and tell me if it’s useful and if I should continue. To end on topic the issue was unitialised memory.

What !Draw wasn’t able to do though was save as a sprite, the option was greyed out.

It may not suit your purpose, but I keep Darren Salt’s Spr2Png handy at all times.

It will accept a Drawfile (or ArtWorks) (as Paint should but doesn’t), but clips it. It will spit-out a sprite or a png very easily, so is my preferred “goto” despite being so old (2006).

Alas, where to get it now?

That’s good advice. I think this is it. http://old-www.moreofthesa.me.uk/progs.source.html

I understand what you mean I was starting think the same when all the applications I ran to do a more thorough basic crunch refused to work. Fortunately Aemulor made them work. But if there was no Aemulor? All those really clever apps would be lost forever to real hardware. If I was clever enough I’d reimplement them but I’m not.

I don’t think I’ve ever wanted a sprite with as many pixels as my screen, so I’ve always just screen grabbed with Paint from a Draw window. (Most of my work in Draw ends up as SVG (via XP1Dr2SVG) for my website, not bit image anyway.)

A good way to convert draw to sprites is with Artworks as it then uses anti-aliased rendering to get rid of jaggies but preserve detail. If you can’t do that, always export to a 16M colour sprite 4x the desired size and scale it down with !ChangeFSI to anti-alias it. Make sure you set sensible widths for all your lines though, as default thin lines wont anti-alias well using either method.

That’s good advice. I think this is it. http://old-www.moreofthesa.me.uk/progs.source.html

Bravo – well-located. I’m sure that’ll help someone in the future!

For completeness, it will accept ArtWorks files as well!

Sorry – I see that I did mention that earlier!

I use !Arworks, but there is a !DrawToSprite utility that works great:
http://www.sinenomine.co.uk/software/#DrawToSprih

As an aside, I should mention that I made an attempt at updating Spr2Png to deal with newer sprite types. I never got around to implementing proper support for creating sprites with alpha transparency, but if necessary I’m happy to do a release of it without that particular feature.

The sources can be found here: https://github.com/ccawley2011/Spr2Png