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: 654
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Just another Blitter demo

Postby Anima » Fri Sep 04, 2015 4:43 pm

Hey guys,

here's another Blitter demo for the Atari STE. It shows 15 bobs (32x32 pixels) on a background with 16 colours. Should work on the Atari Falcon as well.

Image
You do not have the required permissions to view the files attached to this post.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 901
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Just another Blitter demo

Postby Frank B » Fri Sep 04, 2015 5:57 pm

Nice one :) if I get some time I'm going to add some more stuff to mine too :)

Edit: had to flip it to 16 mhz to get it to work properly in hatari.

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

Re: Just another Blitter demo

Postby Anima » Fri Sep 04, 2015 6:16 pm

Frank B wrote:Edit: had to flip it to 16 mhz to get it to work properly in hatari.

Uh... which hatari version did you try it on? Works fine here on standard 8 MHz using hatari 1.8.0 (Windows).

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 901
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Just another Blitter demo

Postby Frank B » Fri Sep 04, 2015 7:01 pm

1.8 on the Mac

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

Re: Just another Blitter demo

Postby calimero » Fri Sep 04, 2015 7:14 pm

and how many 32x32 sprites did you manage to display Frank B? :) :angel:
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
Frank B
Atari Super Hero
Atari Super Hero
Posts: 901
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Just another Blitter demo

Postby Frank B » Fri Sep 04, 2015 7:27 pm

calimero wrote:and how many 32x32 sprites did you manage to display Frank B? :) :angel:



27 but it's not a fair comparison. Mine are 32 * 30 and not 32 * 32. Mine are also half the colour depth and the background is being cleared and not restored :) I have an older intro which does 31 IIRC with the same size, 30 with the teletype. I put the theoretical limit at 34 2 plane 32*30 bobs a frame on the STE.

I suspect the reload per line trick is being used here too? I'd recommend going bigger to get more out of it. 64 * 64? :)

Mine can be quite heavily optimised for set up time at the expense of maintainability.
Last edited by Frank B on Fri Sep 04, 2015 8:04 pm, edited 3 times in total.

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

Re: Just another Blitter demo

Postby calimero » Fri Sep 04, 2015 7:28 pm

And both are 50hz?
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
Frank B
Atari Super Hero
Atari Super Hero
Posts: 901
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Just another Blitter demo

Postby Frank B » Fri Sep 04, 2015 7:31 pm

calimero wrote:And both are 50hz?


Yes. In fact my older one runs from the VBL interrupt handler. If it doesn't run at 50 hz it dies :)

User avatar
lotek_style
Mod(ul)erator
Mod(ul)erator
Posts: 2372
Joined: Sat May 11, 2002 2:39 pm
Location: germany
Contact:

Re: Just another Blitter demo

Postby lotek_style » Sun Oct 11, 2015 2:47 pm

lotek style / the sirius cybernetics corporation
- musician - ascii-artist - swapper - archivist -

.tSCc. - low-tech atari cyberpunks since 1990
http://www.tscc.de/ | http://demozoo.org/ | http://www.lotekstyle.de/ | http://ymrockerz.atari.org/

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

Re: Just another Blitter demo

Postby calimero » Mon Oct 12, 2015 10:27 am

I just wonder: how much sprites could Amiga 500 display?
There are 8 (16pixels width) hardware sprites... but how much Amiga 500 could pull from blitter, cooper sprites... ?


btw
offtopic question: does Atari STe have dual playfields like Amiga?
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

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Just another Blitter demo

Postby DrTypo » Mon Oct 12, 2015 11:48 am

calimero wrote:btw
offtopic question: does Atari STe have dual playfields like Amiga?


No, the STE doesn't have a dual playfields mode.

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

Re: Just another Blitter demo

Postby Anima » Mon May 23, 2016 12:45 pm

Update: a new optimised version now displays 17 Blitter objects: :D
17 (32 x 32) Atari STE Blitter sprites in 16 colours on a 16 colour background at 50 Hz


User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Just another Blitter demo

Postby exxos » Mon May 23, 2016 12:51 pm

Anima wrote:Update: a new optimised version now displays 17 Blitter objects: :D


Very nice :)
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
Ragstaff
Atari Super Hero
Atari Super Hero
Posts: 610
Joined: Mon Oct 20, 2003 3:39 am
Location: Melbourne Australia
Contact:

Re: Just another Blitter demo

Postby Ragstaff » Mon May 23, 2016 2:05 pm

Nice work. I'm curious, after writing this demo has your opinion changed since you made this post? It looks like your blobs are 16 colours, which in my opinion would mean you beat dis (you did use the blitter, but yours and leonards opinion previously was that the CPU routine would be faster)
Last edited by Ragstaff on Mon May 23, 2016 2:07 pm, edited 1 time in total.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Just another Blitter demo

