Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #824 > unrolled thread

Sprite Loading / Plotting SWIs and lotting in any colour depth

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Sprite Loading / Plotting SWIs and lotting in any colour depth Michael <michaelremerton@gmail.com> - 2011-10-02 04:04 -0700
    Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Michael <michaelremerton@gmail.com> - 2011-10-02 04:15 -0700
      Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Michael <michaelremerton@gmail.com> - 2011-10-03 12:09 -0700
        Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Alex Macfarlane Smith <nospam@archifishal.co.uk> - 2011-10-03 20:44 +0100
          Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Michael <michaelremerton@gmail.com> - 2011-10-03 13:24 -0700
            Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-10-03 21:45 +0100
          Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-04 12:36 +0200
            Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-04 18:33 +0200
              Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-04 20:25 +0200
              Re: Sprite Loading / Plotting SWIs and lotting in any colour depth "Ste (news)" <steve@revi11.plus.com> - 2011-11-02 00:25 +0000
                Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 19:05 +0100
                  Re: Sprite Loading / Plotting SWIs and lotting in any colour depth druck <news@druck.freeuk.com> - 2011-11-02 21:21 +0000
        Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-10-03 21:41 +0100
          Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Michael <michaelremerton@gmail.com> - 2011-10-03 18:22 -0700
            Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-04 20:07 +0200
      Re: Sprite Loading / Plotting SWIs and lotting in any colour depth chrisbazley@bigfoot.com - 2011-10-06 21:03 -0700
        Re: Sprite Loading / Plotting SWIs and lotting in any colour depth Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-07 07:04 +0200

#824 — Sprite Loading / Plotting SWIs and lotting in any colour depth

Hi Guys,

Many years ago (when I initially started RiscDJ) I pleaded for help with the Sprite plotting routines.

Being on an SA RPC (and only having TFT screens of that resolution max) I designed the sprites for 32K colours witha  resolution of 1024*768)

Being on a beagle board means I can now get 16M colours at higher resolutions...Something I am sure we are all aware of.

Only thing was that all the sprites then looked wrong (half width / bad colours)


I assume it is in the plotting SWI This is what I currently have: 

SYS "OS_SpriteOp",512+34,SpriteBank%,Image%,X,Y,0,0,0

From what I understand from the StrongHelp Manuals, I should change R5 to 64 to produce Below?

[Action code when plotting sprites: 64 = Dither when plotting a 16 or 32bpp sprite into a reduced depth]

SYS "OS_SpriteOp",512+34,SpriteBank%,Image%,X,Y,64,0,0


However, in my test of plotting a 16M Colour sprite to a 32K colour screen made the sprites double in width with bad colour!


What am I missing?  All I can think of is either I have got the wrong end of the R5 register.

Cheers for any help

Michael

[toc] | [next] | [standalone]

#825

Looking at the code a bit more, I am defining the sprite area as:

!SpriteArea% = Size%
SpriteArea%!4 = 0
SpriteArea%!8 = 16
SpriteArea%!12 = 16

and then

SYS "OS_SpriteOP",256+10,SpriteArea%,SpriteFile$

Would I need to change the 16s to 32 as they are 32Bpp? :@D

[toc] | [prev] | [next] | [standalone]

#828

(Edit Snip)

>> How do I plot a sprite of 16M Colours in a lower screen colour depth? (256, 32K, 64K)


On Sunday, October 2, 2011 12:15:48 PM UTC+1, Michael wrote:
> Looking at the code a bit more, I am defining the sprite area as:
> 
> !SpriteArea% = Size%
> SpriteArea%!4 = 0
> SpriteArea%!8 = 16
> SpriteArea%!12 = 16
> 
> and then
> 
> SYS "OS_SpriteOP",256+10,SpriteArea%,SpriteFile$
> 
> Would I need to change the 16s to 32 as they are 32Bpp? :@D


For reference, this didn't work...


Any ideas?

[toc] | [prev] | [next] | [standalone]

#829

