Just another Blitter demo

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Fri Sep 02, 2016 3:39 pm

dml wrote:So basically your method looks like the best *general case* method for something like games - which I think was your main criteria.

Yes, you're right. The problem is that many games are impressive just because of showing big animated sprites. So that's indeed the main reason why I wanted to have a fast sprite drawing routine with a small memory footprint.

Sadly the console/arcade sprite hardware is also able to flip them at no cost. It is quite simple to find a solution for vertically flipped sprites but you need twice as much memory for the horizontal flipped ones. Also you need a sprite mask which is in fact only one plane (i.e. one fourth of the sprite data) and gives you one more colour but it adds up to the memory consumption fast. Fortunately the RAM requirement for a game can be set to 4 MB since upgrading the mameory in the Atari STE is rather easy.

Do you have some performance numbers of your current generated sprite code?

BTW: I have another idea based on the ENDMASK technique but it seems that it is not as easy as expected but I hope it'll be useful when it works so stay tuned. :wink:

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Fri Sep 02, 2016 3:51 pm

Anima wrote:Do you have some performance numbers of your current generated sprite code?


Not quite yet - just the generated code itself. I'm still working on some weird optimizations to that, which turned out to be a nearly endless task for small to moderate gains. It's been interesting though, and have found some useful new stuff.

Anima wrote:BTW: I have another idea based on the ENDMASK technique but it seems that it is not as easy as expected but I hope it'll be useful when it works so stay tuned. :wink:


I will of course stay tuned :D

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Sat Sep 03, 2016 12:51 pm

Anima wrote:BTW: I have another idea based on the ENDMASK technique but it seems that it is not as easy as expected but I hope it'll be useful when it works so stay tuned. :wink:


BTW I just noticed something too. Will be fun to see if its the same thing or not :D

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Mon Sep 05, 2016 1:33 pm

So i was eventually able to test the generated blitter code and it works ok. Don't have any meaningful way to compare performance but I'm happy enough just now that it draws sprites properly. ;)

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: Just another Blitter demo

Postby leonard » Mon Sep 05, 2016 11:58 pm

I did a lot of generated blitter code in We Were @ demo, that's cool :) The endmask technic is nice and I play with it a bit in some non released code yet. Previous record seems to be 21 sprites here. Do you think you can do 22 with only end mask line re-ordering?
Leonard/OXYGENE.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Tue Sep 06, 2016 12:41 pm

leonard wrote:I did a lot of generated blitter code in We Were @ demo, that's cool :) The endmask technic is nice and I play with it a bit in some non released code yet. Previous record seems to be 21 sprites here. Do you think you can do 22 with only end mask line re-ordering?


Hi Leonard, yes I really enjoyed your entry - it was great work :) (we were both '@' that day on different platforms! :-)

I haven't really tried a comparison with Anima's version. I am mainly trying to optimize the game engine for certain classes of sprite (high simultaneous reuse). I could try to compare but I expect it should be faster simply because the functions are more specific. Anima's version is currently aimed to be general, low memory cost for game use so there's an extra constraint in place.

However for the nice round bob sprite, the difference might not be so big in practice, with 2x or better reuse of 50% of all scans (a lot more in the middle) Anima has already optimized the line order for that shape (I think?). For random sprites the specific one should be consistently faster though.

I find the memory overhead for the per-preshift code to be mostly ok. For 2-4mb STE its not an issue for a typical kind of game. With more animation and variety though it does start to add up so having both methods together is probably a good idea.... 8-)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Tue Sep 06, 2016 8:53 pm

Anima & Leonard,

I'm posting an early sample of the output from my sprite code generator. There are still a number of optimizations missing and some redundant reg loads left behind from the existing passes but it's getting close. You may notice some 'fun stuff' happening in there already if your eyes are very sharp ;-)

Since I'm outputting to a scrolling framebuffer much larger than 32k I've opted for long writes to DSTADDR. I can see a tricky way around this but won't bother with it just now as I need to move along quickly with other bits and pieces.

The code....

