Cheers,

Max

You'd improve performance if the plotted object has had some precalculation done though (such as its own multipliers) - the data size may increase though.

I can think of a way of doing it in 8-bit where each plotted object has its own 64K lookup table, and you just cross-reference each colour. This assumes that it's a flat alpha (ie. you don't have 'patches' of high alpha, and others of low alpha). However, for 16-bit, the table gets a wee bit large

I don't know if having a hashed table of previously calculated blends would help (ie. create a hash of the source, plot and alpha values), but it might - it depends on how variable the images are.

Anyway, I'm sure some people have attempted this, and will probably have better ideas than me - I'm just giving some possible avenues for exploration.

I guess it would be interesting to hear from anyone that's done some PNG plotting routines. Also Rob Davidson of Compo fame may have some tips ... not sure whether he ever hangs around here or not though.

On a related note, has anyone actually tried to develop a game for both Windows and RISC OS at the same time?

PS Since no one has noticed this yet, people may be interested to hear that TEK is due to be released as a budget PC title soon (in German only). See www.comport-interactive.com ...

I assume that since this is in a games forum you want to use the techniques for a game. Thus speed will be important.

Proper alpha blending ie multiplying source and dest colours by a values prior to adding is pretty expensive to do. If you are mainly doing one type of blending it becomes possible to optimize for that - but not necessarily simple, just depends on the blend factors involved.

A better approach IMHO without having hardware support is to use special case blending. In other words additive, 50/50 & subtractive.

Additive is the most commonly used for fx in games and it is simple... just add together the src & dst colours (obviously separated out into colour components) and clamp the values at white.

With 50/50 you add them together and divide by 2 - no clamping required.

With subtractive you subtract the src from dst and clamp at 0 (IIRC).

OK these won't give you fine control, but the PSX managed :-) The main problem you will find with any sort of blending under RISC OS is that you are reading back from the frame buffer and this is horribly slow on the Iyonix. Best bet is to use an offscreen buffer and copy that the the screen when finished. FYI Descent 1 & 2 ports use additive transparency for exposions and such (if the option is on).

In terms of developing a game for Windows & RISC OS the problems would be that you have to do all the gfx engine on RISC OS where on Windows all the grunt work is done for you. Also the lure of floating point math can be very great - especially if you are developing a 3d game. Not that I have done this, but working on console games day in day out and then coming home to a RISC OS box does highlight deficiencies in it.

Hope that helps.

On a related note, has anyone actually tried to develop a game for both Windows and RISC OS at the same time?

ArcCommand was initially developed as a RISC OS game, but over an extended period in the states, it was ported to SDL, so there was a RISC OS, Windows and Linux version available. Note that the RISC OS SDL wasn't available at the time (and due to the way that I generate/use sprites, I probably won't use it anyway). Equinox is supposed to be developed on all three as well, but I've been concentrating on RISC OS.

I'd second David's suggestion of simplifying the alpha process to mix and subtract. I'm not sure if you'd need to separate the RGB values in order to do either - I'd need to do some binary maths in order to see if you would - I'll spend a few minutes on it...

Out of interest, what development environment do you tend to use? Is it GCC or the Castle version of Acorn C? (or something else).

One of the advantages with developing on the PC would be the ability to use a decent deb****r - the downside would be that there is a lot of power available and it would be easy to make something that a RISC OS based machine just couldn't cope with, even with heavily optimised ARM code. Also I'm not sure how generic a game engine could be...

To be honest, I hadn't even considered using the different plotting modes suggested by David - I had wanted to use full alpha blending (i.e. 8bit variable masks) - but this is going to soak up so much more processor time than simple masked plotting or fixed alpha plotting. It seem from your comments that most people wouldn't even consider using variable alpha blending for a RISC OS based game.

Finally, Jason, what is Equinox? Is there any information about / are you at a point where you can comment?

Out of interest, what development environment do you tend to use? Is it GCC or the Castle version of Acorn C? (or something else).

It depends what I'm doing. For most things these days I use GCC - mainly coz I prefer C++, although Acorn C gets used for some stuff.

One of the advantages with developing on the PC would be the ability to use a decent deb****r - the downside would be that there is a lot of power available and it would be easy to make something that a RISC OS based machine just couldn't cope with, even with heavily optimised ARM code. Also I'm not sure how generic a game engine could be...

The best thing about XBox development is that use the standard dev studio deb****r. Once you've used one it's very hard to go back.

