Super Sprite Generator issues

[Andrew]

There are other sprite systems, is it worth vonsidering?

There is only one other - Frank's Sprites.
But the documentation is badly written so I haven't yet understood exactly how to create the sprites and the designer crashes a lot.
It has many more features than SSG and better collision detection - but also has a major drawback: the sprites are all XORed on screen, so if you do not use a black background the sprites will not have the colors as designed.

Can QPTR Sprites be used in games?

I have no idea. I have not yet learned to program with QPTR

[mk79]

Can QPTR Sprites be used in games?

I have no idea. I have not yet learned to program with QPTR

I'm not saying this is the way to go, but at least drawing sprites with the PE is easier than one might fear:

Code: Select all

spr$ = "WIN1_progs_qdock_pen5_spr"
l = flen(\spr$)
spr = alchp(l)
LBYTES spr$,spr
:
SPRW #1,10,10,spr

You need to load ptrmen_cde from EasyPtr for this. Sprites can be designed using my converter for Windows or pixel-by-pixel using the EasySprite executable included in EasyPtr. Again, this was not intended for games, but some things can be accomplished using the PE routines. And they work no matter what screen mode you're in.

[tofro]

Can QPTR Sprites be used in games?

Well, in a limited way, they can. The blockfall animation (or rather all the blocks) in QJewels (look to the left if you haven't seen it yet) is implemented using PE sprites. I probably wouldn't want to build Mario Bros games that way, but in a limited way they can be used for games.

The nice thing about PE sprites used here is: The game runs on all PE platforms that support at least Aurora (or better) graphics without any changes. Obviously, you're paying a (performance) price for that.

[Derek_Stewart]

Hi,

I have got the SSG 4 demo programme working in QPC2 by enterin the QPC_QLSCREMU 8 command.

SMSQmulator requires the JVA_QLSCREMU 8 command for the demo to run.

This implies that the extensions require the Screen, System Variables to be static.

I will work my way through the disassembly, to see what is going on. As I think we need a good Sprite programme, that runs all QL platforms.

I am still interested in QPTR Sprites for animation or game play.

[Derek_Stewart]

Hi,

I have got the SSG 4 demo programme working in QPC2 by enterin the QPC_QLSCREMU 8 command.

SMSQmulator requires the JVA_QLSCREMU 8 command for the demo to run.

This implies that the extensions require the Screen, System Variables to be static.

Does anyone know what assembler might of been used?

I will work my way through the disassembly, to see what is going on. As I think we need a good Sprite programme, that runs all QL platforms.

I am still interested in QPTR Sprites for animation or game play.

[RalfR]

I have got the SSG 4 demo programme working in QPC2 by enterin the QPC_QLSCREMU 8 command.

Do the sprites flicker? As far as I remember, RWAP has written, that this happens under QemuLator.

[RalfR]

I am still interested in QPTR Sprites for animation or game play.

But you may need an easy way to make collision control. And is it possible to let them move fast and smooth? I think there is no way (at the moment) with QPTR or EasyPTR.

[Andrew]

Do the sprites flicker? As far as I remember, RWAP has written, that this happens under QemuLator.

The animations is not very smooth. You cannot move with 1 pixel, but only with 4 pixels.
On unexpanded QL if you have few sprites on the screen it is ok - but if you have 12 moving sprites than animation is a bit jerky.

[tofro]

Do the sprites flicker? As far as I remember, RWAP has written, that this happens under QemuLator.

The animations is not very smooth. You cannot move with 1 pixel, but only with 4 pixels.
On unexpanded QL if you have few sprites on the screen it is ok - but if you have 12 moving sprites than animation is a bit jerky.

Pixel movement is in 4 pixels, because movement by 1 pixel would involve shifting the pixels within screen memory, which would slow down movement too much (the QL is not spectacularily fast at bit-shifting). A really sophistcated sprite engine for QL screen modes would pre-shift the sprites, thus have 4 images shifted by 1 pixel each and display that according to the currently needed one. That should also be possible with SSG (but you obviously need 4 sprites instead of only one).

[Derek_Stewart]

Pixel movement is in 4 pixels, because movement by 1 pixel would involve shifting the pixels within screen memory, which would slow down movement too much (the QL is not spectacularily fast at bit-shifting). A really sophistcated sprite engine for QL screen modes would pre-shift the sprites, thus have 4 images shifted by 1 pixel each and display that according to the currently needed one. That should also be possible with SSG (but you obviously need 4 sprites instead of only one).

Do you mean that 4 images are required with 1 pixel difference, for smooth movement.
Can you expand this