anthonybartram wrote:I'll check out that micro SD card.
I suspect you'll probably want a Class 6 or 10. (I believe there were compatibility issues with Class 10's, but I think that's been resolved now - although best to check/Google it beforehand.)
anthonybartram wrote:In future projects I've been thinking about including a crunched version. But the time spent QAing and betaing the uncrunched code was a bit high for me to take the risk of distributing a crunched version post beta ( it was not something on radar initially...). Also debugging field issues scares me a bit.
Yes, quite understand. The only
reason I crunch my programs (invariably with StrongBS) is because of the sometimes quite significant increase in performance. It can sometimes make the difference between an animation running at 30 fps or 60 fps. How I wish StrongBS was updated and bug-fixed - otherwise it'd be a fine tool. (Incidentally, one minor optimisation that StrongBS doesn't perform is converting hexadecimal constants to their decimal equivalents; ARM BBC BASIC seems to process the latter faster, in contrast to BBC BASIC for Windows which usually processes hex constants faster.)
I found there was visible jitter on the Raspberry Pi 1 when simply blanking the screen and performance dropped below 60hz.
I'm a bit surprised about the RPi 1; I thought (or read somewhere) that it was only about 20% slower than the RPi 2 (for RISC OS users). That said, the RPi 2, apart from a faster & higher clocked CPU (with larger L1 cache), also has significantly faster memory access. Personally, rightly or wrongly, I treat the RPi 2 as my 'minimum spec' machine, although I guess it really ought to be the RPi 1 (one of which I intend to acquire in the coming months).
It seems on the slower machines, Pi 1 and Iyonix, the biggest performance drag is blitting large objects to the screen. The Iyonix seems visibly slower with whole screen operations.
Just thinking aloud: the RiscPC must have been a lot of fun with its 16 MHz memory bus...
That said on my next game I will likely be re-drawing the whole screen every time every frame. I think in that case, I will likely not support the Iyonix...
Perhaps some custom screen-clearing code would help matters as far as the Iyonix is concerned (not helpful if you want to keep things 100% BASIC).
I've played bugs and checked out some of your demos. The Lander style landscape is cool.
Bugs was just to get me back into ARM code.
That Lander thing was pretty much adapted from a BB4W program which in turn was originally written in ARM assembler in 1995 (back in my kebab-fuelled, bedsit dayz). I never did develop it into a game...
Are you going to try a sideways scroller?
I'd certainly like to, but lack of time is the problem for me at the moment (and I suspect it's going to get worse over the coming months).
I did play around with the soft scroll VDU call drawing rough 2D rocks along the bottom. Not sure if its of use however. If so I can e-mail it to you.
I think one way I'd approach it (if writing the game in BBC BASIC), and the way Jeroen Groendaal did it with his excellent Vapiki game, is to create (or load-in) a very long background sprite (say, 50*640 by 480) and plot in one fell swoop with a OS_SpriteOp call. That would be a pretty fast way of drawing a complex background (much faster of course than drawing tiles which how it usually tends to be done). I guess if you want a multi-layered background (e.g. for parallax scrolling) or an overlaid foreground then you might (if using purely BASIC & SpriteOp) be pretty much forced to plot masked sprites (unless you want entirely solid blocks), which can be frustratingly slow with SpriteOp, as you'll know already.
Come to think of it, I don't think I've ever seen a sideways-scrolling shoot-'em-up written in BBC BASIC before. Perhaps some exist, but haven't seen any.
It could be a first?