New version

It ran on my:

Sony Vaio. P4-1.6GHz, 400MHz FSB, 512Meg, 32 Meg Mobility Radeon 7500 @ 32-bits on a 15" display @ 13.9fps to 14.1fps. The window took up my entire display.

Hmmm, real slow. It''s only drawing 30K polys (give or take) in the scene. How much slower is it to render with a single texture than with just vertex colours?

---

Read about my game, project #1

NEW (31st July): There is a new demo, demo #2 at my site. Please try it out.

---

John 3:16

at this rate i dont think ill even dl that demo...

Yeah... lol... looks like you need some serious optimization, maybe cut the amount of vertices you use in half... When it runs @ 16fps on a 1.9ghz/gf3 you know its bad.

1.3 Thunderbird, GeForce2MX, 256mb RAM - ran at a consistent 35fps.

Nice.


Oh and 1152x864 in 32 bit desktop (don't know if it actually takes the desktop res).

Actually - that was Demo 1. Demo 2 just gives me a black window with an fps around 45-50. Not sure whats going on there!

[edited by - Robbo on August 1, 2002 5:39:18 AM]

AthlonXP 1300+ 256 Meg, GF2 GTS 32 meg
35 fps.

32 fps on a Athlon XP 1700+ with 512MB DDR & Radeon 8500... But I got some apps running behind it.

---

Those who do not love don''t live.

---

[MSDN|Google|Bloodshed|My lousy page|email.me]

Is it normal that drawing the wireframe is slower than the coloured vertices?? I tried out demo #1, I get 60-70FPS at both shadings, but the wireframe runs stabel at 1.2FPS...

---

Those who do not love don't live.

---

[MSDN|Google|Bloodshed|My lousy page|email.me]

[edited by - LordLethis on August 1, 2002 6:11:53 AM]

[edited by - LordLethis on August 1, 2002 6:36:01 AM]

18 fps, p4 1.6, gf3. 1024x768.

i know you have been doing a lot of what i have, this heightmap deal, and i don''t know why its so slow. it looks basically what i have been doing, but mine runs 120 fps in 1024x768. i assume by 128x128 metere you mean 128x128 squares? i have 256x256 heightmaps right now and no polygon sorting system. i''m going to put in some kind of lod system hopefully. i think it may be the overhead from the sorting maybe? i think its kind of pointless to make a bsp on a heightmap terrain. and it looks like you have made the same system i have, the three textures lerped, but maybe executed differently. one thing i found that doubled fps in my engine is using 256 color textures, you might try that since terrain textures(that tile well anyway) usually don''t use more than 100 colors anyway. another thing is textures in my engine cover more than one square, its a varialbe to set, how many squares a texture covers before repeating. maybe the sheer number of texels is slowing it?

Thanks for the replies, guys. One minor moan, can you make it very clear which demo(s) you got which result(s) in.

Re demo #2:
I don't know why it's drawing slow. There are 128x128 squares, which equates to 32768 triangles rendered per frame. The sorting is not implemented.
The map is divided into 16x16 leaves, each leaf holds a list of rectangles for each texture being used, and triangles that would not fit into a rectangle due to blending & stuff

struct leaf
{
RECT[Number of textures][Number of rectangles at each texture]
}

//And the rendering loop:

for(i=0 to numTextures)
for(l=0 to numLeaves)
{
draw triangles from leaves[l].Rectangles
}
 

So there is only one texture change per texture used. Maybe it's because the leaves are so small - I should increase them to 32x32 perhaps. I've just screwed up my app somehow though so can't test right now

Actually there are more like 37K triangles due to redrawing transparent triangles over solid ones to get blending, but that only changed my fps by 1. Anyways, ~40K polys isn't very much for a GF2/3/4 is it?

Oh, can people with older cards try to - want to see if it works on non HW T&L cards.

---

Read about my game, project #1

NEW (31st July): There is a new demo, demo #2 at my site. Please try it out.

---

John 3:16

[edited by - d000hg on August 1, 2002 8:34:02 AM]

how many drawprimitives per call? i''m doing 20,000 triangles per call.

20K.

---

Read about my game, project #1

NEW (31st July): There is a new demo, demo #2 at my site. Please try it out.

---

John 3:16

I thought this might help someone help me:
My FVF is:

	struct MAPVERTEX1
	{
		float x,y,z;
		DWORD Diffuse;
		float u,v;
	};
 

I''m using a dynamic vertex buffer with the WRITE_ONLY & DISCARD flags (much faster than a static VB as I have to unlock every time the buffer gets full (holds a few thousand polys) then lock again after calling drawprimitive.

I think the problem may be that I''m calling this function for every vertex I want to put into the vertex buffer (for ~37K tris drawn per frame that''s ~100K calls per frame)

void Terrain::GenerateMAPVERTEX1(MAPVERTEX1 *p,UINT x,UINT y,short z,float u,float v,BYTE c,BYTE a)
{
	BYTE r,g,b;
	r=(BYTE)min( (255.0f*Light.Ambient.r + c*Light.Diffuse.r),255.0f);
	g=(BYTE)min( (255.0f*Light.Ambient.g + c*Light.Diffuse.g),255.0f);
	b=(BYTE)min( (255.0f*Light.Ambient.b + c*Light.Diffuse.b),255.0f);
	p->Diffuse=D3DCOLOR_ARGB(a,r,g,b);
	p->u=u;
	p->v=v;
	p->x=x*Space;
	p->y=y*Space;
	p->z=z*Hspace;
}
 

That''s only 9 mults, 3 adds per vertex, but I am writing each member individually to VRAM which is slow. Would storing 1000 vertices in an array of MAPVERTEX1s then copying across using memcpy be faster?

Another question, is it reasonable to have a vertex buffer containing many thousands of vertices, like a buffer of a few megabytes?

30 FPS

Athlon XP 1.4GHz
768 MB regular SDRAM
GeForec2 MX 400

constant 14 FPS in demo #2

1 Ghz P3 mobile
256 mb
ATI Radeon Mobile 16 mb

Huh?
I don''t. I had a thread for the first demo a couple of weeks ago, now I have a new demo so a new thread seemed sensible. Otherwise people would have to read down to the 20th post to even see I''d got a new demo.