On 03/10/2011 20:09, Michael wrote:
> (Edit Snip)
>
>>> How do I plot a sprite of 16M Colours in a lower screen colour depth? (256, 32K, 64K)
>
>
> On Sunday, October 2, 2011 12:15:48 PM UTC+1, Michael wrote:
>> Looking at the code a bit more, I am defining the sprite area as:
>>
>> !SpriteArea% = Size%
>> SpriteArea%!4 = 0
>> SpriteArea%!8 = 16
>> SpriteArea%!12 = 16
>>
>> and then
>>
>> SYS "OS_SpriteOP",256+10,SpriteArea%,SpriteFile$
>>
>> Would I need to change the 16s to 32 as they are 32Bpp? :@D
>
>
> For reference, this didn't work...
>
>
> Any ideas?

I'm pretty sure OS_SpriteOp's only work on the modes of the sprites they 
were originally created in, so you can't (sensibly) plot a 32K colour 
sprite in a 16M colour mode. But I don't have access to any useful 
documentation at the moment to confirm that.

Alex.

[toc] | [prev] | [next] | [standalone]

#830

On Monday, October 3, 2011 8:44:16 PM UTC+1, Alex Macfarlane Smith wrote:
> On 03/10/2011 20:09, Michael wrote:
> > (Edit Snip)
> >
> >>> How do I plot a sprite of 16M Colours in a lower screen colour depth? (256, 32K, 64K)
> >
> >
> > Any ideas?
> 
> I'm pretty sure OS_SpriteOp's only work on the modes of the sprites they 
> were originally created in, so you can't (sensibly) plot a 32K colour 
> sprite in a 16M colour mode. But I don't have access to any useful 
> documentation at the moment to confirm that.
> 
> Alex.

Isn't that what this is for though?

[Action code when plotting sprites: 64 = Dither when plotting a 16 or 32bpp sprite into a reduced depth] 

Also how does the OS do it?

[toc] | [prev] | [next] | [standalone]

#832

The following bytes were arranged on 3 Oct 2011 by Michael :

> On Monday, October 3, 2011 8:44:16 PM UTC+1, Alex Macfarlane Smith wrote:
> > I'm pretty sure OS_SpriteOp's only work on the modes of the sprites they
> > were originally created in, so you can't (sensibly) plot a 32K colour
> > sprite in a 16M colour mode. But I don't have access to any useful
> > documentation at the moment to confirm that.
>
> Isn't that what this is for though?
>
> [Action code when plotting sprites: 64 = Dither when plotting a 16 or
> 32bpp sprite into a reduced depth]

Sigh.  No.  See my other post.  I quote from the manual page for the SWI
and reason code, OS_SpriteOp 34, you are using:

"Do not use if not in the same mode style (colours/resolution) as the
sprite."

I shall leave determining the correct reason code to use when the above
situation arises as an exercise for the reader.

-- 
  __<^>__
 / _   _ \  I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#834

In message <4e8a1091$0$290$14726298@news.sunsite.dk>
          Alex Macfarlane Smith <nospam@archifishal.co.uk> wrote:

> On 03/10/2011 20:09, Michael wrote:
>> (Edit Snip)
>>
>>>> How do I plot a sprite of 16M Colours in a lower screen colour depth?
>>>> (256, 32K, 64K)

> [...]
> I'm pretty sure OS_SpriteOp's only work on the modes of the sprites they
> were originally created in, so you can't (sensibly) plot a 32K colour
> sprite in a 16M colour mode. But I don't have access to any useful
> documentation at the moment to confirm that.

No, that is incorrect. The modern SpriteOp reason codes (most notably 
SpriteOp 56) work in all screen modes. There are some outdated 
SpriteOp reason codes that only work if you are in the same screen 
mode (e.g., SpriteOp 34, which Michael was using), but they are of 
little use in a desktop Wimp program.

Plotting a sprite to any screen mode requires using ColourTrans to 
generate a pixel translation table. SpriteOp reason codes that do not 
take a pixel translation table do not support plotting to arbitrary 
screen modes.

