Preshifting with blitter?

[Zamuel_a]

Then I did some testings to compare software vs blitter sprites I found that a 32x40 sprites is about as fast with the blitter as in software. You don't have to preshift it then using the blitter so you save alot of memory. But with smaller sprites like 16x16 it's faster doing them in software. One problem with the blitter is that since it's take up the whole bus I can't have interrupts at the same time, so if a blitter sprite takes more processor power than what I have in the borders I get problems with my palette shift routines on Timer B, so I think that I might do all sprites that are smaller than and equal to 32xY in software and then if I have some large one, 64x64 or something I do that with the blitter. And by sorting them in Y I can draw them while I am at the visible part of the screen. One thing I really never thought about was that I wanted to do a software sprite routine on the visible part of the screen for the main sprite, since it's more or less always in the middle of the screen and the processorpower to draw that sprite was roughly one scanline for each scanline of sprite, so a 32x40 sprite took somethere around 40 lines of processorpower, so then I first thought about it I figured that then my main sprite has to be on a scanline BELOW 40, but since I draw the spite line by line you just have to had drawn the next line you want to display, so I can actually put my sprite in that visible area there Im drawing it. I could put the sprite nearly at the top of the screnn without getting it to flicker. So by sorting all sprites I can use alot of the vibisle area for drawing. Tobad I dont know how much processor power I need to the game logic and music and that:)

[earx]

zamuel: interesting!

the blitter isn't omnipotent, of course. the nice thing about it is, though. that's it's a state machine. you only change the registers you want. no need to setup everything all over again. and there's another thing, which can hopefully help you out: run the blitter in bus sharing mode but restart it quickly. this method is documented by atari (doc available online). this will allow interrupts to take place (probably with jitter, but ok).

good luck!

[Zamuel_a]

I draw all sprites of a certain size at the same time so I don't have to set up the registers all over again, but I don't gain so much really. The time it takes to setup registers is really small compared to the rest. Software sprites are faster if they are under 32x32, BUT that is if you make it so it saves the background while you draw the sprite. I first made my software sprite routine so that first it restore the old background, then in the draw loop (well an unrolled loop actually) I first save the line I'm going to draw (so I can restore it later) and then draws it, by doing the save/draw at the same time I can copy the current data from screen, save it, and then put the AND, OR mask/data over it.
That routine was very fast, but the problem is if you have sprites laying over each other. You will then save background data with the underlaying sprite on it and that isn't so good then you tries to restore it. So I had to make it the slower way, restore/save/draw as three independant routines.
So what I do right now is that first on the visible part of the screen I draw two software sprites (interrupt friendly). One 16x16 sprite and one 32x40 sprite. The 32x40 is the main sprite and the 16x16 is a "bullet" sprite. It's a reserved sprite just for the bullets the playes is shooting. You probibly want to shoot stuff and this way I know that the "bullet" never affect the rest of the sprites on screen (the enemies).
Then at the bottom of the screen, before the border, I restore the area that the mainsprite and bulletsprite had. I have to restore it in the visible area since I dont want to spend border cycles on that. Since I draw them at the beginning and restore them at the end of the screen I can't have thoose sprites at the top of the screen or on the bottom or they will flicker or something, but since the mainsprite is always around the middle of the screen and you mostly never shoot anything straight up it doesn't matter. Even if you shoot straight up the bullet would just dissapear some lines before the border and you would never take notice of it anyway since if's going in a high speed.
Then in the border area I draw all blitter sprites by first restore the background of all sprites, then save the background for the new ones AND save the background for the software sprites. That has to be done here since I need a "clean" screen to copy from. Then after that I can draw the blitter sprites.
So what I got so far is that you can have a 32x40 player on screen shooting bullets of a size of 16x16 and you can have two enemies also 32x40 who can shoot stuff at you:) With smaller enemies you can ofcourse put more on screen.
With all sprites on screen and hardware scroller and all that. I get 30% processor power left for game logic and music/sound effects. Game logic for a platform game shouldn't take so much power I guess since it's no problem doing it on a 1MHz 8bit computer.
Playing MODs might be tricky, if I can't find a 25kHz played that runs in less than 20% or something. But I was thinking of having some sample replay instead. Sound effects could be done with the YM chip so they get separated from the sample replay.

