Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1380372 Posts in 65813 Topics- by 58208 Members - Latest Member: leekhogan

August 08, 2020, 03:57:32 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsThe Mission - spider bot side-scroller
Pages: 1 2 3 [4] 5 6
Print
Author Topic: The Mission - spider bot side-scroller  (Read 7195 times)
QOG
Level 3
***



View Profile WWW
« Reply #60 on: October 27, 2019, 01:54:15 PM »

After fixed it for me (1).
Logged
diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #61 on: October 27, 2019, 03:53:46 PM »

I love me some physics controllers. It looks great! I had a nightmare just like that once.
Guess I'll stalk you on every social network now.
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #62 on: October 27, 2019, 11:06:48 PM »

I do feel the motion blur
Thanks for taking your time to write this feedback.
That's what I was afraid of, when I started implementing this I used low motion blur decay values and it caused motion sickness for me, but then I turned it down and it started to feel fine. It seems that you're even more sensitive than me to these kinds of things and there're probably more people that'll notice motion blur, even though it's not for an entire scene... Yeah, difficult issue, I'll probably leave motion blur, but try to make it less noticeable.

Thanks for your feedback, guys!
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #63 on: November 30, 2019, 09:04:13 AM »

So, got some news today. I finally released the demo: https://sheph.itch.io/the-mission
It's been a long way, if someone is willing to actually play it and give some feedback it would be great.
Thanks!



Logged

Shephf
Level 1
*



View Profile WWW
« Reply #64 on: December 04, 2019, 06:08:52 AM »

Here's a letsplay from AlphaBetaGamer, if anyone's interested:





And there's also an accompanying article: https://www.alphabetagamer.com/the-mission-alpha-demo/
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #65 on: December 06, 2019, 01:54:15 PM »

So, I continue working on my game. I want to try something different for the next level, something like liquids, i.e. water, slime, lava, etc.

Here's first test:





It's based on physics particles (which are done with liquidfun) + simple metaball renderer. This is just step 1, I have a crazy idea regarding liquids, if it works, well, it's gonna be freakin' awesome... But it's really mind bending to implement. I won't go into the details for now, I'll just post once I have something working.
Logged

Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #66 on: December 06, 2019, 02:14:02 PM »

Nice!! Excited to see your fancier version!
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #67 on: December 07, 2019, 02:55:48 AM »

Nice!! Excited to see your fancier version!
Thanks) Already banging my head against a wall trying to make it work Smiley
Logged

Schrompf
Level 7
**

C++ professional, game dev sparetime


View Profile WWW
« Reply #68 on: December 08, 2019, 11:27:47 PM »

Dammit. I require details! Looks nice so far.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
Shephf
Level 1
*



View Profile WWW
« Reply #69 on: December 08, 2019, 11:40:31 PM »

Dammit. I require details! Looks nice so far.
Thanks, if (ok, when Smiley) I get things done I'll write a nice post about it all, IMO this can be useful to someone, I searched the internet a lot for this topic, but I couldn't find any info on how to make huge volumes of water with realistic physics behavior not just on the surface, but like at any point.

