Single Surface Vs Sprites
Blitz3D Forums/Blitz3D Programming/Single Surface Vs Sprites
| ||
| Heeello. I have been searching in the forums, and i have found some interesting things about this, but can't find the winner. What is better? I have around 200 sprites in my game. Is it better to use single surface meshes? Is it better to use CopyEntity for each sprite or mesh? thanks! |
| ||
| aaaarrgghhh! not this debate again :) If you do it right single-surface is always faster... alot. Don't let anyone tell you otherwise. |
| ||
| Sorry to ask again. Anyway, is it worthy for only 200 sprites (all the same) to make single surfaces??? |
| ||
| Depends on your target platform... but optimizing is always good. |
| ||
| Ok thanks, but could you explain why a single surface moving vertex is faster than sprites? |
| ||
| It doesn't take much to get the answers... google is your friend. http://www.google.co.uk/search?hl=en&q=single+surface+site%3Ahttp%3A%2F%2Fwww.blitzbasic.com&btnG=Search&meta= |
| ||
| It's all to do with surfaces. Blitz stalls the gfx card everytime it rendersa surface if i remember correctly. And that causes slowdown. The less surfaces in your game, the beter :o) Therefore using single surface for grass, particles...etc is faster :D |
| ||
| KuRiX, Ross C does a good job explaining the need for Single Surface Sprites. I haven't seen 'Single Surface' mentioned in other game dev forums so I suspects its specific to Blitz3D. There is a great deal more work that needs to be done with Single Surface 'Sprites' when one considers Single Texture Image Sets, Pixel Perfect Resolution, Transformation, and Collision. You have to code this functionality. I have a good discussion going here to unlock its mysteries. Coding the functionality I mentioned above can be tricky and there are several Single Surface Libraries that can make your life easier. After playing with several, I decided to give a crack at my own. I'm writing a open source single surface lib. One of my first goals with the lib is create a 3D command set to replace Blitz3D's 2D Image, Graphics Drawing, and Collision commands. This will allow folks to transform there 2D games into 3D with relatively small fuss. |
| ||
| Just some confused about some things. When we talk about single surface 'sprites'? Are they actually image sprites or are they single surface quads/tris? If single surface tris/quads are faster than the native blitz3d sprites, is this because the native sprites are implemented using 2D calls? or are there other reasons why a single surface is faster than a sprite? |
| ||
| To use Single Surface you will need to use VertexCoords and sin/cos to rotate. So i don't know why this should be faster than native sprites... but everybody says so... |
| ||
| I'm thinking along the same lines myself. At least in theory, it seems to me that sprites should actually be faster... unless there is something in blitzbasic that I'm not aware of. |
| ||
| Ok. Everytime you create a new sprite, it creates a new surface, because each sprite can have a different texture. Everytime renderworld is called, it's renders the world, stalling slightly between each surface (as far as i understand), which takes time. So, the less surfaces you have in your game, the better. If your using 100 odd sprites in your game, essentially it's 100 surfaces. That's a hell of alot of surfaces, for just one thing. Now, using single surface, you have one surface, one mesh. It renders far quicker then the sprites, because theres no stalling inbetween, as it's the one surface. That the real speed up. transforming and manually rotating the quads is actually very quick. The math for one thing, is done very quickly. The biggest slowdown you'll normally experience in a game, is the graphics rendering. Shaving a milli-ultra second off by making your math formula shorter, ain't gonna help you out. :o) |
| ||
| Ok, thanks Ross c for the explanation. If i use the copyentity, i duplicate the surfaces too? |
| ||
| Ohh, i have been making tests, and it seems like single surface is faster, but... i can't set the alpha of each quad like they were sprites!!! Any Idea? |
| ||
| i can't set the alpha of each quad like they were sprites!!! VertexColors has an alpha parameter. |
| ||
| I have tried it, but i can't make it work, my fault i thinks. (i set the entityfx 32 too) :( |
| ||
| WORKING! Set the entityfx to 1+2+32!!! |
| ||
| Ok, my last question!: How can i make every quad to be always pointing the camera? |
| ||
| Now that. Heh. You need to rotate the quad to the camera pitch and camera yaw variables. I believe this can be done using the tformpoint command. I used some pretty hairy maths to align mine. I'm not gonna subject you to it, but this can be done with tformpoint. I'll have a look to see if i can find the thread. |
| ||
| Yep, Resolved with TformPoint and TformVector! Now all is Working Perfectly. Faster than Sprites? It seems so, but now i have lot of code, with TformPoint, Math, VertexCoords! Tests Will Decide! |
| ||
| Trust me, it will be miles faster. Try putting 1000 odd particles on screen. That's all the testing that should really be required :P |
| ||
| Mmm, and... if i am going to use one sprite for the HUD, then there is no need for making a mesh? Because it will use one surface too? |
| ||
| Yeah, basically :o) |
| ||
| Well, then Thanks to all the people that have helped me. Now i have my own single surface lib perfectly working in my multiplayer racing ode game. (hehe, sounds great) |
| ||
| Awesome discussion! |
| ||
| Yeah, this I think will help with Galactic I use a lot of sprites for both engine trails, starfields and smoke/fire. If these were combined into single surfaces, it would make things much quicker. It runs smooth anyway, but I know it does cause a lot of slowdown which will become apparent once more of the engine calculations are inserted into the loop. |
   |