As for writing a generic game engine it really does depend on the type of game (if we weren't talking about RISC OS then you can make any engine generic). As evertyone knows on RISC OS we lack a usable 3d library - ideally using hardware - and this really means that dealing with 3d means reinventing the wheel. Generally coz you have to special case stuff to make it fast enough on most hardware.

To be honest, I hadn't even considered using the different plotting modes suggested by David - I had wanted to use full alpha blending (i.e. 8bit variable masks) - but this is going to soak up so much more processor time than simple masked plotting or fixed alpha plotting. It seem from your comments that most people wouldn't even consider using variable alpha blending for a RISC OS based game.

It is possible to do full alpha blending, but it depends how much of the screen is going to be affected by it. IIRC the 3d engine that Robin Watts & Martin Piper were working on did proper alpha. However I would strongly suggest working out what you want to use it for and seeing if any of the special cases can be used - you can of course have more variety of special cases. Also consider what the base machine will be - or if the fx will be toggleable.

Jason - there are various other tricks around. However some of them don't lead to the same result.

One of the advantages with developing on the PC would be the ability to use a decent deb****r - the downside would be that there is a lot of power available and it would be easy to make something that a RISC OS based machine just couldn't cope with, even with heavily optimised ARM code.

You could always do your development on an older machine (say 200mhz)

Also, Spheres of Chaos ( http://www.chaotica.u-net.com/ ) is available for RISC OS, Windows and Linux.

Cheers!

Thanks Jason and David. Your comments are really helpful.

That's okay - it's actually nice to have a decent discussion about something for a change!

Out of interest, what development environment do you tend to use? Is it GCC or the Castle version of Acorn C? (or something else).

For ArcCommand and RISC OS, it was the 26-bit Acorn C compiler (ie. not the Castle one), but with DRLink instead of Acorn's link. For the Linux version, it was GCC. For Windows, it was Visual Studio 6 (because I had that in the office!)

One of the advantages with developing on the PC would be the ability to use a decent deb****r - the downside would be that there is a lot of power available and it would be easy to make something that a RISC OS based machine just couldn't cope with, even with heavily optimised ARM code. Also I'm not sure how generic a game engine could be...

I developed ArcCommand under RISC OS, and then ported it to Linux. Because I wasn't using hardware plotting, and I wanted to keep the data in the original (RISC OS) format, I basically rewrote the ARM plot code into C, and that effectively had to plot pixel by pixel (although it used memcpy() from time to time). This meant that a 400MHz Linux box runs about the same speed as a 40MHz RISC OS box for my game. If I'd used hardware plotting, then it'd be pretty rapid.

When building pretty much everything I do these days (be it games, applications or drivers), I build a debug and a release build at the same time, with appropriate !Run files for each. For games, the debug build doesn't do bank swapping, as I can use !DDT. Because a lot of the debugging had occurred before the Linux build (yet alone the Windows build), gdb wasn't used much. The port to Windows took an afternoon, and the only tweaks were for the music and the filenames (ie. directory name conversions).

It seem from your comments that most people wouldn't even consider using variable alpha blending for a RISC OS based game.

Even static alpha blending sends shivers down me spine :-)

Finally, Jason, what is Equinox? Is there any information about / are you at a point where you can comment?

Equinox was a game I wrote in 1992, but abandoned due to a very bad bug that I wasn't able to solve. It was my first attempt at a Starship Command style game. ArcCommand was done quite a bit later, but was withdrawn because the copyright holder thought it was too close. The new Equinox is based on the ideas of the first, but using coding techniques from the latter (I've learnt a lot since then). Currently, there are only screenshots available, and also I'm in no rush to finish it (although I'd like to do it by next March). It's in 8-bit mode, because you can still do a lot with dithering.

http://www.tribbeck.com/equinox/

[Edited by tribbles at 22:16, 19/8/2003]

http://www.acornusers.org/ans/archive/issue.php?p=1&issue=111

(Look for FANLib v0.02, about halfway down)

It was by the author of Wizards Apprentice. His group was Fantasia Fan, apparently.

I guess the author has left the scene, the link doesn't go anywhere. But you might be lucky - I may still have it stored on my hard drive.
I downloaded it and ran the demo, basically it would plot sprites with various effects at 32bpp and was quite fast and looked very good. The alpha layer was 8 bits, and you could also specify a further global transparency.

To my shame I never looked in to it any more than that.

You may be able to contact the author. I think I have his address somewhere if you want it.

Certainly, plotting sprites with intermediate transparencies is best-case to best-case (ie if both are well-optimised) slower than otherwise. But this may not be a big problem. It depends on what you want to do with it..

