Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Speedcode Multiplexor
2016-07-16 12:06
oziphantom

Registered: Oct 2014
Posts: 502
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?
2016-07-16 12:35
Mixer

Registered: Apr 2008
Posts: 460
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.
2016-07-16 12:38
cadaver

Registered: Feb 2002
Posts: 1163
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.
2016-07-16 14:36
mhindsbo

Registered: Dec 2014
Posts: 51
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.
2016-07-16 16:19
chatGPZ

Registered: Dec 2001
Posts: 11523
multiplexOr makes me cringe
2016-07-17 23:18
TWW

Registered: Jul 2009
Posts: 557
Quote: multiplexOr makes me cringe

+1
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 356
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Codeboys & Endians  (9.7)
4 Mojo  (9.6)
5 Coma Light 13  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Wonderland XIV  (9.5)
9 Uncensored  (9.5)
10 Comaland 100%  (9.5)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Scan and Spin  (9.5)
7 Onscreen 5k  (9.5)
8 Grey  (9.5)
9 Dawnfall V1.1  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Artline Designs  (9.3)
2 Booze Design  (9.3)
3 Performers  (9.3)
4 Oxyron  (9.3)
5 Censor Design  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Acidchild  (9.7)
4 Cash  (9.6)
5 Violator  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.091 sec.