It is a mystery to me why there is no "plot this sprite to the screen" 
SWI call in RISC OS. There is one for Drawfiles, which are a hundred 
times more complex (and encompass sprites). So, ironically, the 
easiest way to plot a given sprite to any mode is to prepend a 
Drawfile header plus a Drawfile sprite object header and call 
"Drawfile_Render".

On Select systems, there is the ImageFileRender API, which is even 
easier to use, but means the program only runs on Select.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#835

On 04/10/2011 12:36, Martin Wuerthner wrote:

> It is a mystery to me why there is no "plot this sprite to the screen"
> SWI call in RISC OS.

Because I think little work was done to the SpriteOp since the days of 
Arthur.

But, that said, it isn't that hard to built a ColourTrans table and plot 
to screen.


> There is one for Drawfiles, which are a hundred times more complex

And a hundred times more difficult. Have you ever tried to render a 
DrawFile using the original API? [*]


Best wishes,

Rick.

* - given who I'm talking to, this is a rhetorical question ;-)

[toc] | [prev] | [next] | [standalone]

#838

In message <4e8b354b$0$30777$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 04/10/2011 12:36, Martin Wuerthner wrote:

>> It is a mystery to me why there is no "plot this sprite to the screen"
>> SWI call in RISC OS.

> Because I think little work was done to the SpriteOp since the days of
> Arthur.

I do not think that this is the case. SpriteOp has changed 
tremendously, even in much more recent times. You are probably right 
as far as the kernel SpriteOp calls go, but not the ones offered by 
SpriteExtend, which are the ones used for rendering nowadays.

>> There is one for Drawfiles, which are a hundred times more complex

> And a hundred times more difficult. Have you ever tried to render a
> DrawFile using the original API? [*]

Yes, of course, but that is exactly my point. So, it can hardly be 
argued that an equally simple sprite rendering SWI would have been too 
high level as an OS service or too much effort to add. In fact, this 
functionality is all present in the Drawfile module. It would have 
made sense to expose it as a SWI.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#980

In article <4e8b354b$0$30777$ba4acef3@reader.news.orange.fr>,
   Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> On 04/10/2011 12:36, Martin Wuerthner wrote:
> > It is a mystery to me why there is no "plot this sprite to the screen"
> > SWI call in RISC OS.

Seconded.

> But, that said, it isn't that hard to built a ColourTrans table and plot 
> to screen.

No, it is not that simple.

First of all, just getting your head around those concepts is hard initially.

Secondly, the documentation is spread over various parts of the PRMs. 

Thirdly, you will still get the wrong answer, because you've not created
your transformation matrix to cope with differing eigen values of different
screen modes. This is a whole extra can of worms.

So a true, mode-independent sprite plotting routine actually takes quite a
bit of crafting, testing and more than two SWI calls. And of course if
you're writing a Wimp application, you then need to be watching for mode
changes and re-calculating various things to cope with changes to the
characteristics of the mode. It all ends up quite complicated.

It can take _days_ (especially if you're fairly new to programming on RISC
OS) of reading all sorts of bits of the PRMs, head-scratching, trying to
comprehend arcane terminology and experimentation simply to plot a f*ing
sprite on the screen. Utter, utter madness.

Thanks,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]

#984

On 02/11/2011 01:25, Ste (news) wrote:

> It can take _days_ (especially if you're fairly new to programming on RISC
> OS) of reading all sorts of bits of the PRMs, head-scratching, trying to
> comprehend arcane terminology and experimentation simply to plot a f*ing
> sprite on the screen. Utter, utter madness.

I've just dug out my sprite plotter code (well, an old copy, I think I 
rewrote that mess). It's kinda icky and, yes, I remember now all the 
extra preliminary work. I probably even thought the same thing. ;-)

Perhaps this is something that *needs* addressing in SpriteExtend? Like, 
here's a sprite, draw it on-screen at this location. Nothing more, 
nothing less.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#987

On 2 Nov 2011 Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> Perhaps this is something that *needs* addressing in SpriteExtend? Like,
> here's a sprite, draw it on-screen at this location. Nothing more,
> nothing less.

