| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
HCB - what is it and what can we do with it?
okay, so.. I was (and possibly others are) wondering what HCB is exactly? what are the possibilities and limitations of this new GFX mode? and where can I get an editor for it? :_)
------------------------------------
http://zomgwtfbbq.info |
|
... 32 posts hidden. Click here to view all posts....
|
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
Not only that - mind that this is quite a flexible mode from a graphicians point of view. Ok - it's hard to tell since I haven't drawn an entire pic in this editor, but it feels like a quite nice format to work with. Limits within the 8X8 (=d800) is actually one of the things which really has irritated me while working with FLI. Unless you really want the pic to show off as FLI, you don't need the fast vertical changes in color that FLI enables. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: The gain is obviously 8x4 fades instead of 8x8 fades. :)
Hah, yeah, that's a good one :) And you only have to change the lda's, so fading d800 is "cheap".
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Hah, yeah, that's a good one :) And you only have to change the lda's, so fading d800 is "cheap".
and you can buffer the 2 screens to 2 other screens.. ;) |
| |
DeeKay
Registered: Nov 2002
Posts: 363 |
Quote: There is not much of a dramatic increase in color/image quality when splitting $d800, nonetheless it is something which has not seem to have been done before. May as well just do fli per 4 lines and get an additional 2 colors per 4x4 block. and leave the $d800 twiddling. Nonetheless the restrictions have been reduced even if it does not make much of a visual difference (and smoother 4x4 defading/fading in multicolor in comparison to 4x8
Well, Rayden did a FLI-Plasma in his SCPU demo that had new $d800 in every line, but for standard c64 this is probably the first time, yes! ;-)
I still find it useless, since it uses just as much rastertime as FLI, also has the FLI-bug (which you can btw cover nicely with sprites, too, in FLI, if you want to! 8) Ever seen Xbow's FLI-Profi?) and because it essentially offers LESS colors than FLI..
Seriously: How many people have ever run out of colors in MCol FLI? How many times did you think "Damn, i wish i could have another $d800 in that char" when working in FLI? 8)
For me Mcol-FLI is pretty much arbitrary colors already, so why would I need 3 new colors every fourth line instead of 2 new colors every line? 8) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: Well, Rayden did a FLI-Plasma in his SCPU demo that had new $d800 in every line, but for standard c64 this is probably the first time, yes! ;-)
I still find it useless, since it uses just as much rastertime as FLI, also has the FLI-bug (which you can btw cover nicely with sprites, too, in FLI, if you want to! 8) Ever seen Xbow's FLI-Profi?) and because it essentially offers LESS colors than FLI..
Seriously: How many people have ever run out of colors in MCol FLI? How many times did you think "Damn, i wish i could have another $d800 in that char" when working in FLI? 8)
For me Mcol-FLI is pretty much arbitrary colors already, so why would I need 3 new colors every fourth line instead of 2 new colors every line? 8)
I see the SIZE-improvment... it could get the proper new gfx-mode for intros... |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Interesting mode indeed...
I was curious if this mode would really work without any FLI-bugs. After some q'n'd tests I managed to reveal the FLI-bug on every 2nd 'half char line'. Any other behaviour would've really suprised me;)
Some notes on optimizing the viewer code: just like WVL noted it is enough to work with 8 x lda #col (long live SAX); but it is even possible to just use 7 x lda #col saving additional 2 cycles per 'half char line' (there are max. 3 cols in one char so you can always choose a 'good one' for d800).
A real advantage over normal FLI is the following flexibility: for every 2nd 'half char line' the speedcode for updating d800-colors does not necessarily need to be done in the rasterlines directly before but e.g. like this
rl---hcl---code
---------------------------------------------------------
0---00---(badline)
1---00---update d800cols for next hcl
2---00---"
3---00---"
---------------------------------------------------------
4---01---(badline)
5---01---do some fancy stuff (digis, sprite plexer,...)
6---01---"
7---01---"
---------------------------------------------------------
etc.
This not only allows for some funny things like e.g. digis or sprite plexers but also frees up rastertime considering the complete frame, because updating the d800-colors for _every_ charline in the lower border only needs the 8 x lda #col once!
I'm sure there's even more advantages 'hidden' in this mode. Thanks to HCL for making it real! Me likes it a lot! |
| |
WVL
Registered: Mar 2002
Posts: 902 |
HOLD ON!
You're not updating $d800 every 4 rasterlines now, and I agree that this works.. but. After you've run the displayer once, $d800 holds different data than it did before!
So you need to write $d800 back to the way it was before you ran the displayer for the first time. timeconsuming!
Maybe you can work around it if you have 2 different displayers, but I dont think so.. since the colors you write for the 2nd 'halfline' are now used for the first 'halfline'
Anyway, I think that's a no-go! or at least you can expone the writes, but that's all. (note : this does save on rastertime, since you only need to do 8x lda to restore the _whole_ $d800 screen)
Oh wait. Now i read your message again, this was exactly what you were planning :D I'm teh dumb. And perff : can you add and BBcode? |
| |
DeeKay
Registered: Nov 2002
Posts: 363 |
copyfault: Maybe you can do some other stuff in the second half-char, but keep in mind that a HCB pic is also less colorful than an FLI pic. So for a bit more colors, is it really preferrable over standard Mcol bitmap? 8)
Keep in mind, like Graham said: 90% of all FLI pics can be converted to Mcol bitmap with no visible or just very little loss of color fidelity! ;-) I remember xbow once even did that with the Dutch Breeze FLI-gallery pics, just for shits'n'giggles, and *I* had a hard time telling the difference! 8) And you don't wanna know how much time I spent looking at these fantastic works by Hein! ;-D
I'm rather sure that JB pic in Ninja's 6-sprite FLI-routine could even be converted with ZERO loss! 8)
So, summing up: To get teh color orgasm you need a motive and a gfxian that makes full use of the colors first and foremost. Whenever I do FLI, i make sure it's worth it, check the FLI-Stretcher Crest Logo in Krestage 2 or the end-gfx in Risen from Oblivion VIC. I highly doubt these could be converted to HCB. And don't forget: There's also some mighty colorful bitmap gfx out there that look like FLI already! ;-)
And hey, did I mention that I've seen quite a few Multiplexers over full FLI and also digis (Dane himself did it long ago, and so did Jolz/Ons) already? <:-) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote:
Maybe you can work around it if you have 2 different displayers, but I dont think so.. since the colors you write for the 2nd 'halfline' are now used for the first 'halfline'
But then you can at least toggle the start position +/- 4 scanlines each frame though, using a 2nd bitmap. Rastertime for fancy stuff again \o/ |
| |
algorithm
Registered: May 2002
Posts: 705 |
FLI should only be used if necessary. an extra 7k and nearly full processor usage on a pic that can be displayed nearly as good in multicolor is not worth it at all. The opposite can ofcourse be said to the Hires equivelant (HIFLI). A great example of what can be achieved in MCol mode is in the end part of DEM (Lovely pics by mermaid) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
