| |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
There must be the state of BL_condition, and this means $d011 and $d012 have the same three lowmost bits... it's even possible to bring the VIC in idle_state after line 7 of a bitmaprow ;) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Werner, throw away your dutch joint while coding, ok ;). You can get VIC to continue showing the next bitmap-line without storing d011 each line, but you can not make it read new colors. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
/me drinks some coffee to wake up.. |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
anyone has done anything new concerning this topic ? |
| |
Ed
Registered: May 2004
Posts: 173 |
I made a simple MUIFLI based heavily on the work of Crossbow just a couple of weeks back. Still there was quite some bugs which Crossbow told us. By now I think we all have witnessed alot of bugfixes in the Vice 1.20.
What I really lack is a good editor to make such pictures in the first place though. Do you feel like incorporating it into your Project One, Oswald? Maybe a new release of Timanthes, Mirage?
Contact me on email if you have any questions.
|
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
timanthes will support any sprite mode sooner than p1 :) p1 code needs major rewrites at the first place before I can even think of adding sprites. I want the bitmap modes to be really close to the c64, 1:1 memory emulation, including the weird rom charset mapping, etc. The real headache is not to do the code but to make a plan that how and what should be supported. Like 1:1 memory model cancels out variable screen sizes... |
| |
Ed
Registered: May 2004
Posts: 173 |
Oswald. I guess the real headache is really to make anything close to the original as possible ;P
If you ever happen to have time over, reconsider all the variations the MUFLI mode really carries and all other modes, as there are no obvious reason why we should stop ;D
|
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
Ed, I have serious plans. If it will ever be done as I want it to, most of the imaginable stuff will be possible to edit. (and that means that the gfxmodes done so far will be just a subset of the possibilities). But these are JUST plans. :) |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Speaking of MUFLI: I still didn't really understand how this works...
I peeked at the viewer_code some time ago which had those obvious STORE_opcodes for $d016 plus the six sprite_color_regs, and ofcourse the opcodes for the FLI. Seemingly the sprites are plexed using sprite_crunching giving a total of 168 gfx_lines (+/- that is, as the sprites start in the upper border area). In order to have 200 lines of gfx, there has to be at least one rasterline in which the spr_ypos are changed. Another look at the viewer code revealed exactly this: one (or was it two?) line(s) had "STA spr_ypos"-stuff instead of these write acceses to the sprite_color regs.
Now what happens if the sprite_mode AND all the six different sprite colors are changed on every (2nd) rasterline? I have to admit I'm too lazy to make such a pic in order to check how the viewer code will look like in that case. Maybe someone's got an idea?
CF |
| |
HCL
Registered: Feb 2003
Posts: 717 |
I don't know, but i suppose that xbow simply assumes that from 168/2*7=588 possibilities to change spt-registers there will be at least 7 free to use for y-pos storing. But of course one wonders what will happen if you make a picture with more spt-splits :)). |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 - Next |
