11-22-2001, 04:05 AM
ok i am just making a shooting game..attached
but the bullets after you have shot over like 20 it starts to really slow down and i dont see any code that i can cut down does anyone have some ideas on how to.....
you have to click on the mp5 in the list box on the left hand of the screen
then you have to click within the game screen
(yea i know there are a few bugs there they occured while changing other code)
11-22-2001, 06:58 AM
I ran your code on a P3 600Mhz, and I had no problems. When I increased the Speed Counters in your code, I noticed that it ran a hell of a lot smoother. All I changed was the BulletSpeed to add 2 rather than 1. Try increasing these values and you'll see what happens.
11-22-2001, 06:58 AM
Ok, I didnt experience the slowdown problem you mentioned but I will still give you some pointers as to things in your code you might want to improve.
1. Lookup tables
You code is riddled with calls to Sin, Cos, and Atn. These are some of the slowest mathematical functions there are. What you might see many professionals talk about are lookup tables, which are arrays of numbers which store the Sin or Cos value which corresponds to that angle. It is normally not used with Atn. It might be something like this:
<pre>Const Rad = pi / 180
Const Deg = 180 / pi
Dim lookCos(0 To 360) As Single
Dim lookSin(0 To 360) As Single
Dim i As Integer
For i = 0 To 360
lookCos(i) = Cos(i * Rad)
lookSin(i) = Sin(i * Rad)
Now, whenever you need the cos or sin of an angle, you would first ensure that it is in degree format by multiplying by the Deg constant. You would then find the number from the lookup arrays. Lets say I want the Cos of 45:
lookCos((pi / 4) * Deg)</pre>
Both of these would provide the correct answer. The first is a direct call with a degree number, the second line converts an angle from radians into degrees first.
2. Allow the user to exit
Currently, clicking the close cross has no effect. This is annoying, and is because you game is running within a loop which is never told to end. I suggest adding this code:
<pre>Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
3. Using smaller types
I noticed that you had used one really large User-Defined-Type called 'Extention' which had some 26 parts. Then, you defined things like the array Points(4) as this Extention and only used the X and Y values of the type. I think you should split your type into a number of smaller types, such as Weapon and Ammo.
4. Dont use so many variants
You used variants a lot, especially in the Type you call Extention. Variants are the slowest data type by far. For X and Y positions, I would think Long would be a suitable data type. As I read it, it seems you are using Variant where I myself would use Single or Double. Are you not familiar with these data types?
Other than that, and a few minor bugs which Im sure you are aware of (such as the player's spinning and label flickering), the game looks good and fine to me. Keep up the good work.
11-22-2001, 07:10 AM
Squirm, using End can cause many problems. I would avoid it whenever you can (I've never found a situation where it was necessary).
In this case I'd would:
Declare a global boolean called quit
Change the Game loop to "loop until quit"
Move the Doevents in the game loop to the bottom.
In the QueryUnload event set quit true and call DoEvents
11-22-2001, 08:03 AM
Yeah, sorry, I also rarely use End except where I am running from a code module. Im not quite sure why I suggested that, I think maybe its because it was easier to explain that way. Sure, I wouldnt use End normally like that.
Sorry if I have badly infuenced anybody here images/icons/frown.gif
11-22-2001, 08:14 AM
That's alright, we all make mistakes.
11-22-2001, 08:47 PM
Can someone please list the data types for...
Real numbers...eg 1.43
Letters............ eg bfdbdf34rfw
11-23-2001, 12:30 AM
The SINGLE and DOUBLE both can hold real numbers
The STRING can hold letters
11-26-2001, 06:11 AM
You are theoretically correct about lookup tables for SIN and COS, but in my testing, I didn't find too much of a speed difference between using SIN and COS and using a lookup table. I suspect that VB may be optimized enough to use a lookup table internally. Or maybe the math coprocessor is simply a lot more efficient.
Maybe you could test it on your system and see what the speed different is....your system is probably different from mine and you may see a significant time savings....(or not)
11-26-2001, 07:09 AM
I've tried this an here are my results:
Over 1 million operations:
Lookup table: 0.349 seconds
Function call: 0.641 seconds
So, although the function call was half the speed of the lookup table I don't think I'll lose any sleep over 300 nanoseconds per operation :)
11-29-2001, 05:50 AM
thanx for looking it up :)