You can always use a large sprint icon and let the Wimp do all the 
work for you.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page    - http://www.armclub.org.uk/32bit/

[toc] | [prev] | [next] | [standalone]

#831

The following bytes were arranged on 3 Oct 2011 by Michael :

> On Sunday, October 2, 2011 12:15:48 PM UTC+1, Michael wrote:
> >> How do I plot a sprite of 16M Colours in a lower screen colour depth? (256, 32K, 64K)
> > Looking at the code a bit more, I am defining the sprite area as:
> >
> > !SpriteArea% = Size%
> > SpriteArea%!4 = 0
> > SpriteArea%!8 = 16
> > SpriteArea%!12 = 16
> >
> > Would I need to change the 16s to 32 as they are 32Bpp? :@D
>
> For reference, this didn't work...

If you come across, as you do here, as if you have not so much as
glanced at the relevant documentation, let alone made an effort to seek
it out, it is no surprise that people are unwilling to help you.  csap
is a last resort.  Trivial API-related questions such as these can be
answered perfectly adequately by reading the OS StrongHelp manual.

See:

http://www.riscos.info/downloads/stronghelp/manuals/

The one you want is os334.zip.  You would also be well advised to pick
up several others while you are at it if you haven't already -
basic200.zip, assembly304.zip, filetypes.zip, starcmds5.zip, vdu203.zip
and wimp124.zip are some I have found particularly helpful.

StrongHelp itself may be downloaded from here:

http://www.stronged.iconbar.com/fjg/zips/strhlp.zip

ARMv7 (BeagleBoard/TouchBook/ARMini) compatible as of version 2.86, so
now there's no excuse!

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#833

Martin,

I will start off by stating that I have (sadly) VERY little time for RISC OS in 
my life... 

As I am sure alot of those whom use it can understand this.

As you seem to feel that my questions are fairly 'trivial', then I am surprised
that you have taken two posts to berate me as opposed to actually helping me?

So I think I will waste my time more by explaining why someone like me who needs
help, asks for it... even if they are trivial issues.


I start my day at 7am by waking my child, I get his breakfast, get him ready
 and take him to School, at 9:30am I enter work, usually at 9pm I leave, drive
 home, cook my food, do a bit of DIY, then sit down at around 11pm to tackle
 an issue I noticed 4-5 years ago, but didn't have the will to fix it.

Please note that on Weekends, I usually spend my time DIYing, going to 
weddings, or spending time with my Children.  Any attempt to code for RISC OS
 during this time is usually full of re-writing or re-formatting the code I 
 have just written after my Son has decided to re-arrange / re-write it.

So Usually my RISC OS coding occurs between the hours of 11pm and 3am.  
So please forgive my in-aptitude in being unable to read a screen at this 
time clearly.
 
I also, have only been using SWIs since starting RiscDJ.  Yes I do have a 
PRM CD somewhere, but I do think that my Son has put it in one of his books... 
I simply do not have the time to hunt.

> If you come across, as you do here, as if you have not so much as
> glanced at the relevant documentation, let alone made an effort to seek
> it out, it is no surprise that people are unwilling to help you.  csap
> is a last resort.  Trivial API-related questions such as these can be
> answered perfectly adequately by reading the OS StrongHelp manual.


with all the best will in the world, the StrongHelp manuals are no where 
near as clear as say PHP's manuals.  In fact some were plainly incorrect 
(but as having noticed that others have raised the issues, I feel I do 
not need to bug the developers.)

I do notice that thoughout the manual the data changes between 
Bits, Hex, and Decimal, and without a heading (especially under 
OS_SpriteOp Reason Codes) I spent the first night on this trying to sus 
out why setting bit 10 didn't work!

For instance, as you have so plainly put it above "Do not use if not in
the same mode style(colours/resolution) as the sprite."

Usually somewhere there ought to be a "Use this one instead:"?

