| |
Magic Mushrooms on RISC OS 3.7 |
| |
swirlythingy (13:25 29/7/2012)
Raeddie (14:26 29/7/2012)
swirlythingy (12:42 30/7/2012)
Phlamethrower (14:20 30/7/2012)
Raeddie (14:31 30/7/2012)
swirlythingy (00:18 31/7/2012)
Raeddie (18:43 31/7/2012)
swirlythingy (21:11 31/7/2012)
swirlythingy (22:11 4/8/2012)
swirlythingy (16:32 7/8/2012)
Raeddie (14:40 9/8/2012)
swirlythingy (17:29 9/8/2012)
|
| |
|
Martin Bazley |
Message #120861, posted by swirlythingy at 13:25, 29/7/2012 |
Posts: 460
|
I've been having problems getting Magic Mushrooms to run properly on RISC OS 3.7. The front end seems to be doing something which the OS really doesn't like, but it hasn't caused me any trouble on any other OS.
Can somebody using 3.7 download the latest version of Magic Mushrooms (1.12) and confirm that it's not just a problem with my old and dodgy RiscPC?
All that should be necessary is to double-click on the !MagicMush application to launch the front end, then right-click on the icon it puts on the icon bar to launch the editor. (I'm not even certain if that last step is necessary.) Then attempt to use the Filer for a few simple tasks - dragging levels into the editor window, for example. If it's anything like my experience you won't manage to execute more than three or four clicks or drags (possibly not even one) before the Filer crashes with a data abort.
If anybody else manages to confirm this, I will at least know it's definitely a bug - but I haven't got the faintest vestige of an idea of where to start looking! |
| |
 [ Log in to reply ] |
| |
|
Holger Palmroth |
Message #120862, posted by Raeddie at 14:26, 29/7/2012, in reply to message #120861 |
Member
Posts: 58
|
Confirmed. Dragged levels 001-006 into the editor window. After this, a single click on the file 006 causes an abort on data transfer.
(RISC OS 3.70 with SCSI-1 harddisc, so it isn't a ADFS issue either) |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120863, posted by swirlythingy at 12:42, 30/7/2012, in reply to message #120862 |
Posts: 460
|
Goddammit.
I don't suppose you have any idea of where I'm going wrong? I can only assume it must be writing to a dodgy address somewhere, but I can't for the life of me see where!
Just to confirm one recent change: It isn't necessary to call OS_SpriteOp 9+256 before using a sprite area, is it? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120864, posted by Phlamethrower at 14:20, 30/7/2012, in reply to message #120863 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Just to confirm one recent change: It isn't necessary to call OS_SpriteOp 9+256 before using a sprite area, is it? All OS_SpriteOp 9 does is fill in the first few words of the sprite area with the right values. So as long as you've got your own code in place to do that, there's no need to use the SWI. |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #120865, posted by Raeddie at 14:31, 30/7/2012, in reply to message #120863 |
Member
Posts: 58
|
I have no idea why the crash doesn't happen on all OS versions. It looks like you produced your own little stack overflow.
In PROCinit you reserve 1024 bytes for stack%. A few lines below you do stackend%=stack%+10240.
Deleting the superfluous zero fixes the problem for RISC OS 3.70. At least it didn't appear after 3 or 4 dozen times dragging a level into the editor window. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120866, posted by swirlythingy at 00:18, 31/7/2012, in reply to message #120865 |
Posts: 460
|
In PROCinit you reserve 1024 bytes for stack%. A few lines below you do stackend%=stack%+10240. Blimey, how did that get in there?! Typical, the one place I didn't think of looking...
In fact, looking at that procedure, I see wsend% is wrong as well - but on the side of caution this time.
(For posterity's sake, the reason the stack was originally so large was that it's used as a buffer between Wimp_LoadTemplate and Wimp_CreateWindow, and the editor window has loads and loads of automatically generated identical Wimp icons in it. I used to store them all in stack% and throw the lot at Wimp_CreateWindow, but I soon realised that 280 calls to Wimp_CreateIcon was simpler and saner.)
That said... I still can't see how that would solve anything. stackend% is a safeguard and nothing more, so if the stack's overflowing then the only difference is that the program will give an error when it happens instead of just letting it overflow. It'll still crash, just in a more friendly way! If it isn't crashing after the fix, then a stack overflow can never have been the reason.
(NB: I haven't actually tested this yet.) |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #120867, posted by Raeddie at 18:43, 31/7/2012, in reply to message #120866 |
Member
Posts: 58
|
Sorry for throwing you a red herring with the stack thing, the error still persists, although it doesn't happen always.
This is what i found out so far:
- The error is only triggered when the editor window is open.
- It isn't necessary to drag to the editor window, any drag can trigger it.
- The data abort is caused in the SpriteExtend module. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120868, posted by swirlythingy at 21:11, 31/7/2012, in reply to message #120867 |
Posts: 460
|
- The error is only triggered when the editor window is open.
- It isn't necessary to drag to the editor window, any drag can trigger it.
- The data abort is caused in the SpriteExtend module. Now that's much more interesting. I did make a change in there recently, but I wouldn't have thought it would make a difference. The icons in the editor window now have filled black backgrounds to cope with the fact that the monster sprite is transparent. The monster button in the tools window also now has a filled background (although I didn't bother changing the others).
What it did before was to remove the mask from the monster sprite, but that interfered with my desire to make the sprite data immutable after loading so that it could be saved back out with the level if necessary.
Of course, the possibility still remains that it's the fault of something completely different... |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120871, posted by swirlythingy at 22:11, 4/8/2012, in reply to message #120868 |
Posts: 460
|
Well, I've solved it, but I'm not happy about the solution.
*ShowRegs revealed that the data abort was a result of SpriteExtend (thanks to Holger for that very useful bit of information) attempting to load data from an address inside application space. A quick check and, yep, it was in the sprite area which Magic Mushrooms was using for its ingame sprites to save polluting the Wimp pool with them.
I changed the code to keep sprites in a dynamic area instead, and I haven't managed to trigger the crash yet. (To make quite sure, I experimentally disabled the dynamic area and went back to using DIM, and it crashed almost immediately.)
So, are you not allowed to create Wimp sprite icons with a sprite area in application space? I ask because the editor's done this since day one, it was originally developed and tested on a RISC OS 3.7 machine, and it causes no problems on any other OS version.
I'm still suspicious that this isn't my bug... |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120873, posted by swirlythingy at 16:32, 7/8/2012, in reply to message #120871 |
Posts: 460
|
Version 1.13 available from here:
http://www.starfighter.acornarcade.com/mysite/games.htm#magicmush |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #120894, posted by Raeddie at 14:40, 9/8/2012, in reply to message #120871 |
Member
Posts: 58
|
So, are you not allowed to create Wimp sprite icons with a sprite area in application space? I ask because the editor's done this since day one, it was originally developed and tested on a RISC OS 3.7 machine, and it causes no problems on any other OS version.
I'm still suspicious that this isn't my bug...
Good news: It isn't your bug.
I think I found the offending module. It is the Window Manager 3.98, the "nested window manager". The module came as part of Universal Boot Sequence, I suspect you installed it somewhere between "day one" and today.
I temporarily disabled the loading of the module and wasn't able to trigger the error again. (Did some dozens of drags and 4 or 5 resets, so I am pretty sure.) |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120895, posted by swirlythingy at 17:29, 9/8/2012, in reply to message #120894 |
Posts: 460
|
I think I found the offending module. It is the Window Manager 3.98, the "nested window manager". The module came as part of Universal Boot Sequence, I suspect you installed it somewhere between "day one" and today. Good to hear it's been tracked down. I've definitely had the nested Wimp installed for as long as I can remember, but it's not the most reliable of bugs to trigger. It's possible it's temporarily fixed if the !RunImage is an even number of bytes long or something...
Anyway, at least I've found out what was causing the crash (access to unmapped memory) and successfully worked around it, even if I don't know why it was peeking there in the first place. Thanks for your help! |
| |
[ Log in to reply ] |
| |
|
