DrawImage is pretty slow.
BlitzMax Forums/BlitzMax Beginners Area/DrawImage is pretty slow.
| ||
Hey everyone. I'm working on a tile-based semi-topdown scrolling game, similar to an isometric game except the tiles are rectangular, similar to the Pokemon view. Anyway, I've written a sorting algorithm that allows the tiles to be drawn based on the mapy value, but it was slow. I then just tried to draw the same amount of images without any sorting to see if it was just my algorithm, but only drawing 63 images of size 32x100 was slow. Anyway to speed this up or am I not getting something? Thank you! :) |
| ||
you might need to post some sample code, BMax can handle a reasonable number of sprites on screen, so chances are, there's plenty you can do to your code. |
| ||
What it does is constructs a game map and just draws images. I haven't added the z component for faking the height, but just drew the images. Last edited 2011 |
| ||
Define "slow"? Try changing Flip to Flip False to get a true representation of speed, otherwise the frame rate will never go above what your monitor refresh rate is set to. |
| ||
When your DrawLevel() fills the whole screen there is also no need of a CLS, because you overwrite it anyway. |
| ||
Thanks for the help guys, and slow as in 600 ms delay. I have a Cls under the while loop. I'm wondering if it's this computer I just moved to, I just ran a demo and it also ran slowly. Hmm... |
| ||
Does this run slowly? |
| ||
I just saw that you use a depth of 16, which most modern cards probably don't display as fast as a depth of 32. [EDIT] Perturbatio was a bit quicker Last edited 2011 |
| ||
Thanks for the test Perturbatio, after about 13 images there's a noticeable lag, and more added after makes it lag more. Does this sound right? I think I'll just have to move to another computer to fix my problem. I wonder what it is? |
| ||
What graphics card does your computer have? Try switching DirectX 7/9/OpenGL. For example, some low end graphics cards really struggle with OpenGL. |
| ||
after about 13 images there's a noticeable lag Eep! I realise I have a high end system, but I don't notice anything resembling lag until after about 8000 images (it's more slowdown than lag). Tip #1: Update your graphics drivers Tip #2: Make sure debug mode is off when testing |
| ||
@Underwood I tested your code with created images and a simple speed annalyzer on my 2ghz core duo macbook. In debug mode takes under 1 millisecond to draw the whole map. this is how I tested it: Try it on your computer and let me know how fast it is. By the way, what are your machine specs. I agree with Perturbatio that you might need to upgrade your drivers. did you reinstalled the operating system? if you did and did not install the drives than Windows is running in sofware graphiccs emulation and everything you do will be really slow. Last edited 2011 |
| ||
Thanks for the help everyone. I agree with both of you, I need to update my drivers. :P I don't think there's anyway around it! |
| ||
Maybe it's not just a driver problem... I have a ATI X1300 on my laptop, and on that original code posted above, it ran at 20FPS displaying 100 images. I then took a look at the code, and change it around: Minimizing state changes (I removed the several 'getscale'/'setscale' from sprite functions), just drawing a black rect on screen instead of calling CLS, moved the sprite update code outside the screen drawing loop and other things, and I managed to DOUBLE the fps - now 100 images runs at 40 FPS here. Last edited 2011 |
| ||
Oh dear. My game makes extensive use of set/getscale. Will this be a problem?? Though I have update and draw code seperated. |
| ||
I don't think it will: I was intrigued and went on Max2D's source to investigate. Max2D doesn't alter API states with the get\set scale's. When you use setScale a piece of code is called that has some multiplications, value assignments and a Sin and Cos calculation but they don't have API calls - so that's about all the overhead you should get. This code calculates variables to aid in offsetting the vertex positions when rendering the quads for each image - so what actually looks like a zoom is the quads getting bigger (their vertices being offsetted by the previously calculated factors). Using getScale retrieves 2 numerical values (stored in BlitzMax fields, not the API). Last edited 2011 |