1024x768 frame buffer...

Code:

:-D

public partial class Form2 : Form
     {
         Bitmap fireBmp;

         byte[,] fireData;

         Timer t = new Timer();

         Random rnd;

         int w = 1024;
         int h = 768;

         int[] clut;

         public Form2()
         {
             InitializeComponent();
             fireData = new byte[w, h];
             fireBmp = new Bitmap(w, h, 
System.Drawing.Imaging.PixelFormat.Format32bppRgb);
             rnd = new Random();

             clut = new int[256];

             for (int i = 0; i < 256; i++ )
             {
                 if (i >= 0 && i < 64) clut[i] = Color.FromArgb(i * 2, 
0, 0).ToArgb();
                 if (i >= 64 && i < 128) clut[i] = Color.FromArgb(i * 2, 
(i-64) * 4, 0).ToArgb();
                 if (i >= 128 && i < 256) clut[i] = 
Color.FromArgb(255,255, (i-128)*2).ToArgb();
             }

                 t.Interval = (int)(1000 / 30.0);
             t.Tick += new EventHandler(t_Tick);
             t.Start();

             this.SetStyle(ControlStyles.OptimizedDoubleBuffer | 
ControlStyles.ResizeRedraw | ControlStyles.UserPaint | 
ControlStyles.AllPaintingInWmPaint, true);
         }

         void t_Tick(object sender, EventArgs e)
         {
             BitmapData bd = fireBmp.LockBits(new Rectangle(0, 0, w, h), 
System.Drawing.Imaging.ImageLockMode.ReadWrite, 
System.Drawing.Imaging.PixelFormat.Format32bppRgb);

             for(int y = 0; y < (h-1); y++)
             {
                 for(int x = 0; x < w; x++)
                 {
                     if(y == 0)
                     {
                         fireData[x, h-1] = (byte)rnd.Next(255);
                         unsafe
                         {
                             int* pBmp = (int*)bd.Scan0;
                             pBmp[x + (h-1) * bd.Stride / 4] = 
clut[fireData[x, h-1]];
                         }
                     }

                     fireData[x, y] = (byte)((fireData[(x - 1 + w) % w, 
y + 1] +
                                     fireData[(x + 1) % w, y + 1] +
                                     fireData[x, y + 1] +
                                     fireData[x, (y + 2) % h]) / 4);


                     int c = clut[fireData[x, y]];

                     unsafe
                     {
                         int* pBmp = (int*)bd.Scan0;
                         pBmp[x + y*bd.Stride/4] = c;
                     }

                 }
             }

             fireBmp.UnlockBits(bd);
             Refresh();
         }

         protected override void OnPaint(PaintEventArgs e)
         {
             base.OnPaintBackground(e);
             e.Graphics.DrawImage(fireBmp, this.ClientRectangle);
         }
     }


-- 
~Mike

Post a reply to this message

Attachments:
Download 'windowsformsapplication1.exe.dat' (11 KB)

Well, according to the Great Language Shooting, the Mono implementation 
of .NET is slower than several other languages. (*cough* Haskell 
*cough*) It depends on what you call "slow", of course.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 escreveu:
> Well, according to the Great Language Shooting, the Mono implementation 
> of .NET is slower than several other languages. (*cough* Haskell 
> *cough*) It depends on what you call "slow", of course.

The Microsoft implementation isn't listed nor would run on their Linux 
server, obviously.  There's a fair amount of evidence that Microsoft's 
F# is faster than OCaml, which is generally faster than GHC.  There's 
indeed good evidence nowadays that good jit compilers produce code which 
is as fast or faster than code produced by ahead-of-time traditional 
compilers.

Post a reply to this message

You scare me each time with these posts. I open an innocent news mail 
item and then suddenly all alarms go off warning me of a potential 
infection.

Post a reply to this message

andrel wrote:
> You scare me each time with these posts. I open an innocent news mail 
> item and then suddenly all alarms go off warning me of a potential 
> infection.

Sorry... My exe's are safe. But, yeah... some AV suites go nuts with exe 
attachments.

I should copy them to my website and post a link to it, rather than 
attach, anyway.
-- 
~Mike

Post a reply to this message

>> Well, according to the Great Language Shooting, the Mono 
>> implementation of .NET is slower than several other languages. 
>> (*cough* Haskell *cough*) It depends on what you call "slow", of course.
> 
> The Microsoft implementation isn't listed nor would run on their Linux 
> server, obviously.  There's a fair amount of evidence that Microsoft's 
> F# is faster than OCaml, which is generally faster than GHC.  There's 
> indeed good evidence nowadays that good jit compilers produce code which 
> is as fast or faster than code produced by ahead-of-time traditional 
> compilers.

Well, you're possibly right. Difficult to see how to verify or refute 
those claims.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Mike Raiford wrote:
> 1024x768 frame buffer...

I would think there's relatively little need to be slow in a program like 
this, where it's all manipulation of fundamental structures. As in, I would 
think the speed of a program like this in .NET wouldn't necessarily be any 
slower than a similar program in plain C, unless the JIT is just really bad.

Was there really any reason to use the unsafe pointers?

It is a cool effect, tho.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Darren New wrote:

> I would think there's relatively little need to be slow in a program 
> like this, where it's all manipulation of fundamental structures. As in, 
> I would think the speed of a program like this in .NET wouldn't 
> necessarily be any slower than a similar program in plain C, unless the 
> JIT is just really bad.

But, that's sort of my point. :) You don't need to be down to the wire 
to get fast performance out of the system.

> Was there really any reason to use the unsafe pointers?
> 

There was. There are 2 ways to access the bitmap data. One by using the 
setpixel and getpixel functions. This is very slow. essentially every 
access to the pixel data requires a conversion to and from a color 
structure.

The other way is to access the buffer directly, hence the unsafe pointers.

Post a reply to this message

Mike Raiford wrote:
> Darren New wrote:
> 
>> I would think there's relatively little need to be slow in a program 
>> like this, where it's all manipulation of fundamental structures. As 
>> in, I would think the speed of a program like this in .NET wouldn't 
>> necessarily be any slower than a similar program in plain C, unless 
>> the JIT is just really bad.
> 
> But, that's sort of my point. :) You don't need to be down to the wire 
> to get fast performance out of the system.

OK. I'm just saying ... what makes you think it's not "down to the wire" in 
this case?  It doesn't look like you're doing anything in the inner loops of 
the tick that you couldn't do equally well in C, so why wouldn't the JIT 
generate equivalently efficient code?

> There was. There are 2 ways to access the bitmap data. One by using the 
> setpixel and getpixel functions. This is very slow. essentially every 
> access to the pixel data requires a conversion to and from a color 
> structure.

Cool. I've only done large-scale manipulations, not drawing pixel-by-pixel, 
so I guess I never ran into that problem.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Mike Raiford wrote:
> 1024x768 frame buffer...

I estimate I'm getting 0.5fps.

Post a reply to this message