Postby shoggoth » Mon May 23, 2016 2:07 pm

Better than bacon!
Ain't no space like PeP-space.

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

Re: Just another Blitter demo

Postby Anima » Mon May 23, 2016 3:13 pm

Ragstaff wrote:Nice work. I'm curious, after writing this demo has your opinion changed since you made this post? It looks like your blobs are 16 colours, which in my opinion would mean you beat dis (you did use the blitter, but yours and leonards opinion previously was that the CPU routine would be faster)

Well, yes, I think "beat dis" can be beaten. However, the current approach aims for flexibility and is meant to be useful for game development. In fact, the routine is able to display 20 sprites without restoring the background (clear only), so it's already quite fast I guess.

Edit: clarify.

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 May 24, 2016 10:15 am

Hi!

I lost track of this thread after the first post, probably because I didn't post a comment at the time!

Anyway I'll just add that it's an excellent bit of work for STE/Falcon, and best of all - is actually really useful too :D, not a special case bodge.


Re: the game development bit - I've been trying to add a similar sprite method to my game prototyping stuff and it seems to be working now, but I more or less guessed how it should be done on STE and it's not clear I ended up with the same code as you - probably not as fast as yours currently. I did manage to implement a clipped version though which does 16,32 and 48 wide destinations (i.e. anything up to 32-wide source) so it works properly in my engine without having to bodge extra margins into the scrolling bit.

Anyway the most general case looks like this (below: per sprite scanline). I haver slight variations on it for the clipping cases since different EMs need loaded when the blitter xcount changes.

Code: Select all

.macro   scan_3w

   ; load plane count
   move.w      d2,(a0)
   ; load em1-em3
   move.l      (a6)+,(a2)
   move.w      (a6)+,(a4)
   ; load dst
   move.l      a1,(a3)
   ; go
   move.b      d1,(a5)
   ; next destination line
   add.w      d3,a1
   
   .endm



I decided that each scanline is short enough in terms of bus access to just use HOG mode without annoying interrupts. Which really helps. I imagine you've been doing that from the start also.

The 'obvious' optimizations I considered beyond this roughly look like this. I have no idea how many of these you have considered or are already using, but I'll chuck them out there anyway. I won't be trying them all and I'll probably keep to a low-as-possible memory footprint for now. Still, some should probably be worth a shot.

1) Use code generation to produce specific blits for each scanline of each sprite frame - allowing the endmask loads to be #imm moves (or from spare registers if it makes sense).

2) Combine deltas with (1), so you only modify EMs which have changed since the last scanline.

3) Combine scanline reordering with (1) and (2), to minimize the EM deltas (since the dest addr needs updated on each blit anyway - might as well reorder them?)

4) Calculate the framebuffer scanline (y) which contains the 16bit address carry (i.e. where the framebuffer_address & $0000FFFF == 0) and split the sprite into upper/lower half, then update only the 16bit part of the dest address register for all other blits. This would be a bit messy for me since each playfield contains the split in a different place, due to the margin sizes, funny alignment, scrolling etc. involved - but it is quite doable. Obviously its better to handle the splitting aspect inside the sprite routine vs calling the routine twice from above, but that should be ok I think.

5) For sprites with symmetry, blit-shift the scanline into the halftone memory first, then blit that scanline N times to different parts of the same sprite (more codegen, effectiveness very dependent on the sprite graphic, more blit state changes :-/ ). Not sure about this one tbh, but worth a mention.

6) Do the same as (5) but for different sprites using the same frame/graphic at the same shift offset. Unfortunately I can't find much use for this one, despite trying - async sprite animation and uncoordinated x positions don't result in enough reuse. You'd probably need 4+ sprites with the same frame and x&15 position to see much gain from it. But again that's mostly guesswork.

Anyway these were some of my random thoughts. If you feel like supporting or refuting any of it, I'll be interested. I'll need to cap the time I spend on sprite routines very soon to move onto other stuff but so far this method looks like a win on STE and was worth the trouble adding it.

Also: My agtcut tool now emits sprites in this format (for the kind of code above - data only, no codegen), given the right flags.