So far I managed to make physics particles (these aren't just bodies with circle fixtures, they are modeled separately so that you can have huge numbers of them) work with buoyancy, that required to make some modification to the physics engine Box2D/LiquidFun, like the particles can now penetrate the bodies and apply buoyant forces to the bodies which float. This already works with large volumes of water:





But I want to make it work with volumes at least 10x larger
Logged

PetSkull
Level 2
**


View Profile
« Reply #70 on: December 09, 2019, 02:08:53 AM »

This is soo cool looking! Smiley
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #71 on: December 09, 2019, 02:16:46 AM »

This is soo cool looking! Smiley
Thanks Smiley
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #72 on: December 12, 2019, 10:38:07 AM »

Don't know why I decided to write a post now, m.b. because those liquid optimization problems are driving me crazy and I want to take a break.
So basically what I'm trying to do is to optimize liquid physics so that it would take much less cpu. Right now for a pretty huge amount of water (~8500 particles) it takes ~45% cpu (of physics thread, i.e. ~45% of 1 cpu core). That's just the water, there will be more stuff in the level, so that's unacceptable, besides, I want to have much more water and have a lot of interaction with it, like I want to have m.b. ~50-80K particles. There're several ways I want to go:

1) Move physics particle calculation to separate thread. That's not a simple thing, but possible, but still, this won't let me have my 50K-80K particle count
2) Optimizing physics particles themselves by freezing inactive particles which are deep within a large volume. That's in some way similar to physics's engine "sleeping" of inactive bodies, i.e. physics bodies can sleep until something comes in contact with them (or they're acted upon with a force)

So I've started with 2) First thing I did is this:





i.e. I split all particles into 3 layers: inner (blue), border (red) and outer (white)
* inner particles are completely inactive, they're deeper within a volume, they don't recalculate state, don't update position, etc. they're very cheap, they cost almost nothing
* border particles don't move, but they participate in collisions
* outer particles are the usual liquid particles that do all stuff

So the point here is that inner particles can become outer and outer can become inner only through border particles, thus, whenever white border around a volume gets thinner, border gets thinner and more particles are activated and vice versa, when more volume is added to the liquid the center of the volume "cools down", becomes inactive. This is not 100% complete still, since the "inner" part is no longer active it no longer applies buoyant forces to the bodies within the water, this has to be implemented separately (fairly simple actually, like finding hull and apply forces within it manually).
Making even this seemingly simple mechanic work took quite some effort, but it gained some nice speed up, about 2x. Well, I expected more, but still...

And then I started to profile more and noticed that most of the remaining "white" particles are eating cpu mostly on contacts with static bodies (the water container itself). So then I realized that it should be possible to extend the "blue" inner zone up to contact points, so that almost all water volume is inactive and only surface of the water is active. And whenever static bodies are removed the contacts are destroyed and contacting particles can become "red" and the old logic kicks off from here and everything will work fine like the liquid will pour out correctly even in this case. Implementing this turned out to be much harder, here's current state of this:





(Coloring is pretty much the same, but green points are particles that are in contact with static fixtures)

Like there're lots of problems here:
* It's very hard to "blend" the inner/border particles into the contact particle fast and right in general case, my current algorithm that I've came up with is based on dynamic programming, it's fast, but it still has some inaccuracies on borders, need to solve that somehow...
* Particles tend to form highly dense partitions near the borders, so when they unfreeze they apply large impulses to their neighbors causing them to "jump up"
* "holes" in the liquid, no idea how that happens for now...
* liquid can sometimes "crawl out" of the container from the sides
* other stuff...

But the thing is, all these optimizations together give a huge speedup, like now it only takes ~5% of cpu instead of ~45%. If I also move this to separate thread and m.b. increase particle size I can have a huge water world with all the liquid interactions I want in any place I want. What is needed to be done now is solving this pile of bugs, which is not that simple at all Sad But 5%, only 5% of cpu now, damn I need to make it work...
Logged

Schrompf
Level 7
**

C++ professional, game dev sparetime


View Profile WWW
« Reply #73 on: December 12, 2019, 11:18:46 PM »

I see we have vastly different opinions about CPU usage :-) Liquids will be the only element in the game occuring in large numbers by far. Even large breaking walls will end up with ~200 fragments at most. So... well... why bother about 45% of a single core? Thread it to four cores, simply accumulating forces in a local buffer, then summing and applying forces singled-threadedly, and you're done.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
Shephf
Level 1
*



View Profile WWW
« Reply #74 on: December 12, 2019, 11:27:29 PM »

