New Game Development

Briefly, because I’m quite conscious I’ve effectively hijacked Tony’s thread(!); you wrote:

“What goals did you have in mind for an enhanced BASIC? And would it still be BASIC after enhancement?”

A BASIC that facilitates better programming practice and easier maintainability; less conducive to buggy or brittle code (which BASIC V is a bit, IMHO), and so on. In the mid-to-late 80’s, Sophie Wilson added some useful bells and whistles to BBC BASIC which we all make use of today. Richard Russell added even more on top to his dialect which most BB4W users exploit because they’re genuinely useful, and they usually lead to better quality and easier-to-maintain programs. The ability to make arrays (not just byte/word arrays accessed through indirection), structures & structure arrays local or private within routines (PROCs/FNs), and the ‘address of’ operator which I make frequent use of, line continuation, 64-bit integers, byte variables, and the way its SYS statement provides a very simple and fast interface to assembly language routines (works differently to BASIC V’s), and several other enhancements, has added considerable power and flexibility to the language. I rather miss them when coding stuff in BASIC V!

Is BB4W still BASIC at the end of the day? I’d say it is. :)

In any case, I accept that the aforementioned enhancements will probably never come (natively) to BASIC V because there probably aren’t enough users out there that want them. It’s a bit late in the day now, isn’t it. After all, don’t most RISC OS programmers code in C nowadays?

David.
—

So on ARMv6+ BASIC could quite happily use unaligned loads/stores

You would need a separate BASIC module assembled for only these processors¹, otherwise you would have to introduce a processor check into every unaligned transfer, which would make a significant difference to the current routines. Or have I got this entirely wrong?
I hope so, because it seems like the logical thing to do.

¹ I realise that this is only a flag away in the source, but different modules for different machines is something so far largely avoided.

A BASIC that facilitates better programming practice and easier maintainability; less conducive to buggy or brittle code

Do you have any particular facilities that you would like to see in that regard?

If you want to tighten up the lax rules for things like IF and remove GOTO etc, you would almost certainly break a lot of existing code.

You are not alone in having a list of wants for BBC BASIC and I have been picking up ideas for many years:

The ability to make arrays (not just byte/word arrays accessed through indirection)

I am not sure what this means, because arrays are integral to BASIC.

the ‘address of’ operator

I have never seen the need for this, but I imagine that you are thinking of BB4W’s ^object. Basalt has PTR (object). Interestingly, when discussing this with Richard, he remarked that he might have prefered to use PTR himself, but had not spotted it.

structures & structure arrays

Mentioned previously.

local or private within routines

Basalt has something similar with LOCAL LIST. This also allows for variables to be local to libraries. Reproducing PRIVATE directly is not feasible the way Basalt works.

line continuation

Basalt has the ~ line continuation, but is is a bit of a cludge compared to / .

64-bit integers

I have had the code for this for a long time, but there has never been any demand for it. However, they would not as fast as normal integers, and require special syntax.

byte variables

That is too tricky, but structures can have byte variables.

SYS statement provides a very simple and fast interface to assembly language routines

Could you be more specific about the difference to CALL?

[BB4W] has added considerable power and flexibility to the language. I rather miss them when coding stuff in BASIC V!

Indeed, but the BB4W model does differ from ARM BASIC at deeper levels than the language itself.

Is BB4W still BASIC at the end of the day? I’d say it is. :)

It is, and it is BBC BASIC, because Richard holds the rights to that.

enhancements will probably never come (natively) to BASIC V

You are right, but why natively? Apart from one obscure facility of Basalt, I could change the run action for BASIC files and all programs would be translated and run with all its features. Only the most awkward and badly written would object. I am not sure this would be a ‘good thing’ though. ;-)

(I’m going to have a go at using quotes!…)

I am not sure what this means, because arrays are integral to BASIC.

I was totally wrong about BASIC V not being able to make arrays local. Oops!

Still learning. :)

I have never seen the need for this, but I imagine that you are thinking of BB4W’s ^object. bq

Yes, BB4W’s ^ (address of) operator. I have used it many times – usually to pass addresses of variables, arrays and/or structures (and structure arrays) to assembly language routines, e.g.:

DIM myStruct{(5) a%, b%, c%}, struct2{a%, b%, c%}
SYS codeAddr%, ^myStruct{(0)}.a%, ^myVar%