(I'll keep you updated if I notice anything else worth a mention)

:cheers:

User avatar
Ragstaff
Atari Super Hero
Atari Super Hero
Posts: 610
Joined: Mon Oct 20, 2003 3:39 am
Location: Melbourne Australia
Contact:

Re: Just another Blitter demo

Postby Ragstaff » Tue May 24, 2016 10:34 am

Anima wrote:Well, yes, I think "beat dis" can be beaten. However, the current approach aims for flexibility and is meant to be useful for game development. In fact, the routine is able to display 20 sprites without restoring the background (clear only), so it's already quite fast I guess.

I think you've already beaten it even at 17 sprites. The Sprites Demo claims 22 sprites at 32x32pixels, 3bpl eacj.... but reading the comments on pouet indicate the sprites are 2bpl, 32x31, it's only 3bpl in some parts of the screen (I guess where the scroller is).
You're are 4pbl, all over the screen, I think it's a better routine to be doing 17. Even more so with 20!
Anyway, I understand your primary goal was not to "beat dis", but to make a usable, practical routine for real-world use, but I was just curious as I'd read the other thread not long ago where yourself and Leonard thought that CPU routine was going to be quicker than anything the blitter could do.
Looks like you out did yourself, awesome work!

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

Re: Just another Blitter demo

Postby calimero » Tue May 24, 2016 10:50 am

17 sprites, 32x32px in size, are almost 1/3 of 320x200px screen! Quite impressive!
Is it possible to achieve same speed with, e.g. double smaller sprites but twice as much in count?
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: 654
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Tue May 24, 2016 2:13 pm

Ragstaff wrote:Anyway, I understand your primary goal was not to "beat dis", but to make a usable, practical routine for real-world use, but I was just curious as I'd read the other thread not long ago where yourself and Leonard thought that CPU routine was going to be quicker than anything the blitter could do.
Looks like you out did yourself, awesome work!

Thanks!

Well, that's probably a long story why I thought that a fully optimised CPU driven routine will always beat a Blitter approach (i.e. use as much memory as possible for precalculation). However, I think that any optimised Blitter sprite drawing routine is faster in pure raw drawing power. OTOH a CPU routine can make good profit from the sprite data itself. E.g. if you only need to draw two planes worth of data on certain lines so you can omit the drawing of the third plane. However, the CPU always has to fetch a "move" instruction for every operation which hurts the aforementioned optimisation.

Maybe I will check what is possible with an optimised Blitter routine in respect of the rules given.

dml wrote:Anyway I'll just add that it's an excellent bit of work for STE/Falcon, and best of all - is actually really useful too :D, not a special case bodge.

Thanks! That's really appreciated! :cheers:

dml wrote:Re: the game development bit - I've been trying to add a similar sprite method to my game prototyping stuff and it seems to be working now, but I more or less guessed how it should be done on STE and it's not clear I ended up with the same code as you - probably not as fast as yours currently. I did manage to implement a clipped version though which does 16,32 and 48 wide destinations (i.e. anything up to 32-wide source) so it works properly in my engine without having to bodge extra margins into the scrolling bit.

I saw your comment about the sprite routine in your Atari STE game development thread. I have to say your work and progress is really awesome and outstanding. Really great work.

I was also thinking about supporting the Atari STE regarding games development. Especially because it really deserves it so much but that's a different story.

dml wrote:Anyway the most general case looks like this (below: per sprite scanline). I haver slight variations on it for the clipping cases since different EMs need loaded when the blitter xcount changes.

Code: Select all

.macro   scan_3w

   ; load plane count
   move.w      d2,(a0)
   ; load em1-em3
   move.l      (a6)+,(a2)
   move.w      (a6)+,(a4)
   ; load dst
   move.l      a1,(a3)
   ; go
   move.b      d1,(a5)
   ; next destination line
   add.w      d3,a1
   
   .endm



:lol: You know what? That's exactly the same routine (except for the setup order) I am using for the general approach. :cheers:
In fact I actually don't care about clipping because I always use a virtual screen with a width of 512 bytes. It's also easier to calculate the Y coordinate (address) of the sprites.

But actually that's not the routine shown in the video. It has some kind of your additional optimisation ideas added, namely point 1 and 4. Not quite exactly the same but at least it uses the word destination address with appropriately aligned screen addresses. A special sprite drawing code has indeed been generated for this demo but it is only one sprite routine (instead of having one for each shifted mask) so the memory overhead per sprite is still quite small.

The idea was to reuse the line masks within the whole sprite to save the ENDMASK setup costs. But how can we reuse them without jumping to the right destination address? So far we only have a spare register for this ("add.w d3,a1"). Well, that's one of the "secrets" of this particular demo: it uses a table of delta values for the destination address calculation. In fact, that can be considered as a kind of mask compression. While the table increases the memory usage per sprite, the number of mask entries is reduced. So in conclusion the additional memory used for the generated sprite code is not that bad but is depends heavily on the sprite data.

The demo code looks like this:

Code: Select all

[...]
   ; 6
   
   move.l   (a2)+,(a0)+ ; Endmask 1 + 2.
   move   (a2)+,(a0) ; Endmask 3.
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add      (a1)+,a3

   ; 25
   
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add      (a1)+,a3

   ; 7
   
   move   (a2)+,(a0) ; Endmask 3.
   move.l   (a2)+,-(a0) ; Endmask 1 + 2.
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add.l   d4,a3

   ; 8
   
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add      (a1)+,a3

   ; 23
   
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add.l   d4,a3

   ; 24
   
   move   a3,(a4) ; Destination Address.
   move   d6,(a5) ; Y Count.
   move.b   d5,(a6) ; Busy, HOG, Smudge, Line Number.
   add      (a1)+,a3
[...]

As you can see, sprite lines indices #6 and #25 share the same mask and so the ENDMASK doesn't need to be set again. The offset to jump from index #6 to #25 is being fetched from the table ("add (a1)+,a3") . Also indices #7 and #8 share the same mask but are (obviously) consecutive lines where the regular constant can be used to calculate the new destination address. The good thing is that we don't need another entry in the offset table for this case.

The interesting part is that the new destination address calculation ("add.w (a1)+,a3") is not only being prefetched by the MC68000 but it will also be executed before the Blitter starts drawing due to the delayed operation. So that memory access is still "free". :wink:

I think it is still a good compromise between speed and memory consumption.

Any comment on this is appreciated.

:cheers:

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

Re: Just another Blitter demo

Postby Anima » Tue May 24, 2016 2:18 pm

calimero wrote:17 sprites, 32x32px in size, are almost 1/3 of 320x200px screen! Quite impressive!
Is it possible to achieve same speed with, e.g. double smaller sprites but twice as much in count?

Unfortunately this wouldn't work as expected. As a matter of fact the following rule is true: the bigger, or better: more "massive" a sprite is - the faster it can be drawn by the Blitter. :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 » Wed May 25, 2016 8:52 am

That's excellent. (I don't have time to reply properly now but will when I return...)

Cheers

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 » Wed May 25, 2016 10:14 am

Anima wrote:The interesting part is that the new destination address calculation ("add.w (a1)+,a3") is not only being prefetched by the MC68000 but it will also be executed before the Blitter starts drawing due to the delayed operation. So that memory access is still "free". :wink:

are you sure?
I did some tests in the past and "move.b" used for starting the BLiTTER newer allowed the CPU to execute next to "move.b" instruction.

I had a positive result when: 1) I used so called "Class 0" instructions for starting the BLiTTER; 2) I used a single word instruction after that "Class 0" instruction.

Ijor explained it with 68000 prefetch behavior (I guess that all its internal registers IRC/IR/IRD should be prefetched before an instruction is being executed)

btw. congrats great the BLiTTER sprite technique!
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: 654
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Just another Blitter demo

Postby Anima » Wed May 25, 2016 11:13 am

Cyprian wrote:
Anima wrote:The interesting part is that the new destination address calculation ("add.w (a1)+,a3") is not only being prefetched by the MC68000 but it will also be executed before the Blitter starts drawing due to the delayed operation. So that memory access is still "free". :wink:

are you sure?
I did some tests in the past and "move.b" used for starting the BLiTTER newer allowed the CPU to execute next to "move.b" instruction.

Thanks!

The only "proof" I have is that you can modify any Blitter register after starting it. That shouldn't work either if any memory access is blocked.

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

Re: Just another Blitter demo

Postby leonard » Wed May 25, 2016 12:45 pm

Anima wrote:Update: a new optimised version now displays 17 Blitter objects: :D


This is really nice code! I love sprites record :)

I though about exactly the same routine. I didn't write it but it's funny I though about reordering the mask data to use "move.l dn,(a0)+" and "'move.l dn,-(a0)" combined to keep using a0 only :) Exactly as the code you posted!

ragstaff wrote:I'd read the other thread not long ago where yourself and Leonard thought that CPU routine was going to be quicker than anything the blitter could do.


Since I wrote the "We Were @" demo, my opinion about blitter has changed a bit :) Blitter is efficient because you don't have instruction prefetching penalties. For 32*32 sprites, because of the "mask set each scanline" trick, I realize blitter is faster than CPU for 32*32. Maybe that's not the case for smaller sprites.

Anyway AMIGA blitter is still even better. It can run on 3 operands at once ( mask + or in a single pass ). I did an amiga sprite test long time ago, far from being optimized to death, but I just checked I put 36 sprites ( 32*31, 3 bitplans ). But It was on a amiga 1200 ( don't know if the blitter is running at the same speed on a plain amiga 500)

Could be interesting to know how many 32*31, 3pl sprites can run on an normal amiga 500.
Leonard/OXYGENE.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest