| |
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 |
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
There was an editor on disk 0 of the demo? |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
was there? then I should look again when I get home! :_)
------------------------------------
http://zomgwtfbbq.info |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
I'd like to know the technical details behind the format - how does it work? |
| |
Ksubi
Account closed
Registered: Nov 2007
Posts: 87 |
Having played around quickly with the editor, I think you can have 4 colours per 4x8 block, that is 3 colours plus the background. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: I'd like to know the technical details behind the format - how does it work?
basically like 4x4 in other words like every 4th line fli. the trick is that the VIC only reads d800 information on badlines, so you have about 3 rasterlines to rewrite $d800 on the fly in the middle of the chars. then I think you would reset $d800 on the border area.
so hcb is basically every 4th line fli - but d800 is included in the new colors. |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
wait, so it still has that shitty FLI bug? lame..
------------------------------------
http://zomgwtfbbq.info |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Thanks Oswald, I think I get it now!
So in essence:
(Badline, $d800-$d827 is fetched by VIC)
Routine start LDA/STA new colors into $d800-$d827
(4 lines later we trigger a new badline, $d800-$d827 is fetched again, but this time we have new values!)
... repeat for next line etc.
If I count correctly the lda/sta for 40 colorram-values should take 240 cycles, which is just about doable in 4 rasterlines, so it all works out nicely.
-edit- and if we have the FLI-bug in effect, we can skip 3 of those, so we only need to update 37 colorram-values.
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
dont forget that there are only 16 different colors -> there's no need for 40x lda # ;) so you can do it with 16* lda # ->
40 writes = 160 cycles + 16 lda # = 32 cycles = 192 cycles, almost there ;) and if you dont use the first 3 chars, you're in business!
BTW, now that i think of it, you only need 8* lda #, because if you load values 8-15, you can also write values 0-7 if you use SAX. profit! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
And no one says all d800 values change for every line, so the # of sta's can probably be < 37 too. Unless you wanna make effects with it, like the fading in EoD. In that case it's probably better to keep all the sta's.
Quote:wait, so it still has that shitty FLI bug? lame.. But there's rtime for 8 sprites that can cover the bug. You could also get rid of the bug, but that would limit the height of the gfx to 4 chars.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
As the updating is dynamic, its probably a better idea to change all 40 cells. Its understandable that there will be less than 40 changes in each line but there would be no consistancy. Some char lines may have 12 changes, some 23 etc and having to modify before bad line and then change back to the previous after the bad line etc.
Its possible to feed the image data through some type of 'converter' which can ensure only a maximum of x amount of changes with less color error
|
| |
Danzig
Registered: Jun 2002
Posts: 429 |
@algorithm: think about it again, maybe not because when you change the colorvalue in a fader, you change it all the same (like #0f gets #01 regardless how many pixels there are in color #0f per 4x4-line)
if i'm right? it's hard to see it... i don't know :D |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
No i understand. I tried to split $d800 when i was on the oxyron party. But i used all 40 lda# so i ran into trouble doing it in 4 rasterlines. anyway i made a split every 5th rasterline in textmode.
If we use only 16 lda# (or 8) and want to dynamically update the screen, we have to modify the speedcode of the sta's.
This is only possible, if the number of characters with color x stays always the same. Perhaps a techtech with colorram could be possible or fpp plasma. but a more complex effect not.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
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 |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
I don't get it? How do we get 2 more colours per 4x4 with fli every 4 lines?
As I understand in full FLI you can change the bg colour every line, have 2 unique colours per 4x1 and have a 3rd colour which is fixed to the 4x8 still. Am I wrong here?
And in the HCB editor you get a new bgcolour every 4 lines, and 3 extra colours per 4x4. And also it seemed as if you can use all 40 chars.
But yeh, I do not have a lot of clue about the coding details at all, just a bit confused about this. |
| |
Wile Coyote
Registered: Mar 2004
Posts: 637 |
From the demo of HCB that appears during EoD, HCB appears to be the same as multi colour bitmap, only each char is 8x4, opposed to the normal 8x8.
/I once had an idea for new graphics mode. I called it Multi Colour Bimtap +1. The idea was to have the usual Multi Colour Bitmap screen, with an extra possible colour (provided by 1 layer of expanded hired sprites). I had this idea pre 1990. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
ptoing: Aren't you mixing up HCB and the 4x4 dither plasma?
HCB means FLI every 4th line as well as "splitting" the d800-colors by replacing them on the fly with the excess cycles in the displayer.
Dithered 4x4 is, as far as I remember from the note, done like Xbow did the 16 color 2x2 plasma in the bonus part of DEM. This means both splitting d800, plus having a layer of sprites where the colors of each sprite and the 2 multicolors (adds up to 10 colors) are updated too. This gives each char a 4th color, but limits the width of the effect to 10 chars, or if the bg color was also used it could be 11, and you could even put half an extra char on each side to make it 12.
I might have an idea of how to make it wider though, so yes, EoD CAN be beaten! ;)
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
I don't understand HCB. I mean, I understand how it's implemented (the code at $2000 and up is easy to follow), but I don't see the advantage over plain FLI. It only uses two screens instead of eight, but the d800 speedcode eats up the difference. 3+1 colors per 8x4 pixels doesn't sound more flexible than 1+1+2 colors per 8x1. It still uses 100% rastertime.
What gives? |
| |
Tao
Registered: Aug 2002
Posts: 115 |
Quote: I don't understand HCB. I mean, I understand how it's implemented (the code at $2000 and up is easy to follow), but I don't see the advantage over plain FLI. It only uses two screens instead of eight, but the d800 speedcode eats up the difference. 3+1 colors per 8x4 pixels doesn't sound more flexible than 1+1+2 colors per 8x1. It still uses 100% rastertime.
What gives?
Hey, it's possible to do. What nobler reason could there possibly be to implement it? Actually being useful? Bah. It's not like the 9 sprites in the lower border in Krestology 3 was particularly useful either. It's still cool :-) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I don't understand HCB. I mean, I understand how it's implemented (the code at $2000 and up is easy to follow), but I don't see the advantage over plain FLI. It only uses two screens instead of eight, but the d800 speedcode eats up the difference. 3+1 colors per 8x4 pixels doesn't sound more flexible than 1+1+2 colors per 8x1. It still uses 100% rastertime.
What gives?
You can free raster time (if only a little) by optimizing the picture/displayer.
First you can save two cycles for each color value that isn't used on that particular line. Secondly you can omit updating colors that are the same on this line too, saving 4 cycles for each occurance.
|
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: I don't understand HCB. I mean, I understand how it's implemented (the code at $2000 and up is easy to follow), but I don't see the advantage over plain FLI. It only uses two screens instead of eight, but the d800 speedcode eats up the difference. 3+1 colors per 8x4 pixels doesn't sound more flexible than 1+1+2 colors per 8x1. It still uses 100% rastertime.
What gives?
The gain is obviously 8x4 fades instead of 8x8 fades. :) |
| |
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: 1055 |
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: 886 |
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: 362 |
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: 429 |
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: 466 |
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: 886 |
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: 362 |
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: 2839 |
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: 702 |
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) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
It should also be possible to update only 20 $d800 values every 4 lines instead of 40 every 8 lines, so the fancy stuff can be spread more evenly, good for digis. |
| |
Style
Registered: Jun 2004
Posts: 498 |
how so krill? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
As in, you update one half of the chars every 8 lines, and the other half 4 lines after the other half, if you get the drift. What exactly is unclear to you? |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@WVL: not exactly; I'm not planning to use 2 different displayers but rather a full_screen_d800_update in teh lower border. Ofcourse there are also only 7 x lda#col needed (not 8 as I wrote yesterday as the same trick like in the "normal" display rout applies)
@Krill: hmm, I do not really understand what you mean... HCB as it is now updates 40 chars every 4 rasterlines. It will surely be possible to only update 20 chars, but as soon as the new bl occurs the other 20 chars won't hold a new color. Maybe you're thinking about some interlace like stuff (toggling the gfx beginning by +/- 4 rasterlines every frame points into that direction;)) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
No, i have to admit i had an error in reasoning... never mind :) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: 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/
Yes, but that makes the picture 4 pixels smaller at the top, and 4 pixels at the bottom.. 8 pixels loss for 50% more rastertime free... (HOLD ON! maybe it's only 4 pixels loss if you make good use of the last bitmap lines.. since you only need bad-lines possible over 196 pixels of the picture, instead of 200 for fli -> you can move the picture 4 pixels down compared to a standard fli picture..)
So i guess you can do it with only 4 pixels loss at the top. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Totally okay sacrifice. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Totally okay sacrifice.
Dont forget you also need 2 bitmaps! and sadly, that means you also need 2 more screens.. because you cannot fit the 2 bitmaps+ 2 screens in the same vic bank. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Oh noes /o\ But wth, easily deriveable from your original bitmap + screens, so only more runtime space. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Damn, I completely missed this discussion back when it occurred; just found it via http://www.atlantis-prophecy.org/recollection/?load=world_of_de..
I thought I invented HCB in 2013, and have been meaning to release a pic for the last year.
Apparently I was five years behind the curve lol*.
FWIW I got as far as grouping the STAs by colour, but didn't use SAX, so I still needed 16 LDAs per line. It still leaves enough cycles free to for a sprite overlay to cover the FLI bug in the lower halves of the chars in the first three columns.
I was doing 37 writes every four lines, so no time was required in the border.
*(my wife just corrected that to lolb - laugh out loud bitterly) |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
HCB, I thought I would be famous forever as the only person in the world who managed to make not one but two(!) pictures in this format. ;) |
| |
Digger
Registered: Mar 2005
Posts: 421 |
|
