News:

PlayBASIC2DLL V0.99 Revision I Commercial Edition released! - Convert PlayBASIC programs to super fast Machine Code. 

Main Menu

Plasma generation

Started by thaaks, May 18, 2006, 04:34:46 PM

Previous topic - Next topic

thaaks

I added some code to generate some random plasma to the code tank.

Here is some piccy:
[attachmentid=668]

Have fun with it,
Tommy

Alex777

pretty cool, Tommy!  fractals?

thaaks

Yup.
It's called random midpoint displacement.
You start with a rect or square and four random colors for the four corners.
Then you divide the rect into 4 new rects by adding a center point to the starting rect. The color of the center point is the average of the four corners' colors plus some displacement based on the size of the rect (the bigger the rect the bigger the displacement).
Then you divide each rect into 4 new rects by...hey here's the recursion bit  ;)
You do so until you have a one pixel big rect where the color is the average of the four corner colors. You draw that pixel in the given color and end the recursion.

I found the source code in the LudumDare code entry of Phil Hassey (Galcon 2006) who used some code of Justin Seyster (Plasma Fractal).

Phil Hassey also added some code to reduce the colors to some blue and violet tones and he also added more black to get nice space nebulae (see the screenshot on his page).
That's what I will do next  :D

Phil's game is also nice and fun to play, btw. Completely coded in Python (using PyGame) and C++. This guy uses some kind of preprocessor to write C++ code that looks like Python code. Then he uses his preprocessor (based on SWIG) to convert it back to proper C++. Weird.
Although I can code in Python and like some of its features (like returning multiple values from functions which PlayBasic also offers! YES!) I find it hard to read.
Code based on indentation is very strange I think!

Cheers,
Tommy

kevin

Cool, just watch the number of buffer locks your doing though.  (Ie. each pixel requires a buffer to be locked/unlocked)  Locking can cost up to 5 ms on it's own.

 So either render to FX buffer, or manage the buffer locking yourself


lockbuffer
DrawPlasma(400,400)
unlockbuffer

Tracy

Looks pretty sweet, Tommy. I'm impressed.

thaaks

QuoteCool, just watch the number of buffer locks your doing though.  (Ie. each pixel requires a buffer to be locked/unlocked)  Locking can cost up to 5 ms on it's own.

  So either render to FX buffer, or manage the buffer locking yourself


lockbuffer
DrawPlasma(400,400)
unlockbuffer

Thanks for the advice, Kevin!
I first wanted to get the code working. Then for optimizing.
I plan to render the plasma into an image - does lock/unlock buffer also work there?
Anything to take care of in this case?

Cheers,
Tommy

kevin

QuoteI plan to render the plasma into an image - does lock/unlock buffer also work there?

yes.  

QuoteAnything to take care of in this case?

erm.. what ? :)

thaaks

Quoteerm.. what ? :)
I just was not sure if I had to add an additional command before locking/unlocking buffers while rendering into an image or something like that.
Or maybe I'd need to call PrepareFXImage or maybe I must not or whatever.

But it seems there is nothing special to take care of. Hopefully I find some free hours during the weekend to fiddle around with this... :rolleyes:

Tracy

Wait a minute... I thought the locking/unlocking of the buffer only made a real difference when drawing to the screen?

The way I understand it: Unlocking/locking the buffer is useful when drawing to the screen, or when you're drawing to an image that's not in the FX buffer. If, say, you were drawing pixels to an FX image, would you still need to lock the buffer?

Big C.

#9
QuoteWait a minute... I thought the locking/unlocking of the buffer only made a real difference when drawing to the screen?

The way I understand it: Unlocking/locking the buffer is useful when drawing to the screen, or when you're drawing to an image that's not in the FX buffer. If, say, you were drawing pixels to an FX image, would you still need to lock the buffer?

Tracy, if I understand the Help of the command UnLock (see FACTS) correct then I would say no because there arn't any noticeable effect when drawing to FX images.

The speed advantages would be when drawing to screen or normal images.. But I'm right?

kevin

QuoteIf, say, you were drawing pixels to an FX image, would you still need to lock the buffer?

Yes, you should.  As anything that draws to an FX buffer, is attempting lock the surface prior to rendering also.  However unlike locking video buffers, this is virtually instant.  So manually pre-locking/unlocking won't really give you much (if any) free time back.   The only exception, might be when performing lots (1000's) of pixel plots.  Then you might gain a little.. might.

thaaks

Space, the final frontier  :D

I worked on the code a bit more to generate some space nebulae.

Here are the results:
[attachmentid=680][attachmentid=681][attachmentid=682]
[attachmentid=683][attachmentid=684]

Hope you like the results as much as I do.

I will add the modified source code to the code tank.

Have fun,
Tommy

Tracy

QuoteSpace, the final frontier  :D

I worked on the code a bit more to generate some space nebulae.

Here are the results:
[attachmentid=680][attachmentid=681][attachmentid=682]
[attachmentid=683][attachmentid=684]

Hope you like the results as much as I do.

I will add the modified source code to the code tank.

Have fun,
Tommy

Pretty sweet, tommy. I like it. :)