XType Engine's Timer class... needs major work!

[sniperwolf]

Okay, after a lot of digging, I found this generic timing code, and modified it slightly to fit my needs:

Code: Select all

public void calcFrameRate()
		{
			frames++;
			int ticks = Environment.TickCount;
			int elapsed = ticks - lastTickCount;
			if (elapsed >= 1000)
			{
				framerate = frames; 
				frames = 0; 
				lastTickCount = ticks;
			}
		}

		public int getFrameRate()
		{
			return(framerate);
		}

As it is now, I create the timer during my Init() call, and at the very start of the OnPaint() method, I call calcFrameRate(). I then call getFrameRate() in the Render() calls, passing it to my movement formulas.

One problem I have is that I get horrid visual tearing when flying past textured terrain meshes. That, and my performance TANKS when they're being rendered. They're very low poly [probably no more than 100 polygons], textured with a 1024x1024 TGA format UV map. The starfield doesn't seem to harm the framerate too much - it's around 2000 polygons, each with no texture and each surface's emissive texture set to white.

Bear with me if I've said anything that should be obvious to you guys - this is my first stab at making anything more complicated than an ASP.NET web app.

[landshark]

It depends on how you are drawing the terrain. If you can, try and optimized it into triangle strips/fans (depending on the terrain type).

What are you calling to draw the text? WIN API routines are notoriously slow as well (though they shouldn't be tanking your machine). Write your own font loading/blitting routines.

A 1024x1024 texture map is pretty damned big. I'm not sure on the performance hit you would take from that. Make sure that you are loading it into hardware.

Also, this is probably a really stupid point, but make sure you are really using the hardware renderer. You have a 2Ghz+ machine right? You might actually be using the software renderer and not knowing it because your machine is keeping up.

[sniperwolf]

It depends on how you are drawing the terrain. If you can, try and optimized it into triangle strips/fans (depending on the terrain type).

I'll see what I can do in this regard. I'm loading .x meshes from exported Lightwave objects, like I've said before... I'll see if I can toy with the loading code.

What are you calling to draw the text? WIN API routines are notoriously slow as well (though they shouldn't be tanking your machine). Write your own font loading/blitting routines.

I don't have my laptop handy right now w/the code on it, but I'm using DirectX's text drawing functions. I know, the Windows API is not too speedy at all.

A 1024x1024 texture map is pretty damned big. I'm not sure on the performance hit you would take from that. Make sure that you are loading it into hardware.

I was thinking that too. I'll try to use something smaller, like 512x512, and see if the performance jumps at all. I didn't think it'd be that big a difference, since both my video cards are relatively modern - but it could have something to do with using a TGA instead of something more compressed...

Also, this is probably a really stupid point, but make sure you are really using the hardware renderer. You have a 2Ghz+ machine right? You might actually be using the software renderer and not knowing it because your machine is keeping up.

Not a stupid point at all - as far as I know, I'm using the hardware renderer, but it does warrant a look at my init() routine. I did notice that the textures on the terrain mesh aren't getting filtered at all, though I figured that had to do with some setting I hadn't set yet. Makes sense that the thing might just be in software mode, though...

[regret]

Okay, after a lot of digging, I found this generic timing code, and modified it slightly to fit my needs:

Code: Select all

public void calcFrameRate()
		{
			frames++;
			int ticks = Environment.TickCount;
			int elapsed = ticks - lastTickCount;
			if (elapsed >= 1000)
			{
				framerate = frames; 
				frames = 0; 
				lastTickCount = ticks;
			}
		}

		public int getFrameRate()
		{
			return(framerate);
		}

As it is now, I create the timer during my Init() call, and at the very start of the OnPaint() method, I call calcFrameRate(). I then call getFrameRate() in the Render() calls, passing it to my movement formulas.

Thats one way of doing it. I would however solve the timing issue by using a delay function. It doesn't have the "lag" problem that you have in your code. Something like this:

Code: Select all

#define FPS 60
int frames;
int starttick;
float intervaltick;
int prevtick;

void initFrameRate(){
  intervaltick = (1000.0/(float)FPS);
  frames = 0;
  starttick = GetTicks();
  prevtick = starttick;
}

void fixFrameRate(){
  int nowtick;
  float nextframetick;

  frames++;
  nowtick = GetTicks();
  nextframetick = prevtick + (float)frames*intervaltick;
  if (nextframetick > nowtick)
    Delay(nextframetick - nowtick);
}

[Tychom]

You do have double buffering setup too? (dunno if this is automatic or anything with DirectX)..

[landshark]

Not a stupid point at all - as far as I know, I'm using the hardware renderer, but it does warrant a look at my init() routine. I did notice that the textures on the terrain mesh aren't getting filtered at all, though I figured that had to do with some setting I hadn't set yet. Makes sense that the thing might just be in software mode, though...

It's been a few years since I've used D3D, but I tend to say that if you do not see any filtering, then you are probably using software mode. I think by default, it enables some kind of filtering unless you tell it otherwise.

Also, try to use smaller textures for better compatibility with other people's hardware. Not all hardware can make use of 1024x1024.

You are making me want to write another engine.

[sniperwolf]

Thats one way of doing it. I would however solve the timing issue by using a delay function. It doesn't have the "lag" problem that you have in your code. Something like this:

Code: Select all

#define FPS 60
int frames;
int starttick;
float intervaltick;
int prevtick;

void initFrameRate(){
  intervaltick = (1000.0/(float)FPS);
  frames = 0;
  starttick = GetTicks();
  prevtick = starttick;
}

void fixFrameRate(){
  int nowtick;
  float nextframetick;

  frames++;
  nowtick = GetTicks();
  nextframetick = prevtick + (float)frames*intervaltick;
  if (nextframetick > nowtick)
    Delay(nextframetick - nowtick);
}

Ooo, very interesting. I was wondering about experimenting with a delay... will have to test that out later.

[sniperwolf]

You do have double buffering setup too? (dunno if this is automatic or anything with DirectX)..

I *believe* it's automatic, I want to say it has to do with the PresentParameters.PresentationInterval setting on the D3D device, but I'm not totally sure. I don't recall seeing a specific device setting for double/triple buffering, need to do some more digging, I think.

[sniperwolf]

It's been a few years since I've used D3D, but I tend to say that if you do not see any filtering, then you are probably using software mode. I think by default, it enables some kind of filtering unless you tell it otherwise.

Okay. Like I said, I tore my Init() function out of some beginner's guide to Direct3D 9 - so I think it might be written to be as compatible as possible, and turn on the software engine by default. I figured, the textures looked SO much better in Lightwave, they shouldn't be composed of 10 foot tall pixels in my D3D app.

Also, try to use smaller textures for better compatibility with other people's hardware. Not all hardware can make use of 1024x1024.

Well, that's true too. A lot of what I was doing up till now was "just make the thing work", which is evident in the godawful [but getting better] code in my player ship class, and my actual windows form class. I'll slice the UV map texture down in size, compress it a bit, and see if I can turn on filtering to compensate.

You are making me want to write another engine.

Glad to provide the influence.

Two things inspired me:

1. I need something really nifty for my portfolio, as a soon-to-be graduate of computer science, and
2. Playing Einhander and Gradius 3, and thinking "I bet I could figure out how they did that..."

[landshark]

Well, that's true too. A lot of what I was doing up till now was "just make the thing work", which is evident in the godawful [but getting better] code in my player ship class, and my actual windows form class. I'll slice the UV map texture down in size, compress it a bit, and see if I can turn on filtering to compensate.

Compression is not always necessary. I'd be willing to bet most people who will play this don't have hardware compression support (some may). If you are using 3d hardware, most of the basic hardware out there should suffice for full speed. Unless you want to get into shaders for effects and such, it's better to stick to the basic hardware stuff (unless you can modularize it) for as much compatibility as possible.

Glad to provide the influence.

I doubt I'll do anything. I've started several shooter (and other genres) projects over the last 8-9 years. None of which have ever seen further than my hard drive. I usually get bored

[sniperwolf]

Compression is not always necessary. I'd be willing to bet most people who will play this don't have hardware compression support (some may). If you are using 3d hardware, most of the basic hardware out there should suffice for full speed. Unless you want to get into shaders for effects and such, it's better to stick to the basic hardware stuff (unless you can modularize it) for as much compatibility as possible.

True. I'm thinking I'll end up testing this on my girlfriend's PC as well - it's much lower spec than anything I have, and it has, if I recall, a GeForce 2. I think that's an acceptable "baseline" to test things against nowadays.

I doubt I'll do anything. I've started several shooter (and other genres) projects over the last 8-9 years. None of which have ever seen further than my hard drive. I usually get bored

You sound like me. My "Visual Studio Projects" folder has dozens and dozens of unfinished ASP.NET and standalone C# apps in it. I keep myself motivated on this one by making it do dumb stuff that keeps my interest, like last night, I figured out how to apply a sin() function to my bullet transform matrix to make them fly in a wave format. That, and the fact I'm actually coming close to a working, well, something, is providing ample motivation for me!

[landshark]

My motivation usually starts during the day/morning sometime when I see something.'

But then it craps out after work since by trade I am a Software Engineer and I don't want to do anything code related when I go home

[sniperwolf]

My motivation usually starts during the day/morning sometime when I see something.'

But then it craps out after work since by trade I am a Software Engineer and I don't want to do anything code related when I go home

Heh, I know what that's like - when I was writing my senior project in ASP.NET, I was coding 3-4 hours a day aside from class... and pulled MANY all nighters [at least once per week for two terms]. I did the occasional side project [and side projects for classes too] but man, I did not want to touch code aside from the big project. I always thought "When I'm not so burned out, I'm teaching myself DirectX over this summer!"

That's what I get for being in a group of three, and the only one doing any work. The bright side is, I now know SQL and ASP.NET way better than I did before.

[landshark]

I did tons of little projects all through college. That's when hobbiest programming was fun for me. Now that I do it for a living, I don't really touch it outside of work (I did for the first 3 years or so, but after that I have only done a few things here and there).