| |
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... |
|
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
tch.coding > nightlord.coding? ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11130 |
x-expandend sprite layer, 7 sprites, priority "behind" bitmap, fli every second line.
that enough? :=P
|
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: x-expandend sprite layer, 7 sprites, priority "behind" bitmap, fli every second line.
that enough? :=P
Ehr,it only uses 6 sprites in the actual picture.
Best program to pixel,though it does have its limits. 8) |
| |
Mason
Registered: Dec 2001
Posts: 459 |
Where was this used? |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: Where was this used?
Veronica
Iron Lady
;) |
| |
Nightlord
Registered: Jan 2003
Posts: 131 |
yep that's enough. thanx groepaz and tch |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
@Nightlord:
If you are unreveling the UFLI method from ´Veronica´,please note that it is an adjusted viewer.
I have tinkered with the sprite-colors routine.
The original UFLI-Editor only allows for 1 color for all the sprites.
If you´d like to have my Beta editor,just let me know. |
| |
Sledge
Registered: Sep 2003
Posts: 102 |
Quote: @Nightlord:
If you are unreveling the UFLI method from ´Veronica´,please note that it is an adjusted viewer.
I have tinkered with the sprite-colors routine.
The original UFLI-Editor only allows for 1 color for all the sprites.
If you´d like to have my Beta editor,just let me know.
That would indeed be nice! :)
|
| |
Nightlord
Registered: Jan 2003
Posts: 131 |
thanks a lot tch. I am actually thinking of pixeling on PC than writing a converter in C++. Mouse is just too convenient :) oh my god ... what am I saying ? people will blame me for converting now :D |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Heheh,another converter.
Quite amazing how everybody seems to be out of touch with C64 pixelling. ;)
Do as you please,I don´t mind..
Anyway,for all of you who still feel like pixelling the ´old´ way..
I have just released the second UFLI-Editor.
You can grab it here..
UFLI Editor V2.0 |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
What's new in v2.0? I must admit, I'm increasingly interested in doing something in formats such as UFLI! |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: What's new in v2.0? I must admit, I'm increasingly interested in doing something in formats such as UFLI!
The only ´real´ improvement is that you can change the sprites-colors.
The first edition only allowed for all sprites to be the same colour.
I found it useful to improve this.
But,brains are needed to use this feature wisely.
I am certain you know what to do! 8)
Please join me in my UFLI-Quest.
If there is one thing this scene needs,it´s a new resolution to work with! ;)
Respect Bizzmo,good to have you back! |
| |
HCL
Registered: Feb 2003
Posts: 717 |
For the record.. 7 sprites are used in the code/timing, but only 6 for the picture. The last one is used to cover the grey bug to the left.
Since 6 sprites only cover 36 chars sideways (FLI allows 37 chars), the rightmost char is mostly left unused.
Further, it's not pure FLI, but only every second line. Fair enough for most graphicians i suppose :). |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Changing spritecolours while doing FLI resolution...whoever came up with that lame idea... |
| |
WVL
Registered: Mar 2002
Posts: 886 |
hope this is not spamming ;)
--------------
UFLI Allgemein:
UFLI, Underlay Flexible Line Interpretation. Wie der Name schon sagt, handelt es sich hierbei um eine Variation des schon bekannten FLI Modus.
hnlich wie schon bei Super-Hires FLI werden hier Sprites benutzt, um die Mglichkeiten des einfachen FLI Modus noch zu erweitern. Allerdings wurde hierbei darauf geachtet, das fast der gesammte Graphikbildschirm (in unserem Fall 288 * 200 Pixel) fr diesen Modus zur Verfgung steht. Das sind 36 * 25 Chars (die ersten 3 Chars gehen durch den FLI - Bug verloren und der letzte Char der Zeile wird durch die Video-Ramfarbe dem Border angepasst). Jedoch verbrauchen die hierfr notwendigen 7 Sprites zu viele Taktzyklen pro Rasterzeile um den FLI Effekt in jeder Rasterzeile rechtzeitig zu starten. Ganz zu schweigen von den zustzlichen nderungen der Y-Spritewerte und Spritedatenzeigern.
Desshalb wird der FLI Effekt nur jede zweite Rasterzeile erzeugt. So verteilen sich die 34 Taktzyklen, die die 7 Sprites verbrauchen (17 pro Rasterzeile), auf eine Badline und eine normale Rasterzeile (zusammen 86 Taktzyklen). Damit bleiben alle 2 Rasterzeilen 52 Zyklen fr die Multiplexer und FLI Routine brig.
Zurck zu der Auslsung des UFLI Modus. 288 Pixel in X Richtung sind mit normalen Sprites nicht zu berdecken, desshalb wurden die Sprites X-Expanded. Somit reichen 6 Sprites + einem weitern zum berdecken des FLI-Bugs in den ersten drei pro Rasterzeile aus. So erhalten wir 8*2 Pixelfelder, in denen 2 Farben frei durch den Hires FLI Modus frei gewhlen werden knnen + einer weiteren Farbe (die Spritefarbe) die jedoch fr das gesamte gleich ist und durch das X-Expanden nur in einer 2 Pixel Breiten Auflsung (also 4*2) vorhanden ist.
Wieso aber "Underlay" FLI?
Grund ist das eigendlich flschlicherweise als "Sprite/Hintergund Prioritt" bekannte Register $D01B. Flschlichweise, da Hintergrund (mit 0 beginnende Pixel) NIE eine hhere Prioritt als Sprites haben knnen. Werden also alle Bits der verwendeten Sprites in $D01B gesetzt, werden alle Farbpixel, die durch das 1 Bits dargestellt werden "ber"ï(also sichtbar) und alle Farbpixel, die durch das 0 Bit dargestellt werden "unter" (also nicht sichtbar) den Spritepixeln dargestellt. Darum ist es im Editor wichtig, bestimmen zu knnen, ob man ein "1" Pixel (Ink: engl. fr Farbe) oder "0" Pixel (Paper: engl. fr Papier) setzt. Man kann sich das also alles wie ein Bild in 3 Ebenen vorstellen. Auf der untersten (mit der niedrigsten Prioritt) Ebene befinden sich die Pixel des Papers. Auf der nchst hheren 2. Ebene die Spritepixel (die 2 Pixel breit sind). Und auf der 3., obersten Ebene die Ink Pixel.
UFLI Die Darstellroutine & Speicherverwaltung:
Zum FLI im Allgemeinen. Die FLI Routine, und somit auch das Bild, sollte in Rasterzeile $30 beginnen und nicht wie das Standardeinschaltbild in Zeile $33. Der Grund hierfr ist ganz einfach. Der VIC kann Badlines nur in den Rasterzeilen $30 bis einschlieálich $F7 erzeugen. Das sind exakt 200 Zeilen. Beginnt man mit der Darstellung erst ab Zeile $33, tritt der FLI Effekt in den letzten 3 Zeilen nicht mehr auf, und diese 3 Zeilen haben dann die gleichen Farben wie in der 4. letzten Zeile obwohl die Editoren im Zoom Modus den Eindruck erwecken, das sie auch hier frei whlbare Farben darstellen knnen (siehe z.B. FLIP, Funpaint 2 oder Gunpaint). Wollen wir jedoch schon ab Rasterzeile $33 mit der Darstellung unseres Bildes beginnen, muá der obere und untere Border ausgeschaltet werden, da dieser normalerweise bis einschlieálich Rasterzeile $32 eingeschaltet ist. Nun erfolgt also eine FLI Routine, die alle 2 Zeilen eine Badline erzeugt ($30, $32, $34, $38, ... , $F4, $F6). D.h. wir brauchen eine Bitmap ($6000 - $7F3F) und 4 Video-Rams ($5000 - $53FF, $5400 - $57FF, $5800 - $5BFF, $5C00 - $5FFF). Das lát uns dann noch gengend Speicher ($4000 -$4FFF) fr die Sprites, die ja auch noch ein Feld von 288 * 200 Pixel abdecken mssen. Da wir die Sprites in X Richtung Expanded haben bentigen wir dafr 6*10 Sprites, also 60, die von $4000 - $4EFF abgelegt werden. Die Daten (alle $FF) die fr ein zustzliches Sprites, das zum Abdecken des FLI Bugs (der hier in den ersten 3 Chars jeder Zeile auftritt) bentigt werden liegen von $4F00 - $4F3F).
Nun zum Multiplexen der Sprites. Zur Vereinfachung der Routine wurden die Sprites auch in Y-Richtung Expanded. Da jedoch in jeder zweiten Rasterzeile die Video-Rams gendert werden, knnen wir durch unterschiedliche Datenzeiger am Ende der Video-Rams weiterhin erreichen, das die Sprites in Y-Richtung Unexpanded erscheinen. Dazu setzen wir die Sprites in die selbe Rasterzeile ($30) in der das Bild beginnt (also Sprite Y Possition $2F, da Sprites ja erst eine Rasterzeile nach ihrer eigendlichen Y Possition dargestellt werden), und lassen die erste Spritezeile unexpanded. In der zweiten Spritezeile schalten wir dann die Y-Expansion ein um gegenlufiges Wechseln der Video-Rams und Spritezeilen zu erreichen (siehe Tabelle 1)
Tabelle 1 (# = Badline , - = Normale Rasterline)
Bildzeile Rasterzeile Video-Ram Spritezeile
1 $30 # 5 1 (unexpanded)
2 $31 - 5 2 (ab jetzt expanded)
3 $32 # 6 2
4 $33 - 6 3
5 $34 # 7 3
6 $35 - 7 4
7 $36 # 8 4
8 $37 - 8 5
9 $38 # 5 5
.
.
.
33 $50 # 5 17
34 $51 - 5 18
35 $52 # 6 18
36 $53 - 6 19
37 $54 # 7 19
38 $55 - 7 20
39 $56 # 8 20
40 $57 - 8 21
---------------------------------------------------------
41 $58 # 5 21
42 $59 - 5 1 (gleiche Video-Ram/Spritezeile Kombination wie in Bildzeile 1)
43 $5A # 6 1
44 $5B - 6 2
.
.
.
Die Spritedatenzeiger in Video-Ram 5 und 7 (bzw. 6 und 8) sind gleich. Nach 40 Rasterzeilen mssen wir dann jedoch die Datenzeiger ndern, da sonst ab Zeile 42 gleiche Video-Ram/Spritezeile Kombination auftreten. Dabei verlieren wie zwar ein Zeile pro Spritemuster, was aber nicht weiter schlimm ist, da wir mit unseren 10 Sprites untereinander (5 Expandete Sprites die hnlich wie 10 normale Sprites verwaltet werden) 210 Zeilen erhalten, wovon wir ja nur 200 Zeilen brauchen. Es geht also ganz genau auf. Und mit dem ersten Verndern kann man schon ab Zeile 35 beginnen, da hier ja dann die letzte Spritezeile von Video-Ram 5 dargestellt ist. Ab Zeile 37 ist dann Video-Ram 6 dran, Video-Ram 7 kommt ab Zeile 39 und Video-Ram 8 ab 41. Und das ganze dann 40 Rasterzeilen spter nocheinmal, insgesammt 5 mal. Desshalb ist die Darstellroutine auch mit einer Schleife programmiert die 5 mal durchlaufen wird. Am Ende wird dann der Border abgeschaltet, auf Video-Ram 3 (auf $4C00) umgeschaltet damit die Spritedatenzeiger ($4FF8 - $4FFF) fr die letzten 10 Zeilen auf ein leeres Sprite ($4F40 - $4F7F) zeigen und die Spritedatenzeiger der Video-Rams 5-8 wieder auf die notwendigen Werte fr den ersten Schleifendurchlauf gesetzt.
Speicherbelegung:
$1000 - $12C7 Darstellroutine (Start mit Sys 4096)
$4000 - $4EFF Daten der 60 Sprites
$4F00 - $4F3F Deckspritedaten (fr den FLI - Bug)
$4F40 - $4F7F Leersprite
$4FF0 Spritefarbe
$4FF1 Borderfarbe ($D020 + Decksprite)
$4FF8 - $4FFF Spritedatenzeiger von Video-Ram 4 (alle auf #3D)
$5000 - $53FF Video-Ram 5
$5400 - $57FF Video-Ram 6
$5800 - $5BFF Video-Ram 7
$5C00 - $5FFF Video-Ram 8
$6000 - $7F37 Bitmap
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
Werner, are you totally out of your mind!!?!? DELETE THIS CRAP!!! It's clear how UFLI works, why posting the whole tutorial? Maybe a *link* would have been enough, don't you think?!? |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
And please, English only, don't speak in your own language!
Hoe was de hutspot trouwens? |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Werner, are you totally out of your mind!!?!? DELETE THIS CRAP!!! It's clear how UFLI works, why posting the whole tutorial? Maybe a *link* would have been enough, don't you think?!?
too late :).. can't edit it anymore.. also this might make a nice place to put it so other ppl can find it aswell (I can't guarantee i'll host the file forever ;)..
didnt have hutspot, but i did buy a new breedbeeld teevee! |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
No hutspot? You're a fake Leidenaar! Even my gf had some, and she only works in that city! |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: No hutspot? You're a fake Leidenaar! Even my gf had some, and she only works in that city!
lol.. hutspot is crap :).. then again, if your girlfriend is into YOU, i see no reason to think she wouldnt like something crappy as hutspot aswell :) |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
Quote: lol.. hutspot is crap :).. then again, if your girlfriend is into YOU, i see no reason to think she wouldnt like something crappy as hutspot aswell :)
Hey, at least both hutspot & me have people actually touching us ..
Grmb grmbl .. pinball playing, hero shooting, demo postponing son of a b.. |
| |
Six
Registered: Apr 2002
Posts: 287 |
Does anyone know if the UFLI displayer has already been NTSC fixed by someone? I've been thinking of using the format for something, and don't want to rewrite the display routine if someone else has already done so... |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Wonder if it would be possible to make a UFLI routine with FLI every line. 6 sprites over FLI has been done in this demo: Darwin |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Don´t really know if X-expanded sprites reduce the available rastertime.
Would be really great to have each line available!
Believe it or not,it does interfere and more compromises are required.
I think Dane´s XFLI is a one-liner.
Just don´t like to have a half-empty screen.
My code is not good enough to fill it up with something else. ;) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
It's possible, but tricky. You have to use the sprite-crunching trick to automatically *stretch* the sprite, since you have no cycles to put new spt-ypos. That will give you at most 168 lines of gfx, probably a few lines less in reality. But i don't know where the sprite-data go, and which video-banks have to be used.. I guess Ninja's 8-cycle FLI-routine is not too flexible ;).
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
sssssssssshhh!!! STOP TALKING NOW!
well, fortunately it's not ME who's working on it :) I hope nobody has just gotten any ideas though..
weird shit, every time something seems to hang in the air and it just makes sense to make a particular routine, so everyone goes for it.. why is that?
woef. :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: It's possible, but tricky. You have to use the sprite-crunching trick to automatically *stretch* the sprite, since you have no cycles to put new spt-ypos. That will give you at most 168 lines of gfx, probably a few lines less in reality. But i don't know where the sprite-data go, and which video-banks have to be used.. I guess Ninja's 8-cycle FLI-routine is not too flexible ;).
well, i didnt check ninja's routine out in detail, but i'm guessing there's the usual 8 lines-o-repetion.. so max 8 color banks are used and there should be plenty-o-space for sprites..
i agree the order of the sprites in memory WILL be totally crazy though, with the irregular $d018 pattern :) but i don't want to force myself to think about it ;)..
Anyway, i'm guessing that if you use the correct y-offset at the top of the screen, things will fall into place and you will get true 168 different lines of sprite data, which is the real problem here. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
The problem is not to do that code, it's to code the editor for it and then find someone stopid enough to use it ;). I've had the idea for a while, but i probably wouln't do it. |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
Quote: The problem is not to do that code, it's to code the editor for it and then find someone stopid enough to use it ;). I've had the idea for a while, but i probably wouln't do it.
If you build it, they will come -> if there's an editor, people will use it. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: The problem is not to do that code, it's to code the editor for it and then find someone stopid enough to use it ;). I've had the idea for a while, but i probably wouln't do it.
I think I know someone ;) |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Ehrr.. mi sjtupeed....mi piksel massoghist. ;)
Well,I´d probably use it.
But I can understand the editor being one b°tch to make.
Maybe it´s an idea to use a $DD00 swapper in the original UFLI editor?
|
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
Quote: Ehrr.. mi sjtupeed....mi piksel massoghist. ;)
Well,I´d probably use it.
But I can understand the editor being one b°tch to make.
Maybe it´s an idea to use a $DD00 swapper in the original UFLI editor?
Swappers are so last century! |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Yeah yeah, who's stupid enough to use it... fuck sake, busted! |
| |
Hein
Registered: Apr 2004
Posts: 933 |
:) nag, nag, boohoo.. |
| |
NoiseEHC
Registered: Feb 2005
Posts: 51 |
I am halfway throught creating the UFLI MAX graphic mode but you are welcome to try that too. However do not bLAME yourself with less than 200 pixels high images, please. If you do succeed and will be faster than me then it would became the de facto standard what would make me sad... |
| |
WVL
Registered: Mar 2002
Posts: 886 |
as said before, creating it isnt the real problem :) but making gfx (and an editor) for it...
creating UFLI MAX :
-set your 6 sprites on screen
-do d017 stretch trick, multiplex sprites immediately (so you get 168 lines-o-sprite)
-do ninja's 6 sprites over fli
erh.. that's it :)
nasty thing is figuring out the order of the sprites in memory, since the sprite contents are washed out over lotsa sprite images...
btw, did ninja use $dd00 also, or wasnt that necessary? being required to use $dd00 aswell makes the memory-use incredibly high.. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
So, now Werner also has an idea of how to make it. good ;). Everyone can add their own explenation as they also figure it out.
Yes, Ninja uses DD00, or rather DD02. RTFM for that, as well as all the nasty illegals. Hmm, i though it had to be an 8-cycle loop..
Guess this will not be suitable for interlace.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Not sure u'll get 168 lines since doing sprite crunching to make a sprite wrap three times requires the d017 trick to be at line 3 of the sprite. Also, if things turn out really nasty maybe the $d017 write (which is cycle exact) collides with the $d011 write to make FLI. All in all I suspect you have to cut three or four lines on the sprites to make it all work. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
You don't do the d017-thing and FLI at the same time!!
btw. I did the same trick in the first screen of SOUL, there i got 124 lines of gfx (without multiplexing). Appearantly i lost 2 lines there..
Also check Crossbows DemusInterruptus, there you have it all with *only* 5 sprites, and **only** 160 lines :D. How lame ;) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
124 + 42 == max seems to be 164... not too shabby ;) that's 20.5 lines. and ofcourse you can always fill the rest of the screen with normal afli... or spend 1 or 2 lines on multiplexing the sprites again, which would make only those lines normal afli (or even no fli at all for one line..) |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Don´t know what all this sprite-crunching is about. (shamed)
But why is it that UFLI is the normal 200 lines then?
If there will be an earlier UFLI-MAX editor,but with lesser lines,I´ll probably wait for the one NoiseEHC is working on. ;)
The screen-ratio is pretty lame as is...
|
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
you can mess up the VIC's sprite gfx counters with the spritecrunch fx. so it is possible to have a 168 line high sprite, with different gfx in each line of it (if you change also d018 each line), altho the memory layout and the code would be a hell on earth. Maybe this fx would make possible to have a 168 line high ufli, but with every line fli. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
As I mentioned before, sprite crunching repeates the sprite three times, not four. It really simple to see. What happens is that a byte is skipped and a sprite will not stop render until byte 3 on a line is #63. Since it skips one byte, the last byte will be #64, and after yet another 21 lines it'll be #62, and not until the third run it'll be #63 which will terminate the sprite. So, one simple $d017 sprite crunch will generate a sprite that is 63 gfx lines high, but since it also requires them to be y-stretched the complete sprite will be 126 raster lines high. But as WVL mentioned you can easily multiplex them in the beginning and add an additional 42 lines. So all in all you will have 168 lines.
(I did get that right didn't I?) =D |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Quote: The problem is not to do that code, it's to code the editor for it and then find someone stopid enough to use it ;). I've had the idea for a while, but i probably wouln't do it.
I'd be interested to hear the opinions of other graphicians on this, but my feelings are the best way to get people to use it is to build an editor for the PC.
Whilst I have done some things in UFLI which may get released at some stage (if I finish them :) ), there's 2 reasons I've so far been put off fully adopting it:
1. Pixelling with a keyboard for hour after hour, in a mode that is heavily technical as it is, just isn't much fun to me. The scene is no longer made up of school kids who have nothing to do but sit behind a computer day after day.
2. Most people don't just pixel Boris Vallejo rip offs anymore, where you know exactly where you're going with a picture from the start. I like to play around with my compositions and experiment with ideas. It's disheartening to have to spend 3 hours pixelling something in an awkward editor, only to find it doesn't really work.
Maybe everyone else will disagree, I dunno, just an idea! :)
I would definately like to use some of these hires modes, if only they weren't so frustrating to work with. It's quite possible that I'm just lazy though :) |
| |
NoiseEHC
Registered: Feb 2005
Posts: 51 |
Using NINJA's code will not allow interlace not to mention will limit you to 168 pixels... Creating the 200 pixel high effect in interlace is WAY HARDER than creating an editor (modifying my PC editor would take ~5 hours...). Note that a C64 editor usually means that you think that graphicians should suck big :) |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
@Deev: you could start with ditching your TV..saves plenty of time. ;)
Seriously,I know UFLI is slow to work with.
And you are right that´s it important to know where you´re going. (look at Veronica - I lost it,bigtime!)
UFLI is not a free-way to create what you have in mind,the restrictions are too many for that.
Think hard about what you want to create and mind the ´X-limits´.
Experimenting with colors in UFLI is something better done previously.
Best is to start with a picture in your mind,it will take long enough to do that. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
@Deev: There will never be any true-color mode, so bitching with pixels is THE way to do it. If you want a free-hand painting prog on the PC, why not load a proper palette into your favourite PhotoChop and go on? Converting it to whatever mode you want later on..
I've been into PC-painting myself for quite a long time, only producing crap. But i found the joy of pixeling again when i returned to a *real* lo-tech bitmap editor :). It's not the amount of pictures that count, it's the quality and effort that counts!! |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Regarding UFLI-MAX...
I did a tiny calculation, please correct me if I'm wrong:
* 6 sprites take minimum 1+6*2=13 cycles (if you use RMW-instructions).
* FLI char fetch takes 40 cycles.
* D011 write to make FLI takes 6 cycles.
Left is: 63-(13+40+6)=4 cycles.
Now, how on earth is it possible to make any screen or bank flip in 4 cycles each line? Of course you could flip every second line or so... |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
I can see what Deev is getting at. Personally I find it incredibly difficult to do anything where I can't play around in a "freehand sketch" mode. I find the thought of doing everything in a zoom window pixel by pixel very daunting. I have a lot of respect for anyone who can work that way.
The way to encourage more people to take on a technically difficult format is to create an editor (on whatever platform) that gives the "artist" as much control and easy of use as possible, and prevents them from spending days banging their hear against the wall due to technical frustrations!
I can see that formats that push the 64 to the limit are going to be difficult/impossible to draw directly, so this would seem to be the perfect opportunity for a tool that gives you these functions!
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Regarding UFLI-MAX...
I did a tiny calculation, please correct me if I'm wrong:
* 6 sprites take minimum 1+6*2=13 cycles (if you use RMW-instructions).
* FLI char fetch takes 40 cycles.
* D011 write to make FLI takes 6 cycles.
Left is: 63-(13+40+6)=4 cycles.
Now, how on earth is it possible to make any screen or bank flip in 4 cycles each line? Of course you could flip every second line or so...
just check out ninjas routine.. he's using WICKED illegals to have a different d018/dd00 combo each line, using only 4 cycles for that, and 4 cycles for the $d011 write..
@tch : ULFI is 200 lines high, because you still have some cycles free to do multiplexing.. there's even enough cycles free to split spritecolors vertically every once in a while.
|
| |
Deev
Registered: Feb 2002
Posts: 206 |
Quote: @Deev: There will never be any true-color mode, so bitching with pixels is THE way to do it. If you want a free-hand painting prog on the PC, why not load a proper palette into your favourite PhotoChop and go on? Converting it to whatever mode you want later on..
I've been into PC-painting myself for quite a long time, only producing crap. But i found the joy of pixeling again when i returned to a *real* lo-tech bitmap editor :). It's not the amount of pictures that count, it's the quality and effort that counts!!
oh yeah, I realise it will always be difficult to work in, but never underestimate the simple pleasures of a mouse, and a few brush options :)
Don't get me wrong, I still use c64 editors for quite a few jobs, but there's something about these hires modes that begins to rot my mind after more than a couple of hours :) I agree quality matters more than quantity (not sure effort always counts, some great stuff can sometimes be pixelled in an evening), but it's a shame when the quantity is zero because the editor drives you insane. Maybe that's just me though :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@WVL: ahh I c, so that's what Ninja's routine was all about. Hum, guess I should check it. Not that I'm eager to implement UFLI-MAX but tricks such as that can always come in hand. =) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Come to think of it.. iUFLI-max should also be possible.
while Ninja IS using multiple banks, and normally you can only use banks 1 and 3 (or 0 and 2, depending how you call them ;) for FLI, as you need 8 color maps.. But if you use multiple banks, one of them MUST be using only 4 or less, so it would be possible to use a combination of bank 0 and 1, or 2 and 3, or 0 and 3 or 1 and 2...
making iUFLI-Max possible, so take that David!.. then again.. flicker-horror!! |
| |
iopop
Registered: Dec 2001
Posts: 317 |
wvl: So, we can expect a release of the iUFLI-Max editor on sunday afternoon then? :)
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
Werner, you think either too much or too little. You need around $c00 for sprites as well. But then again, don't let me stop you :). Btw. i didn't know that I was dedicated to this project at all. |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Do the format yourself. Code the editor yourself. Problem solved. No more headbanging. |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
I have a hard enough time working with multi-colour mode! ;-) |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
No more headbanging? Is that a good thing? :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Werner, you think either too much or too little. You need around $c00 for sprites as well. But then again, don't let me stop you :). Btw. i didn't know that I was dedicated to this project at all.
In this case I was DEFINATELY thinking too little :).. i completely forgot about the sprites..
then again, if a bank uses 4 colormaps, that means it'd only use 4*6 sprites of data, so $600 bytes... still too much obviously, but not if one of the banks uses 5 colormaps, and the other one 3..
3 colormaps -> $1f40 for bitmap + 3 * $400 for colors + $480 bytes 3*6 sprites + $1000 charcrapmemory = $3fc0..
granted, it'd barely fit, but fit it would! (now I start to sound like Yoda ;-) )
anyway, I'm definately waiting for other ppl to do it first :) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
this is like the monkey island topic on lemon64, everyone talks about how to realize it, but no1 cares to set a single bit. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: this is like the monkey island topic on lemon64, everyone talks about how to realize it, but no1 cares to set a single bit.
Like I said, someone I know is already making it, so why should I set bits? :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
iUFLI-MAX i definitely possible, as long as the gfx that needs to be interlaced is small enough to be switched by software each frame... or alternatively just eor $d016 by 1 each frame :) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Yes Werner, i was wrong! It is possible at least if you only consider the amount of memory needed. However i fell into the FLI-sudoku, trying to fiddle with Ninjas code to make it use only two video-banks instead of all 4. 5-10 sheets of paper wasted and the only result was my girlfriend going totally nuts at me for spending the whole weekend doing *nothing* (as it appears to her).
So, i'm starting to doubt that there is a possibility to do that interlaced UFLI thing, but a *normal* one sould be no problemo.. Hmm, Cruzer seems to think it's possible, but at the same time he's talking about d016 (!). Guess he's totally out walking ;).
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@HCL: Sorry, I forgot that you also had to eor $d000, $d002 ... $d00a with $01 to make it all flicker correctly. ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
And adding to the soduko...
First, each 42-line segments need unique screens with their own set of sprite pointers, otherwise the same sprite data will simply wrap (the sprites wraps 4 times).
Secondly, every 4th line has a 5 char FLI bug, not 3char (not entierly sure why?!?). Probably not possible to circumvent.
Considering these two facts you can forget Ninja's code and you will have to find your own set of 1337 instructions.
Also in Ninja's case he can re-adjust the initial bit values each time he multiplex the sprites, UFLI-max mode can't, you will have to stick with the patterns all 168 lines or so.
|
| |
Clarence
Registered: Mar 2004
Posts: 119 |
"Secondly, every 4th line has a 5 char FLI bug, not 3char (not entierly sure why?!?)."
Yes, but only under Vice.
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
@JackAsser: It's not that complicated, you can reuse the sprite-areas since only each 4:th line is used during the FLI-timing. It's not straight to see this since the sprite-crunching makes the sprites behave strangely. As i said, in Soul i made 126 lines without any bank-switching, but for the last 42 i guess you'll have to do a switch :(. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Gnah, me teh stupid.... HCL, if you read what was written in this message before, kindly ignore it. :D |
| |
WVL
Registered: Mar 2002
Posts: 886 |
you teh stupid! ;) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Ok, I think I have the idea for the ultimate PC gfx editor for weird C64 FLI/sprite-modes, which would work for all conceivable modes people might come up with...
It should allow FLI each line, 3 chars bug (or maybe 0, so it could also be used for 40 chars wide stretched FLI), 26 chars high (208 pixels), and 8 sprites, that's also 208 pixels high each.
For each rasterline it should be possible to adjust FLI multicolor on/off, d016 scroll bits, bg-color (which only has effect in multicolor mode of course) and for each sprite these parameters should also be flexible for each line: x-position, x-expansion on/off, multicolor on/off, fg/bg priority, and sprite color.
This would of course allow the user to create some gfx that was impossible to display on the C64, but it should be the user's responsibility to keep within the boundaries of whatever displayer he/she wants to use. It should also be up to the user to make a converter that could place the gfx correctly in the memory. The editor should just export it as a standard FLI screen, 80 std. sprites, and some tables with the different data that can be adjusted for each line.
To help the user not to draw anything "illegal" it might be useful to also be able to set FLI on/off and FLI bug size for each line. Support for interlace could also be added. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Tell me when you're done... |
| |
Ninja
Registered: Jan 2002
Posts: 406 |
@cruzer: Sounds a bit like this ILM-grafix-mode by The Obsessed Maniacs. The appropriate pixel-plot-routine is keeping Copyfault busy for years now ;) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Don't think it would be that hard to do, but I also have a list of about 200 ideas for effects I wanna implement first. :) |
| |
iopop
Registered: Dec 2001
Posts: 317 |
well, the source for Gimp is free. So, given your specs its just a matter of setting a c64 palette and make some kind limited layer functionallity for the FLI and sprites.
..then if its possible to implement on the c64 is someone else's problem. |
| |
algorithm
Registered: May 2002
Posts: 702 |
I know there are a lot of people who prefer pixeling on a real c64, but the convenience of a PC based editor (maybe implement the PAL emulation) would be more of a better option. as well as offering additional features such as importing, converting images to various formats and modifying them etc.
The Photoshop/Gimp idea would not work properly due to attribute limitations (unless the colors are manually counted per attribute area) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
nähä! =D |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
"offering additional features such as importing, converting images to various formats and modifying them etc."
Are you talking about my editor, P1 ? :) New version is on the way... ;)
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Cruzer: As Ninja said, I have been working for a while on such an editor... hmm, if you take away the Sprites!!! 208 Rasterlines, every Line has its own $d016/$d021-values, every line is FLI (except for the last eight, that is;)), and the whole f*ck is interlaced with an additional y-offset. This way you can aviod *far* more colorclashes compared to the "usual FLI", but in order to have an easy-to-use-Editor there should be some intelligence which decides how to put a certain colorpixel. If you consider all settings ($d016-scroll, y-offset, Hires/Multicolor-Interlace), I think its not such an easy task...
Over 10 years ago we put out some kind of "beta" Version of this "ILM" - it's to be found on the wellknown FTPs if you really want to take a look ;) If I could only find more time and activity to finish the user-friendly version... or should I rather kick my own butt and code a PC_Editor???
Copyfault |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@copyfault: I could imagine it would be kinda hard to code a pixel plotter like that on the c64. It could easily become a bug hell. In C++ or Java it would be a lot easier I think, but I haven't got any intentions of trying though.
Btw, I just had a closer look at the famous 6 sprites FLI routine by Ninja, and to my surprise it looks like it's using more than 8 cycles per line on most of the lines, e.g.
SRE $d018
STA $d011
Which adds up to 10 cycles, according to Graham's opcode list: http://www.oxyron.de/html/opcodes02.html
Guess there is something I don't know here... Jackasser also talks about that "6 sprites take minimum 1+6*2=13 cycles (if you use RMW-instructions)" - I always though the formula would look like "3+6*2=15". And I don't even know what RMW-indstructions is...
Could someone please help me feel a bit less lame?
|
| |
NoiseEHC
Registered: Feb 2005
Posts: 51 |
Cruzer, read this (little tables at the half of the page):
http://unusedino.de/ec64/technical/misc/c64/64doc.html
If an opcode does a write cicle or two (RWW) it can steal 1-2 cycles from the 3 cycles long period which happens before every VIC DMA (sprite read or bad line).
Sprites take 3 priordmaperiod + 2*spritecount.
Bad line takes 3 priordmaperiod + 40.
FLI takes 40 (no 3 priordmaperiod).
HTH
Ninja: your routine is soo braindamagingly cool... :)
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Interesting... So the VIC actually steals 3 cycles even though it only needs 1. But at least nice that you can steal 2 of them back.
Yep, Ninja's routine for sure is one of the kewlest pieces of coderpr0n ever. |
| |
NoiseEHC
Registered: Feb 2005
Posts: 51 |
Actually the VIC does not need even 1 cycle. The fact is that the 6510 is only stoppable when it does a read cycle. Because the longest write cycle length is 3 (interrupt) the VIC needs the 3 cycles long period to play safe...
BTW my routine will be better :)
PS: Note also that on an NTSC chip this routine would be trivial to create because of the +1 cycle before the sprites... |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@NoiseEHC: just in order to exactly know what to think about: the routine you'll sooner or later come up with will be able to do 200 lines FLI with 6 sprites in every line, and this interlaced - or did I get that wrong? Hmm, maybe 200 lines FLI+6sprites can be done, have some kind of idea, but INTERLACE??? I have to think more about this FLI-sudoku ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
200 lines FLI + 6 sprites on all lines can NOT be done. How the hell did you plan to multiplex the sprites beyond 168 lines???
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
This *is* getting interesting. Call me when you're done! ;) How many are we now that has got no further result than headache?! Would be nice to see us all bite the dust :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Just wanna hint some things too, all EMUs and seemignly different real VIC-II versions all fetch the sprites differently. So if you manage to get unique sprite lines that work in VICE, don't expect it to work on the real thing or vice versa... For instance in VICE every 4th line in ninja's code fetches the sprites from the pointers pointed by the screen that was used the line before, not the current screen etc.
=) |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Code it already so I can start pixeling David ... |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I wanna see 200 lines FLI + 6 sprites before I believe it too. Right now I would rate it "impossible." Hope that magic word can motivate you to do it, NoiseEHC. :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: I wanna see 200 lines FLI + 6 sprites before I believe it too. Right now I would rate it "impossible." Hope that magic word can motivate you to do it, NoiseEHC. :)
me too :) |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Don't worry, you all WILL see it. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Crossbow, you listening? |
| |
Ninja
Registered: Jan 2002
Posts: 406 |
Thanks a lot for your positive comments, guys! :)
NoiseEHC: I think I know what you are trying to do. I wish you good luck. Would be cool if it works out!
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
I'm really getting the feeling I'm being the dumbass here..... both clarence + ninja seem to get it.. and i think 200 lines is impossible.. hmm
let me think..
to get 200 lines, you either have to multiplex, or stretch
only way to stretch == $d017.. only way to multiplex is $d000.. but still you need to change $d018/$dd00 and $d011 every line..
sounds impossible.. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Maybe it's something with some weird illegal opcode that writes to d018 twice, so one command can store the d018 value for two lines, which makes it possible to store to d001 on the 2nd line? |
| |
HCL
Registered: Feb 2003
Posts: 717 |
No illegal is *that* wierd :). I see one possibility by having a 16-lines FLI-loop in stead of 8. Then you can omit a store to d018/dd02 every 8:th line since VIC will read new gfx anyway. Possibly you can use those 4 cycles to make multiplex, but this must me a real hell! I don't wanna see those sprite pointers ;). |
| |
WVL
Registered: Mar 2002
Posts: 886 |
HCL : correct ;) too bad i can't edit my last anymore :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
AAAAAaaaarg!!!! Why didn't I think of that! I'm teh stupid ONCE AGAIN! I know the answer though, I don't do 4x4-modes like u HCL hence I'm not used to that FLI-thingie. =) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Ahh yes, I think you got it HCL! :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
I guess this was what Clarence and NoiseEHC was referring to when they said that we will see it. =) |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
This thread is like a (wet) dream come true!
Really looking forward to seeing this NEW format with an editor for it..
Doesn´t matter when,I am a patient man. ;)
True Wizkids,all of you!! 8) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@HCL: this was also my little idea, omitting the $d018 resp. $dd00-change every 8th line. But this idea is still not enough to get this brainf*cking mode interlaced... still wondering how this could be done, maybe no 16-lines FLI-loop but some larger one... |
| |
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: 5022 |
IMHO hires pix shouldnt be laced for more colors... |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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: 466 |
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 |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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: 5022 |
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: 5022 |
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: 5022 |
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: 466 |
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 :)). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The magics of the code generator :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Well, after 18 years we are almost there.. I managed 124 lines in 2006, but that was not good enough.. Finally I got to 166 lines in Halloweed 3. The main problem was keeping the sprite data unique as I thought way back.
So now.. how do we get to 200 lines? |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Congrats guys, well done pushing the limits. Must be a hell of a memory layout to accomodate the illegal opcode register manipulations (and finding a working combination). :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Yes, the memory layout is completely fucked up. Actually there are 3 'solutions'. It starts with one, and has to switch to a second one in the end. There are some special lines in the middle to get the switching from solution 1 to solution 2 working. At the end of solution 3 I needed some special lines aswell to avoid problems with sprite uniqueness again.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
amazing work, WvL!... now make a converter so we can actually use it for GFX! ;-D
I remember Crossbow had a look at Ninja's code and was seriously impressed and guessed that he must have worked many months on solving this.. and apparently he did, he said that he spent about a year on the train to work and back on his 6 sprite routine!
Now, the only thing I wonder about, both with your and with Ninja's part: Why do you guys always use graphics that do not show off the full FLI coloring? ;-) Yours is better than JB's in Ninja's part, but it could still be a half- or even quarter-FLI pic!..
Just tested in VICE 3.1 - No worky, good job, Werner! ;-D You br0ke the emu, vice devs many headaches now... |
| |
WVL
Registered: Mar 2002
Posts: 886 |
We are at VICE 3.7 now and that works perfectly :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
crazy code man, what do you mean by special lines? if there is no time for anything how can you even change dd00 ? :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
@Oswald : I mean lines that do not follow the 8-line repeating loop. To switch between loops, you have to switch dd02 and d018 to work in the new loop. I also found a good spot that didn't need a d018/dd00 write so I could refresh A and X.
I even found a solution with a repeating 16 line loop not needing a d018/dd00 write every 8th line, but couldn't make it work past 124 lines..
Also, I couldn't find a solution with good A,X,Y,A&X,A&Hibyte to multiplex the sprites for the last row. And even then you'd need a combination of a last loop that does not need d018/dd00 writes AND had proper register values for the multiplex.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
UFLI?
Quoting WVLWell, after 18 years we are almost there.. I managed 124 lines in 2006, but that was not good enough.. Finally I got to 166 lines in Halloweed 3. The main problem was keeping the sprite data unique as I thought way back.
Congratulations!
Quote:So now.. how do we get to 200 lines?
Excellent question.
Back in 2019 I wrote a limited instruction simulator/search function that allowed me to find a few thousand solutions to "build a loop to display a 6 sprite 200 pixel high wall over FLI," but none of them managed to avoid reusing sprite data past the 168th line. I thought I'd make a bigger splash if I managed to solve the latter issue instead of just making a demo with what I had, but instead I just failed to beat you to the punch on the 168 line version (publish or perish!).
My approach was to search for 16 line loops that had a free instruction twice per loop (no need to change either of dd02 or d018 at the end of a char row), and I had a cunning way to use the free instruction to update one Y position every eight lines during the leadup to line 168
I think I took a few runs at using one loop above line 168 and a different loop below, but every combination of compatible loops from the solution set I found still had collisions in their sprite access patterns :-/
I got a little bit distracted with other projects after that, but I really should get back to it one of these days.
(my starting point was - Ninja did it, and while I didn't read his code I knew it was published in No More Secrets, so unintendeds must have played a part in his solution.. and the DMA burden says RMW instructions are necessary to be able to do the requisite two instructions per line in the cycles available..) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
It sounds you ran into the same problems that I did. I tried to prove mathematically that you will always run into a collision above line 166, but I couldn't quite prove that.
So it might still be possible. I didn't restrict too much, maybe more restrictions help. I wonder how you wanted to do the sprite multiplexing. I couldn't find suitable solutions with correct values for a,x,y etc, but maybe I should have been more clever and also search for solutions in which you can multiplex with ASL $d001, or ROR $d001 or something, but that can't work: you need a 4 cycle instruction, so only sta/stx/sty/sax... |
| |
Repose
Registered: Oct 2010
Posts: 222 |
Speaking of computed graphic modes, do nuvie's use any special tricks? I saw a claim that it was freely coloured but needed to use REU to do this. Is it just stuffing colour RAM per line? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
I seriously doubt that; I already had to bend over backwards to get an 11 char wide free–colour image for REUtastic |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
I seriously doubt that; I already had to bend over backwards to get an 11 char wide free–colour image for REUtastic |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
I really should add Oswald to the credits for that one. Is there a role of “fellow gymnast”? |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
:)) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Speaking of computed graphic modes, do nuvie's use any special tricks? I saw a claim that it was freely coloured but needed to use REU to do this. Is it just stuffing colour RAM per line?
Nuvie's are in Nufli format : hires every second line FLI with 6 sprites underlayer + 1 sprite to cover the FLI bug.
It's certainly not free coloring. |
| |
Burglar
Registered: Dec 2004
Posts: 1033 |
there should be a link to wvl/xenon's achievement here: Halloweed 3 - VIC or Weed, so there, last part. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Nuvie's are in Nufli format : hires every second line FLI with 6 sprites underlayer + 1 sprite to cover the FLI bug.
It's certainly not free coloring.
Actually it's two sprites on (or rather under) the FLI bug! ;-) One muco and one hires. and there's 40 char FLI every 8 lines, too, so in practice the FLIbug (5 colors/4 colors+lt.grey) is actually more colorful than the rest of the picture (3 colors per 8x2 area max) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
soo... a 166 line high nufli max picture editor / converter would be nice :) |