Jason, I like the look of your game, and look forward to it.

Also, Spheres of Chaos ( http://www.chaotica.u-net.com/ ) is available for RISC OS, Windows and Linux.

Cheers!

Spheres of Chaos is a superb game, with excellent, but simple effects. The sound effects are some of the best I've come across too. Inspiring stuff!

I remembered something about a (sprite) alpha-blending library. After a bit of googling I found this:

http://www.acornusers.org/ans/archive/issue.php?p=1&issue=111

(Look for FANLib v0.02, about halfway down)

It was by the author of Wizards Apprentice. His group was Fantasia Fan, apparently.

I guess the author has left the scene, the link doesn't go anywhere. But you might be lucky - I may still have it stored on my hard drive.

I remember the author posting on c.s.a.games a while ago, I guess he must have left the scene now. At the time I remember asking whether FanLib is usable from C, but I think he said that it wasn't (it's all a bit vague). I would still be interested in getting hold of a copy of the demo though - it would give me an idea of what might be possible.

Once again thanks for your input. It's interesting to see the different types of approach people take on various platforms. I'm mainly used to using Visual Studio (for VC++ / VB) since it's what I use in my day job. Although a few years ago I did code a basic game engine on my Risc PC, which was a mixture of C and ARM code.

As I've said, the deb****r on the PC is a big help and makes it frustrating to go back to the Risc PC. I also used to use (shock horror) EasyC, which wasn't exactly fast but did the job. If I were to do coding on the Risc PC again, I think I'd be forced to use gcc (I couldn't justify buying Castle's C compiler), besides I prefer C++ to C. However, once again, the lack of a decent, integrated development environment would be a pain.

Still, a lot of us are still drawn to coding for RISC OS! I guess it gives us a chance to write optimised code. Also, as some of you might be aware from my work on TEK's graphics, I have an artistic side which would like to combine with my software skills for once! There are also some excellent graphics apps out there which would be nice to put to use with a worthwhile cause in mind ... (hence the alpha plotting question).

I guess the author has left the scene, the link doesn't go anywhere. But you might be lucky - I may still have it stored on my hard drive.

I remember the author posting on c.s.a.games a while ago, I guess he must have left the scene now. At the time I remember asking whether FanLib is usable from C, but I think he said that it wasn't (it's all a bit vague). I would still be interested in getting hold of a copy of the demo though - it would give me an idea of what might be possible.

I don't know what you need to do to interface with C so I can't comment on that. I think they are meant to be accessable from Basic.

On my HD I found I have 3 zips, totalling around 150k. They are the library (binaries), the demo and another arc of supporter progs which can convert sprites to RGBalpha &vv.
The demo draws 7 fairly large (identical) sprites on a background at 18fps with 256 level blending and fading too. Looks very good. I didn't think to look as to whether the sprite would fit in the cache (ie is <16kb) but I'd guess not.
You can change the plotting effect to several different types. Plotting with 'block copy' (ie no mask) gave 24fps IIRC.
Oh, and at least one of the sprites is screen-clipped, so it seems to be a fully functional plotter.

If you can contact Bill K. he might let you have the sources; he says he'll send them to people on request but not to distribute them. (The binaries are freely distributable as a unit.)

[Edited by loris at 11:00, 21/8/2003]

I don't know what you need to do to interface with C so I can't comment on that. I think they are meant to be accessable from Basic.

It would be possible to write a veneer between C and the BASIC routines - the veneer would save the APCS state, set up entry registers, call the routines, and restore the APCS state.

For example, if you used R0 to R6 on entry, then you could do it in one of two ways - either the C function passes a pointer to the registers, or you pass in each function. For example:

For the first:
void myFunction(int* regs);

For the second:
void myFunction(int r0, int r1, int r2, int r3, int r4, int r5, int r6);

Now, the first veneer is probably simpler [in ObjAsM format]:

 EXPORT myFunction
myFunction
 STMFD r13!, {r0, r4 - r11, lr}
 LDMIA r0, {r0 - r6}
 IMPORT myBasicFunction
 BL myBasicFunction
 LDMFD r13!, {r12}
 STMIA r12, {r0 - r6}
 MOV r0, r12
 LDMFD r13!, {r4 - r11, pc}^

[Note this is 26-bit APCS]

This is a minimal APCS, and DDT won't allow you to follow the code too well if you have problems in it. It stores all the registers back into the array provided. If you don't want this, then the code is a lot simpler:

 EXPORT myFunction
