[Coco] Let's figure out the best method to compile sprites for the CoCo - Please add your input
Steve Strowbridge
ogsteviestrow at gmail.com
Sat May 13 13:27:32 EDT 2017
This would make a great episode for a CoCo TALK in the near future, I'm
going to bring up the topic today, but it would be great to have a panel of
some of you experts on the call, and the ability to visually demonstrate
some of these methods so people watching can fully grasp the concept.
Hit me up if interested, and even if you just want to be part of the verbal
discussion today, please join us, but I think this would make a great video
interview/presentation/discussion we we can align a few of you together to
make it happen, reach out and let me know!
Steve Strowbridge, aka
The Original Gamer Stevie Strow
http://ogsteviestrow.com
ogsteviestrow at gmail.com
On Sat, May 13, 2017 at 8:00 AM, Steve Bamford via Coco <
coco at maltedmedia.com> wrote:
> [just noticed I hit reply, not reply all, so resending] :(
>
> I'm not so much short of memory as keen to cram in as many fun elements as
> possible. :)
>
>
> Pre-shifted sprites are working pretty well performance-wise. I strike a
> memory/performance balance by shifting and mirroring some sprite data into
> a common buffer only when it's required and overwrite it as necessary.
>
>
> The lookup table suggestion is a interesting idea but wouldn't pay
> dividends in my situation.
>
> I'm not that experienced at coding but I don't think there is a single
> best method for drawing sprites. The trade-offs are going to be different
> from game to game but being aware of a broad range of techniques definitely
> leads to better tailored solutions.
>
> On a general related note, I find thinking about how data is stored can
> lead to efficiencies when it comes to processing sprites etc.
>
> Cheers,
> Steve.
>
> From: msmcdoug <msmcdoug at iinet.net.au>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Cc: Steve Bamford <stevecindybamford at yahoo.co.uk>
> Sent: Saturday, 13 May 2017, 11:28
> Subject: Re: [Coco] Let's figure out the best method to compile sprites
> for the CoCo - Please add your input
>
> If you're running out of space but your sprites are plenty fast enough
> you can use lookup tables for shifted bytes rather than store shifted
> sprites. Slower of course, but maybe fast enough.
>
> Sent from my Samsung GALAXY S5
>
> -------- Original message --------
> From: Steve Bamford via Coco <coco at maltedmedia.com>
> Date: 13/05/2017 7:56 PM (GMT+10:00)
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Cc: Steve Bamford <stevecindybamford at yahoo.co.uk>
> Subject: Re: [Coco] Let's figure out the best method to compile sprites
> for the CoCo - Please add your input
>
> Hi Glen.
> I haven't gone down the compiled sprite route as I'm fine for performance
> but limited on memory.
> My game features a lot of sprites which are pre-shifted for speed but less
> than 32k of Ram to squeeze the whole game into. That said it's working out
> pretty well and the game runs smoothly at 60Hz.
> I should add this is a Dragon/CoCo2 game so the graphics mode will differ
> from what you're using.
> Cheers,Steve.
>
> From: Glen Hewlett <glen.hewlett at sympatico.ca>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Saturday, 13 May 2017, 1:22
> Subject: Re: [Coco] Let's figure out the best method to compile sprites
> for the CoCo - Please add your input
>
> Hi Steve,
>
> Are you talking about regular stack blasting? Where you do a PULS & PSHU
> then move U to the next line? That is what I was using for my sprites
> originally. Then I found compiled sprites are faster. Now I’ve kind of
> combined them both the code is super fast and short. This is an example of
> simple 8 x 8 sprite of a Pac Man Power Pill (which has a lot of repeated
> data). In my case it needs to be 5 bytes long (shifted one pixel) so it’s
> actually 10x8
> 444AAAA444
> 44AAAAAA44
> 4AAAAAAAA4
> 4AAAAAAAA4
> 4AAAAAAAA4
> 4AAAAAAAA4
> 44AAAAAA44
> 444AAAA444
> Stack Blasting version: Cycles = 238, bytes = 40 the bytes are from the
> original sprite data to be copied from, the code below can be reused for
> all the sprites that are the same size so I won’t count that FYI it is 76
> bytes
> 7D40 10FF7D8C (pacman_6809_Main_):09388 [7] 7 STS
> Temp1
> 7D44 10CE7D8E (pacman_6809_Main_):09389 [4] 11 LDS
> #PowerPillData
> 7D48 3384 (pacman_6809_Main_):09390 [4+0] 15
> LEAU ,X
> 7D4A 33C90385 (pacman_6809_Main_):09391 [4+4] 23
> LEAU 5+128*7,U
> 7D4E 351E (pacman_6809_Main_):09392 [5+5] 33
> PULS D,DP,X
> 7D50 361E (pacman_6809_Main_):09393 [5+5] 43
> PSHU D,DP,X
> 7D52 33C885 (pacman_6809_Main_):09394 [4+1] 48
> LEAU -123,U
> 7D55 351E (pacman_6809_Main_):09395 [5+5] 58
> PULS D,DP,X
> 7D57 361E (pacman_6809_Main_):09396 [5+5] 68
> PSHU D,DP,X
> 7D59 33C885 (pacman_6809_Main_):09397 [4+1] 73
> LEAU -123,U
> 7D5C 351E (pacman_6809_Main_):09398 [5+5] 83
> PULS D,DP,X
> 7D5E 361E (pacman_6809_Main_):09399 [5+5] 93
> PSHU D,DP,X
> 7D60 33C885 (pacman_6809_Main_):09400 [4+1] 98
> LEAU -123,U
> 7D63 351E (pacman_6809_Main_):09401 [5+5] 108 PULS
> D,DP,X
> 7D65 361E (pacman_6809_Main_):09402 [5+5] 118 PSHU
> D,DP,X
> 7D67 33C885 (pacman_6809_Main_):09403 [4+1] 123 LEAU
> -123,U
> 7D6A 351E (pacman_6809_Main_):09404 [5+5] 133 PULS
> D,DP,X
> 7D6C 361E (pacman_6809_Main_):09405 [5+5] 143 PSHU
> D,DP,X
> 7D6E 33C885 (pacman_6809_Main_):09406 [4+1] 148 LEAU
> -123,U
> 7D71 351E (pacman_6809_Main_):09407 [5+5] 158 PULS
> D,DP,X
> 7D73 361E (pacman_6809_Main_):09408 [5+5] 168 PSHU
> D,DP,X
> 7D75 33C885 (pacman_6809_Main_):09409 [4+1] 173 LEAU
> -123,U
> 7D78 351E (pacman_6809_Main_):09410 [5+5] 183 PULS
> D,DP,X
> 7D7A 361E (pacman_6809_Main_):09411 [5+5] 193 PSHU
> D,DP,X
> 7D7C 33C885 (pacman_6809_Main_):09412 [4+1] 198 LEAU
> -123,U
> 7D7F 351E (pacman_6809_Main_):09413 [5+5] 208 PULS
> D,DP,X
> 7D81 361E (pacman_6809_Main_):09414 [5+5] 218 PSHU
> D,DP,X
> 7D83 8600 (pacman_6809_Main_):09415 [2] 220 LDA
> #DirectPage/256
> 7D85 1F8B (pacman_6809_Main_):09416 [6] 226 TFR
> A,DP
> 7D87 10FE7D8C (pacman_6809_Main_):09417 [7] 233 LDS
> Temp1
> 7D8B 39 (pacman_6809_Main_):09418 [5] 238 RTS
>
> Regular compiled sprite code (many methods can be used for this, and
> optimized a little more): Cycles = 199, bytes = 104
> 7C93 3005 (pacman_6809_Main_):09310 [4+1] 5 LEAX
> 5,X
> 7C95 CC444A (pacman_6809_Main_):09311 [3] 8 LDD
> #$444A
> 7C98 ED1B (pacman_6809_Main_):09312 [5+1] 14 STD
> -5,X
> 7C9A CCAAA4 (pacman_6809_Main_):09313 [3] 17 LDD
> #$AAA4
> 7C9D ED1D (pacman_6809_Main_):09314 [5+1] 23 STD
> -3,X
> 7C9F C6AA (pacman_6809_Main_):09315 [2] 25 LDB
> #$AA
> 7CA1 ED887C (pacman_6809_Main_):09316 [5+1] 31 STD
> 124,X
> 7CA4 C644 (pacman_6809_Main_):09317 [2] 33 LDB
> #$44
> 7CA6 E71F (pacman_6809_Main_):09318 [4+1] 38 STB
> -1,X
> 7CA8 E7887B (pacman_6809_Main_):09319 [4+1] 43 STB
> 123,X
> 7CAB ED887E (pacman_6809_Main_):09320 [5+1] 49 STD
> 126,X
> 7CAE 30890100 (pacman_6809_Main_):09321 [4+4] 57
> LEAX 256,X
> 7CB2 C6A4 (pacman_6809_Main_):09322 [2] 59 LDB
> #$A4
> 7CB4 ED1E (pacman_6809_Main_):09323 [5+1] 65 STD
> -2,X
> 7CB6 ED887E (pacman_6809_Main_):09324 [5+1] 71 STD
> 126,X
> 7CB9 C6AA (pacman_6809_Main_):09325 [2] 73 LDB
> #$AA
> 7CBB ED1C (pacman_6809_Main_):09326 [5+1] 79 STD
> -4,X
> 7CBD ED887C (pacman_6809_Main_):09327 [5+1] 85 STD
> 124,X
> 7CC0 864A (pacman_6809_Main_):09328 [2] 87 LDA
> #$4A
> 7CC2 A71B (pacman_6809_Main_):09329 [4+1] 92 STA
> -5,X
> 7CC4 A7887B (pacman_6809_Main_):09330 [4+1] 97 STA
> 123,X
> 7CC7 30890100 (pacman_6809_Main_):09331 [4+4] 105 LEAX
> 256,X
> 7CCB ED1B (pacman_6809_Main_):09332 [5+1] 111 STD
> -5,X
> 7CCD ED887B (pacman_6809_Main_):09333 [5+1] 117 STD
> 123,X
> 7CD0 86AA (pacman_6809_Main_):09334 [2] 119 LDA
> #$AA
> 7CD2 ED1D (pacman_6809_Main_):09335 [5+1] 125 STD
> -3,X
> 7CD4 ED887D (pacman_6809_Main_):09336 [5+1] 131 STD
> 125,X
> 7CD7 C6A4 (pacman_6809_Main_):09337 [2] 133 LDB
> #$A4
> 7CD9 E71F (pacman_6809_Main_):09338 [4+1] 138 STB
> -1,X
> 7CDB E7887F (pacman_6809_Main_):09339 [4+1] 143 STB
> 127,X
> 7CDE 30890100 (pacman_6809_Main_):09340 [4+4] 151 LEAX
> 256,X
> 7CE2 C644 (pacman_6809_Main_):09341 [2] 153 LDB
> #$44
> 7CE4 ED1E (pacman_6809_Main_):09342 [5+1] 159 STD
> -2,X
> 7CE6 E71B (pacman_6809_Main_):09343 [4+1] 164 STB
> -5,X
> 7CE8 E7887B (pacman_6809_Main_):09344 [4+1] 169 STB
> 123,X
> 7CEB C6AA (pacman_6809_Main_):09345 [2] 171 LDB
> #$AA
> 7CED ED1C (pacman_6809_Main_):09346 [5+1] 177 STD
> -4,X
> 7CEF 864A (pacman_6809_Main_):09347 [2] 179 LDA
> #$4A
> 7CF1 ED887C (pacman_6809_Main_):09348 [5+1] 185 STD
> 124,X
> 7CF4 CCA444 (pacman_6809_Main_):09349 [3] 188 LDD
> #$A444
> 7CF7 ED887E (pacman_6809_Main_):09350 [5+1] 194 STD
> 126,X
> 7CFA 39 (pacman_6809_Main_):09351 [5] 199 RTS
>
> Here is the new version using PSHU and the DP register: Cycles = 167,
> bytes = 69
> 7CFB 3384 (pacman_6809_Main_):09356 [4+0] 4 LEAU
> ,X
> 7CFD 33C90285 (pacman_6809_Main_):09357 [4+4] 12
> LEAU 5+128*5,U
> 7D01 CC4AAA (pacman_6809_Main_):09358 [3] 15 LDD
> #$4AAA
> 7D04 1F9B (pacman_6809_Main_):09359 [6] 21 TFR
> B,DP
> 7D06 8EAAA4 (pacman_6809_Main_):09360 [3] 24 LDX
> #$AAA4
> 7D09 361E (pacman_6809_Main_):09361 [5+5] 34
> PSHU D,DP,X
> 7D0B 33C885 (pacman_6809_Main_):09362 [4+1] 39
> LEAU -123,U
> 7D0E 361E (pacman_6809_Main_):09363 [5+5] 49
> PSHU D,DP,X
> 7D10 33C885 (pacman_6809_Main_):09364 [4+1] 54
> LEAU -123,U
> 7D13 361E (pacman_6809_Main_):09365 [5+5] 64
> PSHU D,DP,X
> 7D15 33C885 (pacman_6809_Main_):09366 [4+1] 69
> LEAU -123,U
> 7D18 361E (pacman_6809_Main_):09367 [5+5] 79
> PSHU D,DP,X
> 7D1A 33C885 (pacman_6809_Main_):09368 [4+1] 84
> LEAU -123,U
> 7D1D 8644 (pacman_6809_Main_):09369 [2] 86 LDA
> #$44
> 7D1F 8EAA44 (pacman_6809_Main_):09370 [3] 89 LDX
> #$AA44
> 7D22 361E (pacman_6809_Main_):09371 [5+5] 99
> PSHU D,DP,X
> 7D24 33C90285 (pacman_6809_Main_):09372 [4+4] 107 LEAU
> 5+128*5,U
> 7D28 361E (pacman_6809_Main_):09373 [5+5] 117 PSHU
> D,DP,X
> 7D2A 33C90085 (pacman_6809_Main_):09374 [4+4] 125 LEAU
> 128+5,U
> 7D2E C64A (pacman_6809_Main_):09375 [2] 127 LDB
> #$4A
> 7D30 8EA444 (pacman_6809_Main_):09376 [3] 130 LDX
> #$A444
> 7D33 361E (pacman_6809_Main_):09377 [5+5] 140 PSHU
> D,DP,X
> 7D35 33C9FC85 (pacman_6809_Main_):09378 [4+4] 148 LEAU
> 5-128*7,U
> 7D39 361E (pacman_6809_Main_):09379 [5+5] 158 PSHU
> D,DP,X
> 7D3B 8600 (pacman_6809_Main_):09380 [2] 160 LDA
> #DirectPage/256
> 7D3D 1F8B (pacman_6809_Main_):09381 [6] 166 TFR
> A,DP
> 7D3F 39 (pacman_6809_Main_):09382 [5] 171 RTS
>
> On simple sprites like the PSHU can save a lot of cycles and bytes over
> the already fast compiled sprites. This one example went from 199 CPU
> cycles to 171 CPU cycles and the byte count went down from 104 to 69! If I
> setup U as my pointer ahead of time before I call the sprite routine I can
> remove the LEAU ,X instruction on the first line and save another 4
> cycles and two bytes.
>
> Another thing to think about could be the order of colours in the colour
> palette. The Power Pill sprite above uses $4 for black and $A for almost
> white in the palette table. If the black was changed to the value $B in
> the palette, then it might be possible to use INCA or INCB or DECA or DECB
> to save a byte and cycle if the accumulators can be changed in that way.
> It doesn’t seem to work with this sprite but it might for others. Just a
> thought...
>
> This is looking very interesting now. As always I’d love to hear if
> anyone has any other ideas for speeding up the sprite rendering.
>
> Cheers,
> Glen
>
> > On May 12, 2017, at 3:06 PM, Steve Bamford via Coco <
> coco at maltedmedia.com> wrote:
> >
> > This is exactly the technique I use for drawing sprites ie. PULing
> consecutive data bytes, (four bytes at a time), and drawing the sprite from
> bottom to top.
> >
> > This approach also works well when a character's origin is at their feet.
> >
> > From: Glen Hewlett <glen.hewlett at sympatico.ca>
> > To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> > Sent: Friday, 12 May 2017, 19:48
> > Subject: Re: [Coco] Let's figure out the best method to compile sprites
> for the CoCo - Please add your input
> >
> > Great idea Curtis!
> >
> > That’s definitely something else to add to the collection of ideas on
> how to create the smallest and fastest compiled sprites.
> >
> > Thanks for the input,
> > Glen
> >> On May 12, 2017, at 10:56 AM, L. Curtis Boyle <curtisboyle at sasktel.net>
> wrote:
> >>
> >> Since PSHing goes backwards in RAM, it might be more efficient to draw
> your sprite from bottom to top (better chance that your LEAU’s will be
> smaller), depending on the graphics mode you are using, and the width of
> the sprite.
> >>
> >> L. Curtis Boyle
> >> curtisboyle at sasktel.net
> >>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
More information about the Coco
mailing list