If there is an option which states "64 Dither when plotting a 16 or 32bpp
sprite into a reduced depth (3.60+)", was I really that wrong in ASSUMING
that this means it will dither (Dither is an intentionally applied form
of noise used to randomize quantization error, preventing large-scale 
patterns such as "banding" in images. Wikipedia) the colours to make them
appear in lower colour depth modes?


If you feel that someone else on here, whom gave me a pointer into the 
direction of OS_SpriteOp 34, was also incorrect, then may I enquire what 
Reason Code it is which I require? (for "Put sprite at user coords" 
is obviously incorrect)

I do assume 28 "Put sprite to screen" is also wrong?  But OTOH it doesn't
seem to mention that it cannot plot 32BPP in 8Bpp modes?

> 
> See:
> 
> http://www.riscos.info/downloads/stronghelp/manuals/
> 
> The one you want is os334.zip.  You would also be well advised to pick
> up several others while you are at it if you haven't already -
> basic200.zip, assembly304.zip, filetypes.zip, starcmds5.zip, vdu203.zip
> and wimp124.zip are some I have found particularly helpful.
> 
> StrongHelp itself may be downloaded from here:
> 
> http://www.stronged.iconbar.com/fjg/zips/strhlp.zip
> 

For reference, I have in-fact got all of those, but I feel that you maybe
out with your BASIC manual which is up to 300!

I do apologies if I seem somewhat upset by your lacking response, but I 
live in the real world, where my daily job is switching between 
VisualBasicScript, JavaScript, PHP, HTML, and CSS.

In these worlds a simple google will suffice in correcting my inaptitude 
towards these languages.


> ARMv7 (BeagleBoard/TouchBook/ARMini) compatible as of version 2.86, so
> now there's no excuse!

Lastly I feel that the "now there's no excuse" comment a little bit of 
proof, as to why a few people I know of, left the RISC OS scene.

I have been using an SA RiscPC for many years (2000 +), I have hated 
this fact since the Iyonix appeared as I hate it when people do not 
support new technology, but being a College then Uni Student, the funds 
simply were not there.

My Brother (one of those whom left the platform) brought me my 
BeagleBoard for helping him. (Cheers bro!)

It took me around a week of fiddling with the thing before RISC OS 
popped up (Ubuntu was around 1 day).  (Please remember my 'days' are 
constrained to post 11pm)

Since then, it has been rather hit & miss on software working on it.

!Zap does fail every so often... StrongEd creashed EVERY time I opened 
a BASIC file!
ect ect.

I cannot remember exactly what failed, but I now use very little of 
what my RiscPC could access, even with an SA!

I feel it is my duty to get my application working under 
RISC OS 5 / BB as I would like to leave a little of something behind 
for the OS, especially when I keep being asked by everyone else 
"Why don't you just port it to Windows?"  Something I did look into 
using a language which enabled me to debug without putting hooks in 
or using other add-ons.

Usually I can pop on here, have a quick look, ask the development 
stumping question, and realise how it works / my in-aptitude and 
whack though another chunk of the code.

Ah, I now see that it is 02:17!  About time to go to bed before I 
have to get up at 07:00.

Another 'day' lost to looking at the sprite plotting!  

I was hoping to have a stable enough version for the London RISC OS Show.

So, I will now paste this back into Google, and head to bed!

[Rant Over]

Thankyou to anyone who is generous enough to help my with my issues!

Michael

[toc] | [prev] | [next] | [standalone]

#837

On 04/10/2011 03:22, Michael wrote:

> So I think I will waste my time more by explaining why someone like me who needs
> help, asks for it... even if they are trivial issues.

This, unfortunately, is the nature of the internet. Replying something 
like "try SpriteOp 1234" is so much more difficult than a three 
paragraph flame, to be justified by RTFM or RTFFAQ...


> Any attempt to code for RISC OS during this time is usually full of
> re-writing or re-formatting the code I have just written after my Son
> has decided to re-arrange / re-write it.

How old is your son? You really ought to get him to either fork his own 
version, or stop screwing around with yours. What's to say an accidental 
keypress wouldn't alter a pointer (ie block!%1234 -> block%!123) leading 
to potential hours of frustration at a later time?

