Limits in UDG bank switching trick [solved]

[Felix]

In my latest game (which you can download here), I use the UDG bank switching trick described in the How to Write a Pac Man Clone tutorial. Unfortunately, it only allows UDGs from "\A" to "\U", whereas I need to go up to "\W" -- I have only 8 terrain tiles, but 23 different items. I suspect there is a way around the limitation, but my knowledge of ZX Spectrum development is rusty at best. (I'm lucky to have ZXBasic holding my hand so much, heh heh.) Help, please? Thank you.

Edit: never mind, in the mean time the question was answered over at World of Spectrum. I'm leaving this here for reference purposes.

[britlion]

Yes - redefining the font to point to the data is an alternative. In that tutorial I did the graphics bank switching thing, because I thought it would be the easiest explanation for Sinclair Basic users. But it's not really the most efficient way to use graphics. Having 21 is a holdover from sinclair basic, and pretty much designed into the ROM. There's only 21 ascii numbers assigned to the UDG; and there's just no way to get more at any one time using this system!

Of course, you can redefine the whole font, or just write a print routine that will print straight to screen from your udg defined bytes in memory, as well. For example <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Putchars.bas">http://www.boriel.com/wiki/en/index.php ... tchars.bas</a><!-- m --> is designed to blit graphics data straight to the screen.

[Felix]

It was the easiest, and also very fast. The putchars routine appears to be optimized for displaying entire blocks of characters, and taking advantage of that would have required significant reworking of my display code (not to mention having to store a rendered version of the map, complete with colors... ugh). The other method described by LCD, namely changing just the first UDG every time I display a tile also promises to be slow, and more fiddly on top of that. But redefining the font was also fairly easy once I understood your tutorial, which laid the foundation for me. Thanks!

[britlion]

Oh certainly - putchars is an example. And actually it can drop anything from a single character to a whole screen, so it's quite a flexible bytes-to-screen pusher. Not quite sure what you mean about the colours? It's a monochrome subroutine. (You'd have to do both paint and putchars to print a certain colour) - and paint (x,y,colour):putchars(1 character from my data point n) is actually faster than a print

If you're worried about speed, there are optimizations to make - boriel has already put in the random stream generator, but I've got some optimized integer versions in the library part of the wiki; just for example. And printing can be sped up with optimized print routines like putchars and again, others in the wiki library.

Not to worry - I'm mostly REALLY happy to see that someone read my tutorial and found it useful! (Also, you used my 64 character print routine, and so on and so on Most of all: Good job! I know it's a long hard slog to get a game up and running!

BL

[Felix]

paint (x,y,colour):putchars(1 character from my data point n) is actually faster than a print

Hm... I'll have to try that at some point, because printing appears to be the slowest part. Random dungeon generation, for all the RND calls, is surprisingly fast. Combat is a little slow, but it also involves quite a few calculations on top of the dice rolls -- and the combat system is as simple as it gets.

Not to worry - I'm mostly REALLY happy to see that someone read my tutorial and found it useful! (Also, you used my 64 character print routine, and so on and so on Most of all: Good job! I know it's a long hard slog to get a game up and running!

print64 is also yours? Cool! You make ZXBasic development so simple for the rest of us. I couldn't have written my games without this simplicity. Call it laziness, but my brain is already chock-full of programming knowledge, and there's only so much effort I can put in for fun.

Luckily, developing for the Speccy is a LOT of fun. And that's what brings us all together, isn't it?

[britlion]

Is it mine? Well, partly. I borrowed quite a bit of the concept from other sources, wrapped it up and got it online here. Then hacked at it some more. (See <!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/post1552.html?hilit=print64#p1552">post1552.html?hilit=print64#p1552</a><!-- l --> for example).

I also did a few other sizes. I suspect that Einar Saukas and Andrew Owen's FZX may end up blowing it out of the water with flexibility, however. Getting that up for BZXB is on my todo list. So will probably happen by 2020.

If you want to put a single character to the screen, there are faster routines than putchars. I'd be happy to put up a tiny MC character blitter, for example if that's what you want. Something like printUDG(x,y,UDGNumber,@UDGDataSTART) ? The beauty of this compiler is you can throw in small machine code routines to speed up any slow spots. (I tried to explain this in the Pac Man tutorial )

Do have a look through the library in the wiki, if you haven't played with this stuff. Some of the routines that Boriel included have been optimised and updated here - Boriel doesn't necessarily include the latest versions with the compiler. Mostly because I'll tweak em in the library, and am bad about nagging him for write access to upload newer patches officially, of course Also there are likely to be other routines that are useful there. I think, shy of FZX, the print 64x32 one can be quite neat, for example. But if you think that's too small a font, there's a 42 char one, and a proportional print routine in there (that I didn't do!).