| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Speedcode Multiplexor
The other froum about speedcode for the D800 got me thinking what else would benefit from it. To which I then hit upon the multiplexor, being able to set the sprites up as fast as possible allows for tighter turn around. Mixing in other splits that you might want to do, colours, charset, screen etc could really save a lot of live raster time.
On a game where most enemies run along platforms, and only occasionaly jump or climb would probably benefit the most, but I would think that in most gaming situations you would have a mostly fixed sort order. The AI could even be coded such that it can flag I will cross a barrier in X frames and start the rebuild early.
Anybody done something like this? |
|
| |
Mixer
Registered: Apr 2008
Posts: 421 |
Perhaps I misunderstand you, but many, if not most, demo effects are about "compiling" the next frame "code" composition somehow. Where to put interrupts, where to change VIC values etc, so yes. Done a lot. Sometimes it is just selfmodifying interrupt routines, sometimes it is unrolling a table for colorbars, sometimes it is about unrolling code to open sideborders and viewing dynamic starfield. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Not done personally, but I could see it working. You'd save 2 cycles per sprite variable (lda #$xx vs lda spriteValue,x). The destination writes ($d000, $d001, $d027 etc.) should already be unrolled per sprite instead of indexing in any case.
You wouldn't even need a fixed order, just copy the variable values to the speedcode when going through the sprite sort order. And insert an rts instruction into the speedcode for the break into the next IRQ.
I'd advise against AI or logic code having to worry about multiplexing or sort order, rather they should just be able to command a bunch of "logical sprites" and lower layer code takes care of the multiplexing. |
| |
mhindsbo
Account closed
Registered: Dec 2014
Posts: 50 |
it of course depends on the specific game and multiplexor as mentioned. In my game I support z-ordering of sprites (e.g. ground based sprites hidden by aerial sprites) so destination is dynamic and decided by the sorter.
on the flip side all the variables are sorted into a table so getting the sprite values are unrolled (lda spriteColor+1, etc.) and in zeropage.
but you are right that any couple of cycles per sprite variable would benefit a multiplexor greatly when sprites are close and you need quick turn-around from one to the next. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
multiplexOr makes me cringe |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: multiplexOr makes me cringe
+1 |