Or, at least, drop a copy onto a floppy or somewhere and keep it away 
from your son.


> So Usually my RISC OS coding occurs between the hours of 11pm and 3am.
> So please forgive my in-aptitude in being unable to read a screen at this
> time clearly.

In which case might I suggest you look to rearranging to find a time 
when coding is better? You'll not get far if staring at the screen 
bleary-eyed. Especially if you begin your session by undoing potential 
damage to your code.


> Yes I do have a PRM CD somewhere, but I do think that my Son has put
> it in one of his books... I simply do not have the time to hunt.

You son sounds a menace!

Try: http://foundation.riscos.com/Private/manuals/


> with all the best will in the world, the StrongHelp manuals
> are no where near as clear as say PHP's manuals.

Compare the efforts behind php.org (or is it .net?) and the StrongHelp 
manuals.


> In fact some were plainly incorrect

And some PHP docs are less than correct. It pays to read the commentary 
to note that <x> does not work with <y> without doing <z>.


> I do notice that thoughout the manual the data changes between
> Bits, Hex, and Decimal, and without a heading (especially under
> OS_SpriteOp Reason Codes)

?

Random example:
   => R0 = 34, &22 (Put sprite at coords)
            ^ = ^
Likewise the list of them all does it side by side.


> Usually somewhere there ought to be a "Use this one instead:"?

You *are* aware that StrongHelp's PRM was in response to the price of 
the official PRMs? Now there are PDFs, no excuse...

[caveat: how about an RO5 update?!?]


> If there is an option which states "64 Dither when plotting a 16 or 32bpp
> sprite into a reduced depth (3.60+)", was I really that wrong in ASSUMING
> that this means it will dither

Specify *where* you saw this, I'm sorry, I don't have time to look for it.


> (Dither is an intentionally applied form of noise used to randomize
> quantization error, preventing large-scale patterns such as "banding" in
> images. Wikipedia)

Wiki is not entirely correct going by your quote - you need "error 
diffusion" dithering. A basic dither can lead to patterning depending 
upon the algorithm used.


> If you feel that someone else on here, whom gave me a pointer into the
> direction of OS_SpriteOp 34,

Try 34 HEX. ;-)


> I live in the real world, where my daily job is switching between
> VisualBasicScript, JavaScript, PHP, HTML, and CSS.

Err... to my mind none of that is *real* programming. <stir> <stir>


> Lastly I feel that the "now there's no excuse" comment a little bit of
> proof, as to why a few people I know of, left the RISC OS scene.

Not to mention the many areas where RISC OS is lacking. Take, for 
example, "social media" or something like playing a fansub animé (H.264 
MKV). Or how about a web browser with scripting? The world on The Dark 
Side is fighting over Flash or HTML5 for video playback, we on RISC OS 
get neither.

Now that Linux is easily available and easy to install, there is a good 
and viable alternative to The Big Bad.

Perhaps these are reasons why the market has been shrinking. Of course, 
unkind responses don't help those who are still around.


> as I hate it when people do not support new technology,

You mean the programmers? Most of my code is written with VB5. Which may 
or may not work on Windows7, and maybe not at all on Win8. I'd like a 
more up to date dev enviro, but have neither the money nor the hardware.

Likewise RISC OS. I can 'play' with RO5 on RPCemu. It'll be fun cutting 
some code on a real 32 bit machine. ;-) But before that, the only thing 
that would get me to buy an Iyonix (or Beagle) would be love - but love 
doesn't justify the outlay. I have my fingers crossed for the RaspberryPi...


> the funds simply were not there.

That's exactly it. It annoys the hell out of me when somebody answers 
with "just buy <x>", as if it never crossed their mind that if I could, 
I would have. <sigh>


> I cannot remember exactly what failed, but I now use very little of
> what my RiscPC could access, even with an SA!

A lot of older stuff might be affected by the change to 32 bit 
operation. Old RISC OS (even SA) worked in 26 bit mode. The Iyonix had 
the Aemulor software to make old stuff work. Is this technology a part 
of the open RISC OS 5? Or do we just have to suck-it-and-see?

