• ### Popular Now

• 10
• 9
• 13
• 10
• 18

#### Archived

This topic is now archived and is closed to further replies.

# I'm offering $100 (USD) to the person who can speed this thing up This topic is 5941 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic. If you intended to correct an error in the post then please contact us. ## Recommended Posts I''m at the end of my wits. For the life of me I can''t figure out why my engine won''t run fast. I need a real D3D guru who''s willing to spend a little time to try to get this thing running. So I offer$100 (USD) to the person who can fix this problem. Here are the requirements: A) Must run using hardware B) Must be fast enough to draw MANY hundreds of these models per frame at 30FPS. Currently I can only get 75 per frame. The model is shown in the picture below. C) Must use internal model rendering routines and make no use of external libraries other than D3DX. D) Must run on machines which don''t have the DX8 SDK installed Limitations: A) This is an engine DLL, so there isn''t much that can be done to optimize the scene for rendering since each render request is sent directly to the DLL. Here is what I already know: - On the one machine I tested which didn''t have the DX8 SDK, the CreateDevice() function would return a mysterious error code (0x8007000E), which doesn''t equate to any in the SDK documentation that I could find. - It seems as if it is using hardware to render, since enabling/disabling bilinear filtering doesn''t affect performance very much at all. The performance level is extremely low even still. - For more details, read THIS post. If you think you''re up to it, PLEASE email me at: x_bios@hotmail.com. The person whom I choose to fix the problem would receive the full source code, a sample program (source and executable) to benchmark it, and (of course) a contractual agreement outlining the nature of the work, the \$100 payment, and to protect my engine. Here is a sample of the model and a sprite which are used in the game:

##### Share on other sites

A decent machine with a GF3 should have no problem rendering several hundred of these things. Before you part with your money, you might want to nail down some additional ground rules such as:

1. what is your hardware target?
2. how general should the solution be - are you just looking to draw that one model, or are you trying to solve a more general problem?
3. How does one prove that they've done this? If it works on my 2Ghz + ti 500 do I "win"?

It seems that you may have a general problem that will not be solved by throwing money at a very specific issue, assuming that you are developing the engine beyond this column thing. I'm *guessing* that there are many people that could earn the money but not really help you in the larger sense.

Edited by - CrazedGenius on December 12, 2001 1:59:36 AM

##### Share on other sites
Hey flaXen,

Your "mysterious error code" (0x8007000E) is the COM error, E_OUTOFMEMORY. It sounds like you''re having memory problems on that system for some reason.

-Alias

##### Share on other sites
The target system is the average computer. Any 3D accelerated video card should be able to run this w/o a problem. I''d be willing to bet that even on your fabulous system, performance wouldn''t be too unlike what I can achieve on my own system.

A little math here answers a lot of questions. There are 209 textured and lit faces on that model. Of which, not all, but most, are being drawn. I''d estimate about 180 or so are actually drawn. So.. 180 tiny polygons per model. Simple multiplication tells us that 180 * 75 (75 per frame) * 30 (target FPS) = 405000 per second. Do you know of any modern video card capable of rendering SLOWER than this?

Some of these polys are no larger than a pixel. The problem is a general one. The sprite put is also limited in number to some 14500 per second (last I checked). Each sprite consists of 2 triangles, and has alpha testing enabled. There is a serious performance issue here, and it''s beyond me what the problem is. That''s why I''m offering a money reward. I could spend days trying to solve it, but instead, I''d rather offer someone with experience with D3D a chance to fix it for a reward.

-- Dan

##### Share on other sites
Are you sure that it is the rendering code? For instance, if you are calling a dll, are you sure that the dll is being called in a timely fashion. ie - if you don''t render anything in the call is the rendering extremely fast?

Every card is MORE than capable of rendering slower than that.

By general, I meant that maybe you are doing something fundamentally wrong with the device, etc., in which case the mesh drawing may not be the issue at all.

Either way, you should anser your email.

##### Share on other sites
want a quick way to kill card performance? kill the fillrate. swap textures many times and use textures too big to fit into video cards memory, use obsecene resolutions, turn on full scene anti-ailising, switch renderstates many times over, use features not properly supported by the hardware, use vertex buffers improperly by locking ones setup for video memory and lock/unlock them before every drawprimitive(), and a host of other things.
heck you could just be killing cpu time with crap that is doing too much. your framerate code could be bad, giving you bogus results. the real question is not how many polygons are being pushed, but how many vertices are being transformed. in other words
209 polys*100*30 = 627000 polys/second which can be either
209*3*100*30 = 1881000 vertices transformed or 1254000 vertices or even only 800000 vertices depending on how you set up your model. since using index primitives reduce amount of vertices transformed, using triangle strips and fans do this as well. are you even using vertext buffers or using the slow drawprimitiveup (ok for a few quads on a gui but not for anything else)

##### Share on other sites
I''m using a single texture. It''s getting set only once (first draw after BeginScene, which is only getting called once). The texture is 32x64/32bpp and is sent to the video card and unlocked before the model geometry is loaded from the file.

Likewise I cache render states and only reset the cache when BeginScene is called.

Screen resolution is roughly 400x360 or so in the test program.

No FSAA is being used since the TNT2 Vanta doesn''t support it.

The index and vertex buffers are loaded from a file, put in their respective DX buffers, and unlocked. They are never locked after that point.

I''m not rendering on a timer or anything like that. I call BeginScene once, before taking the current time and before drawing anything. EndScene is then called after the end time is taken (after 10000 draws of the model). So none of that is an issue.

I use DrawIndexedPrimitive to draw my models. Each model is divided up into texture groups. That model has 4 texture groups, but for the sake of benchmarking I used the same texture on each one.

The number of vertices for this specific model is 215, and the number of polys is 209. Since I can only draw 75 per frame @ 30fps w/ my current routines (ie 10000 draws takes about 4.45 seconds), that means 215*75*30=483750 vertices transformed per second. 209*75*30=470250 polygons going thru the pipe per second. An unknown number of those actually draw, but I guestimated 180 or so.

Culling is on. Z-buffer is read, but not written to (to make sure all polys are drawn and not ignored).

##### Share on other sites
480000 tris per second? Arent you glad you arent developing on my card. I get at most 100000 per second.

Z.

##### Share on other sites
I had a similar problem back when I first started my engine. I found that the thing that brought my framerate up to par with every other game out there has nothing to do with your geometry, but rather the size of your textures. Make absolutly sure that your textures are perfectly square, and a size that is a power of 2 (32x32, 64x64, 128x128, 256x256, etc...). You might even try disabling textures and see what happens. You may have already tried this, or someone may have already posted a similar idea, but I hope it helps anyway.

HanSolo
Sector 13 Games

##### Share on other sites
"Z-buffer is read, but not written to (to make sure all polys are drawn and not ignored). "

Disable it, it not a good idea to use only read in your case i think.If I assume you clear the z-buffer each call, you test for just nothing. I think it is needed for you to enable it. But I have see performance boost when you disable it on some hardware.

Why English rules?? C pas très malin tout ça!