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.  8)

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.

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.

[quote]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.[/quote]
GetTickCount's resolution sucks.  You should definitely not use it for precise timing!  Instead use QueryPerformanceFrequency and QueryPerformanceCounter.

[quote]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.[/quote]

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.

[quote]In vb I heard longs are faster then integers so i made all my integers longs. What about doubles, etc?[/quote]
I don't think longs and integers have any speed difference. Floating-point variables are definitely slower than integers though.

[quote]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.[/quote]

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..

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.

[quote]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.[/quote]
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.

[quote](64 bit: longs, 32 bit: ints)[/quote]
You've been influenced by Java too much.

[quote]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.[/quote]

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

Whoops, thought he was in C.

And yeah, Yoni is correct ;)

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

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?

[quote]Even in C, long == 32 bit...[/quote]

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 :)

Atom, I'm sure you're having an easy time of using Direct Draw in VB and enjoying it.  But you're asking me to make a optimization recommendations for continued use of Visual Basic in your game.  I will not do that.  VB is an application development tool that has its niche carved out due to its abilities that come from its architecture.  From a price/performance view, it is appropriate for kicking out business applications to a user desktop in relatively short order, as well as for a few other specialties.  Even the specialties get their power from C-derived DLLs cooperating with Visual Basic wrappers communicating via COM.

VB in my opinion would be terrific for prototyping your game, but not for delivering it.

[quote]especially since Direct Draw was designed especially for Vb[/quote]
Nope.

[quote]
If in the future I implemented some online play, you think i should use Direct Play or just do the Ol' Winsock?[/quote]
I've never used DirectPlay myself, but from what I've heard, the API sucks horribly. Since you probably already know Winsock pretty, well, I'd go for that.

I didnt mean that Direct Draw was made for just VB, but i meant that they made it to work well with vb.
You know what i mean?

Thought I would throw my 2cents in here, longs are faster, IIRC vb passes everything by a pointer, and it just happens to be 4 bytes so it is obviously faster =) a integer would have to pass a ptr to itself and IIRC long might just pass its value instead of a ptr making it faster??? i dunno could be wrong... something along these lines =P

VB passes everything by pointer? Ever heard of ByVal?
And even if that were true, if VB variables work anything like they're supposed to, wouldn't passing a pointer be faster than passing a value? Calculating esp+offset should be faster than reading [esp+offset].

Passing by pointer for small variables is mostly slower. Some reasons:

The pointer will have to be dereferenced in the called function anyway - might as well do it now.

The function might also be using the variable more than once, causing code to get bigger each time: Load address from stack + load variable from address instead of just load variable from stack.

If the variable has been optimized as a register variable, it will have to be stored to a memory location before the call.

You're unable to pass in a constant value for the argument, have to use a variable, or the compiler will have to create a temporary variable for it.


Conclusion: Call by reference only when you will be modifying the argument, or when the variable is big and it would take time to push it all onto the stack.

Why would you need it to go that fast anyway?

Well, typically the time it takes to pass a parameter to a function is so tiny it's meaningless. But you have to take care of every tiny detail if you're writing "real time" code, such as a function that will be called 1000000 times per second as part of rocket guidance software. It's the principle of the thing.

In a game it really doesn't matter, especially since you're coding it in VB. You generally have very little control over the speed just because of that (not comparable to the control you have if you code in assembly).