Latest changes to SprExtend

Has anyone else built the rom with the latest changes to the SprExtend module ?

On my desktop, some of the icons seem to have a problem being displayed correctly.

They seem almost inverted.

One Icon as an example is the Acorn switcher that is used to replace the “blob” switcher from the Misc Configuration plugin from Paul vigay.

Changing back to a previous version fixes this.

(on another note, how do you checkout previous versions from CVS ?)

I’ve not brewed it into an actual ROM, but have been using the module softloaded without issue (ie. by double clicking on MkROM). Can you provide details of the sprite in question, and the screen mode you’re in, eg. by uploading it to some webspace.

  cvs co -r Thing_123 path/of/the/thing

The screenshot with the problem is here and the same shot with an older SprExtend here

The screen mode is 1280×1024 16m @ 57Hz.

Thanks for the CVS tip.

That’s pretty! Something special about plotting into 16M colours.

I think I might have had a problem with my two times tables when I ran out of fingers – I’ll take a look.

Yeah – 1.29 should be a bit less orange. Please give it a try.

Thanks, that’s a lot less “Halloween”.

One error I encountered when building was _rt_udiv was being referred to from o.putscaled.

Searching through the source, I found Sources.CSupport had two EXPORT lines with _rt_sdiv in, so I changed one and it then compiled

What version of ‘cc’ are you using? The duplicated EXPORT is the mistake, but I didn’t get any calls to __rt_udiv so didn’t see it.

CC 5.68 [25 June 2009]

Ah OK, different versions, and presumabky its policy on dividing by known constants has changed from sdiv to udiv at some point. Mystery solved.

I’m getting the following error building the latest OMAP rom.

SpriteExtend...
amu -E  install_rom INSTDIR=RAM::RamDisc0.$.RiscOS.Install.ROOL.OMAP3.Video COMPONENT=SpriteExtend TARGET=SprExtend 
do mkdir -p o
objasm -Stamp -quit -depend !Depend    -o o.SprExtend sources.SprExtend
ARM AOF Macro Assembler 3.32 (Acorn Computers Ltd) [10 Feb 2005]
Error: Undefined symbol at line 198 in macro MakeSpriteErrorBlock
 at line 183 in file Sources.SWIs
 included by GET/INCLUDE directive at line 783 in file "sources.SprExtend" 
  198 00000368         DCD     ErrorNumber_Sprite_BadJPEGUnsupported
Error: Assertion failed at line 95 in file Sources.SprOp
 included by GET/INCLUDE directive at line 785 in file "sources.SprExtend" 
   95 00000b44         ASSERT  (.-myjptable) = (mymaxreason-myminreason) * 4
Using SMULL - StrongARM or later only
Assembly terminated: 
2 Errors, 0 Warnings
AMU: *** exit (1) ***

AMU: *** 'install_rom' not re-made because of errors ***

Error running make install_rom on module 'SpriteExtend'.
Fatal error running make install_rom on module 'SpriteExtend'.
Batched errors...
Error running make install_rom on module 'SpriteExtend'.

Looks like this HdrSrc change needs applying to the Cortex branch. Give me a minute and I’ll get it sorted…

I haven’t had a chance to test it yet, but it should work now!

I’m fascinated by the revision logs in that component:

To allow public release of this component, sensitive header files have been moved out of the way. HdrSrc will in future only contain preprocessed versions of those files with confidential information filtered out.

What dangerous secret highly classified damning material could possibly be held in lists of standard SWIs and filetypes? Is there something you’re not telling us, Ben? ;-)

That worked. Thanks.

One thing I’ve noticed when building the OMAP rom. The modules Chars, Help and AUN Messages always get stamped with the date the rom is built.

The modules Chars, Help and AUN Messages always get stamped with the date the rom is built.

That’s because the code is wrapped in a fake module automatically generated (‘modgen’) which doesn’t know how to find the version of the thing it just wrapped up (the contents have the right date), unless you’d like to change modgen…

The allocations database, including lists of filetypes, SWI names, etc. has always been confidential because it reflects registrations by companies for products which may not be released yet. HdrSrc was traditionally the home of the allocations database. This is no longer the case, we build HdrSrc from a private component called HdrGen.