| |
Nightlord
Registered: Jan 2003
Posts: 131 |
UFLI?
Hi everyone,
I tried to google around in order to learn how ufli works but could not find anything. I know how fli, afli, shfli, shifli and finally xfli works.
can someone please explain how ufli works and what are its limitations. i tried to look at the displayer code of that veronica picture. i see sprites involved. but i do not understand the code... |
|
... 131 posts hidden. Click here to view all posts....
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Interlace would require that there were two ways of storing some useable d011 and d018/dd00/dd02 values, in max 10 cycles/line, which didn't use the same bitmap or color screens, at least not on the same lines (char lines for the color screens.)
I won't say it's impossible since I haven't tried, but I'm impressed that there even is ONE way of doing it, so I guess the chances of two solutions to that sudoku are very small.
But who needs interlace anyway with hires FLI + 6 sprites? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
quote: "But who needs interlace anyway with hires FLI + 6 sprites?"
All the lazy graphicians who don't want to deal with the C64s limitations. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Hmm, someone spent the weekend solving fli-sudoko? I'm glad i had better things to do ;), however it would be cool to have it. I also don't think that omitting some d018-stores will do. It may help a bit, but not enough. That's why i posted the idea.. :). Maybe a more sprite-oriented FLI-routine, i don't know. You still have to focus quite a bit on those d011-d018 things to make it work :/. But i can give you 200 lines of 5 sprites + FLI right away ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
IMHO hires pix shouldnt be laced for more colors... |
| |
JackAsser
Registered: Jun 2002
Posts: 1993 |
Lace the sprite layer to get 1x1 resolution, and lace the bitmap layer to get more colors IMO, that's entierly up to the artist. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I totally count on NoiseEHC to solve the sudoku, so I can't see any reasons to bother with that. :)
I'm not really sure it's enough with the omission of the d018-store every 8th rasterline either, but it might be if you start out with the sprite-crunching/pre-plexing to get 168 lines initially. Then you just need to plex the sprites once, and if you use the 2 excess sprites for 2 of the lower 6 sprites, we're down to 4 sprite-y-storings. This also means that there are some cycles left for e.g. changing the sprite colors.
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
i think you can omit one complete d011/d018 store each 8 lines.. so not only the d018 store...
I've been thinking the same as cruzer, but i think it's not possible to use different sprites (so include sprite 6/7 at the bottom).
to solve it, i think you can offset one of the sprites in Y, and keep multipexing it, and 3x stretch + immediate multiplex the other 5 sprites..
now you have to multiplex the first sprite each 42 lines, which is no problem.. but you still have to multiplex the other 5 once more, where you only have 5 rasters available (42/8 = 5).. well.. i think it's possible to have full 200 lines anyway..
but the REAL problem is getting 200 _unique_ sprite lines.. things will get really messy here :)..
possible even not a 16-line fli loop, but maybe a 200-line fli loop is necessary.. oh my.. |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
no, it should not be possible to omit a $d011-change; this would make the appropriate line no badline, and when we're at it, we should create a FULL FLI-Screen ;))
But it is enough to omit this $d018 resp. $dd00-change every 8th line if we just have a look on srpite_plexing. Via Sprite_crunching+y_Expand we first make the 6 sprites 124 lines tall, and if we let the sprites begin in the upper border we can multiplex rightaway to get 168 spritelines. Now we _just_ have to do multiplexing as soon as the first spriteline of the 42 lines tall sprite plexed at the beginning is reached (or, relative to the 168 spritelines, if the 125th spriteline is reached). But if it is possible to allign the sprites in a way that the 125th spriteline coincides with a rasterline where we omit the $d018/$dd00, we get 6 chances to change the y_pos of the sprites (1st, 9th, 17th, 25th, 33rd, 41st line of the sprites). This way we can keep using sprites number 2-7, and I have the feeling that we will loose any chance if sprites 0 resp 1 have to be used... The monstrous FLI_routine now just has to hold a good value in some reg on every "omit-$d018/$dd00-change"-line so that it gives a suitable y_pos for plexing... And I still didn't say a word about INTERLACE 8// |
| |
WVL
Registered: Mar 2002
Posts: 886 |
I think you get a badline automagically after line 7 of a bitmaprow has been drawn.. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote: I think you get a badline automagically after line 7 of a bitmaprow has been drawn..
not if d011 was set to make the previous line a badline |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 - Next |
