Performance Test - Isometric Engine Using ZBuffer
Community Forums/Showcase/Performance Test - Isometric Engine Using ZBuffer
| ||
| Hi All, Could I please ask some people to try out this demo and let me know how good/bad it performs on different PCs. Demo is here: http://home.swiftdsl.com.au/~Matthew.Lloyd/lloyd/IsoTest.zip It is a 2.8 MB download zip file. I am interested in finding out how many 'units' it takes before the frame rate drops below 40fps and/or what the frame rate is when the unit count is between 30-50 units. When it loads it should show a fairly basic dungeon environment with the logictime/rendertime/fps/unit count shown in the upper left. Press space bar to place a unit on screen (which can be moved around with the cursor keys) and press the left mouse button to add units (not player controlled) to the environment. Thanks, Matt PS - I've tried it on my old 500 Mhz AMD machine (Geforce 2 MX) and it slows down considerably with only a few (less than 10) units on screen. While on my laptop (AMD 3600+ (?I think?) ATI Radeon 9700 64MB VRam 512MB System Ram) I can have around 50 units on screen before any noticeable slow down occurs. |
| ||
| Frame rate (30-50 units): 60FPS Units before framerate drops: ~110 Anything over 110 gives me a sudden drop from 60FPS to around 30/35FPS. (Specs in sig) |
| ||
| Frame rate ( up to 145 units ) 60fps Anything above and Frame rate drops to 30 suddenly?! Specs: P4 3mhz , gfx440mx , 512meg RAM , WinXPPro. Stevie |
| ||
| He's using vwait or flip 1 :) |
| ||
| FrameRate (30-50) 60 fps over 110 drops to 30/35 fps Things to take into account that can cause frame rate drops like that 1. Make sure you only check collision with the nearest characters to the player. 2.Ai units dont really need any imagecollision with the map .store map info in a grid format and reference that ie 3-4 passable 5-7 blocked. 3.Make sure you dont have collision set up to check if all ai units collide ie only check for units that are within a fixed range of each other or use similar to method 2. |
| ||
| Cyg has it: a halving in framerate means Vsync is on, which I prefer actually. Best to keep the game running full speed where pos but it it drops the odd frame here and there, that's OK as it won't be noticed. Actually running at 30FPS doesn't look so bad if it's constant, what's worse is constantly going from one to the other because the code is borderline. |
| ||
| i've run into the same sorta timing thing... i wound up slowing down the game logicm independent of the refresh rate, so that everything has a chance to get done before the next game tic... still though, i can see some potential problems... and each level of the game has to have a different logic speed... this is what i'm asking Ant about now concerning the structure of his latest 'engine'... the 'stuffing all the update function calls for everything in your game in mainloop' method is what i have a problem with... better to have some sort of messaging or callback available... yes, no ? --Mike |
| ||
| Hi All, I am using flip 1 which is why it drops to 30 fps suddenly - I am mainly concerned with knowing on what level of hardware I can have 30-50 units in game on and still run at 60 frames per second or higher. Duckstab - you will likely find that it is not the collisions which are slowing things down but the draw routine. That is why I had the 'logic time' and 'render time' displayed on screen. I would be surprised if the logic time went above 10 ms (even on my 500 Mhz machine the logic time remains below that figure way before the render time becomes a problem.) I'd be quite keen to also hear from anyone with a lower end system how their system performs, particularly with regards to when 30-50 units are present. I'm thinking of using this to re do my "Blood And Plunder" game or at least make something similar. |
| ||
| didnt mean to seem negative but if i see that sort of fps with less than 2000 images,sprites using blending on my spec it normally points to code not the images. ie sorting methods.. what are the character dimensions 128 by 64? |
| ||
| The reason it slows down so much with only ~110 images is because I am using writepixelfast for every sprite (coded in blitzplus) in order to be able to use a single bitmap as the background. As you know most isometric engines use tiles. Mine uses a single image as the backdrop. This means that I need to have two depth values for each pixel - one for the detailed environment and another for the 'floor'. By comparing each individual pixel in the image between the backdrop depth value and the floor depth value at the unit's feet I can tell whether a pixel should be obscured by walls and other obstacles. Therefore I cannot use 'drawimage' (which would easily allow for thousands of sprites) but instead must use writepixelfast....unless you or anyone else can point to another method of doing an isometric engine that uses a single image for the environment. Also - I have ensured that no pixel ever gets drawn more than twice. The image strip that the character dimensions came from was 128x128 but I don't store the images in VRAM but instead store them in system RAM using my own image format (all those .pix files). By doing this I can have many more different characters. For these character sprites the file size is slightly larger than a corresponding png file but it is not compressed. |
| ||
| ok..well on my 800mhz 9600pro setup..10 units drops fps under 50...to 40 something.. Then i doubt you care about having it run on systems this old.. You no doubt have your reasons for performing per pixel ops, but its going to be killer even on good systems..there must be another solution. anyway - goodluck. |
| ||
| At 95 it starts to go to 30 once and a while. Specs below |
| ||
| 39 units is still at 70fps then suddenly 40 dips the fps to 40 ish. IPete2. Athlon 1900+ 768 MB RAM GeForce 6600 (256MB ddr) |
| ||
| same as IPete2 but mine dips when I have 39 units. |
| ||
| @ Matty, I cannot understand the need for a single image for the background? Why not use a tiling system like most others? Surely the overheads needed to determine the drawing order for each tile / character / item far outweigh writing each invividual pixel on screen. |
| ||
| The reason I use a single image for the background is that it means I can use a prerendered image for the environment which may not be easily reduced to 'tiles'. Also another reason for writing each pixel is that I have a lot more control over the appearance of the sprites - I can adjust colors in real time (for no additional performance hit) so that for instance the sprite flashes or is brightened/darkened without needing additional images for each of these states. Also I can fit a lot more different types of unit into the game as for each sprite I am only storing the color value of non transparent pixels in system RAM instead of Video RAM meaning that each image uses less memory than if I were to use standard images and that I have more memory to play with since available system RAM is usually greater than Video RAM. |
| ||
| No Units - 1000fps 42 Units - approx 200fps 200 Units - approx 40fps |
| ||
| 40 units = ~70 fps 100 untis = ~40 fps 170 units = ~30 fps These figures are based on the number of units required to start making the fps drop below the stated level. |
| ||
| Thanks everyone. |
   |