BritLion's Putchars

[britlion]

You do realise that mine should be able to do anything from 1 character to a whole screen just by changing height and width (and making sure there's enough data at the address given!) ?

No, I was confused because you called it PutChars and not PutBlock. Your routine is working char-wise and has no attribute yet (but that is okay in most games), mine is working progressive. Anyway, yours is faster, so if you will add attribute, I would like to use it. I ask you to swap the place of height and width values:

Sorry! Perhaps I should have made it clearer. I did show speed test data for block sizes from 1x1 to 8x8 though! I called it putChars because it can put more than one!

Code:

SUB putChars(x as uByte,y as uByte,width as uByte,height as uByte,dataAddress as uInteger)

If you change the first line to read that way, I'm quite certain it would work exactly as you wanted :-) It would call the 3rd variable width, and the fourth one height instead; but they get used by name in the routine.
I'm definitely sticking to data being used in columns before rows, though. It's just faster that way. Ironically, it's faster to paint attributes in rows and then columns.

The reason for this is you can head down a column of screen data with inc H to go down (unless it's across a 1/3 screen boundary, which gets a little awkward). Inc HL moves to the right for attributes. You have to add 32 to go down.

This might lead to data being in a format that's more convenient for the computer and less convenient for the human reading it; but that's the way to get speed!

So what you could do, is to precalculate the adress after bitmap/char data, and use it as source for attribute data. Will this be possible?

I'll see about adding a routine then, that puts attributes on top of the screen data, and either takes one attribute for all of the squares, or assumes it's immediately after the screen data. And actually, since we just had a pointer go through the screen data if we follow on immediately, then we shouldn't need to calculate the attributes address at all - we're already pointing at it.