2DMax v.s. Blitz3D?
BlitzMax Forums/BlitzMax Beginners Area/2DMax v.s. Blitz3D?
| ||
| http://mywebpage.netscape.com/Mindstorms1/particles_small.zip The above program written in Blitz3D, is pushing around 9000 particles at frame rates of around 20fps on my system. My little demo coded here: http://jgoware.com/mge/5000stars.zip is pushing only 5000 particles at the same frame rate on my machine. So..which is right? a) The Blitz3D program is lying about how many particles are actually being rendered. b) For doing 2D apps, 2DMax is ALOT slower than Blitz3d. Any thoughts would be appreciated. |
| ||
| Have you tried the different Graphicsdriver? (OGL/DX7 or the DX9 driver) It would be good to display the particlecount in the 500stars app. and maybe the code or at least a dialog where the user could change the driver. Results: Both fullscreen B3D: 23 fps BMax : constant 60 fps |
| ||
| Same as Klepto here.... Bmax without sync about 75 FPS |
| ||
| So..which is right? a) The Blitz3D program is lying about how many particles are actually being rendered. b) For doing 2D apps, 2DMax is ALOT slower than Blitz3d. or c) None of the above... possibly. I don't think you can make any conclusion from 2 .exes. How are you doing your particles? Single-surface? Object pooling? Arrays? Lists? |
| ||
| "Have you tried the different Graphicsdriver? (OGL/DX7 or the DX9 driver)" The 5000 stars one I coded is using the DX7 driver. Single surface, arrays and lists. Strange that the B3D demo is running around 23fps on those machines, where my BMax app is running at least twice as fast, meaning perhaps I could have bumped out another 5000 sprites on those machines to come close to equaling the performance of that B3D demo. hmm... "It would be good to display the particlecount in the 500stars app." My demo (5000 stars) always has a constant 5000 sprites on screen. When one goes out of bounds it restarts in the middle again, so no need to display the count. Sp perhaps it's just on my machine the B3D app is getting much better performance, probably due to poor drivers. I dev on a low end on board intel box. ;) |
| ||
| No on B3D you could do single surface stuff. The problem that is slowing Max2D down is the fact that every single quad does its own glbegin / glend and send a single quad. Thats plain suicide for something that could and better would be done single surface ie all quads within a single glbegin / glend. Alternative to that, you can use VBOs and a vertex shader to do it, but that needs more knowledge and quite an extension of the current max2d compared to single surface which actually would only need a few additions (addToBatch, removeFromBatch, renderBatch most likely) |
| ||
| Granted. However, it's still seems confusing that on my particular box B3D is out performing BMax by a long shot, but in the thread here, 2 have reported B3D actually seeming to run slower. I'm assuming when klepto said 23fps for B3D and 60 for BMax, he had around 9000 particles being displayed for the B3D version? It's all good though, I'm getting good enough render speed via Bmax. ;) |
| ||
| B3D: 104 BMax: 224 |
| ||
| On my work machine: B3D: 57 Max: 71 (I get a huge difference between DirectX and OpenGL drivers on different machines with my own stuff. It all depends on what the card is capable of doing.) |
| ||
| The best speed so far I got with the inofficial DX9 drivers. If you are on ATI, they will most likely be best as well of if you just do not have a card capable of enough bandwidth pushing. |
| ||
| in the max version your also scaling , rotating each or some of the stars as well. thats eating up cpu cycles. where in the b3d one your not. To make a valid comparison you need both examples to be identically. |
| ||
| B3D: 71 FPS Max: 131 FPS Core 2 Duo E6600, ATI X1650XT |
| ||
| wow.. according to the data posted, it's actually fairly even since the B3D one is pumping out around 9500 particles and the Bmax version is pumping out 5000. |
| ||
| Which is what I would expect. This is gfx intensive, so it's comes down to the speed of the graphics card/API. Do something with a lot more number crunching and you will see Max pull ahead. |
| ||
| wow.. according to the data posted, it's actually fairly even since the B3D one is pumping out around 9500 particles and the Bmax version is pumping out 5000. ... or one is well programmed and the other not? I'm not trying to be disparaging but you're still comparing framerates on 2 .exes and using the results to make assumptions on the programming language. How about posting your source with 'Can I improve on this?' |
| ||
| When do you think you'll have something for others to play with? |
| ||
| @tonyg - Very true! Based on the replies, the rendering speed difference is not as extreme as I originally thought. My little engine is VERY generic, un optimized, etc, I'm sure that has ALOT to do with it as well. @dooz - I'm a little over 3 weeks into coding MGE, I would say if I keep up at this pace, there could be a demo up within a week or 2. ;) |
| ||
| There are quite a few discussions on Particles and how best to do them. It's possible to do a nice, simple one which works well BUT the Garbage Collector is a factor. This wasn't so much an issue with B3D. In addition, arrays are quicker than lists AND the way Bmax draws isn't fantastic for lots of texture swapping which is where the TAnim code will make a difference. It could be argued that you shouldn't have to fanny around with all this. However, as was necessary with B3D, there is always some way to optimise if the base commands needed to be improved. Where Bmax wins, for me, is how much you can deviate from the normal command set. |
| ||
| "It could be argued that you shouldn't have to fanny around with all this." Agreed. At this point in my software "careeer" I'm done writing low level optimized code. I did enough 6502, 68000 assembly back in the day. ;) Thanks to BMax (and modern gpu/cpu) I (anyone!) can create a generic high level "multi use" engine that will serve probably all of my 2d needs for now and into the future. As long as my little engine can shift a few hundred sprites around at 30 or 60fps on most machines, I'm happy. ;) "...is where the TAnim code will make a difference...." One of the first things I did was implement a generic single surface type blit similar to the TAnim handling. On my dev box, my average fps increase was around 8fps. The speed wasn't the issue, it was the fact that I could put as many sprites on 1 texture, which was how I was used to doing it in VB6 with DX8. ;) |
| ||
| One of the first things I did was implement a generic single surface type blit similar to the TAnim handling. On my dev box, my average fps increase was around 8fps. The speed wasn't the issue, it was the fact that I could put as many sprites on 1 texture, which was how I was used to doing it in VB6 with DX8. ;) why wouldn't you just use LoadAnimImage for that then? (no speed up of course though) something else... everybody is talking about single surface in respect to just the texture. When we were all doing single surface in B3D we were really talking about a single mesh with detached tris. I know that's where I got my biggest speed gains. |
| ||
| re: Single Surface, for me simply means if I want 64 images of a sprite, I can place all of those on one texture instead of having 64 surfaces. Normal 2DMax handling would make 64 seprate images instead of drawing from the "single surface". That by itself is a pretty big optimization under DirectX, not so much under OpenGL I'm finding out. |
| ||
| right I know that, but you mentioned it wasn't the speed that was the issue which implied it was the ease of use. I just wasn't sure you were aware that you can put all your textures in one gfx and load them with LoadAnimImage. wow, you'll really kicking butt on that engine of yours, not to mention the updates to the site... where do you find the time? |
| ||
| "I just wasn't sure you were aware that you can put all your textures in one gfx and load them with LoadAnimImage." Yes, I was, and I was all pumped to use it until I read it internally makes individual surfaces from them. Kind of defeats the purpose? If you load a 512x512 texture using LoadAnimImage where each size is 32x32 BMax will create 256 surfaces internally! The excellent TAnim from (awesome) IndiePath solved this problem, but I ended up using something more generic for my needs. "wow, you'll really kicking butt on that engine of yours, not to mention the updates to the site... where do you find the time?" Thanks dmaz! Bmax has brought me back form the deasd as far as coding goes. Time? I'm self employed (re:broke) so I have all the time in the world! ;) lol... I have 2 projects I plan to work on during the development of MGE, from there we'll see where it leads. |
| ||
| vortex_small.exe gets 12-14 fps at 9000 stars, 5000stars.exe gets 20-26 fps when left running for about 30-40 seconds |
| ||
| MGE: even with TAnim it still defeats the point. The only thing you defeat with that stuff is the texture switch as it does not rebind. BM itself does no batch rendering. each draw command is a single quad sent to the GPU. Unless you modify it on that end, you have no chance of really breaking something with image rebinds ... especially in pure 2d where the max size of images for 95% of the images is 128x128 or at worst 256x256 even an intel won't break with bandwidth problems due to that. |
| ||
| Hi Dremora. Texture state changes can make an impact, especially on older gpu's. On my older Intel, the frame rate increased enough that the optimization was worth it. But again, the main reason to use it was ease of use not the speed gain, which is fairly small I admit. |
   |