Consider this like old and new generation RISC OS. Remember when Win32 
kernel (95, 98, ME) became NT kernel (XP) and suddenly all those old 
device drivers fell over and died? It's the same kinda deal here.


> "Why don't you just port it to Windows?"

;-) My stuff is so damned obscure I don't get asked that very often.


Still, I code for pleasure, not for cash, so I can pick'n'choose what I 
want to do.


> Something I did look into using a language which enabled me to debug
> without putting hooks in or using other add-ons.

C.

You can wrap all the debug code in #ifdef and either compile, or not. 
Plus you get the fun of using the Debugger.

Compared to other platforms, the dev tools for RISC OS are... lacking.


> Ah, I now see that it is 02:17!  About time to go to bed before I
> have to get up at 07:00.

It's 20:02. Got to get ready for work at 21:00, until 05:00. Then I'll 
come back and maybe watch some animé or one of my growing list of 
movies-to-watch, or the last two Dr Whos. Then I'll check my emails and 
stuff, read TheRegister, and hit the sack around 07:30.

Coding? I don't seem to be getting much of that done at all. Though this 
animé season seems pretty boring so maybe I'll have more time.


> [Rant Over]

:-)


If I may have a mini-rant of my own: slap your son into shape [*]. Get 
him to give you back the PRMs and leave your code the hell alone...


* - For added awesome, I have a replica (but metal) katana you could
     borrow. Why? Because:
       http://tvtropes.org/pmwiki/pmwiki.php/Main/KatanasAreJustBetter


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#858

On Oct 2, 12:15 pm, Michael <michaelremer...@gmail.com> wrote:
> Looking at the code a bit more, I am defining the sprite area as:
>
> !SpriteArea% = Size%
> SpriteArea%!4 = 0
> SpriteArea%!8 = 16
> SpriteArea%!12 = 16
>
> and then
>
> SYS "OS_SpriteOP",256+10,SpriteArea%,SpriteFile$
>
> Would I need to change the 16s to 32 as they are 32Bpp? :@D

This is the purest instance of http://catb.org/jargon/html/C/cargo-cult-programming.html
that I have ever seen. SWIs execute in a privileged mode (i.e. have
access to all of the memory map). The values that you blithely propose
changing are address offsets. SWIs are not toys.

If you want a programming language in which to hack carelessly then I
suggest one such as Java or Python that provides a secure execution
environment. Writing software in BBC BASIC that uses the !, ? or $
operators or the SYS keyword requires considerably more tIme and care.

You really need to read and understand the relevant chapter of the
Programmer's Reference Manual or you will shoot yourself in the foot
(and anyone unfortunate enough to use your software). The StrongHelp
manuals are notes for experienced programmers, not a tutorial.

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#859

On 07/10/2011 06:03, chrisbazley@bigfoot.com wrote:

>> SpriteArea%!8 = 16
>> SpriteArea%!12 = 16
[...]
>> Would I need to change the 16s to 32 as they are 32Bpp? :@D

> This is the purest instance of http://catb.org/jargon/html/C/cargo-cult-programming.html
> that I have ever seen.

I missed that one. Laughing my ass off here.


Michael - not sure what your smiley is supposed to mean (it isn't on 
http://www.cool-smileys.com/text-emoticons ) so I'm not sure if you're 
serious or taking the p....

If you really meant your question, please PLEASE *P*L*E*A*S*E* read up 
on what the sprite area is, how it is formatted, and what you're 
actually poking into !8 and !12.


> The values that you blithely propose changing are address offsets.

Although, granted, you CAN change them to 32 and it'll still work. 
Though IIRC (when I was playing around with poking extra data into 
sprites), !Paint didn't like it much [but this was RISC OS 2 days]


> SWIs are not toys.

Unless your idea of fun is assembling directly into another task's 
workspace in a live running application. Or is that just me? ;-)


Again, thank you for a big smile.


Best wishes,

Rick.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web