I’m aware that BASIC V, if using CALL with a list of parameters, will set up R9 with a pointer to the parameters’ l-values, and R10 with the number of parameters. BB4W’s CALL does something similar. I’ve really got to make more use of this functionality myself.

Basalt has something similar with LOCAL LIST. This also allows for variables to be local to libraries. Reproducing PRIVATE directly is not feasible the way Basalt works.

I’ve made fairly frequent use of private variables (but only very occasionally arrays & structs — I’m sure I have used them, though). I think the alternative was probably having to resort to globals, and I usually want as few of those as possible (even if my programs, admittedly, still tend to be replete with them!).

Basalt has the ~ line continuation, but is is a bit of a cludge compared to /

Yes, I know. I’ll probably be making use of it! There were times in the past few weeks when it would’ve come in rather handy.

Could you be more specific about the difference to CALL?

I don’t think you can pass constants as parameters to CALL like you can with BB4W’s SYS command (I’m quite prepared to see this assertion shot down in flames!):

SYS myCodeAddr%, var1%, ^var2%, ^struct{(0)}.a%, 0.125*&10000, 23, &FF8000

Very convenient. If it turns out that BASIC V’s CALL does support this, then I will have learned something else new today.

The other difference (although not usually an issue), is that with BB4W, SYS parameters are pushed onto the BASIC-created stack rather than loaded into registers. It’s especially convenient if you need to pass a lot of parameters (I think I have some graphics routines which take up to 10 or 11 parameters — some of which may be specified as numerical constants), but loading into registers is also very convenient under most circumstances, I think.

You are right, but why natively?

I don’t want to come across as making this sound like a bigger issue than it really is, but I think that robust, native support for the kind of relatively basic, extra functionality that’s been discussed over the years (and what I’ve been enjoying and taking for granted as a BB4W user), is more desirable than having your programs dependent on a third-party module (with all due respect). Over the years, I and others have posted quite a few program listings onto the BB4W Conforum and other places which people can simply copy & paste into the BB4W IDE and run, and which I know will work without any dependencies other than having the full version of BB4W installed on their system (which most BB4W users have). It’s really no biggie for me; I’ll certainly be using Basalt, and I can see myself becoming quite dependent on it as I get back into tinkering around with RISC OS & BASIC V.

David.
—

(I’m going to have a go at using quotes!…)

:-)

You don’t need

'bq. '

at the end of the quote the quote ends at the first blank line.

You can also put

'bc. '

before any code – it avoids textile mucking things up. If the code has a blank line in it use

'bc.. ' 

before the code and start your 1st non code paragraph after that with

'p. '

The quote marks are only there to show you need a space.

Thanks Colin, I figured it out within a minute-or-so of posting, and I promptly edited my post. It was a first attempt at using quotes on this particular forum. :)

David.
—

SYS codeAddr%, ^myStruct{(0)}.a%, ^myVar%

You would certainly have to use PTR to pass the address of a Basalt structure, as you do with a long string (called a strand), but it is not necessary for normal variables, as you note.

SYS myCodeAddr%, var1%, ^var2%, ^struct{(0)}.a%, 0.125*&10000, 23, &FF8000
Very convenient. If it turns out that BASIC V’s CALL does support this, then I will have learned something else new today.

No, BASIC does nothing like this and I have often thought it a shortcoming.

On a passing thought, if you have followed any of my ramblings, you will have noticed that in a translated Basalt program USR can return strings and floats as well as integers. I owe no-one (sic) the secret to this. In the source it looks to me as if this was probably intended to work in BASIC at one time. It also looks as if there might have been a method to pass parameters to USR in the way you can with CALL. Is there a demand to do these, because I do not think it would be difficult to implement?

people can simply copy & paste into the BB4W IDE and run, and which I know will work without any dependencies other than having the full version of BB4W installed on their system

This partly comes down to the lower level differences of BB4W. When you run/save a program from BB4W it is crunched and a runtime created appending all the parts of the BB4W interpreter required. This results in larger code, but it is independent of any shared resources, such as a BASIC module. This whole topic of dependencies and shared resources in ARM BASIC is a big one, but not to be expanded on here.