[Frank B]

Hi. I worked out roughly how many cycles the blitter would take for your use case. See below.

Bullet
------

16*16 4 planes

5*8*16 cycles to save (1 extra word)
640 cycles

4*24*16 cycles to mask
1536 cycles

5*8*16 cycles to restore
640 cycles

total cycles == 2816


player (ignoring NFSR, you can save a read on your source too
----------------------------------------------------------------

save
32*40 == 3 words wide * 4 planes * 8 cycles * 40
== 3840 cycles


Mask
32*40 == 3 words wide * 4 planes * 24 cycles * 40
== 11520

restore
32*40 == 3 words wide * 4 planes * 8 cycles * 40
== 3840 cycles

total cycles == 19200



So that's

2816 (bullet)
19200 (player)
19200 (bad guy 1)
19200 (bad guy 2)


60416 cycles for all drawing ops

total bandwidth == 160,000 cycles per frame

you should have 99584 cycles left assuming hog mode.
you should get about 90% of that with the restart method
maybe a bit less depending on what you're doing with interrupts.
blitter set up overhead etc will eat into this too but that's
what I would expect in terms of the cycles the blitter would
eat a VBL. You could also cancel having to save the background if you
use a third buffer as a restore source.

I'm a bit confused as to why you're not double buffering though.
Can you please explain? The numbers look too low for me*

Frank

*obviously I don't have the full picture of what you're doing so I might be misunderstanding something

[Zamuel_a]

Well, Im doing a platform game, somthing like Turrican and I can't use double buffering since I use hardware scrolling on the world. I would then need to draw everything once and I dont like that:P I use Timer B for interrupts every 16 scanline to change 8 colors in the palett so I can have a total of 12*8 + 8 = 104 colors on screen at the same time. I leave 8 colors since the sprites needs ofcourse to have the same color independant of there they are on the screen:) since I use Timer B I can't use Blitter for the sprites I draw on the visible part of the area, even with bussharing it wouldn't work since I have to change the palette at the precis moment. I use the blitter to do that palette change to. It's abit slower than doing it in software, but I can preset all registers BEFORE the change and then do the blitter call the first thing at the beginning of the scanline.

I haven't looked into any of the NFSR and that stuff on the blitter. I never really figured out how it work. I use sprites of the size 16xY, 32xY, 48xY and 64xY instead. I don't preshift them as from the tests I did, preshifting them was much slower than lettig the blitter do the shifting (since you have to draw 16 more pixels in X). I only draw in 3 bitplanes since I only have 8 colors for sprites.
I can then have 3 32x40 sprites drawn by the blitter plus the played who also is 32x40 and then the "bullet" that is 16x16.
After that I have to draw the world and all that. It gives me about 30% left after all graphics are drawn.

Doing a game for just 25fps would be so much easier. Then I could spend time on double buffering and don't have to save/restore anything for the sprites and that would ofcourse lead to many more sprites on the screen at the same time. A 25fps game is good enought, but there is ofcourse always something special with 50fps:)

[Frank B]

Well, Im doing a platform game, somthing like Turrican and I can't use double buffering since I use hardware scrolling on the world.

Hi. Thanks for the reply. This is an interesting thread* I'm still a bit confused though. Why can't you double buffer because you're using hardware scrolling? Is it because of the memory requirements? If your playfield is really huge I can understand why you're doing it Are you writing a mapper or scrolling around a large virtual playfield? You might need to use two restore lists and swap them as you double buffer. I'd be careful about using the blitter from an interrupt and also in your main code. You might run into crashes because you interrupt it mid way through setting it up for another blit. :0

Frank

*be sure and post a vid or prg when you're done

[Frank B]

Have a look at this doc. http://aminet.net/package/dev/asm/8wayscroller
It's for the Amiga but it's applicable for the STe too.
The Y wrap trick is quite clever and can be done with time b. It might save you loads of memory.

Frank

[Zamuel_a]

I made a real 8 way scroller that only uses a buffer twice the size of a screen so its'a a 640x400 playfield and by drawing copies of the new tiles on the opposite site of the scroll direction I can have a virtual unlimited playing area without using more memory. To use double buffer you need to redraw the entire screen every time or else it doesnt give you anything really. You would still have to restore/save the data for the sprites. I would have to draw everything twice if I used a double buffer system, since I only draw 1/16 of the tile data for every frame. So if I used a double buffer in the normal way I would draw some lines on one buffer and then some on the next, wich is ofcourse useless. I would have to draw the same data to both buffers then instead and use twice the processor power for the scroller (wich isn't that bad really since I scroll 8 way in just about 10% mpu time). The only thing you gain by a double buffer would be that you can draw sprites there ever you want and not just in the borders, but the Timer B interrupt would prevent me from using the blitter at all then I now don't know there I am on the screen.
By doing it the way I have it now, I have a very precis measurement of the cycles used. I know that I will ALWAYS get 30% mpu power left for game logic and all that, independant if I have zero sprites on screen or 10 of them.
I will count the amount of cycles a sprite needs so then I make up a list of all sprites to draw for a current frame I can add all the spritecycles together to see if it fits in the time I get in the border or not. If I tries to draw outside the border it messes up the Timer B routine since it's now in the visible area of the screen so I have to check that I don't draw to much. What to do if I find that I want to draw more sprites than allowed is another thing I have to think about. I could just ignore them so the sprites that takes to much time wont be drawn at all. That isn't so good from a game point of view, but it' would be a safety feature for the game engine itself. I just think that I have be carefull then I make the levels so I tries to never have to many sprites at once.
The other thing that can solve the problem and the way I think about to do it is to multiplex the sprites so I alternate between the sprites that goes outside the "legal cyle" amount, just like the NES does it. You get flicker ofcourse, but can still display all sprites at the same time. I still think I have to be carefull with the leveldesign but if I would get more thant allowed sprites on screen it will still display it. I could always make a priority list so that some sprites get's drawn first, like enemies and then stuff like enemy fire get's drawn last. So if I need to multiplex them it would mostly be the enemy fire that flickers and so on.

I think about doing a Metroid like game. With just one big level (but several sub areas) that you walk around in and not like Turrican with independant levels. In Metroid there it's so many enemies at screen at once, so it wouldn't be so graphic intensive. But it's still a long way to go before Im there:)

[Zamuel_a]

Have a look at this doc. http://aminet.net/package/dev/asm/8wayscroller
It's for the Amiga but it's applicable for the STe too.
The Y wrap trick is quite clever and can be done with time b. It might save you loads of memory.

Frank

Take a look at this thread:
viewtopic.php?f=16&t=12961

This is the type of 8 way scroller I'm doing and it's real fast to.

[Zamuel_a]

Use NFSR and align your source data on a 16 bit boundry. You can still use the shifting on the blitter but you save 4 cycles per plane per line when blitting. Ie don't bother leaving 16 pixels at the side to shift into.

I'm not really sure about how the NFSR works but it sounds interessting, if someone knows how I should do it? My sprites are all 16 or 32 pixel wide. Is there a easy way to make 24 pixel wide sprites. I guess you have to use the NFSR or FXSR register for that?

[Frank B]

Use NFSR and align your source data on a 16 bit boundry. You can still use the shifting on the blitter but you save 4 cycles per plane per line when blitting. Ie don't bother leaving 16 pixels at the side to shift into.

I'm not really sure about how the NFSR works but it sounds interessting, if someone knows how I should do it? My sprites are all 16 or 32 pixel wide. Is there a easy way to make 24 pixel wide sprites. I guess you have to use the NFSR or FXSR register for that?