myFunction
 STMFD r13!, {r4 - r11, lr}
 LDMIA r0, {r0 - r6}
 IMPORT myBasicFunction
 BL myBasicFunction
 LDMFD r13!, {r4 - r11, pc}^

For the second case, the code is conceptually a little more complicated (since arguments 4 to 6 are on the stack), but in reality isn't:

 EXPORT myFunction
myFunction
 MOV r12, r13
 STMFD r13!, {r4 - r11, lr}
 LDMIA r12, {r4 - r6}
 IMPORT myBasicFunction
 BL myBasicFunction
 LDMFD r13!, {r5 - r11, pc}^

This version doesn't restore the register values, but the return value is kept in r0.

Basically, to make your code callable from C, you need to ensure that r4 to r11 and lr are restored, and for 26-bit, the processor flags need to be restored too. If you want to make it deburgerable, then you need to keep frame pointers up to date, and it's best to look at some code that C has produced.

Purists are probably going to complain that I haven't explained APCS correctly, nor used it correctly; I've just put something that is compatible to the extent that it can be called from APCS code (the difference being that between compatible and compliant).

As I've said, the deb****r on the PC is a big help and makes it frustrating to go back to the Risc PC. I also used to use (shock horror) EasyC, which wasn't exactly fast but did the job. If I were to do coding on the Risc PC again, I think I'd be forced to use gcc (I couldn't justify buying Castle's C compiler), besides I prefer C++ to C.

I'd say two things about this:

1) If you're going to use gnu, then cross-compile from *BSD or Linux. It's a *****lot***** faster - I've been developing a C++ WIMP library, and it takes 60 seconds to compile the code under RISC OS, and under FreeBSD it's nearer 2 seconds. (That was an older release of gcc, though).

2) I wouldn't use C++ for games for two reasons:

a) If you want to call C++ functions from assembler, then you've got to worry about C++ name munging (which may be in gcc's assembler; not used it)

b) C++ tends to cause a bit of code bloat, and every cycle is important (well, I think it is). This is especially true if you don't use C++ as a C with classes (ie. you use templates and so forth).

Do you know if there are any good sources of documentation for getting to grips with gcc and cross compiling?

unfortunately not - I'd used gcc for a long time before I did any cross-compilation. And even then, I followed the instructions from where I downloaded it from (http://hard-mofo.dsvr.net/gcc/).

You will need a convenient way of transferring from Linux to RISC OS machines; I use LanMan98 and Samba, but you should be able to get Linux to mount a RISC OS Samba partition (alhough I've never tried it).

... I would still be interested in getting hold of a copy of the demo though - it would give me an idea of what might be possible.

I have just this moment emailed them (3 archives totalling ~150kb) to the address in your profile, Max.
If anyone else wants them please let me know. (As I mentioned, they are freely distributable.)

The demo makes it look to me like it would be perfectly possible, with care, to use a fair amount of alpha-blending at a reasonable frame-rate.
For what it is worth, I suspect that it would be possible to squeeze a little more juice out of the machine with some cunning optimisation. I haven't looked at the source or disassembled the code, but I seem to remember an email conversation I had with Bill about it.

Thanks for sending the files. Unfortunately, I'm having trouble downloading the attachments from my ISP. In addition, my email address is about to expire so I'm going to have to get a new one. As and when I do, would it be possible to resend the files?

Regards,

Max

It has been a while since I did anything with it, but would you be interested (and have time to make) some graphics for it? It is a fairly small project but the specifications are quite finicky (as is usual with my stuff). We're not talking plain bit-maps. Also I want them to be well drawn, which I don't think is a problem for you (it is for me!)

Actually Max, this makes me think about something slightly related.
I once wrote a program which... well, I don't want to say what it did, but it did funky processing for every pixel on the screen. Admittedly at very low resolution.

It has been a while since I did anything with it, but would you be interested (and have time to make) some graphics for it? It is a fairly small project but the specifications are quite finicky (as is usual with my stuff). We're not talking plain bit-maps. Also I want them to be well drawn, which I don't think is a problem for you (it is for me!)

Hi Tony,

What kind of bitmap images are we talking about? There are some things I can create reasonably well, but I'm not actually very good at certain types of 2D stuff or 'organic' 3D stuff. Still I have a fair amount of graphics software that gets me out of holes every now and again!

If you can let me know (perhaps by email) what your requirements are then I'd be better placed to judge:

(a) Whether I think I would be able to create what you want.
(b) How long it would take.

Sounds interesting anyway ...

Regards,

Max