C64 Sprite Multiplexing (IT)
Вставка
- Опубліковано 27 сер 2024
- Un tutorial su come realizzare uno sprite multiplexer con un'implementazione in assembly 6502 e XC=BASIC 3 (versione italiana). #commodore64 #retrocomputing #sprites #multiplexing
Codice sorgente e binari (licenza MIT): drive.google.c...
Se il video vi è piaciuto e volete vederne altri, per piacere mettete "mi piace", condividete ed iscrivetevi! Grazie!
English version: • C64 Sprite Multiplexin...
Voci generate via TTS dal sito: ttsfree.com/te...
Geniale, ma soprattutto ben realizzato e spiegato in maniera chiarissima ! 👍
Grazie, ho cercato di sforzarmi di esserlo, realizzare video di questo tipo è abbastanza impegnativo. Per incentivarmi vi chiedo solo di iscrivervi e condividere. Grazie! 🙂
Interessante implementazione dello sprite multiplexing in ambiente basic, bravissimo.
video veramente eccellente sia nella spiegazione che nella dimostrazione , mi piace motlo , voglio studiarmela bene, prima di porre qualche domanda. anche se in parte gia conoscevo questa tecnica spiegata dal prof. leonardo , ma in questo video è stato aggiunto qualcosa in piu spero ce ne siano altri
Grazie, come sempre, l'eventuale pubblicazione di altri video dipende dal successo dei precedenti. Quindi, spargete il link, please 😉
Interessantissimo!
I thought that a great thing with the C64 is that the z order of the sprites is fixed. So when you have a snake or caterpillar the head is in front and everything else behind. Or when you have an arcade racer with not much scenery you take care of z. So I guess that you should not overdo multiplexing. Maybe there is a way to optimize for low number of CPU cycles stolen. The VDP from TI with its hardware multiplexer can sort all sprites every scanline, but only 4 sprites per line are allowed. Nobody notices when the VIC-II steals a few cycles from the CPU, but everyone notice the flicker on TI or Atari 8-bit.
Would be so cool if you could instruct the VIC-II to insert or delete (1 bit) a sprite at one position (3 bit) and either shift the front or back sprites ( 1 bit).
Good point. One of the problems with sprite multiplexing is the order of the sprites. In my game NewsStand, I had to implement a multiplexer where it's possible to choose the order of the sprites since many of the "actors" of the game (including the player) are made up of multiple overlapping sprites to obtain high resolution sprites (320x200) in multicolor (sore point of the VIC-II where multicolor has 160x200 resolution). It involves making a non-sequential allocation of the sprites, reusing them based on the required order.
this consume CPU cycles, how much % of CPU time the mux algo is using compared to a screen frame?