I seem to remember you can wring slightly more speed out of the Beeb for games by turning off some routine tasks undertaken by the OS. For example keyboard scanning. Now I think I'm already doing this with the code RTW gave me for vertical scrolling. But are there any other areas that can be turned of to improve speed a little ? And if so how ?

Can't you just turn off everything?

I just enable timer1 and vsync IRQ

What Dave said.

The easiest way to do this is to intercept IRQ1V and never return to the old handler. This means you have to handle every interrupt yourself - and remember what you've enabled!

Doing that already, two timers and vsync, damn, hoped I'd missed something, need more speed !!!!

I guess all you can do now is try to optimise what you have already a little bit more.

One way I use to see where the bottlenecks are in the main loop is to set the background palette colour to different colours at various points in the main loop. You'll see various bands of colour across your screen, the 'thickness' of each corresponding to the time spent in each one. Then, you can look at the ones which take the most time, and try to streamline them a bit more.

Some ways you can do this might be, but are not limited to :
* unrolling frequently called loops, e.g. in the background map plotter, sprite routines etc
* removing CLC/SEC inside frequently called code, when you already know what the C flag state will be
* Pay special attention to things like this:

worst way to do it:
(8 bit value) * 64 = (16 bit value)


better way to do it:


this is also a good example of a place you can save a CLC:




If still nothing will budge, then unfortunately you only have two options:
* cut some content
* reduce your frame rate

This is what happened with Blurp

Thanks Rich, I'd noticed your background palette thing on the stars demo I think.

As usual your always very helpful.

I haven't really gone through my routines yet to really have a go at optimising but that's my next task.

It doesn't help that I've got full masks on the sprites with them being able to float "effortlessly" over the background and one another. It's a real cycle eater.

Looks sweet with just a couple of 100Byte+ sprites but starts to lose it a little if I push the routines harder. I should get some improvement when I review all the code (hopes). It still includes a lot of "quick and dirty" stuff I wrote for the show.

If I can't get enough then there are areas I could cut back on

Just thought I'd add a few more thoughts about optimisation.

Sometimes lookup tables can save you some time, if you're prepared to afford the memory.

e.g. the multiply by 64 can just become:



This is much quicker again than doing the maths by hand.

In your sprite routine, if you are using colour 0 (edited from colour 8) to represent a transparent pixel, you can speed up the masking using a table, if you dare to allocate 256 bytes (gasp) as a mask table lookup:



...or that kind of thing, where masktable(n) just contains &00, &55, &AA or &FF to mask neither, both or one of the pixels in a Mode 2 byte.

Even better of course is to allocate a separate mask for each sprite, but I don't think it's so feasible to double the size of your sprite data in memory just for this. In general, the balance to be struck is between speed and memory usage. Tricky one.

Always remember about X and Y. If they're free, it's much quicker to preserve A by doing TAX .... TXA than by doing STA zp .... LDA zp. The stack is the slowest - avoid PHA .... PLA in critical code (unless you really need to use the stack due to reentrancy), because you can do just as good a job with STA ... LDA. If I don't want to consider which zp location is free, I sometimes use:


which is just as fast as using the zero page.

Remember JSR/RTS have an overhead. If you have a very small subroutine, consider moving its code into the body of the calling code, if it's a critical section of code - e.g. don't JSR mult64, but repeat the code from my last post everywhere you need it (it's only 11 bytes long).

I'll add more as I think of them....

Ha, just seen your message about your sprite routine (must've sent it while I was writing mine!)...

I guess it's worth saying that the sprite routine is always the bottleneck in any game, particularly a nice, fully-masked, non-EORed one. I would say that this should probably be the first thing you try to optimise.

How does your sprite routine look at the moment? (or what is it doing, more-or-less?)

Thanks Rich, the 256byte mask table is a possible option. Short on memory but he ho !

Loving all your suggestions so far

Just another thing worth mentioning:

if you are using colour 0 as transparent for your sprites, and you don't require "opaque" black anywhere, the values for sprite data bytes will only ever be between 0 and 63, which means just a 64 byte mask table, which is maybe more affordable...

Yes, logical colour 0 is the transparency. Unfortunately I want to remain faithfully as I can to the game so I need opaque black as well.

In my head yesterday I was designing a hardware sprite add on But that would be cheating !

What Blurp does is defines logical colour 0 as blue (i.e. the background colour) and black is some other logical colour, so I can have the outlines around everything. It just means I can't use the background colour in my sprites.

Maybe something similar would work for you?

Hardware sprite addon - that would be perfect proper sideways scrolling while we're about it too. And how about 'dark' versions of the standard colours instead of flashing? Then we'd have maroon, dark green, brown, dark blue, purple, 'teal' and grey too...

May also sound obvious but I have separate sprite routines for each spritesize I have instead of faffing with width/height arguments. So I have for eg:



... and so on

yeah, good point Dave, I have a few different routines for different sizes/alignments too.

On the same theme, you might even find that calling a different routine when the sprite is character row-aligned is worthwhile too (because you can unroll the loop 8 times). It's probably only worthwhile if the character is walking on platforms a lot of the time, but you never know.

All good stuff.



Heh heh, actually I'd planned it all out to include full pixel level scrolling in all directions, support for umpteen sprites and possible filled vectors as well. However extra colour depth could not be supported in the original design I envisaged as it was still making use of most of the Beebs existing video circuity.

All pipe dream stuff really, but feasible. Can't help thinking it would be a real cheat though

On subject of sprite routines. I have optimised plotters for background. In fact the background graphics are 8 bytes high by 2 wide, so these are stored in the natural flow of the screen memory. For the background there are 3 separate plotters depending on the type of background cell to be plotted (i.e. solid colour, normal and flipped horizontally).

For my main sprites I've not analysed the ones in the actual game to see if they follow fixed sizes. Perhaps they do. I'll investigate. End of level bosses are obviously exceptions. I suspect the game graphics are quite varied though

Just now getting back into looking at this (been a long time) and decided this mask technique is the way for me to go (although it uses up a valueable 256 bytes of memory). Anyhow for anyone else wanting to do this I've genertated the mask table data with a bit of code so you can just 'lift' the numbers from here if you need them to save anyone a little time (not that it's a big effort !)

Welcome back Steve

lol, well it has been just short of a year since I last worked on it seriously !

anyway I forgot to attach a file version of the data for people to directly use (oops), here it is.

Note : although the file extension is .zip, it is NOT a zip file, it is the pure 256 bytes of data. Using .zip as the extension was the only way I could get the data uploaded to the forum.

Compiled sprites? You're trading memory for speed, but hey - it's a classic!

CSprites are just about the fastest way to draw. You literally turn your graphics into code. No masking necessary as you only draw the pixels you need to draw. and no lookups/loops.

I suppose there's a complication in that the beeb's screen memory isn't linear - is that right? Hmm, that just might kill this idea off but I'll leave it here to float and see what happens.

C

Oh yes, the Beebs screen memory is an 'interesting' layout to say the least Have a look in the advanced user guide