Making my game go faster

Atom · February 17, 2003, 08:04 PM

Ive been workin on a game engine, and im tryin to do all the little things i can to make it go as fast as possible. In vb I heard longs are faster then integers so i made all my integers longs. What about doubles, etc?

On my Pentium 3 450mhz, 128mb of ram, 32mb nVidia GeForce
I get an average frame rate of about 170 fps. Im asking you Grok cuz you are the master of computer science and me bows to you.

iago · February 17, 2003, 10:05 PM

The human eye can register about 30 frames/second, so what's the problem?

But things you can do to speed up a program:
- Check your algorithms, if you can avoid iterations of a loop then do it
- Time your functions using GetTickCount() [or equivilant vb function], find out what's taking up the most time and work on that.
- Reprogram complicated functions in assembly [this doesn't apply to vb, but I'm paraphrasing a book I'm reading]
- If you're using library functions that are designed to have a wide variety of uses and you're only using it for one thing, program it yourself since you don't need the extra functionality
- Finally, because somebody's going to say it anyway, get a real programming language

Except for the last one, that was from Programming Pearls, by Bentley, a very good book.

Naem · February 17, 2003, 10:27 PM

30 FPS? Where did you hear that?

I play Counter-Strike and get FPS ranging from 20 to 99. The difference in 30 to 60 is very obvious, but after 60 I cannot really tell the difference much.

Skywing · February 18, 2003, 03:38 AM

QuoteThe human eye can register about 30 frames/second, so what's the problem?

But things you can do to speed up a program:
- Check your algorithms, if you can avoid iterations of a loop then do it
- Time your functions using GetTickCount() [or equivilant vb function], find out what's taking up the most time and work on that.
- Reprogram complicated functions in assembly [this doesn't apply to vb, but I'm paraphrasing a book I'm reading]
- If you're using library functions that are designed to have a wide variety of uses and you're only using it for one thing, program it yourself since you don't need the extra functionality
- Finally, because somebody's going to say it anyway, get a real programming language

Except for the last one, that was from Programming Pearls, by Bentley, a very good book.

GetTickCount's resolution sucks. You should definitely not use it for precise timing! Instead use QueryPerformanceFrequency and QueryPerformanceCounter.

Grok · February 18, 2003, 04:36 AM

QuoteIve been workin on a game engine, and im tryin to do all the little things i can to make it go as fast as possible.

You can only do so much in VB. Performance optimization is about control. VB does not give you control of your own code.

For example, pcode runs faster than native code where strings are concerned. If you're doing number crunching, native code runs faster. If database then we're back to pcode again. There's nothing you can do about it either.

Switch to C with a mix of assembly to get the control you want. OR do your best with VB and acknowledge the limits of your tool choice.

Yoni · February 18, 2003, 07:58 AM

QuoteIn vb I heard longs are faster then integers so i made all my integers longs. What about doubles, etc?

I don't think longs and integers have any speed difference. Floating-point variables are definitely slower than integers though.

iago · February 18, 2003, 09:02 AM

Quote30 FPS? Where did you hear that?

I play Counter-Strike and get FPS ranging from 20 to 99. The difference in 30 to 60 is very obvious, but after 60 I cannot really tell the difference much.

Well, my vcr reads at 32 fps, and that seems pretty smooth :-)

Plus, even if there IS a difference between 30 and 60, I doubt 170 is anything to complain about..

Banana fanna fo fanna · February 18, 2003, 10:49 AM

Yoni: yes there is

ints are actually 32 bits, so don't use longs unless you're coding for a 64-bit platform. Maybe you'd #define a data type, based on the platform (64 bit: longs, 32 bit: ints). I'd move some core loops into inline asm if you think the compiler isn't doing a good enough job. Also, make sure you use OpenGL and not Direct3D if it's 3D. Ensure that you move as much of the work as possible into the graphics lib, which will likely pass it down to hardware accelleration. Finally, don't be afraid to use up memory. If you load stuff at startup and sacrifice memory, so be it. The payoffs in speed will be worth it.

Skywing · February 18, 2003, 11:36 AM

QuoteYoni: yes there is

ints are actually 32 bits, so don't use longs unless you're coding for a 64-bit platform. Maybe you'd #define a data type, based on the platform (64 bit: longs, 32 bit: ints). I'd move some core loops into inline asm if you think the compiler isn't doing a good enough job. Also, make sure you use OpenGL and not Direct3D if it's 3D. Ensure that you move as much of the work as possible into the graphics lib, which will likely pass it down to hardware accelleration. Finally, don't be afraid to use up memory. If you load stuff at startup and sacrifice memory, so be it. The payoffs in speed will be worth it.

Umm, Integers in VB are 16-bit. Not to mention that VB doesn't support inline ASM...

I've got no idea where you're getting the idea that longs are 64-bit on a 32-bit platform.

Yoni · February 18, 2003, 11:39 AM

Quote(64 bit: longs, 32 bit: ints)

You've been influenced by Java too much.

dxoigmn · February 18, 2003, 01:40 PM

Quote30 FPS? Where did you hear that?

I play Counter-Strike and get FPS ranging from 20 to 99. The difference in 30 to 60 is very obvious, but after 60 I cannot really tell the difference much.

Reason you can tell a difference is due to input. Each frame the engine is waiting for input and consequently you "see" lag but really its just that the input for the mouse/keyboard is lagged. That is why people always try to get the most frames out of a game by reducing visual aspects and such because input is as important as the visual, if not more.

Edit: Fixed quote bug

Banana fanna fo fanna · February 18, 2003, 03:43 PM

Whoops, thought he was in C.

And yeah, Yoni is correct

Zakath · February 18, 2003, 05:17 PM

Even in C, long == 32 bit...

Atom · February 18, 2003, 05:23 PM

Skywing is correct, Integers in Vb are actually... oh nm.
Yeah i would use OpenGl cuz it is a LOT better then Direct 3d, ive seen games that use both, and Gl runs a lot better. But my game is 2d and i am using Direct Draw. So far i love it, my first attempt at gaming, and its working very well.

Grok if i was doing 3d i would indeed using a different language, cuz 3d vb games run about 50 fps, and a 16-bit Snes runs at 60 fps, so thatd be rather crappy. Anything above 60 tho you cant really see the difference. The reason im using Vb is because... I love Vb, and for a 2d game, i think its a lot more appropriate, especially since Direct Draw was designed especially for Vb, if youve ever used it in Vb you would see how easy it is. Anyways now im rambling.

If in the future I implemented some online play, you think i should use Direct Play or just do the Ol' Winsock?

iago · February 18, 2003, 08:53 PM

QuoteEven in C, long == 32 bit...

This is platform dependant. For example, in x86 and 68k, a word is 16 bits and consequently a dword is 32 bits, but on SPARC (and other such systems), a word is 32 and a dword is 64.

My point is, you can't rely on datatypes always being the same size. The best thing to do is, at the top, or even in a header, #define INT32 long #define INT16 short, etc, that way, if you decide to change it to a system that has different standard sizes, it doesn't screw up. Unless, of course, it doesn't matter