whats quicker ?
BlitzMax Forums/BlitzMax Programming/whats quicker ?
| ||
| just wondering. whats faster with images collide, a full colour image 800*600 or a black/alpha image same size. |
| ||
| Shouldn't make a difference by my understanding of how it works. The pixel data is stored RGBA in either case, it just compares the alpha channel value for the pixels unless I'm mistaken which means it makes no difference what is stored in the RGB portion. 0,0,0,255 takes just as long to check as 255,255,255,255, they're both 4 bytes so iteration and splitting them apart is not affected by it's content. Mask collision is different, you only need 1 bit per pixel instead of the full 4 byte RGBA set, so there's less data to crawl and you don't need to split the pixels... however since the data is still stored in bytes you have to address each bit in the byte to get to each of the bits in it, not sure what the overhead in max is for that level operation vs decoding a 4 byte pixel and comparing the alpha bytes... |
| ||
| currently running my code at 400+ fps and this aint all that good a PC, so im not really worried about it at the moment, just trying to put some thought into it before the project end. When I normally clean a lot of stuff up and start to trim things down to make it as sleek as I can, I think I might just move to rect collisions and cover my image of my level with rects to detect against, thats gona be a lot faster I rekon. I thought it was testing against the rgb, looking for a value more than 0 but then it would hit on black so yeah now that you mention the alpha channel I dont know why I never thought of that. |
| ||
| Using a combination of both is quite useful. First check with a rectangle check -> If this is true also do a pixel-perfect check. |
| ||
| yeah right now it's near pixel perfect, currently I move my sprites by .2 or .4 in a loop until it hits the full move distance which is giving good results so far. I was thinking of changing to be a percentage of distance, so moving say 20 pixels, I might divide that by 10 to get my step distance, think that would work better for much larger distances if I say move my sprite 30 pixels, looping through it at .2 would eat up cpu time when combined with the collision check. will all boil down to how fast I want my units moving in the end. but so far its .2 and their moving sharpish with no issues. |
| ||
| I don't get what the big deal is with FPS in excess of what the average monitor can display. It seems to me that if you can render at 1400FPS internally, but even top end monitors are pushing 120hz or possibly 240hz, that a lot of processor/GPU time is wasted on unusable data (at 1400FPS, for example, 1280 frames are discarded, essentially, every second on a 120hz display). And then of course, there's the fact that the human eye (well, brain really) can't even distinguish more than about 75 to 100 or so frames per second. If you're using this figure to compare various algorithms or hardware, then I can see where it might matter, otherwise it seems to be a moot point. Russell |
| ||
| I believe the imagescollide method does a rect check internally so you don't really need to do one yourself as that's just duplicated effort (I could be wrong about that...) Regarding fps greater than your monitor can display, it s a good way to tell how much headroom you have to play with. For actual production you should throttle your frame rate so you don't end up burning CPU and Gpu time for no reason. Simple way to do it is just enable vsync with flip(1). If you can render at 2k fps on a min spec system it just means you have a LOT of room to grow (time for more advanced ai, more objects on screen, etc.). If you're at say 45fps then you can't really afford much more, and should really look into optimizing things to get room for background tasks etc. |
| ||
| That's what I thought. But who knows? Maybe in 10 years or so, we'll actually have monitors that can display thousands of actual frames/sec AND graphics cards that can keep up! (Compare what we have today to what was available just 10 years ago. I can remember when having just a couple of megs of video memory was considered "outlandish", and now some have, what, 2GB? And you can chain them for even MORE power? Astonishing. Looks like Moore's law is staying true so far...). Russell |
| ||
| Computers will keep getting faster but the human eye can barely see above 120hz and anything past 60 gives almost imperceptible difference anyway so while I'm sure we'll be capable of rendering tens of thousands of fps, there's no point unless we get eyes to match... It's more a matter of what we can cram into those frames and how much we can get done between them. Secondarily how much power it takes and how small a package we can fit it in... |
| ||
| It's the head room as ima says, it's a good way of seeing just how much active and dynamic crap I can throw into the screen before it drops bellow that much desired smooth 60 frames per second. What my plan is at the moment is get the frame rate as high as I can, and keep it there, then when I have all my game object code done, dump as much into a screen as it can take, and find that sweet number that results in about 80 frames per second, and that's the maximum number of dynamic objects I will allow the game to render at once. I also plan to only make calls to drawimage if the image x,y is actually on the visible screen, which will free up some more time for the stuff that is on screen. |
| ||
| This may be a bit OT (or not, since we are talking about gaming environments), but what do you see as the next big "thing"? Now that we have processors and GPUs capable of doing some impressive physics and texturing, is the next hurdle the AI or just more on-board texture memory for extremely detailed worlds? AI has come a long way since the 80's, but is still not quite there, as far as I'm concerned (referring to game AI, not the stuff being worked on at the finest technical colleges in the world). Would a graphics card 100x faster than anything available today with, say, 16GB (or more) of texture/world memory be earth-shattering? Probably, but only if the imaginations of the game developers can utilize it to its fullest potential. Imagine a game like Super Mario World rendered as though it were real: Super-realistic textures (Mario's skin and clothes, for example) and creature behavior, physics, etc. It would be a completely different KIND of game, but would it be more fun? Hard to say. Probably don't have to wait too long to find out! Russell |
| ||
| I have my own theory about AI, I don't think that will be the next big thing, I think it's simply going to be more detail, and I do not mean photo realism because thats about here now, I'm simply talking about having gaming worlds with 10 times more stuff in them, world where each blade of grass reacts to the player, where each branch and leaf in a tree react on their own to the wind, simply detail. As cards get more and more powerful, developers will keep cramming in more and more things for them to do, no point having all that power and then only using a faction of the pollygons that it can actually handle. So yeah, just more detail, which aint a bad thing really. |
   |