Dynamic Sprites

[dilwyn]

Hi Dilwyn
Just saw your post. I should (post-)hasten to add that I was only thinking of SMSQ/E! Never occurred to me that youd be doing this for Qdos!

I dont know the limit for Qdos animated sprites! It could well be less than 64x64. Busy day today, but I can try to find out later.

I should add that there are many reasons why it wouldn't be practical to have my program run on QDOS+PE. What I meant was that the program would run on SMSQ/E but of course the dynamic sprites themselves could be used on a QDOS system.

[pjw]

Hi again, Dilwyn,

The EasyPtr 4 manual states: "With EASYSPRITE sprites, blobs and
patterns up to a size of 64 x 48 Pixel in MODE 4 or 32 x 48 Pixel
in MODE 8 can be designed on the screen (these are the maximum sizes
allowed for pointer sprites by the pointer interface not older than
V1.36)."

I tested a mode 4 animated sprite of 64x48 in Qdos JS, with ptr_gen
2.06 and that worked fine. The same sprites works under SMSQ/E in mode
32 also, BTW.

I dont know if that is the limit for Qdos PE V2.x though. So thats the
best I can come up with for now. The SMSQ/E source might give a clue
as Qdos PE V2 should use the same code base.

Nice that your program supports PACs! I find the format useful as
for most typical "QL-type graphics" it seriously reduces file sizes.

Glad to see you have some time to do some programming again!

[dilwyn]

Hi again, Dilwyn,

The EasyPtr 4 manual states: "With EASYSPRITE sprites, blobs and
patterns up to a size of 64 x 48 Pixel in MODE 4 or 32 x 48 Pixel
in MODE 8 can be designed on the screen (these are the maximum sizes
allowed for pointer sprites by the pointer interface not older than
V1.36)."

I tested a mode 4 animated sprite of 64x48 in Qdos JS, with ptr_gen
2.06 and that worked fine. The same sprites works under SMSQ/E in mode
32 also, BTW.

I dont know if that is the limit for Qdos PE V2.x though. So thats the
best I can come up with for now. The SMSQ/E source might give a clue
as Qdos PE V2 should use the same code base.

Nice that your program supports PACs! I find the format useful as
for most typical "QL-type graphics" it seriously reduces file sizes.

Glad to see you have some time to do some programming again!

Thank you Per. Of all places, I didn't think of looking in EP manual . I recall reading somewhere that there was a specific reason why that size limit was chosen - doesn't make much sense having bigger pointer and cursor sprites anyway. Armed with this it should help me debug. Seems to confirm my observations, in that it explains why I was having difficulty with 64x64

[BSJR]

Thank you Per. Of all places, I didn't think of looking in EP manual . I recall reading somewhere that there was a specific reason why that size limit was chosen - doesn't make much sense having bigger pointer and cursor sprites anyway. Armed with this it should help me debug. Seems to confirm my observations, in that it explains why I was having difficulty with 64x64

Also TTs Sprite program as bundled with QPTR used a 64x48 pixels limit.
This is of course a 4:3 ratio and would produce a square image in the CRTs of that time.
SQRview uses a limit of 4K pixels to decide if it can be a pointer sprite or handled as static sprite so neither 64 or 48 is the limit but the total of pixels.
In SuQcess2's Print menu a text line is picked up and made into a pointer sprite, up to 34 chrs by 12 pixels high is possible.
The Basic routine to do this was Per's I believe.
Animation is not limited to pointer sprites (see the examples "SWxmplxx_spr") as zipped with SQRview.

BSJR

[pjw]

<>
SQRview uses a limit of 4K pixels to decide if it can be a pointer
sprite or handled as static sprite so neither 64 or 48 is the limit
but the total of pixels.
In SuQcess2's Print menu a text line is picked up and made into a
pointer sprite, up to 34 chrs by 12 pixels high is possible.
The Basic routine to do this was Per's I believe.

Duh! Indeed I shouldve known - having written the routine! In my
defence, I never tried it with an animated sprite.
Its a problem that the documentation is all over the place, and it has
evolved over time so it can be hard to keep up. Im pretty sure there
is at least an advisory note somewhere that system sprites, or at
least those to be used as a pointer sprites, mustnt be more than 64x64
pix. But perhaps I just misunderstood. Sorry for spreading
misinformation! Glad we got that cleared up.

