Massive dot count fun?
BlitzMax Forums/BlitzMax Programming/Massive dot count fun?
| ||
| Here is a neat little Java "game" that is very similar to the sorts of things I used to make in Qbasic as a kid. This one though, can handle many many dots. I'd like to mess around with my own version of one of these, but I can't seem to get Blitz to draw dots fast enough. I've tried the default Plot and gl_points, but both are too slow to render a 400x400 grid. Obviously this is not the answer. How might you guys go about rendering this type of program? |
| ||
This demo by Binary Therapy (maxed up by FlameDuck) uses pixmap, banks, and writepixel. It's certainly fast: * DOWNLOAD I tried gl_Begin GL_POINTS / glVertex2f / gl_End against standard Plot and managed to gain a marginal speedup but I suspect the above demo's method will be faster: |
| ||
| Hmm, my copy of that fireball program must be broken. I get nothing but a small, intermittent purple poof and that's it. I'll still check out their pixel-writing method because it seems to have a crazy implementation. Thanks, Jim. |
| ||
| Hmm, my copy of that fireball program must be broken. I get nothing but a small, intermittent purple poof and that's it. In OGL mode or DX mode, or both? What kind of graphics card have you got, how fast is your memory? I can get about 25000 or so on my Laptop. I'll still check out their pixel-writing method because it seems to have a crazy implementation. I just translated it straight across (from BlitzBasic), without any mind to optimize it. It could probably be optimized quite a bit if anyone could be bothered. |
| ||
| Doesn't work here at all, only the DrawText shows up. |
| ||
| I suspect that the fact that the BlitzBasic (bb) version is so much faster than the BlitzMax (bmx) version is the fact that the bb version uses a back buffer to draw the image and the max version has to use a pixmap, I think the back buffer is in video memory and the pixmap has to be in main (slow) memory. Unfortunatly I don't have the experience to work out how you could enhance it's performance but I do know that as it is working on the pixel colours this routine could possibly be replaced with a shader program which (depending on hardware) could well blow the socks off the bb version. However I've noticed a lot of requests for backbuffer support for bmx and a lot for the 3D module either of these enhancements would allow increased performance. |
| ||
| Merx: Where might I learn how to implement a shader program in Blitzmax? FlameDuck: I tried it in OpenGl, have a 6800 GT, and I'm not sure how fast my memory is. I forget what the latency numbers are, but they are good. You'll have to explain to me how these things have anything to do with a particle's lifespan. ;) (That's what I'm guessing is the problem) I haven't yet touched Banks and pointers with their Peeking and Poking because it feels like playing with fire. I may change that stance if they are as powerful as it looks they are. |
| ||
| I believe the shader programming for blitmax will only arrive with the 3D module. However blitzmax supports openGL which might allow you to experiment in this area but unfortunatly that's all I know and I would be as interested as you to find out how to learn and play with shaders. Sorry ;0) If a little knowledge is dangerous, where is the man who has so much as to be out of danger. Thomas H. Huxley (1825 - 1895) |
| ||
| I posted some shader code in the opengl forum (based on toms shader mod), its not the most friendly language glsl its a bit like painting by math, if you were after lots of dots moving about following complex rules you might have some problems just using the shader language, if you positioned the dots in max, you'd have to shift all the co-ords to the gfx card which could take longer than a glpoints call... |
| ||
| I got it working by getting rid of flip false and putting a flip command in the main loop. I also had to make it create particles when I held the space bar down (didnt create them of its own accord). If you only have a few hundred particles, you only get a bit of purple. |
| ||
| I suspect that the fact that the BlitzBasic (bb) version is so much faster than the BlitzMax (bmx) version That's odd. Here the BlitzMAX version is roughly 3 times faster than the BlitzBasic version. Add to that the BlitzMAX version is working on 4 times as large a buffer (480x480 rather than 240x240), and drawing twice as many pixels (as opposed to the BlitzBasic version which only draws every other pixel), and doesn't have an unrolled main loop. If you only have a few hundred particles, you only get a bit of purple. Yeah. You need a few thousand. Should get them within a few secs. I'm thinking the culprit here is your 1GHz P3 not being able to do its thing in the ammount of time it's given. Should probably have at least a 2GHz Pentium class processor or better for decent results. You'll have to explain to me how these things have anything to do with a particle's lifespan. ;) (That's what I'm guessing is the problem) The code does quite alot of read/writes to and from system memory. It keeps generating more particles as long as the main loop takes less than a certain threshold to execute.Apart from "you're running a debug version" (which adds massive overhead), I can't imagine what could possibly cause such a dramatic loss of performance. I've tested it on both the GeForce Go 6800 and Radeon X600XT and both cap out well above 25K particles for the BlitzMAX version. |
| ||
| Ahh, that did it. Good job, Nomen. All you have to do is get rid of the False after Flip. I topped out at 18k particles. |
   |