So... well... why bother about 45% of a single core? Thread it to four cores, simply accumulating forces in a local buffer, then summing and applying forces singled-threadedly, and you're done.
Yeah, something like that was my optimization option #1, only I wanted to have a single dedicated thread, but you're right, it can be like #cores threads. But then it means no mobile version of the game ever, because even though modern smartphones have multiple cores it'll eat up the battery in no time.
On second thought... you gave me something to think about here, thanks! Smiley I'll probably try to make the freezing approach work for a bit more, if it won't, well, I'll just go with threaded approach
Logged

Schrompf
Level 7
**

C++ professional, game dev sparetime


View Profile WWW
« Reply #75 on: December 12, 2019, 11:31:02 PM »

Freezing would be sexy, no objection. But I fear you'll run up into all sorts of inconsistent fluid states if you don't get it ... erm... watertight. Those are a nightmare to debug or even not solvable at all.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
Shephf
Level 1
*



View Profile WWW
« Reply #76 on: December 12, 2019, 11:41:29 PM »

Freezing would be sexy, no objection. But I fear you'll run up into all sorts of inconsistent fluid states if you don't get it ... erm... watertight. Those are a nightmare to debug or even not solvable at all.
Yeah, I fear the same, it may be very hard to do or even unsolvable. Though I came across this paper yesterday - https://www.hindawi.com/journals/ijcgt/2014/806095/
They seem to use an approach similar to mine and state that it works and gives a 3x speedup without loosing visual fidelity. But the question is - if that algorithm is so fancy and working fine then why isn't it widely used by everyone...

btw, I forgot one more thing, the second reason why I do this freezing thing is to increase particle stability, the thing is particles are unstable inside complex shapes. If you want to have like some twisted pipe with a liquid then particles will try to pass impulses all the way through the pipe causing jitter. This doesn't happen when using freezing approach because impulses don't propagate too far in the liquid. But kinda think about it, this can be solved even without freezing by introducing some depth factor, so that deeper particles will react less on passed impulses, so m.b. it's not a big deal. Now I'm really thinking about dropping all this freezing stuff Smiley
Logged

bitbulldotcom
Level 2
**


#indiedev since the #zxspectrum days


View Profile WWW
« Reply #77 on: December 13, 2019, 12:43:46 AM »

This looks very cool indeed - great atmosphere and much respect for how you've dealt with the physics side of things. That stuff melts my brain!
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #78 on: December 13, 2019, 02:11:48 PM »

This looks very cool indeed - great atmosphere and much respect for how you've dealt with the physics side of things. That stuff melts my brain!
Thank you Wink
Logged

Shephf
Level 1
*



View Profile WWW
« Reply #79 on: December 14, 2019, 11:20:10 AM »

Ok, so after more analyzing and thinking I've changed the algorithm, it's now more complex and heavier, but IMO it somehow works. Here's stress test with 90.000 particles, cpu load on start is 35%, 70% on "flush" and 35% afterwards (without any optimizations even 8K particles utilize 60% of cpu and having 90K without any optimizations isn't possible at all, the system is unstable all the time due to insane amount of impulses going around, it never balances)





This isn't 100% perfect, e.g. closer to the end of the "flush" water behaves a bit like grain, because lower layers are frozen they cannot pass impulses around, thus, upper layers need to "roll down" themselves in order to form straight water line. But IMO this won't be noticeable on small scale, at least I hope so Smiley

There're also some other tiny details that I want to fix like those white "polyps" in the water where they shouldn't be. Sometimes contacting particles can have holes, thus, algorithm thinks it's an open water surface and "wakes up" some particles around. This wouldn't be a big deal if they were somewhere in the center, but since it's right on the water tank it queries geometry, solves collisions, etc. i.e. eats up cpu, this can be considerable if there will be a lot of those "polyps" around.

Other stuff left to do is support dynamic particle addition/removal with my freezing algorithm, optimize renderer, support buoyancy it frozen area... Damn, so much stuff left to do, I just want to continue making the game already Smiley
Logged

Pages: 1 2 3 [4] 5 6
Print
Jump to:  

Theme orange-lt created by panic