z88dk forums

Hi,

I am beginning to experiment with z88dk creating some graphics/animation for the TRS-80 Model 3. At first, I create a very slow sprite function using plot/unplot but I am not happy with the results.

I noticed that there are sprite related functions in the SDK, but it is my understanding they are not meant for the TRS-80 low-res graphics. I wonder if there is something already out there that shows how to design a sprite function..

Did anyone here manage to do something similar for this platform?

Thanks!

The putsprite() function should work on the TRS80, it similarly uses plot/unplot but may well be a bit quicker than what you've written, however, given that we're printing characters rather than pixels there's only so fast it can go!

It's possible to create optimised putsprite() functions for a target, for example, the Colour Genie has one, but I can't see anything for a vanilla TRS80.

Thanks, dom, I will take a look at putsprite. I was trying to use the "bksave" first, but I got all sorts of errors so I assume these functions weren't supported.

I just found under examples folder a graphics folder so I was trying to compile the spritest.c with the command:
But I got these errors:
Am I missing a parameter or something? (Not sure if matters but I am using macOS with zcc version v16905-8b62708-20200825)

Thanks again

Paulo

I just found some examples that are working (wall, dstar, microman). I think I can now have a better understanding of the putsprite function!

Thanks

The errors you got were caused by a placeholder function, getsprite() is missing on many targets, I should really think at a slow generic function based on getpixel()

I checked the source code tree for the classic library, there could be still a bit of regression after the last sorting out.
Some of the functions inserted in the list for the 'narrow' graphics won't work with the text modes and should be overriden (e.g. the 'getsprite2.asm' alternative could be better on the trs80). I still haven't found the cleanest way to fix it, though.

Yeah, the graphics was a bit of a mess and I tried to organise things a bit more sensibly, somethings may have got lost in the cleanup though.

Regarding this, it's probably easiest/best to add gfx/narrow/getsprite2 to gfx/text/gfx_test.lst above the @gfx/narrow/gfx_narrow.lst - I'm guessing that getsprite2 would be better for all text based graphics? - I don't think there exists a text display with > 256x256 characters?

perfect then, it was what I was going to do
I'll take a while to test the result but consider it addressed. .

TEXT, TEXT6 and ZX81 modes should now be fixed

..for the record, I should have sorted out also the TS2068 port.
There is still a bit of overlapping/redundant elements here, and I've been probably too conservative but it is back in working order

stefano wrote: ↑Tue Jan 05, 2021 5:33 pm ..for the record, I should have sorted out also the TS2068 port.
There is still a bit of overlapping/redundant elements here, and I've been probably too conservative but it is back in working order

I thought the TS2068 was working - the graphics functions were meant to follow the screen mode, so supporting regular, hires and hi-colour screen modes. I suspect getsprite() might have been broken, but it looks like now clg() will clear the second screen then in regular ZX screen mode?

I used chessboard.c (configured as for the c128 build hint) and mandel.c (to check getmaxx and getmaxy). Spritest for getsprite.