Update on Overlord:
-———————-
I’ve added a new adversery drone that shoots at your ship to the asteroid fields & energy bomb fields (to make those parts a little more fun) + added a 30 frame fading sprite for particles as the old particles that I had look a bit dated.

Various RMEnsures & other good practices tweaks made.

Now just need to add the health display for the Overlord & support for Risc OS 4 via AMplayer (i.e. the MP3 player will be switched between AMPlayer and AudioMPEG based on Risc OS version) and I should be able to send out RC2.

Tony

What is the reason to switch from AudioMPEG to AMPlayer on RO4?

Hi Steffen,
I had some feedback from Andrew Rawnsley of RComp that highlighted AMPlayer was a much better fit for Risc OS 4 under emulation. It was strongly recommended that I select AMPlayer on Risc OS 4. Currently I’m waiting for my Virtual Acorn activation code so that I can test the game on Risc OS 4 to check AMPlayer is selected and Overlord runs correctly.

Best Regards,

Tony

Tony, I’ve just downloaded the AMPlayer module, although currently I’ve no time to experiment. Are you able to say at this point what kind of performance hit (if any) one might expect in a game loop with a moderate bitrate MP3 playing in the background? Have you noticed any drop in frame rate with your game, for example? I strongly suspect that the vast majority of x86-based MP3 players are coded (at least for the computationally expensive parts) with SIMD instructions – at least MMX. Decoding MP3s in real-time is probably quite a lot of work for a SIMD-less ARM processor to do!

David.
—

Hi Anthony, interesting – never heard of that. I am fairly sure that neither AMPlayer nor AudioMPEG use any floating point – VRPC floating point performance is the only thing I could imagine to make a difference.

On the other hand, I dimly remember a special version of AMPlayer that used the host system to decode the MP3 data. A clever bit of software by Ian Jeffray IIRC. But googling only turned up VirtualAmp http://ian.jeffray.co.uk/riscos/virtualamp/ which is something completely different, so maybe I am misremembering.

Hi David,
Frame rate was affected by three factors:
1) A slow SD/micro SD card where the read of the stream caused a pause. Faster cards presented no problem, however in AudioMPEG (AMPlayer is not compatible with Cortex processors unless exception alignment is turned off) I Improved this by increasing the read buffer size.

2) In Audio MPEG (possibly not AMPlayer, I will have to check) the initial load of the MP3 caused a temporary reduction in frame rate for a second or two.

3) If the rendering of the frame + any other background processing caused more processing than fits within 1/60th of a second the vertical blank would be missed resulting in stutter while the next vertical blank is waited for.
=> Total cost of rendering frame = the cost of rendering graphics + other logic + the cost of MP3 deoding.
=> If I turn off MP3 audio then on the slower Raspberry PI 1, I notice an improvement in performance on later missions if there are a lot of objects on screen.
==> I improved this in general by reducing the number of stars and particles on screen & by using 256 colour graphics – because the scaling and rotate operations result in ~4x increase in blitting cost.
==> Further, reducing the size of the erase objects I track in my frame buffer improved
performance.
==> I’m also using 128K bitrate MP3s,

Would you like me to the MP3 load basic routines for AudioMPEG/Digital CD ? Actually, there was a pretty good example in the Digital CD package.

Playing the audio in AMPlayer was easier as the management of the stream was more automatic. So using AMPlayer requires no signficant examples of API call as its more or less a single call to play an MP3.

Steffen – I believe it might be that AudioMPEG is not optimised well for legacy ARM architectures as it appears to be targeted to Cortex processors. I’ve looked over the AMPlayer source code (which is availble on riscos.info) but have not profiled it. Given that AMPlayer was developed for slower clock speeds, it could be that it runs more efficiently. However, I’ve no good evidence/specific reason to support this. I am prepared to take Andrew’s recommendation on faith as he has much more experience of RISC OS than I and a much wider range of hardware.

Best Regards,
Tony

Regarding MP3 processing, I think its suprisingly low cost. I sometimes use AMPlayer for playing MP3s in the background while developing and it barely shows up on CPU with no apparent impact on running applications. MP3 is a pretty old spec and ran on 20-30 year old hardware + various cheap Mp3 players (I have an old 10 pound one from Tesco somewhere).
Basically MP3 uses a DCT / FFT:
http://www.soundonsound.com/sos/may00/articles/mp3.htm
http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform

One of my hobbies is DSP. Reading over the notes, I can see how MP3 could be implemented using some relatively lower cost operations.

At some point soon, I hope to get back to finish a new software synthesiser module for RISC OS which has my own low pass filter implemented using fixed point for speed.

This is because I felt a more modern better/more consistant SOUND command (with sample playback) would be generally useful.

I am fairly sure that AudioMPEG has not changed that much (and I am happy to be corrected by Andre if I am talking bullshit here) since Peter Teichmann’s original version, which was optimized for the StrongARM.

Fair enough. I wonder if AMPlayer has a lower footprint then?

I won’t speculate further. I will perform some testing once I have Virtual Acorn to see if I can see any evidence of a difference in behaviour.

If I have got this right – there are three modules of AMPlayer – 26bit 26/32bit and AMPlayerFP (Floating Point for A7000+).

Was there was a extra FPE module for the emulator that used the x86 hardware FP?

What sort of errors does AMPlayer give – when used with the latest Hardware?

Ah. AMPlayerFP. How did I miss that one? Since VRPC IIRC emulates an FPU, it might well be faster and more efficient to emulate.

Tony, given that these days there is so much memory available (usually at least 512MB on the RPi for example), that a solution involving the decompressing of an entire MP3 to memory and simply playing it back without the overheads of background loading & decompression is now quite desirable and feasible, is it not? A decompressed, 5 minute stereo audio track resampled from 44.1KHz to, say, 16KHz would probably still sound pretty good, and would take up about 19MB of RAM (assuming 16-bit samples), which is hardly an issue these days. (Or if resampled to 22.05KHz then approx. 26MB.)

Would you like me to [send you] the MP3 load basic routines for AudioMPEG/Digital CD ? Actually, there was a pretty good example in the Digital CD package.

Ah that’s ok for the moment, Tony, cheers. I’ll take a good look at the docs when time permits.

Thanks for the information re. AMPlayer and AudioMPEG.

David.
—

http://www.proggies.uk
http://www.youtube.com/channel/UC1E2sxhlc9h9C82q6RFvAWQ

Hi David,

Your suggestion gave me a thought I was thinking that the MP3s could be copied to a Ram Disk. Looking over the PRMs, it seems that resizing the RamFS is easy to do. Then there would be no latency on playback and the files would be in memory.

At 16khz, playback would be similar to a PAL TV signal or audio cassette. There might be some noticable aliasing in the upper audiable spectrum unless a basic IIR filter were used (which is quite cheap). However, as you say, MP3 decoding would be avoided, so it might be a good tradeoff if the game couldn’t afford the overhead.

Tony

Just uploading release candidate 2:

> I have added a new ship that shoots at you during the asteroid and energy bomb stages.
> I’ve added an overlord health display
> Also the particles now look much better than they did as I now use an animated sprite for each particle.
> I fixed some important bugs including initialising the sprite area properly (caused occasional failures before due to UMR) & using RMEnsures etc in the Obey files.
> I’ve made some performance improvements.
> I’ve changed the instruction’s colour as it was too dark
> An exit button has been added.

In addition:
===
I now have a Risc OS 4 version too which I have run on Virtual Acorn (RISC OS 4.02).

I had to fork the code for Risc OS 4 support as it required double buffering (not triple) & AMPlayer rather than AudioMPEG & the OS calls were in a more traditional order.

I think Release Candidate 2 would be good to go.

However – I am added a few visual improvements & more power ups in any case. I think the game needs as many ways as I can fit in to zap things…

So there will be a release candidate 3. Then that’s it..

Your suggestion gave me a thought I was thinking that the MP3s could be copied to a Ram Disk. Looking over the PRMs, it seems that resizing the RamFS is easy to do. Then there would be no latency on playback and the files would be in memory.

Keep in mind that RamFS can only be resized if it is completely empty.

So I would suggest just decoding into app memory (RO5) or a DA (RO4).

Hi Steffen,
Thanks for the comment. I will look at this again for future work, but am not planning to alter MP3 decoding in Overlord.
Tony

Just added power-ups including : Warp to accelerate forward in the game (3x normal speed for 3.3 seconds), Smart bombs to destroy all objects on screen, rapid fire for 30 seconds and additional shield energy power-ups.

Now entering regression testing again…