I'm coding a GameBoy Advance game in C and I'm trying to come up with the most efficient way of spawning enemies. The game is going to be similar to SpyHunter (http://en.wikipedia.org/wiki/Spy_Hunter).
The problem is that I don't know what would be the most efficient way to have randomly appearing enemies at the top of the screen and never have more than 3 or 4 at the same time on screen.
I thought about creating 4 structures at random places at top of the screen and as soon as one reaches the bottom initialize it again at the top and so forth using random positions but I don't know if this would be the most efficient algorithm.
How should I spawn the enemies?
The algorithm you outline does seem quite efficient.
You are only allocating memory for the actual sprites you wish to have on screen. You'll need to track their position down the screen anyhow to properly render them. Once they are off screen, you are re-using existing structures. Doesn't get much better than that.
One thought would be to randomly delay some period of time after a sprite goes off screen before re-initializing it at a random position at the top of the screen again. This would lead to some variability.
Related
I've been reading through a couple posts with this same question, but most seem to have gone about the easier problem differently than I did, so I'm having trouble finding tips on how to proceed.
Without posting my code, (not sure if we can do that here or not), the pseudo code for the main resizing portion was kind of like this:
for each scanline
{
for number of times to extend vertically
{
for each pixel in infile
{
read pixel from infile
for number of times to extend horizontally
{
write pixel
}
}
done extending horizontally, add padding to outfile
move cursor to front of line
}
done extending vertically, move to next line by passing padding
}
Maybe my nested loops aren't that quick or elegant, but it was the first logic train that came to me and it worked out. Nonetheless, I'm pretty unsure of how to adapt this for floating point numbers and the fact that I need to shrink things now.
I'm aware I'll have to do some sort of rounding. If I have only one pixel and the user tells the program to resize it by .5, I'll still give them one pixel because I can't tear apart the bytes that make it up. Similarly, whenever I upscale, I'll presumably always give full pixels.
But where do I start with this logic? How do I decide what the "scale" is and how will it interact with my loops? I can't loop something 1.5 times, so I imagine I'll have to know what the rounded scale is prior to going into the loops. I can't even begin to think about shrinking something this way... I'd probably have to skip over certain pixels in the loop in order to do that? Seems like a totally different mechanism that could mess up the resulting image.
Anyways, any help is appreciated!
I'm creating a side-scroller video game for my final project in my grade 12 programming class. Right now I have nice delta-timer my partner made for me, a flying ship, asteroids, and a scrolling background. I've added a few basic things such as collision detection between asteroids and the ship, and ship movement. Now, my next steps are implementing random enemy spawns, and projectiles (laser beams :D) from both ships. Implementing random enemy spawns should fun and relatively easy, however I'm struggling with figuring out how I will create so many bullets that will fit on the screen. I need bullets from the enemy, and the ship (player controlled).
How can I achieve this? I know there are probably many answers to this question, but I would really like to see the types of approaches people have to this problem.
So far I have thought that:
a) I could make the game have a (say) 200 bullets max on the screen
b) I could make a dynamic array (I believe this term means the array gets bigger or smaller), that way I don't limit the amount of possible projectiles
...and then I'm afraid that all these bullets will cause lag from all the collision processing that will happen.
Please shed some light on this, and help guide me along the path to an efficient; well executed; side-scroller game.
Thanks,
Guest dude
I am writing an OpenGL program in C that implements alpha-transparent bill boarding particles that use a PNG (with transparency) as their texture via pnglib. However, I have discovered that a particle's transparent zones will still replace particles called before it that are also behind it. In other words, particles newly called, though transparent in some areas, are completely overlapping some particles called before them when, instead, those previously called particles should be showing through the transparency.
In order to visualize the effect this is having, I am attaching a few images to display the problem:
Initially I am calling the particles from oldest-to-newest:
However when the view is changed, the overlapping effect is apparent:
When I decide to reverse the call order I get the opposite:
I believe that a solution to this would involve calling the particles in order from farthest from the camera to nearest. However, it is pretty computationally heavy to go through each active particle, order them from furthest-to-nearest, and then call each one every display frame. I am hoping to find an easier, more efficient solution. I've already tried my hand with glBlendFunc() but no sfactor or dfactor seems to work.
Draw all non transparent geometry first. Then, before drawing the particles, disable the depth-buffer writes by calling glDepthMask (GL_FALSE)
That will fix most of the rendering problems.
Sorting the particles by distance from the camera is still a good idea. With todays CPU power that shouldn't be much of a problem.
I am new to stack overflow and new to 3D graphics programming. I have been given the task of creating an app that will read in data (currently I am reading from a delimited text file, but eventually will read from data arrays) and to graphically display the data in 3D. The data is x,y,z coordinates read from a 3D scanner which is scanning logs. I need to show the 3D representation of these logs on screen, from 4 different angles. I am reading the data into a 2-dimensional Point3D array and then using it to create 3D models in a HelixViewport3D. I use a nested for loop to check that the data points in the array are within certain x,Z bounds- and if they are I need to create a triangle out of that data. Once the entire array is passed through, I add the Model3DGroup to the children of my viewport:
topModel.Content = topGroup;
this.mainViewport.Children.Add(topModel);
It takes about 8 seconds for this to take place and zooming,panning, rotating are very very slow with all this data on the screen (around 500,000 triangles). Are there any ways to improve performance of WPF 3D graphics? I actually don't need to be able to zoom/pan/rotate in the finished app but it is helpful for debugging. The final app will simply be the same model shown statically 4 different ways, from different sides. However, I need to be able to read in the data and get the graphics to display in 1-5 seconds. Any help is greatly appreciated, and I hope my question is fairly clear!
EDIT: After doing some more digging into vertex buffering, this is what I need to do. I am using way too many points. If anyone can point me to some literature on doing vertex/index buffering in c#, it would be greatly appreciated!
I have solved this issue. Thanks for the input Capt Skyhawk! You saying that you doubted this was a WPF3D shortcoming helped me look in the right places. My problem was that the way I wrote this made every triangle it's own ModelVisual3D!! I re-wrote the code to contain only 3 GeometryModel3D (sp?) objects, and all the triangles are placed in a MeshGeometry3D and then the mesh is used to create a model. This made the models render in < 0.1 seconds. I now have a new issue- for some reason only about half of the triangles are showing up in the model in my viewports. I'm not sure why, though it may be that I have too many Point3D points or too many triangle indices in my mesh.
I doubt this is a shortcoming in WPF3D. It's more than likely the loading process. Parsing a text file with 500,000 triangles(even more points!) is where the bulk of the processing time is being spent.
If the loading of the text file is not being included in the 8 seconds, something is very wrong.
Are you using index buffers? If not, you're shooting yourself in the foot with that many vertices.
I am working on a simple soccer simulation, I am using potential fields for collision avoidance more specifically following technique,
http://www.ibm.com/developerworks/java/library/j-antigrav/
only obstacles on the field are other players and they are constantly moving. Problem is it works if I assign really big push force to the characters since characters move at speed it takes some time to change direction but this has few drawbacks with such a high gravity I can never position an npc to grab the ball cause there is always some force pushing me around.
I though I could solve this by assigning pulling force to the ball but that actually made it worse. nps would go to the ball, ball starts pulling which makes npc push the ball it goes into a loop until npc crashes to a wall.
How I've implemented this is, I have a vector that would steer me towards my target then I add to that all gravitational forces acting on the npc and steer towards that direction.
Basically I am wondering what kind of improvements I can make? my current problem is not hitting other players precisely getting behind a ball without getting affected by other players.
I'm not sure that employing potential fields is the way to go here. If all players are directly between you and the ball, how do you get to it?
I'd be tempted to plot a straight line, then iteratively adjust the route for the position of other players, adjusting for their trajectories and — if you're really clever — anticipating changes in the same.
You could put some kind of limit as to the area of effect that another player's gravity well will have. Limit it to a small radius around that player so that when you're clear of other players, there are no forces acting on your character. You could also diminish the collision avoidance force when you're near the ball, reasoning that players care less about not hitting each other when it's time to kick the ball.