Making my game go faster

[Grok]

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.

[Banana fanna fo fanna]

especially since Direct Draw was designed especially for Vb

Nope.

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

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.

[Atom]

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?

[n00blar]

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

[Yoni]

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

[Adron]

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.

[pileofcrap]

Why would you need it to go that fast anyway?

[Yoni]

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