Multiplexing Using Vsprites Code

[Havie]

I hadn't realised that Vsprites wasn't general knowledge so never occurred to me discuss/upload.

This include (not quite a library) allows you to easily multiplex sprites. Basically you copy the bob image into the sprite as normal (Getasprite) and then display it with:

vsprite {sprite no., x,y)

Able to reuse sprites over and over again no problems!

I have uploaded (to the zone) the lha file I found which has 2 examples (apologies I added a background to one and didn't remove it) for your pleasure.

I am currently working on a Doodle Jump game which I will upload soon which is all sprites and no bobs.

I thought I'd start a thread to collect any information on Vsprites as documentation is sketchy to say the least!

[Havie]

From read me file:


VSPRITES v0.5ß

(A BB2 *Hardware-Sprite-Multiplexer*)



Developed by Manfred Linzner
in November 1997, January 1998


This is a free extension for BB2. Please note me in your projects if
you use it. Any comments or suggestions are appreciated.



Overview:
---------

Have you ever tried to code a fast action game in BB2 ?
Then you will have experienced the limited number of BOB´s that
BB2 can handle in 50hz (including restauration of the old screen!).
SPRITES are not too useable if you want to bypass the blitter.
AMIGA´s hardware can only handle 8 SPRITES with 3 colors or
4 SPRITES with 15 colors. That´s not enough for any kind of action-game.
VSPRITES is the solution for this!




Generall:
---------


VSPRITES is a BB2-include that allows you to use upto 512 sprites.
And all those sprites are using the same 16 color palette.

Alot of hardware banging is necessary to force the hardware to
give you such impressive amount of nearly non-cpu stressing sprite magic.

The most interresting feature is the use of many BIG VSPRITES that are not
possible to be handled by the BLITTER in realtime. Many small
VSPRITES are too slow in most cases. The overhead of multiplexing them
is to complex todo it in realtime for severall hundred VSPRITES.
(My code is simply too slow =)


Technical:
----------

The multiplexing of the sprites will be achieved by waiting to
specific scanlines and reseting the needed sprite-registers.
A special treatment of the temporary spritebuffer-2-screen registers
is needed. The Sprite-DMA pointers will also be rewritten ´on the fly´.
I suppose that my routine does only work with a standard 320pixel wide
lowres-screen. All Sprite-register-writes will be done at specific
y-beam positions. By changing the display-window size everything will
be easily out of the right sync. All AGA fetch-modes are supported by
setting them into the BB2-coplists. Previous commands written into
the BB2-coplist (i.e SETRAINBOW) will be discarded.




Features:
- Upto 512 multicolor-sprites onscreen in 50hz (AMIGA POWER =)
- 16 colors for every sprite (from one 16-color palette)
- Upto 256 pixel high sprites
- 16,32 or 64 pixel width sprites for AGA display
- 16 pixel width sprites for OCS display
- Fully compatible to BB2 sprites-data and size
- Very small and easy to use
- Compatible to BB2 Spritesmode (16,32,64 pixel width)


Limitations:
- Maximum of 4 sprites for one vertical scanline
- Only upto 4 sprites can overlap themselves
- Disables most BB2 customcoplists commands
- The display code is far from optimised. I bet the
display routines could be up-speeded by 300-400%.


Note: Use double-buffered coplists for
optimal flicker free performance!


ps: Developed and tested on a 68030/50 System. I don´t know if slower
AMIGA computers will have problems in any way. Please report bugs

Email: manfred.linzner@munich.netsurf.de

[Havie]

Have also located the original page where I downloaded it:

http://www.amigascne.org/abyss/pink/...itemultiplexer

Have tried emailing but address not found. Maybe someone knows how to contact Manfred and we could get more info directly from him?

[idrougge]

He's actually here on the forum: http://eab.abime.net/member.php?u=66936

[Cobe]

Hah! Awesome! I didn't know of Doodle Jump but somehow by the way you described sprites in your game I got a hunch that your game would be the similar to the demo I did few weeks ago for local retro meeting.
https://drive.google.com/open?id=1ag...jX31nuuOBax6yF

and thanks for the VSprites. It'll come handy sooner or later.

[Havie]

Have contacted Manfred but sadly he doesn't remember much about VSprites.

Have uploaded a copy of my Doodle Jump game to the zone:

http://eab.abime.net/zone/Doodlebeta.lha

I am currently (re)using 4 sprites -3 for the different platforms and one for the Doodle jumper. THERE ARE NO BOBS AT ALL. So my theory is that this should be just as quick on an A500 as a 1200?

Let me know how it runs..

[Cobe]

I tried it in winuae. First on A4000 and it runs well.
Then on A500 it started loading but stopped at some point.
On A600 it loaded but there where just some trashed squares on screen.
On A1200 it runs but slower than on A4000.
On A3000 it runs well as on A4000 but colors are a bit different. Doodle's head is white and his white stripes are yellow.

[Havie]

Originally Posted by Cobe

I tried it in winuae. First on A4000 and it runs well.
Then on A500 it started loading but stopped at some point.
On A600 it loaded but there where just some trashed squares on screen.
On A1200 it runs but slower than on A4000.
On A3000 it runs well as on A4000 but colors are a bit different. Doodle's head is white and his white stripes are yellow.

Thanks - what I need to do is compile with debugger active as this may give some clues to why it doesnt work. Also I wasn't surprised by the A3000 as I think I have set up display as aga and not ecs. Sprite colours for me aren't working as they should so I'll have a look at that too.

One other interesting comment is A1200 slower than A4000/3000 which implies that reusing multiplexing sprites takes more time than just using normally as it must take longer than 1 frame to execute on slower computers. I have some ideas for optimization...

Thanks for your efforts and support.

[Cobe]

Yeah, unfortunately at the moment it seems to me that vsprites are unexpectedly slower than blits... maybe you pushed them too far(many).
Did you actually narrowed the display? How wide are your bitmaps? And are you using more than one bitplane? Cause in your case I don't see a reason why to use more.
Also I don't see a reason why would you set up a display as aga. When A3000 displayed sprites with a bit different colors I suspected you poked some sprite color registers to be in aga range above 32 or something like that.

[Havie]

Haven't narrowed display but plainly could - maybe this issue? Currently 320 wide. I think I may be In 32 colours too - legacy of Bob version. Could get away with 2 bit planes for background.

Away from computer for a few days but will think about this and hopefully have update at weekend.

Also collision code currently tests all platforms but would be easy enough to exclude most of them although currently less than 20 to test so can't see this as the problem?

[Shatterhand]

Multiplexing sprites AFAIK shouldn't be so demanding... I believe all work is supposed to be done by the copper, so it shouldn't tax either CPU or Blitter tasks.

[Cobe]

Originally Posted by Havie

Haven't narrowed display but plainly could - maybe this issue? Currently 320 wide. I think I may be In 32 colours too - legacy of Bob version. Could get away with 2 bit planes for background.

Away from computer for a few days but will think about this and hopefully have update at weekend.

Also collision code currently tests all platforms but would be easy enough to exclude most of them although currently less than 20 to test so can't see this as the problem?

Narrowing the display and lowering the number of bitplanes should definately free some dma for sprites.

But we dont know how vsprites are implemented as I agree with Shatterhand that it shouldnt be cpu heavy yet it is..

[Havie]

An adventure we can go on together. ??

[Samurai_Crow]

I want to write a sprite engine that is more flexible than the Graphics.library ones. My idea is based on wrapping the sprite buffers with bitmap structures so you can blit or cpu copy to them as the needs arise.

Bobs are slow because the blitter rereads the mask for each bitplane. OS VSprites are slow because they populate the buffer from images in Fast RAM and tie up the CPU with mindless copying.

If the roles were reversed, an '020 has a code cache that will speed up CPU blitting of BOBs and the blitter runs twice as fast when doing an opaque blit without a mask.

[Cobe]

Originally Posted by Havie

An adventure we can go on together. ??

Thanks for the invitation.

I did that base demo prototype of DJ Nick's 'Running snake' as a second side project just for fun and for that retro meeting, it's not published anywhere, I don't have the rights. I was thinking to ask him if his interested to prepare or share its gfx for Amiga version and to do full game port but I don't have time for it right now. I'm already working on other project that I'd like to finish first but its not yet in advanced phase so its not gonna be soon before I could go back to running snake/doodle jump game.
For the base code of my demo I "reverse" engineered Graham's Downfall. I mean source is out there and I reversed it You could look at it too.
I was thinking to wrap my demo with some other gfx, credit Graham, and get it out just like bare game prototype.
I'd be glad to help but I cant fully commit. Fell free to drop some pm.

@Samurai_Crow
Thanks for some deeper insight. It'd be nice if you'd write one.

[Havie]

Fiddled with the code a bit but still having problems on A500/600 - runs on 3000 (with wrong colours). I guess I am setting up something wrong so thought I'd post the setup code as I can't see what the problem is:

LoadPalette 0,"graphics/backgroundpal.iff",0

BitMap 0,320,257,2
BitMap 1,320,257,2

BLITZ

Buffer 0,16384
Buffer 1,16384

INCLUDE "includes/vsprites-asm.bb2"

;For n=0 To 6: GetaSprite n,20: Next n
GetaSprite 0,0

SpriteMode 0

InitCopList 1,52,256,$2,8,32,-255    ; Create two coplists for
InitCopList 0,52,256,$2,8,32,-255    ; doublebuffering! (needed)

DisplayControls 1,0,32,$11
DisplayControls 0,0,32,$11

DisplayBitMap 1,0
DisplayBitMap 0,0

CreateDisplay 0

DisplayPalette 1,0
DisplayPalette 0,0

I know there is something wrong as the only way I can affect the sprite colours is by changing colours 0-15.

Thanks in advance for suggestions...

[Cobe]

at first glance i think you got the doublebufffering wrong.
you dont need 2 coper lists for it, just 2 bitmaps and alternate them every frame.
but at the first place why would you need double buffering at all when you're not bliting anything?
and where didi you come with such a high value -255 for copper offset? i never needed more then one digit value. and once i experimented already with two digit values it starts to slow down.
displaycontrol holds the key for that sprite colors but i cant tell just by looking at it what actually you're doing and that command is always hit and miss for me, every time i make it to do what i want and i think i figured it out, the next time it turnes up i didnt..

[Havie]

The code is just adapted from the examples. I see what you mean about double buffering but maybe it's needs for vsprites - I will experiment.

Again, -255 for copper is just the value that came in the original code. I did play around with it a little but it just crashed so I left it as is.

I think Displaycontrol is probably the key it not working on 500/600?

Thanks.

[Havie]

Right - spent a few hours per night playing around and discovered that actually the game works on 68010, 68020, 030, 040 but not on 68000?

It is very slow on 68010 but seems fine on 020+. Also needs 1mb of memory for some reason.

I am therefore wondering if it is something to do with display width when trying to run it on an A500. I don't know how to reduce the width of the screen to all more DMA time? Do I use Display Adjust and if so how?

[Cobe]

Yup. But its one stuburn command. I think earok tamed it once
http://eab.abime.net/showthread.php?...=displayadjust
But i'm thinking all of whats happening gotta do with vsprites and their implementation and requirements.