 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Mike Raiford wrote:
>> 1024x768 frame buffer...
>
> I estimate I'm getting 0.5fps.
Wow... are you running Vista, by any chance..? On my WinXP machine, I
was getting about 20fps..
I found that on my Vista machine it runs significantly slower.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Mike Raiford wrote:
>
> 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?
>
Maybe it is, but everything is still managed code. The JIT should
produce efficient code, for sure, and it does. I was just happy to see
that an effect like this can be achieved, and with a relatively large
frame buffer. That's all I guess. Some seem to think that the .NET
framework, or that JIT environments are too slow for these sorts of
tricks, or effects.
I think, didn't someone port Quake to Managed C++?
>
> Cool. I've only done large-scale manipulations, not drawing
> pixel-by-pixel, so I guess I never ran into that problem.
>
Right, the GDI+ functions are generally pretty good for most drawing
situations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Maybe it is, but everything is still managed code. The JIT should
> produce efficient code, for sure, and it does. I was just happy to see
> that an effect like this can be achieved, and with a relatively large
> frame buffer. That's all I guess. Some seem to think that the .NET
> framework, or that JIT environments are too slow for these sorts of
> tricks, or effects.
True. People who never really think about the issues tend to just listen to
the FUD.
> I think, didn't someone port Quake to Managed C++?
Yes, but I'm not sure they ported the "hard parts". As in, it was something
like a few hundred lines of code written over the course of a handful of
hours to "port" it. I don't think they (for example) moved all the data
structures into managed space, other than perhaps the screen and keyboard I/O.
> Right, the GDI+ functions are generally pretty good for most drawing
> situations.
I thought the transformation matrix approach to color control was pretty
cool. Probably pretty common across toolkits, I'd guess, tho.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I found that on my Vista machine it runs significantly slower.
Running Vista here, I estimate about 10-20 fps (assuming it goes up one line
per frame).
It's only using 1 of my cores though .... :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I would think there's relatively little need to be slow in a program like
> this, where it's all manipulation of fundamental structures.
I think the GPU would be faster at this sort of program than the CPU :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I found that on my Vista machine it runs significantly slower.
>
> Running Vista here, I estimate about 10-20 fps (assuming it goes up one
> line per frame).
Then why the hell is my Vista box always so freaking slow?!!
> It's only using 1 of my cores though .... :-)
>
>
Yeah, I didn't get all fancy and multi-threaded.. I suppose it could be
easily parallelized, though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Running Vista here, I estimate about 10-20 fps (assuming it goes up one
>> line per frame).
>
> Then why the hell is my Vista box always so freaking slow?!!
Ooh I just tried it on my XP laptop, and by the time the red has got to the
top it's only 80% of the way there on Vista. My Vista box is about 10x
faster than my laptop so who knows what is going on.
Does it make a difference under Vista if you take out the
"ControlStyles.OptimizedDoubleBuffer" flag?
Also you are locking the bitmap for quite a long time (relatively), you
should literally lock, memcopy, unlock. Any processing should be done
outside of that on a separate buffer. Maybe it is holding up Vista somehow
when it's trying to copy the bitmap to the graphics card?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott 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.
>
> I think the GPU would be faster at this sort of program than the CPU :-)
http://www.nzone.com/object/nzone_cascades_videos.html
--
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:
> Wow... are you running Vista, by any chance..? On my WinXP machine, I
> was getting about 20fps..
I'm running it via Mono, on Linux.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> http://www.nzone.com/object/nzone_cascades_videos.html
I'm *still* irritated that you can't run Cascades without Vista...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Mike Raiford wrote:
>> Wow... are you running Vista, by any chance..? On my WinXP machine, I
>> was getting about 20fps..
>
> I'm running it via Mono, on Linux.
>
Did you paste the code, or did you run the executable?
Mono has come a long way, then, last time I messed with it, there was no
support for Windows Forms.
I guess that lends credence to Andrew said about mono being slower than
even Haskell.
Though, I wonder where the bottleneck could be... Does Mono use JIT, or
is it simply interpreting the bytecode?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
Just in case anybody thought I was pulling facts out of thin air:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=csharp&box=1
It seems that Mono has improved since last time I checked. (Or Haskell
as got worse.) It still remains at least 10% slower in 8 of the
benchmarks (verses 3 where it's faster) and uses more RAM in 8 of the
benchmarks (verses 3 where it uses less).
It's a similar story here:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=csharp&box=1
This uses "Mono JIT compiler 1.9.1"; the first one is "Mono C# compiler
version 2.2.0.0".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
Regarding "slower than even Haskell":
http://tinyurl.com/dj3wm3
At the top of the tree sits C++. Directly below that is C. Directly
below that is ATS. And the very next thing on the list is... Haskell.
It's faster than Java, it's faster than Smalltalk, it's faster than
Lisp, it's faster than Erlang, it's faster than Mono, it's faster than
Fortran, it's faster than Clean or OCaml... in fact, it's faster than
everything in the entir shootout apart from C, C++ and ATS.
Of course, the beauty of the shootout is that if you twiddle the knobs
and dails enough, you can make *any* language "win". So I wouldn't put
too much faith into the exact numbers produced. But the fact that
Haskell ends up anywhere near the top of the list means it can't
possibly be *that* damned slow.
So it's possible to write fast code in Haskell. As Warp keeps pointing
out, the trick is working out how to make your code go fast; it turns
out to be a bit unpredictable...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Nicolas Alvarez wrote:
> > Mike Raiford wrote:
> >> Wow... are you running Vista, by any chance..? On my WinXP machine, I
> >> was getting about 20fps..
> >
> > I'm running it via Mono, on Linux.
> >
>
> Did you paste the code, or did you run the executable?
>
> Mono has come a long way, then, last time I messed with it, there was no
> support for Windows Forms.
>
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
>
> Though, I wonder where the bottleneck could be... Does Mono use JIT, or
> is it simply interpreting the bytecode?
It's JIT, if it was interpreting bytecodes it should be as slow as python.
Howver, System.Drawing must be doing it by translating into respective X or GL
calls or, worse, into GDK calls which in turn get into X or GL calls. I'm sure
the mono guys aren't that dumb and are writing directly for GL though. Still,
perhaps the native Windows drawing routines are much faster.
I got my 4 cores crunching at it and it seems to go at a good clip as far as
lava-like things move...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> http://www.nzone.com/object/nzone_cascades_videos.html
>
> I'm *still* irritated that you can't run Cascades without Vista...
Hehe, good luck trying to implement marching cubes on the GPU under XP :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Did you paste the code, or did you run the executable?
I ran the executable. I have no idea how you go about compiling C# code.
> Though, I wonder where the bottleneck could be... Does Mono use JIT, or
> is it simply interpreting the bytecode?
I even tried AOT (compiling it to a native program), and it wasn't any
faster. But I now tried it again and ran top, it looks like the X server is
the bottleneck! Are you doing pixel-by-pixel changes without double
buffering or something? (causing an X command on every pixel drawn)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Mike Raiford wrote:
> > Did you paste the code, or did you run the executable?
>
> I ran the executable. I have no idea how you go about compiling C# code.
You'd save the text to a .cs file and run the mcs compiler from mono project.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
