16 July 2017, 17:47 | #1 |
Banned
Join Date: May 2017
Location: Paris
Posts: 39
|
Generated code for sprites
As a (lazy) ARM coder I have developed what I believe is a good 'generated code sprites' generator.
I would like to know which solutions you chose on the Amiga. My technique and ideas are described here : http://www.stardot.org.uk/forums/vie...ilit=generated Mode 13 is the 320 x 256, 8 bits per pixel screen mode on the Acorn Archimedes. Thanks for your comments, it will be highly appreciated. I think I have re invented the wheel and it has all been done already on the Amiga ; but if, who knows, that wasn't the case, I would be more than happy to give even more details to some programmers out there to port the technique to the Amiga. |
16 July 2017, 18:54 | #2 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,551
|
Didn't read everything, but on the Amiga you will rarely generate "Sprites" with the CPU. Either you use the Blitter or hardware sprites.
But when using the Blitter it might in fact also be advantageous to select an interleaved bitplane format, to write them with a single Blitter-start. |
17 July 2017, 01:24 | #3 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
You'll have to go to an Atari forum if you want to discuss precompiled sprites. That's their domain.
|
17 July 2017, 09:16 | #4 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
This would obviously have been a rare thing on the Amiga, since we weren't as lucky as you Archimedes users who had real chunky-mode graphics right from the start (IIRC), but there is a thread on this somewhere in the forums.
|
17 July 2017, 10:16 | #5 | |
BiO-sanitation Battalion
Join Date: Jun 2017
Location: Scotland
Posts: 152
|
Quote:
B |
|
17 July 2017, 12:38 | #6 | |
Banned
Join Date: May 2017
Location: Paris
Posts: 39
|
Quote:
I do not know to which extent it is or not true, but if it is, I thought, humbly as you saw I wrote from the very beginning, that it could be great to exchange ideas and share the algorithms used. Now, of course, if the interest of this thread is annihilated by thieves like the delusional G and his juvenile behaviour, it'll be hard to do anything constructive. |
|
17 July 2017, 13:29 | #7 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
|
18 July 2017, 18:08 | #8 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,551
|
Quote:
Quote:
|
||
20 July 2017, 19:09 | #9 |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
There is a possibility on 68020+ CPUs to use bitfield instructions to plot out graphics data in planar format with BFEXTU/BFINS. With them you can place out up to 32 pixels with a single instruction in a single bitplane. You get pixel precision shifts like with blitter, but instead of working with 16 bit data, bitfields are 32 bit wide. Transparencies in objects are more limited than with blitter though as there is no mask data. Haven't seen anyone using bitfields to plot out CPU graphics objects though on the Amiga, but I made a small routine, and it does actually work.
|
20 July 2017, 20:22 | #10 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,674
|
Here is the current realtime Amiga OCS record for 17x17px "sprites".
Records are mostly silly and special-cased, and don't translate well across platforms. The best way to find out if yours is the best is if you can see if someone wants to compete with you on your platform on agreed terms. Zarchos, you will have to find a way to discuss this without resorting to personal attacks, or there's a risk the thread will be closed. |
21 July 2017, 10:36 | #11 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Thread has been cleaned.
Zarchos and Galahad; we are all getting really bored of this. Again, this stops now!!! |
21 July 2017, 14:44 | #12 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,438
|
Quote:
I don't know if these instructions are particularly fast or slow, but this should make soft-blitting easier than using seperate rotates/logic operators etc. |
|
22 July 2017, 20:40 | #13 | |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
Quote:
On a 68030 a BFINS is 12-18 clock cycles (depends on shift length, as field can overlap two longwords in memory), and source operand must be datareg. In the graphics case one can optimize away the BFEXTU with a move + shift, it will be faster. Generally, the idea with BFEXTU/BFINS pair is that you can pick up from memory a bitfield within a 32-bit memory location and write it into a dataregister with BFEXTU. It will erase datareg, and place fielddata into it with correct alignment to LSB, and you can easily manipulate the value further. From there you can write it out again with BFINS with a different shift into another 32-bit memory location. That way it is easy to deal with bitdata of various sizes within a longword and manipulate this data without also trashing nearby data when writing it out. Good news is that bitfields will work faster with newer CPUs, on a 68060 it will be fast, and on the new Apollocore 68080 a bitfield operation is just 1 clock cycle. Will work pretty well with planar graphics modes. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Some sprites | Frog | project.Sprites | 6 | 22 August 2022 20:01 |
Generated code and CPU Instruction Cache | Mrs Beanbag | Coders. Asm / Hardware | 11 | 23 May 2014 11:05 |
Games with generated levelcodes | Joe Maroni | Nostalgia & memories | 12 | 24 February 2013 01:23 |
Where are all the sprites? | Gambit37 | project.Sprites | 8 | 14 October 2005 14:49 |
3D code and/or internet code for Blitz Basic 2.1 | EdzUp | Retrogaming General Discussion | 0 | 10 February 2002 11:40 |
|
|