Code: Select all

 lea 5520(a1),a1        ;8
 move.l #$0fffc000,d3   ;12
 move.l d3,(a6)         ;12 [EM:2:3] ($0fffc000)
 clr.w d3       ;4
 move.w d3,(a2)         ;8 [EM:1] ($0000)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.l #$03ff0000,d4   ;12
 move.l d4,(a6)         ;12 [EM:2:3] ($03ff0000)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -5704(a1),a1       ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 lea 736(a1),a1 ;8
 swap d4        ;4 [$000003ff]
 move.b d1,(a5) ;8
 not.l d4       ;8 [$fffffc00]
 move.l d4,(a6)         ;12 [EM:2:3] ($fffffc00)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 4232(a1),a1        ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 suba.w d0,a1   ;8
 move.w #$0001,(a2)     ;12 [EM:1]
 move.w #$fe00,(a4)     ;12 [EM:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -3864(a1),a1       ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w #$0003,(a2)     ;12 [EM:1]
 move.w #$ff00,(a4)     ;12 [EM:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 368(a1),a1 ;8
 move.w #$0007,(a2)     ;12 [EM:1]
 move.w #$ff80,(a4)     ;12 [EM:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 2760(a1),a1        ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -552(a1),a1        ;8
 move.w #$001f,(a2)     ;12 [EM:1]
 move.w #$ffe0,(a4)     ;12 [EM:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -1656(a1),a1       ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 368(a1),a1 ;8
 move.w #$000f,(a2)     ;12 [EM:1]
 move.w d1,(a4)         ;8 [EM:3] ($ffc0)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 adda.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -2208(a1),a1       ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 suba.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -368(a1),a1        ;8
 move.w #$0003,(a2)     ;12 [EM:1]
 move.w #$ff00,(a4)     ;12 [EM:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 3312(a1),a1        ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 suba.w d0,a1   ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -3864(a1),a1       ;8
 move.l #$7ffff800,d6   ;12
 move.l d6,(a6)         ;12 [EM:2:3] ($7ffff800)
 move.w d3,(a2)         ;8 [EM:1] ($0000)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea 4600(a1),a1        ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 adda.w d0,a1   ;8
 and.w d0,d4    ;4 [$0000]
 move.b d1,(a5) ;8
 lsr.l #3,d4    ;12 [$1fffe000]
 move.l d4,(a6)         ;12 [EM:2:3] ($1fffe000)
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 lea -4968(a1),a1       ;8
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 suba.w d0,a1   ;8
 move.l #$0fffc000,(a6) ;20 [EM:2:3]
 move.w d2,(a0) ;8
 move.l a1,(a3) ;8
 move.b d1,(a5) ;8
 rts


The reordered deltas....


Code: Select all

deltas...
000000000000000000001111111111111100000000000000
................00000011111111110000000000000000
................................................
................11111111111111111111110000000000
................................................
0000000000000001................1111111000000000
................................................
0000000000000011................1111111100000000
0000000000000111................1111111110000000
................................................
0000000000011111................1111111111100000
................................................
................................................
................................................
................................................
................................................
................................................
................................................
................................................
................................................
0000000000001111................1111111111000000
................................................
................................................
................................................
0000000000000011................1111111100000000
................................................
................................................
000000000000000001111111111111111111100000000000
................................................
................00011111111111111110000000000000
................................................
................00001111111111111100000000000000

surviving datawords...
000000000000000000001111111111111100000000000000
----------------00000011111111110000000000000000
----------------11111111111111111111110000000000
0000000000000001----------------1111111000000000
0000000000000011----------------1111111100000000
0000000000000111----------------1111111110000000
0000000000011111----------------1111111111100000
0000000000001111----------------1111111111000000
000000000000000001111111111111111111100000000000
----------------00011111111111111110000000000000


The resulting sprite (mask) when simulated...

Code: Select all

debug simulation...
000000000000000000000011111111110000000000000000
000000000000000000001111111111111100000000000000
000000000000000000011111111111111110000000000000
000000000000000001111111111111111111100000000000
000000000000000011111111111111111111110000000000
000000000000000111111111111111111111111000000000
000000000000001111111111111111111111111100000000
000000000000001111111111111111111111111100000000
000000000000011111111111111111111111111110000000
000000000000111111111111111111111111111111000000
000000000000111111111111111111111111111111000000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000001111111111111111111111111111111100000
000000000000111111111111111111111111111111000000
000000000000111111111111111111111111111111000000
000000000000011111111111111111111111111110000000
000000000000001111111111111111111111111100000000
000000000000001111111111111111111111111100000000
000000000000000111111111111111111111111000000000
000000000000000011111111111111111111110000000000
000000000000000001111111111111111111100000000000
000000000000000000011111111111111110000000000000
000000000000000000001111111111111100000000000000
000000000000000000000011111111110000000000000000


User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: Just another Blitter demo

Postby leonard » Tue Sep 06, 2016 10:37 pm

dml wrote:we were both '@' that day on different platforms! :-)


really? sorry I didn't know how you looks like! What platform?
Leonard/OXYGENE.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Tue Sep 06, 2016 11:38 pm

leonard wrote:really? sorry I didn't know how you looks like! What platform?


Oh I didn't manage in person unfortunately (family stuff) - just entered remotely. My entry was the Falcon030 realtime-raytracing 64k thing at the start of the compo. (Well the music tipped it *slightly* over 64k in the end but that's another story! ;-)

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Wed Sep 07, 2016 8:32 am

dml wrote:Anima has already optimized the line order for that shape (I think?).

Yes, the drawing routine is optimised using line reordering. However, it does this for all different shifted masks for using less memory. So you definitely should see a performance gain when using Doug's sprite generator due to reducing the Blitter setup costs and the number of RMW cycles. Unfortunately in fact, the Blitter does a whole RMW process for each ENDMASK = 0 which is quite expensive.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Wed Sep 07, 2016 8:46 am

Anima wrote:Unfortunately in fact, the Blitter does a whole RMW process for each ENDMASK = 0 which is quite expensive.


I wondered about this, but wasn't sure. Pity they didn't optimize that case too...

I imagine though Leonard might be even *more* happy if the cost was constant for all cases ;-)

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Wed Sep 07, 2016 9:05 am

Thanks Doug.

dml wrote:Since I'm outputting to a scrolling framebuffer much larger than 32k I've opted for long writes to DSTADDR. I can see a tricky way around this but won't bother with it just now as I need to move along quickly with other bits and pieces.

How large is "much" larger? I think you know that you can use the word increment technique in the range of 64k but not only 32k, don't you? 64k is quite much when using the horizontal scrolling option, or did I get something wrong here?

Regarding the code you posted: the numbers behind the code is the cycle count for that instruction, isn't it? Isn't a long move slower than a byte move? So I suppose that you just replaced the word DSTADDR increment with a long instruction without changing the cycle count ("move.l a1,(a3) ;8")!?

Still pondering over the code... :coffe:

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Wed Sep 07, 2016 9:40 am

Anima wrote:How large is "much" larger? I think you know that you can use the word increment technique in the range of 64k but not only 32k, don't you? 64k is quite much when using the horizontal scrolling option, or did I get something wrong here?


Yes you're right that's true. In the current example/demo its only using H-scrolling and the buffer is under 64k so it would work ok - but the engine currently doesn't align playfield buffers and I'm just dropping the new sprite code in to test, so I'll have to stick with long writes until other changes are done there.

Also the playfield engine can be switched into 4/8-way mode for the other examples, which doubles the buffer size and then long writes are needed again. I will probably need a switch for the tool to decide which kind of code to generate in the end.

Anima wrote:Regarding the code you posted: the numbers behind the code is the cycle count for that instruction, isn't it? Isn't a long move is slower than a byte move? So I suppose that you just replaced the word DSTADDR increment with a long instruction without changing the cycle count ("move.l a1,(a3) ;8")!?


Yup - the cycle numbers next to some of the operations are stale - a bit distracting. These are just stuffed in the printfs for some instruction emits and suffered some c&p accidents - they will be replaced by the proper counts soon. :)

There are internal head/tail cycle counts which is being used by the transform passes and not shown in the listing yet.


Anima wrote:Still pondering over the code... :coffe:


I should post some more interesting examples later. There are definitely some really funny things happening in there from time to time :-)

I still need to add a pass which converts redundant register loads back to immediates if they didn't take part in a transform opportunity. This will save a few extra reads.

BTW I also was thinking about having the generated code create the sprite-restore records, which is normally done inside my old sprite routine anyway (but previously based on xcount/lineskip calculations). This amounts to a few constant writes so it should be another decent gain in my case at least.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Wed Sep 07, 2016 10:25 am

If you want a slightly more entertaining case, have a look at this one....

where does it get EM=$00007000 and EM=$fffe0000 from? :-P

I'll add the final passes tonight - definitely losing cycles & words to the redundant loads. I might also try to combine your table-based address stepping method by opportunity, where resources allow it. This should kill off a bunch of the remaining lea's. I'll leave it there however and complete the clipping changes - will consider it 'good enough' for now. I definitely saw quite a big improvement in the game after switching over so: ++bonus points to you for highlighting the 32-wide EM sprite thing in the first place! :)