Animation is not limited to pointer sprites (see the
examples "SWxmplxx_spr") as zipped with SQRview.

Sure, Bob, but I have a slightly different idea of animated sprites.
Id want the image to keep changing while handing control back to
the user. But TBH I dont know what Dilwyn has in mind.

[dilwyn]

This is of course a 4:3 ratio and would produce a square image in the CRTs of that time.

Yes, of course. I think I remember about this now, thank you.

[dilwyn]

Sure, Bob, but I have a slightly different idea of animated sprites.
Id want the image to keep changing while handing control back to
the user. But TBH I dont know what Dilwyn has in mind.

Originally, I wanted to come up with that type of animation, then after the initial "not very good results" experiments it was to be more of a animated GIF to dynamic (pointer or cursor) sprite routine.

I'll leave the code in to make the larger dynamic sprites in the hope that someone will write a good animator for them.

[Tinyfpga]

I can't really follow this topic but my guess is that sprites, dynamic and static, would be useful for writing games.
Dynamic, cursor and pointer sprites are mentioned but it is not clear if they are the same thing by different names.
I have some questions as follows:-
What is a sprite? Can any sprite be dynamic? Can they created and used in SBASIC without using Easy Pointer? If they can, how does one do this and is there a sprite manual ?

I have tried to use Easy Pointer a number of times but sadly find it too difficult to use. I find using QPTR natively easier.

[dilwyn]

I can't really follow this topic but my guess is that sprites, dynamic and static, would be useful for writing games.
Dynamic, cursor and pointer sprites are mentioned but it is not clear if they are the same thing by different names.
I have some questions as follows:-
What is a sprite? Can any sprite be dynamic? Can they created and used in SBASIC without using Easy Pointer? If they can, how does one do this and is there a sprite manual ?

I have tried to use Easy Pointer a number of times but sadly find it too difficult to use. I find using QPTR natively easier.

Short and simple answer: no they can't be used as moving sprites for games. The operating system has no support other than using them as 'moving' or animated on-screen pointers (mouse pointer), and writing them out as simple non-animated objects using commands such as SPRW in Easyptr and WSPRT in QPTR toolkit. Recent SMSQ/E can use them as cursors too instead of the standard flashing cursor block. To make a game animation would require that some fairly substantial software is written for animation, collision detection, limit checks and so on. It's unfortunate that the name 'sprite' was used in some ways, as people think you can use them to write games easily, which you can't.

Very little by way of "beginner" documentation other than what's in the QPTR manual and a few articles from Marcel and Wolfgang which appeared in QL Today. Use the search box on my home page to see what info there is on my site, for example.

Basically, it's not much more than a small graphic or icon with a particular header. To make a dynamic sprite you basically stick a load of them together and put some timing values in to indicate how much of a pause between printing each one (somewhat simplified explanation). No support whatsoever for moving them around the screen in games or anything like that.

The program I'm writing is simply to view animated GIF files. You can then save it complete or as individual frames, in a choice of formats (PIC, PAC, or multi-frame sprites). If small enough (up to 64x48 pixels) you may be able to use them as "dynamic" (=animated) pointer sprites and that's about it. My program will let you save them as larger sprites, but AFAIK there is no software yet to use these. There will be a BASIC animator with it, to just display a simple animated sprite at a given place on the screen, but nothing vaguely approaching moving graphics for games writing etc.

[Tinyfpga]

Thank you for your short, simple and informative answer. I have been trying to write some "crap" games for the 2021 competition, mostly to learn how to program in SBASIC.

My best, so far, is a bat and ball game in which the animation consists of repeatedly writing characters to the screen. My main problem with this process is that I have use the keyword PAUSE, with a minimum pause of 20msecs, to control the program flow. My animations either run flat out (no pause and too fast), or too slowly (20 msec pause).

Is there a fine grained way of controlling the flow of an SBASIC program? I know this is off-topic but my question seems
too trivial for a new topic.