ZXB allows you to do stuff that's pretty crazy.

I had a fancy cls routine - that didn't actually clear the screen, just ran a attribute bar over the screen, and then of course you do a CLS from basic afterwards. The effect is the same, but it looks cool.

It wouldn't compile right - the call to the ZX ROM sound routine kept corrupting things. Probably messing with IX and IY registers in naughty ways.

Then it occurred to me.... just compile a beep into the middle. :-)

Look:

Version zxb 1.2.5-r1489

As I promissed, here I am with an adaptation for the Mojon Twins "Fourspriter". Well, in fact I promissed just the opposite (skip this one and post the other sprite routine I'm working in), but I think this one is more suited to a basic enviroment and the other one is just great for a crap game (see my game Colour Clash of the Titans in the CSSCGC 2010 thread within the WoS games forum) but not so good if you plan to do a polished game.

The engine itself comes in assembler, and all you have to do is POKE the right adresses to configure and move your sprites (up to 4). All I have done is adding 3 subroutines to make easier the poking part, and 4 labes so you can call the different subroutines of the engine via gosub.

Here goes the code you have to include in your library folder (I called it fourspriter.bas):

I was thinking that it might be incredibly useful, for inline assembly to be able to set what's on the registers as you hit z80 asm.

And a command to do that, that works in a similar way to a function call, might be a good way to do it and avoid a lot of the overhead of a function call for very small jobs.

How about a register and an unregister command?

Register - takes a variable and puts it in the current registers
unregister - takes registers and puts them into a variable.

So you could do something like:

DIM a as long
register a
asm
LD D,0
end asm
unregister a

To kill off the top byte of a long, if that was your whimsy.

Not sure if other people would find this useful, but I could imagine ways it could be useful.

How about:
dim a as fixed
dim b as uinteger
(do things)
register a
unregister b

to put the decimal part of a into b if you wanted to deal with the integer part and the decimal part separately. You could even shunt it back later...

Anyway, just a crazy thought from me, as per usual :-)

I did wonder if this was a bug or not, since it might be odd to modulus a floating point number.

But mod works perfectly with type FLOAT, so logically it should also work well with type FIXED. Fixed division works, and the compiler seems to know where the code for mod should be - at label _MODF16.

Error: Undefined label '__MODF16'

Here are more general purpose functions for AND, OR and NOT. They work with Byte, Integer or Long types (the function is long, but the cast works upscale).

A binary NOT is tougher - what bits do you invert? If you send me 8, and I invert 32 is that what you wanted?
(of course, you could bAND the result into the last 8 or 16 bits)

These functions are very similar, of course.

Binary AND:

Print $1234567 compiles.

Print $12345678 does not.

Since this happily fits into a LONG type, just like the first one, it looks like a buglet.

C provides bit shift functions >> and << which aren't available in Sinclair or ZX basic. Since I happened to have a need for such a function, I decided to drop them up here. Again, this is something that's easy on the CPU.

They work with Long Unsigned integers - and will work fine with smaller values, or you can use them as a template for 16 or 8 bit versions in assembler.

Sometimes we're willing to lose accuracy for speed. ZX BASIC uses the spectrum's ROM routines for many of its math functions, and as a result of them being general purpose routines that use 40 bit numbers, well, they can be a bit slow sometimes.

See my article on square roots, for a good example.

Here is a routine to produce SIN(angle) - where angle is in degrees. It uses a lookup table to calculate sin values, and it's a very quick and dirty method, in that it only actually knows 32 angles, and those to only 8 bit precision. It does linear interpolation between these known angles, however, so that does improve things somewhat.

I was actually surprised how precise it was - it's good for at least 2 decimal places, probably 3 as a rule of thumb. The average error is 0.002 That's probably good enough for games that need to calculate angles. It's about 4-5 times faster than the SIN(FLOAT) function, and not even written in native assembler.

If you need better accuracy, it would be fairly easy to change the method to use a bigger table - perhaps 2 bytes per entry, even.

Remember to work out COS and TAN can also use this function - COS is SIN(90+x) and TAN is SIN(x)/COS(x). It should be easy to write COSINE and TANGENT functions to do the adjustments and call the SINE function.

(And this one I didn't copy. It's all mine! Bugs and all. And now it's free for anyone to use.)

I was having trouble with a variable not being where I expected. In the end, I have this code: