Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / 3D Pacman: lots of pills = major slowdown?

Author
Message
Video Boy
21
Years of Service
User Offline
Joined: 21st Mar 2004
Location:
Posted: 13th Feb 2005 05:21 Edited at: 13th Feb 2005 05:36
I'm trying to make a first person Pacman game in DBC (I found it on sale for less than €10, so I chose to buy that).
The first thing I did was to lay out the pills, following the same layout they have in the original Pacman, but they gave a MAJOR slowdown to the program. I tried to follow every applicable suggestion in the "Make your game faster" topic, but they seem to have no effect.
This is the code: can anyone tell me what I'm doing wrong?
NanoBrain
20
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Portland, OR
Posted: 13th Feb 2005 18:21
Video Boy,

First, you probably should keep from using DBC's built-in collision detection. Especially setting it "to spheres". This will definitely cut down your frame rate. I would consider doing your own collision detection using math. Here is how I believe you should set your collision up, which will make your game run at a substantially faster speed.

1.)Because you really do not have a need for spherical collision detection, in this case, create a box collision formula for each pill. Let's say you have all your spheres 1 to 171. As you have done, you've placed them in their positions. Now, create simple collision detection in the shape of a box around the sphere. Check and see if the player position is within that area. If so, then execute the desired code. Check this
Now, in just this simple line of code, you can efficiently test whether or not your player is within the box area around the sphere. This, it'self, should raise your frame rate tremendously, by cutting down on the processing. It takes a great deal of processing to check for collision of spheres. Especially 171 of them.

2.)On top of the box collision of the spheres themselves, there is also another way to speed up your frames per second. Instead of checking for collision of every sphere(box) every loop, check to see if your player is within a certain area of spheres. If so, then check just that area of spheres for collision. In oher words, if the player enters area 1(a box area around the group of spheres), which could contain a number of spheres, then have the computer check for collision of those spheres only. When the player enters area number 2, then have the computer check just area number 2 for collision, and so on. To do this, simply code the group area box collision just like I did the spheres' box collision(if the player is within the boundaries).

3.)Lastly, in such a game, it might not be necessary to have the computer check for these collisions every loop. If you are looping the game 60 times a second, then it would not hurt to only check for these collisions every 5 loops, I suppose.
Doing this can slash your processing time by 12 times a second.

+NanoBrain+
Video Boy
21
Years of Service
User Offline
Joined: 21st Mar 2004
Location:
Posted: 13th Feb 2005 21:07
Thank you, I did it as you said and it's much MUCH faster! I get 62 fps now!
Now, for the second part... the maze. I had previously made a model of the maze as a single object, because my original intention was to check the collision of Pac-Man with the polygons of the maze, but I suppose I don't even have to think about setting collisions to polygons.
I imagine what I have to do instead is to split the maze model into rectangular objects that will be the walls, and check for every collision with the same method. Did I get it right?
PiratSS
22
Years of Service
User Offline
Joined: 18th Oct 2002
Location:
Posted: 15th Feb 2005 07:16
also, take a look at the "INSTANCE OBJECT" command, the loading times will be greatly decreased.
NanoBrain
20
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Portland, OR
Posted: 17th Feb 2005 07:14 Edited at: 17th Feb 2005 15:09
Video Boy,

Since your walls are all rectangular, just simply check to see if your player is within either of them. Also, you can use another method to speed up processing time. Let's say you have five walls and their object numbers range from 172 to 176. Create another counter variable which counts from 172 to 176.
Use this counter variable as the object number you are checking for collision of. In doing this, you are not checking for collision of every wall every loop. Therefore, saving another great chunk of your processor to handle other necessities.

+NanoBrain+
Los
20
Years of Service
User Offline
Joined: 3rd Jan 2005
Location:
Posted: 18th Feb 2005 08:42
the game ran fine on my machine when I first took a look. I wasn't handy in the improvement department! I saw all the deploy pill for loops and thought... yeah, ok!

I'd answer with a brilliant way of collision checking but it seems all these ways are fine. How could you make it faster? If you don't know how fast code A way works, or if it's faster than code B (running both at acceptable speeds, reaches sync limit) is to do it more times a loop. Check it twice, three times etc until you find the quickest. Pointless post?

" Ahh to finish something! My boy, have you ever accomplished anything? "

Login to post a reply

Server time is: 2025-05-25 04:16:27
Your offset time is: 2025-05-25 04:16:27