arithma
My first post,
Wanted to share my little adventure into emergent behavior on actionscript
Here's the link:
http://wonderfl.net/code/d6ecc1a75ceece9b3b6d0758654a3adddac58f46
http://wonderfl.net is a japanese website, you'll see lots of amazing stuff and lots of things you can't even understand.
Tell me what you think, and enjoy :)
sin
It's nice, I like it.
Problem with flash is that it's still CPU bound for animation so CPU usage is jumping to 30% as a minimum.
This can run as smooth as charm as a DirectX application.
Nonetheless, good job.
J4D
i really liked following some of the arrows , they seem alive ! good work :)
rolf
interesting from a programming/math perspective bt not so much from an aesthetic/graphic perspective
arithma
sin wroteIt's nice, I like it.
Problem with flash is that it's still CPU bound for animation so CPU usage is jumping to 30% as a minimum.
This can run as smooth as charm as a DirectX application.
Nonetheless, good job.
It's actually compute bound, not graphics bound.. so DX could only help with just a minor bit. Of course the jump to C/C++ will give a boost but still, it's asymptotically capped (n^2).. Optimizations helped (distance based dismissal of calculation, could have used a grid as well), but for completeness I posted it without any (degrades quality of effect).
@rolf:
Just because it's computed doesn't mean it's aesthetically upsetting. My first reaction to it was almost orgasmic because I didn't even know what to expect. Kind of looking at a mirror and getting surprised in a sort.
sin
arithma wrotesin wroteIt's nice, I like it.
Problem with flash is that it's still CPU bound for animation so CPU usage is jumping to 30% as a minimum.
This can run as smooth as charm as a DirectX application.
Nonetheless, good job.
It's actually compute bound, not graphics bound.. so DX could only help with just a minor bit. Of course the jump to C/C++ will give a boost but still, it's asymptotically capped (n^2).. Optimizations helped (distance based dismissal of calculation, could have used a grid as well), but for completeness I posted it without any (degrades quality of effect).
Actually, it's not about the programming language, it's about what the compiled application is actually doing.
Flash is CPU bound (we both agree I assume?). But when using DirectX or OpenGl, whether it's through unmanaged C++ or managed C# (like XNA), you will get amazingly better results. This is because DirectX is an API that communicates with the GPU, and will not only help "with a just a minor bit", because the GPU is a lot faster than CPU in graphical calculations. Nonetheless, Flash is not able to talk to DirectX, mind you.
arithma
OK since you're interested, I'll try to make it all clear, we're discussing here.
If I stop some of the calculations, (I have a double nested loop iterating over the elements twice), the animation will go seamlessly with around 8-10 msec per frame. So you see, the graphics are not intensive, and in that sense, DirectX won't be able to help - there are a lot of instances, although basic, where DirecX could be a lot slower than using just the native code.
On the other hand, switching to native computation (using C++ for example) will only multiply the computational efficiency with a constant factor. It will perform a "bit" better in that sense (maybe twice, trice..).
In a sense, what am trying to say, this kind of problem has its bottleneck in the algorithmic detail rather than in the hardware and API.
And anyway, I only created it to see the emergent behavior; who would want to write Win32 "Window creation" code to see some particles move, ugh!
xterm
sin wroteActually, it's not about the programming language, it's about what the compiled application is actually doing.
Flash is CPU bound (we both agree I assume?). But when using DirectX or OpenGl, whether it's through unmanaged C++ or managed C# (like XNA), you will get amazingly better results. This is because DirectX is an API that communicates with the GPU, and will not only help "with a just a minor bit", because the GPU is a lot faster than CPU in graphical calculations. Nonetheless, Flash is not able to talk to DirectX, mind you.
Well put sin, in fact, WPF's latest release (3.5 SP1) had a major enhancement in terms of GPU doing all the processing.
arithma
ok guys, I really can't let this stay on the internet unexplained.
You are suggesting that simply having DirectX doing the rendering will make it a lot faster. This is plainly wrong:
- DirectX is NOT faster in the following conditions (there can be other sets of conditions too, this is not exclusive)
- When there are no vectors to be drawn (bitmap)
- When there is no scaling
- When there is no rotation
DirectX usage needs the CPU communicating with the GPU which is really a slower process (compared to BitBlt-ing from inside memory to inside memory using DMA - the process used in flash player).
As for the thing I posted, it's NOT SLOW because of the graphics. Turn some of the lines of code off (if you've checked the link) and you'll have 125FPS.
Saying that DirectX accelerates any application is like saying DirectX can accelerate a command line application.
However: there is one case where DirectX can be really useful, if the whole application was written as Shaders of some sort and all the initial data passed in as textures, I believe it can be whopping close to zero frame times.
In short what I wanted to say: the animation is using 20msec for each frame. 16 of those go for computation, and 4 for graphics.
Going native (C++) can give us a compute advantage of higher than 2 fold. The graphics need not change: 12msec. If DX was to be used, it won't matter much since we're already not doing anything like lighting, shadowing, blending, alpha manipulation, matrix multiplication. Nothing. At most it can cut it in half (and I am skeptical) That will give us a drop of two frames: 10msec. Flash (20msec), C++/BitBlt (12msec), C++/DX (10msec). Those are my personal approximates, but I'm well exposed to DX (well at least till version 9)
Ayman
Well done, keep up the good work :)
sin
I didn't say that DirectX can accelerate any application, but it's not true that there are no benefits to using DirectX with bitmaps! This is because bitmaps for DirectX are GPU-bound textures that are handled by the graphics device.
For DirectX, a bitmap is simply a vectorized representation of 2 triangles skinned with the texture being the bitmap! As a matter of fact, you can move your bitmap on your screen using the GPU directly (in addition to rotation, scaling and any custom made transformation matrix).
To put it to the test, just get a simple stupid bitmap and move it around the screen on a 1400 x 900 full screen resolution on flash. Do the same application on DirectX.
The first thing you will notice is how smooth the animation is rendered. But also, you will get a lot less CPU charge. Of course, this is only if the application was written correctly.
My friend, the fanciest 2D games are written using GPU-bound APIs. Get your GPU to handle graphical calculations, and you will see that your CPU will be able to process logical hundreds of time faster!
arithma
The correct application doesn't always need DirectX even if there was a bitmap moving around
BitBlt is a memory to memory operation. DirectX would need the CPU communicating through the motherboard, throught the PCIe to move that same bitmap. DirectX in that specific case is slower.
The less you're doing graphics, the less important GPU is. And btw, things are done nowadays using DirectX for 2D only because its easier to rotate.
Ok, now on to something constructive!
How the hell do you know all this stuff? :)
Am self taught, dabled for a while with DirectX 9, got my first book at highschool right after finishing some C++ books.
Cheers.
sin
Well I really don't think the CPU-GPU communication is as slow as you're making it sound. For one, it's faster than having the software clean up behind blitting for BitBlt.
Anyway, I'm not saying that you should be doing the emergent behavior thing via DirectX, I just assumed it would be smoother running on GPU.
I've been learning game programming for a while, and I worked with managed DirectX running on XNA with C#. I've just finished implementing my 2D game engine, and I'm satisfied with it for now.
Glad to know that someone in Lebanon knows so much stuff :)