Uh oh... I think I did something awesome... Is that full movement projectiles I smell? This gif also manages to show off one of the basic mechanics of the game-to-be, which is directional speed. Basically, depending on where you're facing while you're moving, the faster or slower you move. You move full speed when running toward your mouse and slowest when backing away. Up to 50% slower to be exact.

Just a nice little mechanic that I think'll really work well with the project.
In response to Kats
Needs more explosions and shit.
In response to Godtetsu
Godtetsu wrote:
Needs more explosions and shit.

Oh course it needs explosions. But I'm saving the fluff department for later. You know, make it work, THEN make it have explosions.
In response to Ter13
Ter13 wrote:
Stress

Tests

Are

Super

Fun

Right?


Yes... yes they are... Obviously 500 full collision projectiles can overload the system hardcore. What LICEcap didn't get was the massive FPS drop when the CPU spiked, but trust me, it's there.


You know, when I do stuff like this, it kind of looks like a Touhou ga-... uh oh...



Okay, now I'm just goofing off.
That CPU usage. Oh dear lord.
In response to Zecronious
Zecronious wrote:
That CPU usage. Oh dear lord.

That's what I'm screaming...

Also, I'm having trouble with the mouse parameter "right", which doesn't seem to be working. "left" and "middle" work just fine, but "right" does nothing. Is the parameter simply named something different under the mouse controls?
In response to Kats
You need to disable client.show_popup_menus to enable right click detection.
In response to Kaiochao
Hmm... well, thank you. That would seem to be a problem, I guess. Lol.
Our projectile code peaks out at about 96% CPU usage at 40fps with ~5000 projectiles active in the world and about 1000 in the same place on the map. Looks like your code is decent so long as you tune your gameplay to prevent too much projectile stack.
In response to Ter13
Ter13 wrote:
Our projectile code peaks out at about 96% CPU usage at 40fps with ~5000 projectiles active in the world and about 1000 in the same place on the map. Looks like your code is decent so long as you tune your gameplay to prevent too much projectile stack.

I run mine at 60 FPS, but mine can only handle a tenth of the projectiles before chugging like an alcoholic German. Right now my projectiles are all mobs moving every tick. Are there ways to make it more efficient without effecting frame rate or projectile collisions?
Remember to make sure that the projectiles are getting culled once they're out of screen range of the player. If they're getting removed when they hit a wall or something then it might be an issue of just having too many on the map at one time.

Increasing the speed of the projectiles can also help CPU performance as you'll end up with a smaller upper limit on how many are in existence at any given time.

With 60 FPS the projectiles seem to be going a bit too slow for the CPU's liking.

In response to Bravo1
If I remember correctly Kats is using a fractional system and moving things at less than 1 pixel amounts. Could cause a lot of excess usage. Most of the time things look fluid with a few pixels jumped at a time and a good FPS imo.
Agreed, When it comes to projectiles en mass, the faster the better, just make sure they're not moving faster than the smallest targets bounding box (lets say 40 speed trying to hit a 30 object) otherwise you'll have cases where the projectile completely misses the point of collision.
In response to Bravo1
Given the mechanics of the game, this is about as fast as I can make them and most of the time they'll be much slower. But I also know that for the most part, players won't be firing a billion of them at a time. I just ran a profiler on my code and by far it's the built-in Move() proc that's taking up the most CPU. Even calculating next correct position for the move takes up maybe 1/10th of its CPU usage.

Also, the fastest projectiles move at about 5 pixels per step at 60 FPS, which means that I shouldn't have to be doing any extra work to calculate the vectors between very fast shots for collision.

Is there a manual way to check for collision using the engine's collision detection, say with the Crossed() procs? Or am I stuck using Move() if I want to make sure everything's accurate?
In response to Kats
Ah, I was under the impression it was going for a form of bullet hell game, but if that's the case then this is more than reasonable numbers, especially if accuracy is key.

Using Move() is your best bet if you'd like things to be accurate for the sake of having each individual projectile be a separate mob, carrying it's own various procedures and variables.

The other option is to make them entirely visual, which cuts down a lot on the creation and deletion of each projectile as there's less to deal with. You'd likely use the bounds() proc to enter in the position of the projectile and return a list of mobs that are in that spot, then have your hit/damage/etc. happen with that.

That requires a bit more coding and ends up with overall less features than using mobs, but it's much much less overhead on the CPU.

You can also, for faster moving projectiles (if you want to speed them up) use bounds to check the spot directly between the projectiles current position and it's next position after it moves, and work out collision from there, perhaps with a short delay to make it seem more accurate as it flies along it's trajectory.

Ultimately when it comes to programming projectiles there's a LOT of options to go with.
In response to Bravo1
Lol, no, it's not a bullet hell game, although the more I play around with it, the more I'm kinda thinking that should be my next little side-project.

These projectiles don't currently have a density to them because I was planning on using circular collision for everything. It's going to be an intense PvP game and I figured that players with square hit-boxes would provide too much unbalancing when it comes to firing from certain angles. Obviously shooting at someone diagonally gives you a much bigger surface area to hit than from a straight angle, which I did not want.

The question I have then is if I'll be manually doing the collision detection myself, is there a way to shut off the built-in collision detection? Or bypass it altogether? I know that all atoms are checked for collision, so would I have to rely on a datum for the variables and an image for the actual bullet itself? Could that even work efficiently?


Bouncing bullets!

Okay, now I admit, I'm just wasting time with this projectile stuff... Lol. I have so many better things to be working on but this manages to keep my interest away from more productive things.
In response to Kats
Kats wrote:

I know that all atoms are checked for collision, so would I have to rely on a datum for the variables and an image for the actual bullet itself? Could that even work efficiently?


It sure can! It's basically how complex projectiles were done back before pixel movement was introduced.

What was originally done was a datum, with it's own procedures and variables, was created to represent the projectile and an image/object/mob/etc was created just to visually represent it on the map.

It's position changed on the map not as an actual object but just as a set of variables describing it's position and where it should be, and the display object would be updated to match where it's supposed to be. You essentially just keep track of the position of the projectile and give it a visual representation, then have it check as it updates.



Now that we have pixel movement built-in, we don't need to do that, but at the same time, making dozens of mobs isn't very efficient, it's just way easier.


For circular detection, here's what I would do: As the projectiles travel, have them check their position with bounds() to detect a square area in which a mob might exist within.

Then what you'll want to do is get the center of the mobs in the list and compare them to the position of the center of the projectile, this can be done by dividing the height and width of the objects in question and adding it to their pixel position.

Then, you'll get the true distance between the centers of both objects, via the pythagorean theorem (a*a + b*b) = c*c.

Once you've got that distance, you can then determine whether or not the two circles overlap by comparing the distance to the radius of the projectile plus the radius of the mob that's being tested.

If the distance is larger than or equal to that value, it misses (as there's a gap between,or it just manages to scrape by), if it's smaller, it hits.

Now, I'm not the best (or even remotely good) at describing things, but hopefully it helps.

If you'd like to talk more in depth about it I'd be happy to oblige.
Page: 1 2 3 4