| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
'HCL-plasma' - how does it work?
That fullscreen-fast-plasma-thing that we saw quite a few versions of in Edge Of Disgrace (with sprite zoomer on top, in sideborder, with techtech etc.) - what's the theory?
It is pretty obvious from speed and size that it is not done using per-pixel-code...
My theory was that it was done using FPP-technique, ie. we have a base-plasma-picture, and then by displaying cleverly chosen lines from this base-picture we get the plasma.
I did some prototyping on PC to test this theory, but I can't get anything that looks correct. Am I barking up the wrong tree here? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you got the theory alright :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Only that it's been done long before EoD already. :D |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
How a simple version works:
step 1: have an FPP routine of your choice. It's gonna need to be sprite FPP if you're in the borders, natch, charfpp if you don't, bitmap fpp if you want more colours, or some crazy assed fun combination.
step 2: for each possible FPP line (you need as many of these for maximum smoothness) calculate a sinus line for finalY=yval for this line. You can do this each frame, or once and just move the y sinus.
step 3: calculate each y line in your raster IRQ, and set the FPP display list appropraitely from a table based on the y output.
step 4: display fpp according to display table.
maybe i'll upload one appropriatly commented and commentated to codebase later this week, if people are interested in such things. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Who came up with the name HCL-plasma?
..and if Mr.Krill would be so kind to show us a *link* to where this has been done long before.. Funny, i don't remember any full-screen-side-border-FPP-plasma, will be most interesting to see. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Who came up with the name HCL-plasma?
..and if Mr.Krill would be so kind to show us a *link* to where this has been done long before.. Funny, i don't remember any full-screen-side-border-FPP-plasma, will be most interesting to see.
Wasn't the end part of Cycle some kind of full screen sideborder FPP-plasma? |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Hmm, i don't really get what you're discussing here. It's mostly talk about the FPP-routine.. The're nothing fancy about that, except possibly for the plasma with the sprite-stretcher on top. The tricky thing in this plasma (compared to what we have already seen) is how the x-shit works. But i'll leave that if noone is really interested ;).
<edit>
@JA: That's exactly what's the difference. Those all-border "plasmas" only contain some kind of FPP-routuine and thus only a y-plasma (typically double sinus indexed plasma), the x-"plasma" is just some static graphics that has been generated once. The plasma we have here has an x-component also updated every frame, also typically a double sinus indexed plasma.
</edit> |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
I didn't intend to step on any toes by calling it 'HCL-plasma', I just thought that everyone would know what I meant then, since the type of plasma I'm talking about has appeared in a few BD demos now (Royal Arte, Cycle, Edge Of Disgrace).
Seems like I have the technical theory correct then.
I have a precalced picture that looks about what a single frame from a normal per-pixel-double-sine-plasma looks like.
Then in the displayer I pick y-lines from that above plasma indexed on a double-sine.
However somehow it don't get that 'plasma'-feeling in it.
But now we hear that HCL has added some kind of extra X-component magic to it, which would explain why it looks even better in EoD. I'll have to start Cycle again and compare the last-part-plasma there.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: That fullscreen-fast-plasma-thing that we saw quite a few versions of in Edge Of Disgrace (with sprite zoomer on top, in sideborder, with techtech etc.) - what's the theory?
It is pretty obvious from speed and size that it is not done using per-pixel-code...
My theory was that it was done using FPP-technique, ie. we have a base-plasma-picture, and then by displaying cleverly chosen lines from this base-picture we get the plasma.
I did some prototyping on PC to test this theory, but I can't get anything that looks correct. Am I barking up the wrong tree here?
it's Graham's invention. I think the mod's should change the topic title if possible, before the credit will go to HCL in the scene's mind. :P |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: I didn't intend to step on any toes by calling it 'HCL-plasma', I just thought that everyone would know what I meant then, since the type of plasma I'm talking about has appeared in a few BD demos now (Royal Arte, Cycle, Edge Of Disgrace).
Seems like I have the technical theory correct then.
I have a precalced picture that looks about what a single frame from a normal per-pixel-double-sine-plasma looks like.
Then in the displayer I pick y-lines from that above plasma indexed on a double-sine.
However somehow it don't get that 'plasma'-feeling in it.
But now we hear that HCL has added some kind of extra X-component magic to it, which would explain why it looks even better in EoD. I'll have to start Cycle again and compare the last-part-plasma there.
how do you calculate a plasma?
mix 2 sines to get a "verticalsine"
mix other 2 sines to get a "horizontalsine"
then each pixel: pixel(x,y)=palette(vertsine(y)+horsine(x))
note that on a horizontal line vertsine(y) is constant. so if we reduce the vertsine values to smth like 0-16, then we may precalculate 16 gfx lines (horsine still changes each frame, thats where you got it wrong!) and choose from them along the line as dictated by adding up 2 sines where the result is 0-16. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Well, maybe i mis-interpreted the term "base-plasma-picture".. I thought of this as a static picture, but in the case of EoD, this base-plasma-picture is always calculated and updated each frame.
This effect is so over-used ever since Krestyron, so i thought everyone knows the difference between this and the static FPP-plasma in e.g. Coma Job.
With a faster calculation of the base-plasma-picture, i managed to squeeze out a little bit more of this poor plasma-effect, but then again it felt a bit old in 2004 already when i coded it.. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Quote: it's Graham's invention. I think the mod's should change the topic title if possible, before the credit will go to HCL in the scene's mind. :P
Yepp, shit like that always happens. When you reach a certain level of popularity, people will start giving you credit for stuff that others made.. That also happens to Graham. e.g. the all-border sprite-zoomer from ComaJob, which ppl think is Graham's invention, but just look at this.. Fierce Creations or was it Design Overdose. And many more examples in *real life*(tm).
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: I didn't intend to step on any toes by calling it 'HCL-plasma', I just thought that everyone would know what I meant then, since the type of plasma I'm talking about has appeared in a few BD demos now (Royal Arte, Cycle, Edge Of Disgrace).
Seems like I have the technical theory correct then.
I have a precalced picture that looks about what a single frame from a normal per-pixel-double-sine-plasma looks like.
Then in the displayer I pick y-lines from that above plasma indexed on a double-sine.
However somehow it don't get that 'plasma'-feeling in it.
But now we hear that HCL has added some kind of extra X-component magic to it, which would explain why it looks even better in EoD. I'll have to start Cycle again and compare the last-part-plasma there.
better calling it FPP plasma, as the technique (*drums*) was invented by Graham. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Yepp, shit like that always happens. When you reach a certain level of popularity, people will start giving you credit for stuff that others made.. That also happens to Graham. e.g. the all-border sprite-zoomer from ComaJob, which ppl think is Graham's invention, but just look at this.. Fierce Creations or was it Design Overdose. And many more examples in *real life*(tm).
was there an fpp plasma before graham's one ? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Shadow: You also might wanna "cycle" the colors, i.e. have a constant that you add to the sine values, which is incremented for every line in the generated pattern. Anyway, experimentation is the way to go for getting the plasmatic feel. It usually takes a lot of trial & error before it looks good.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Quote: was there an fpp plasma before graham's one ?
No, but a sprite-zoomer. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Aha! So the base-picture IS recalculated each frame, no wonder I couldn't get it to look right! |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Quote: How a simple version works:
step 1: have an FPP routine of your choice. It's gonna need to be sprite FPP if you're in the borders, natch, charfpp if you don't, bitmap fpp if you want more colours, or some crazy assed fun combination.
step 2: for each possible FPP line (you need as many of these for maximum smoothness) calculate a sinus line for finalY=yval for this line. You can do this each frame, or once and just move the y sinus.
step 3: calculate each y line in your raster IRQ, and set the FPP display list appropraitely from a table based on the y output.
step 4: display fpp according to display table.
maybe i'll upload one appropriatly commented and commentated to codebase later this week, if people are interested in such things.
sad panda, what do you mean with bitmap fpp, i understand sprite fpp and char fpp but never heard of bitmap fpp...
i am just curious.....
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
You can do bitmap-fpp just like char-fpp, at least the 20-cycle timing will allow fpp-behaviour. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Hcl: Nice i didn't know ,do you know a demo with this effect ?or do you mean the already mentioned plasma fpp?.
and what about fli fpp?.. works fli fpp the same as bitmap fpp? or am i totally wrong once again.....
|
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
Quote: No, but a sprite-zoomer.
But I think, Graham was first with this kind of zoomer, presented in Parts. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Quote: But I think, Graham was first with this kind of zoomer, presented in Parts.
That's a char-based zoomer. But yes, that's his invention.
Oh, and bitmap-fpp.. Yes you get some FLI-like stuff there. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: That's a char-based zoomer. But yes, that's his invention.
Oh, and bitmap-fpp.. Yes you get some FLI-like stuff there.
I'm not sure I invented the all-border sprite zoomer.. there might have been some before. The first that comes to mind is the one by Glasnost in The Unnamed Demo ofcourse :) even when that one is a rather different technique (only a few pixels high..)
Might be interesting to tell you the difference between the zoomers in Design Overdose, Comajob and Pearls for Pigs.
Design Overdose and comajobs are basically the same, they're based on a stretched sprite routine, with $d018 switches to get extra lines. For every 21 pixels in the sprite, there are 3 d018 options, to give a 63 pixel high picture (so if you stretch the sprite 3x, you can display the picture at 1x zoom). If you dont stretch the sprite, you're at minimum height, at 1/3 zoom.
I think this 'shrinking' trick was invented by Pernod btw ;) just to give some credits ;)
The difference between the comajob one and the one is design overdose is that graham worked hard to make it more flexible, especially by rearranging the sprites when it moves into the borders..
The one in Pearls for Pigs is different. It uses sprite-fpp to shrink and expand in y, basically this allows you to shrink down to 1 single pixel, or to display the picture upside-down. You can also move the picture completely in the upper border (meaning it's possible to only show the bottom pixelrow at the complete top of the screen). With the $d018 technique, you can only move the first 2 pixelrows out of the topborder.. Basically this one is a lot more flexible :) |