lea 736(a1),a1 ;8d
move.l #$000fffff,d3 ;12
move.l d3,(a2) ;12 [EM:1:2] ($000fffff)
move.w #$e000,(a4) ;12 [EM:3]
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
adda.w d0,a1 ;8
move.w d2,(a0) ;8
move.l a1,(a3) ;8
adda.w d0,a1 ;8
move.l d2,d4 ;4 [$ff000004]
move.b d1,(a5) ;8
asr.l #7,d4 ;12 [$fffe0000]
move.l d4,(a6) ;12 [EM:2:3] ($fffe0000)
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
lea -920(a1),a1 ;8
move.w #$fe00,d3 ;8
move.w d3,(a6) ;8 [EM:2] ($fe00)
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
suba.w d0,a1 ;8
move.w #$6000,(a6) ;12 [EM:2]
move.w d2,(a0) ;8
move.l a1,(a3) ;8
lea 1840(a1),a1 ;8
sub.b d1,d3 ;4 [$fe40]
move.b d1,(a5) ;8
muls.w d1,d3 ;70 [$00007000]
move.l d3,(a2) ;12 [EM:1:2] ($00007000)
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
suba.w d0,a1 ;8
move.l #$0001fe00,d6 ;12
move.l d6,(a2) ;12 [EM:1:2] ($0001fe00)
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
suba.w d0,a1 ;8
move.w #$ff80,(a6) ;12 [EM:2]
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
suba.w d0,a1 ;8
move.w #$fff0,(a6) ;12 [EM:2]
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
lea -920(a1),a1 ;8
move.l #$0007ffc0,d7 ;12
move.l d7,(a2) ;12 [EM:1:2] ($0007ffc0)
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
adda.w d0,a1 ;8
move.w #$fffc,(a6) ;12 [EM:2]
move.w d2,(a0) ;8
move.l a1,(a3) ;8
move.b d1,(a5) ;8
rts

[EDIT]

BTW I think I'll give my own blitter-SLABS technique (left-justified skewed spans) the same codegen treatment a bit later. Its difficult to clip those objects horizontally even without codegen and they are too large to animate in a trivial way - so might as well save the wasted cycles on span setups. Vertical clipping is still possible with some hackery...

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: Just another Blitter demo

Postby leonard » Thu Sep 08, 2016 7:32 pm

dml wrote:Oh I didn't manage in person unfortunately (family stuff) - just entered remotely. My entry was the Falcon030 realtime-raytracing 64k thing at the start of the compo.


Oh that was you! Congratulations, I really like that demo and the rendering pattern!
Leonard/OXYGENE.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Just another Blitter demo

Postby dml » Sat Sep 10, 2016 7:38 pm

leonard wrote:Oh that was you! Congratulations, I really like that demo and the rendering pattern!


Thanks Leonard, appreciated! :)

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Wed Oct 26, 2016 8:01 pm

Some numbers about the Amiga Blitter performance. Check out this JSFiddle to see how many Bobs can be displayed in one frame on the Amiga. So on a 320 x 200 screen with four bitplanes the maximum number of 32 x 32 per 50 Hz frame is about 22.8.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2063
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Just another Blitter demo

Postby calimero » Thu Oct 27, 2016 4:28 pm

^ So it is faster than ST blitter?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Thu Oct 27, 2016 5:00 pm

calimero wrote:^ So it is faster than ST blitter?

Yes, it is and it always was. :wink:

However, please note that the theoretical maximum number of Bobs depends heavily on other DMA consuming devices. So for example when you are choosing a height of 256 pixels the maximum number is only 20.7 Bobs.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2063
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Just another Blitter demo

Postby calimero » Thu Oct 27, 2016 5:08 pm

but than again, it is faster by... 5% ? :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Thu Oct 27, 2016 5:22 pm

calimero wrote:but than again, it is faster by... 5% ? :)

If so just add sound! ;)

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 846
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Just another Blitter demo

Postby EvilFranky » Thu Oct 27, 2016 5:23 pm

4.78% I think :)

Based off Anima's 21 sprites...

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2063
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Just another Blitter demo

Postby calimero » Thu Oct 27, 2016 5:30 pm

but Amiga has 8 sprites?

they can be used freely beside (in parallel with) blitter bobs?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
Cyprian
Atari God
Atari God
Posts: 1404
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Just another Blitter demo

Postby Cyprian » Thu Oct 27, 2016 8:41 pm

Anima wrote:
calimero wrote:^ So it is faster than ST blitter?

Yes, it is and it always was. :wink:

not exactly.
in some cases faster in some slower.
e.g clearing/filling is much faster on the STE, masking sprites are faster on amiga
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Fri Oct 28, 2016 8:38 am

calimero wrote:but Amiga has 8 sprites?

they can be used freely beside (in parallel with) blitter bobs?

Not freely: adding eight sprites to the scene will further reduce the number of Bobs to about 18. You also have to combine two of them to have 15 colours available for each 16 pixel wide sprite so there are only four sprites left.

Cyprian wrote:[...]not exactly.
in some cases faster in some slower.
e.g clearing/filling is much faster on the STE, masking sprites are faster on amiga

Do you know the cycle numbers for clearing? I thought it was 4 cycles on both Blitters...

Edit: now I know what you mean: because the CPU is clocked at 8 MHz makes the Atari Blitter faster. :wink:


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests