8bit-Dude

Hi Mozz! Are you still looking into this? I have been mulling something along the same lines myself for a while, I would be interested to bounce ideas together.

I could still fake it with a video, by running it on an Atari ST! ?

It's been a while since I last posted something... Check out these screenies from the "Aztec" and "Desert" maps:

Of course, but then the game would only work on the XE!

No I cannot. This games needs about 10K for the charset/tileset/charmap, about 5K for network code, and so on... I was already closed to maxxed out with the current implementation. I might perhaps try to generate those immediate loads / indirect addressing code blocks when setting the sprite.

Alright, after playing around with this for a while, I now understand how the engine can be so fast. Instead of just storing the sprite bytes and transferring them by indirect addressing, it relies on lists of immediate loads (like lda #0) followed by absolute,X stores (like sta $C600+0,x). This saves quite a bunch of cycles when setting the sprites, but..... it takes up a huge load of memory. Especially because the instructions are repeated twice (for PMG 0/1 and 2/3). Each sprite takes up about 6~8 times more memory space. I won't be able to use the engine for 8bit-Strike, as I have 112 x 8 x 16 multicolor sprites (that would take about 28K of memory instead of 3.5K currently).

Thanks for the tip! I remember using G2F a few years ago, I forgot that it supported a "MIC" format. ?

The engine's demo sure looks impressive! But I had never heard of the "MIC" image file format before. Is there a PNG2SHP.exe somewhere out there?? (I cannot find any PNG2MIC.exe convertor)

Thanks very much Mr. Fish! I will study and see how I could integrate the engine into 8bit-Unity (some rewriting is probably needed, looks like some macros in there are not supported by ca65).

The example which I posted (http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM) is close to what I would like to achieve. Are there code snippets out there showing how this wizardy was achieved?

This is more or less what I already implemented: re-use of Players in the vertical direction (by updating the XPOS and COLOR on DLI lines).

Hey Guz, Taking inspiration from https://playermissile.com/dli_tutorial/, I implemented vertical sprite multiplexing in 8bit-Unity last year. However the performance is less than ideal in my new game "8bit-Strike". I still get excessive flicker when more than 2 multicolor sprites share the same DLIs. I have seen some pretty impressive stuff on this forum (Like this: http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM)．So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle.... Thanks in advance!

Your code caused a compilation error on beq @IRQexit1 : Error: Range error (130 not in [-128..127]) I fixed it up as follows, which saves 16 bytes from the CC65 version and seems to work correctly: IRQ: lda INTSET ; Poll all pending interrupts and #SERIAL_INTERRUPT bne @doIRQ clc rts @doIRQ: bit TxDone bmi @tx_irq ; Transmit in progress ldx SERDAT lda SERCTL and #RxParityErr|RxOverrun|RxFrameErr|RxBreak beq @rx_irq tsb SerialStat ; Save error condition bit #RxBreak beq @noBreak stz TxPtrIn ; Break received - drop buffers stz TxPtrOut stz RxPtrIn stz RxPtrOut @noBreak: lda contrl ora #RxIntEnable|ResetErr sta SERCTL lda #$10 sta INTRST bra @IRQexit @rx_irq: lda contrl ora #RxIntEnable|ResetErr sta SERCTL txa ldx RxPtrIn sta RxBuffer,x txa inx @cont0: cpx RxPtrOut beq @1 stx RxPtrIn bra @IRQexit @1: sta RxPtrIn lda #$80 tsb SerialStat @tx_irq: ldx TxPtrOut ; Has all bytes been sent? cpx TxPtrIn beq @allSent lda TxBuffer,x ; Send next byte sta SERDAT inc TxPtrOut @exit1: lda #TxIntEnable|ResetErr bra @IRQexit @allSent: lda SERCTL ; All bytes sent bit #TxEmpty beq @exit1 bvs @exit1 stz TxDone lda #RxIntEnable|ResetErr @IRQexit0: ora contrl sta SERCTL @IRQexit: lda #SERIAL_INTERRUPT sta INTRST clc rts

Thanks for that StarGunner! I will check it the code still works with those modifications. If so, it would be worth letting Karri know about it, as he coded the original serial code in CC65!