| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Large FLI picture
Greetings, exalted ones! I am looking for a large (not a narrow, logo type of) esteemed FLI picture with permission to reuse it in the BeamRacer programming tutorial example. Suggestions whom to turn to would be highly appreciated. |
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Hey Silver Dream
PM me with details. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Hmm, BeamRacer could also free up a lot of CPU time for games running FLI-ish graphic modes, no?
Could finally do something more than just very colourful tile-moving puzzles... maybe Wolfenstein/Doom-esque things? :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Well, it greatly simplifies the handling of the mode thus shaving some cycles on the way. Still, as FLI is based on increasing badlines frequency, it is probably not be the best example for huge savings. A badline is still a badline after all. It's just that whatever is left of the CPU time, doesn't have to be all used for keeping the display in shape. Having said that, since VASYL instructions execute in one cycle, another HAM-type modes with standard badlines frequency are now possible and indecently easy to implement at zero CPU time cost ;-) |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
That sounds interesting! So, using only standard badlines frequency, you could enable multicolor char mode, and alter the contents of $D021, $D022 or $D023 every cycle, i.e. every 4 multicolor pixels, without affecting CPU time? That would be cool. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting S.E.S.That sounds interesting! So, using only standard badlines frequency, you could enable multicolor char mode, and alter the contents of $D021, $D022 or $D023 every cycle, i.e. every 4 multicolor pixels, without affecting CPU time?
For a perfectly valid example.
Quoting S.E.S.That would be cool.
It is cool. I can tell from first-hand experience :-)) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
If i've gotten that right, you can write to one register at most for each cycle, no?
So updating $d021..3 would have to happen in a round-robin fashion, with each of them being updated every 3 cycles. |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
I think so. But depending on the picture you want to display, instead of using a simple fixed round-robin method, you could each cycle update the register that contains the least useful color regarding the next 4 pixels. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Yes, you got it correct - one cannot address multiple VIC-II registers during single clock cycle. |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Quoting Silver Dream !Still, as FLI is based on increasing badlines frequency, it is probably not be the best example for huge savings. A badline is still a badline after all. Since beamracer is a "middle man" between VIC and the c64, isn't it able to drive AEC and BA on its own, overriding VIC's behavior ?
I believe the 6510 should not have to be stalled during badlines while beamracer's logic let VIC grab data from beamracer's local RAM. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
New synthetic video modes, including "badlines-free" ones are in fact possible with BeamRacer. As is improving FLI to overcome the FLI-bug or add even more colours on its right-hand side. |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