To use a sprite size not divisible by 16 you can use the LWM. I set them anyway each time I draw a bob. If the bob is 32 pixels, starts on a multiple of 16 and the shift is four the fwm is set to %0000 1111 1111 1111, the lwm is %1111 1111 1111 0000.
Since I need a word for shifting into a 32 pixel sprite is really 48 pixels in size. As the source sprite starts on a multiple of 16 you can see the source width is 32 pixels (2 words) but the destination is 48 (3 words). So you don't need to read the last word of the source.
This is what NFSR does. The source isn't fetched on the shift word since it's unused. You need to adjust your src y inc for this too. Bitblit is a function which can take a srcx, srcy, dstx, dsty, width, height. The source may span more/less words than the dest and the dest may span more/less words than the source. So you might need to read more than you write and write more than you read. That's what this feature is for.

Hope this helps.

Frank

[Frank B]

Use NFSR and align your source data on a 16 bit boundry. You can still use the shifting on the blitter but you save 4 cycles per plane per line when blitting. Ie don't bother leaving 16 pixels at the side to shift into.

I'm not really sure about how the NFSR works but it sounds interessting, if someone knows how I should do it? My sprites are all 16 or 32 pixel wide. Is there a easy way to make 24 pixel wide sprites. I guess you have to use the NFSR or FXSR register for that?

[Zamuel_a]

Ah ok, thanks. I have to look into it. Usually a size of 16,32,48,64 is good enough, but a sprite width of 24 might be a good one. Now then I save/restore the background I have to copy 48 pixels for a 32 pixel wide sprite, since the sprite is shifted and not on a 16 pixel alignment and all that. Is there a way to just copy 32 pixels instead? I guess it doesn't since I would have to "shift" the source data and not the destination data, but perhaps there is a way by using the NFSR and FXSR for that? I would save some memory

[Tomchi]

Many crap games on ST use even 3 VBLs....

Damn I just realised that the mighty xenon 2 uses 3 vbl ...

[Zamuel_a]

I have got most of the sprite routines working now. I even have a multiplexer function so if I tries to draw more sprites than the time in the border let's me do it multiplex the sprites so the time fit in the border. You get flicker, but atleast the sprite gets on the screen. I will try and create a game so that the sprite count always should fit in the border, but in some cases then perhaps it won't atleast the sprite gets on the screen.
I used to organize the sprite data so that you don't need the ADD for the source address between the different bitplanes. There are another topic here about that optimizing "trick", but I noticed that you get some bad side effects on that. You can't change the height of the sprite by changing the LINE register for the blitter since the data is all mixed. I guess it doesn't matter if you have normal sprites on the screen, but I have to clip my sprites on the screen borders and that is impossible then you have the sprite data all mixed so I had to go back to the usual method there you have to make a ADD 2,srcaddress between all the bitplanes, but removing a couple of ADDs aren't improving anything compared to the blitter time itself.
I can clip the sprits in Y without problem but in X seems to be impossible. I think I have to "preclip" the sprites instead and cheat by drawing the sprite on screen, but with different "preclip" data, like then you preshift.

[leonard]

>32x40 with 16 colours is a big sprite for ST/STE - look on most of the ST games and you will see that the sprites are normally smaller! (with exception of games >with only few sprites - here we are back on IK+ )

yes you're right. If you want to see "big sprite" look at the nostalgic-o-demo mainmenu ! The sprite is 64*80 pixels high, with a fullscreen multi-directional scroller!

Of course the sprite routine is preshifted. The fastest non cliped preshifted sprite routine is made like this: you have to read the screen, and do the sprite on registers,n then write the new data to the screen. Basically:

movem.l (a0),d0-d7 ; a0 is the screen
and.l (a1),d0
and.l (a1)+,d1
or.l (a1)+,d0
or.l (a1)+,d1
...
and.l (a1),d6
and.l (a1)+,d7
or.l (a1)+,d6
or.l (a1)+,d7
movem.l d0-d7,(a1)
lea 230(a1),a1

and if you want to backup the back buffer, just add push to a custom stack:

movem.l (a0),d0-d7 ; a0 is the screen
movem.l d0-d7,-(a2) ; store the backbuffer screen to restore the background later
and.l (a1),d0
and.l (a1)+,d1
or.l (a1)+,d0
or.l (a1)+,d1

[Zamuel_a]

Yes I first made a software sprite routine that looked about the same as what you wrote with background save/restore. But then I noticed that it didnt work out so good. Since you save the background at the same time you draw the new data you might also save sprites that are "under" you if you have overlapping sprites. My sprite routine (blitter + software) is first restoring the background for ALL sprites, then save the background for ALL sprites and then draw all sprites. Then I never get any problem with overlapping sprites.
It's abit easier to program a demo then you don't have to think about all cases that will occur in a game:)

[p01]

I haven't fiddled much with the special features of the STE, so sorry if I'm saying bulls, but Zamuel_a are you sure you need to clip the sprites horizontally at all ? I thought it was possible to set the number of words per line on STE ? Then, if it is possible, virtually make the screen a larger ( by as many pixels as your widest sprite ) and skip the clipping X altogether.

[leonard]

Yes I first made a software sprite routine that looked about the same as what you wrote with background save/restore. But then I noticed that it didnt work out so good. Since you save the background at the same time you draw the new data you might also save sprites that are "under" you if you have overlapping sprites. My sprite routine (blitter + software) is first restoring the background for ALL sprites, then save the background for ALL sprites and then draw all sprites. Then I never get any problem with overlapping sprites.
It's abit easier to program a demo then you don't have to think about all cases that will occur in a game:)

yes you're right if you have several sprites you should not interleave the save/restore background.

The routine is a bit more complex and it depends of your game configuration but if you have a lot of sprite overlaping, you may optimize the backup/restore process? A nice (but not optimal way) is to divie the screen into fixed sized square (say 16*16 pixels), and mark only block to save/restore. If you have a lot of overlaping, it may speed things a lot.

[Zamuel_a]

Normally I shouldn't have any overlapp since I won't have enemies over each other, but if they will overlap by some reason (they walk in each others way or somthing) I still want everything to work, but I don't plan to do a game with alots of enemies on screen at the same time so I think it will be ok. Right now I can have 3 32x40 sprites and 3 16x16 sprites on screen at the same time and it takes something like 45% processor time. All time in the border (39% processor time) is always reserved for the sprites independant of how many there are on screen. Since I never want the game (or can, since it would crash!) to go under 50fps I don't need to optimize it to go faster than the slowest part, so I have divied the processor time between all different parts in the game so every part is always taking the same amount of time.

I haven't fiddled much with the special features of the STE, so sorry if I'm saying bulls, but Zamuel_a are you sure you need to clip the sprites horizontally at all ? I thought it was possible to set the number of words per line on STE ? Then, if it is possible, virtually make the screen a larger ( by as many pixels as your widest sprite ) and skip the clipping X altogether.

Yes it's true, my screen is already larger than 160 bytes since I have a 8 way scroller so the only loss I get from making the screen larger is that I have to draw some more data, but it's not that much really. I haven't thought so much about how I will solve it yet.

[p01]

Great. Then you don't need to clip in X, your restore routine will clean the mess outside of the currently visible area, and the CPU time would be pretty stable which is something you're apparently looking for.

[Zamuel_a]

Yes I will look into it alittle bit more. The cpu time don't have to be stable, it's just that I can't gain anything from any extra time I get if I don't draw any sprites compared to draw as many as I can. But it would be stable and faster (since I don't have to increase the screen area) to preclip sprites to, just like preshifting I preclip them so they "clip" to the screens left and right edges. That takes ofcourse alittle bit more memory.