Jump to content

  • Log In with Google      Sign In   
  • Create Account


How to handle offscreen processes like fire?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 K1rl   Members   -  Reputation: 112

Like
1Likes
Like

Posted 14 November 2012 - 06:40 AM

Hello, I'm working on a game with destructible and rebuildable environment, which is working great. Fires slowely spread and burn up any material it touches. Now I would like to make the (top-down 2d) map scrollable, but I'm unsure of what to do with things like fire. I can't keep this running these offscreen processes while maintaining performance, but it would be weird if it stops or dissappears after moving offscreen.

Any ideas on how to handle this?


I don't keep track of the fires in an array or something, every fire is it's own little isolated process and checks after a delay wether it is touching material (non transparant pixel) and starts new fires at those locations.



PS: I've been a member of this community for nearly a decade now (Kirl), but I had to re-register because I forgot my password and don't have acces to the mail acount I used at the time I registered.

Edited by K1rl, 14 November 2012 - 06:42 AM.


Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 6881

Like
0Likes
Like

Posted 14 November 2012 - 07:31 AM

starts new fires at those locations.

I fear that you need at least some kind of offscreen simulation. Best to break down your simulation effect in level of details and reduce the LOD (=faster) of parts which are not near the visible screen.

#3 Waterlimon   Crossbones+   -  Reputation: 2417

Like
0Likes
Like

Posted 14 November 2012 - 07:47 AM

"Pixel" sounds scary for checking if fire should spread. I think you should try to simplify it by treating objects as a bunch of boxes or spheres, as fire is kind of chaotic after all so it doesnt need to be perfectly accurate.

The longer a fire is offscreen, the more you can lower the accuracy/take bigger simulation steps for your fire. (if the user looks away for a second, you dont want to throw all the simulation state away and say "BIG FIRE HERE, OK?" and when he returns its completely different...)

Assuming you even need a LoD after making the fire itself fast.

EDIT: crazy optimization idea from the evil volcano of premature optimization! :D
have time slow down farther from the player, but so that if he walks there, the objects will simulate faster until theyre up to date again before being seen. This will make the computer process a more concentrated chunk of fires at once, instead of all of them. Because its kind of smooth simulation falloff, it wont hopefully cause bad errors because of fire not being able to spread farther because not being simulated there.
This will improve cache coherency by a ridiculously small amount. yay.

Edited by Waterlimon, 14 November 2012 - 07:51 AM.

o3o


#4 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 14 November 2012 - 09:40 AM

Hello, I'm working on a game with destructible and rebuildable environment, which is working great. Fires slowely spread and burn up any material it touches. Now I would like to make the (top-down 2d) map scrollable, but I'm unsure of what to do with things like fire. I can't keep this running these offscreen processes while maintaining performance, but it would be weird if it stops or dissappears after moving offscreen.

Any ideas on how to handle this?
I don't keep track of the fires in an array or something, every fire is it's own little isolated process and checks after a delay wether it is touching material (non transparant pixel) and starts new fires at those locations.

The first idea would be to assemble more information and make some rough estimates of what problem we are actually dealing with here.

What is the structure of your world (continuous, tile-based, ...)?
How large is the world?
How much burning stuff does it contain?
How large is one "unit of fire" (if applicable)?
Do burning things stop burning? If so, how fast, and can they burn again or are they scorched?

I suppose the fires are objects using some kind of timer callback instead of being actual operating system processes?
And it sounds as if a fire always starts a new fire if something flammable is adjacent to it during a game logic tick. No randomness. Correct?

#5 K1rl   Members   -  Reputation: 112

Like
1Likes
Like

Posted 14 November 2012 - 11:27 AM

Thanks for the thoughts all, I have included a link to an earlier prototype because a picture says more then a thousand words (not to mention 30.000 words a second). Posted Image

You can see it in action here: http://kirl.nl/pixelfunk.html (click screen to set focus)
Controlls:
Arrow keys = move and turn
Ctrl / LMB = shoot
Space = change weapon (gun, fire, water, matter)
Hold Shift = drill mode for when you get stuck
Alt = generate new random walls


What is the structure of your world (continuous, tile-based, ...)?
The world is continuous, I tried adding an underlying grid in an attempt to optimise some stuff, however this hasn't been very succesfull yet...

How large is the world?
I'm not sure yet how big the world will be, for now the map doesn't scroll so it's as big as the screen (400x550);

How much burning stuff does it contain?
Depends, in theory the entire screen can be ablaze.

How large is one "unit of fire" (if applicable)?
One fire unit is a sphere of about 20x20 pixels.

Do burning things stop burning? If so, how fast, and can they burn again or are they scorched?
One fire unit continues until a delay (~1-2 seconds), then it removes the underlying material, checks for neighbouring pixels (starts new fires if there are) and removes itself. So the burning material is basically being chipped away by little sphere shaped bites.

Edited by K1rl, 14 November 2012 - 11:41 AM.


#6 kseh   Crossbones+   -  Reputation: 1954

Like
0Likes
Like

Posted 14 November 2012 - 01:05 PM

Cool demo.

I think it's going to depend a lot on how you decide to approach working with a larger area and what the project is to become. If you're thinking you want to unload the portion of the level from memory while the player is off somewhere else, the only thought I have might be to do up some sort of floodfill algorithm that behaves similar to the way the fire behaves. When you return to the area and need to load it up again, run the floodfill from where the fires currently are, spreading outwards a distance appropriate for the time the player has been away.

Also, just a thought if you want to limit how much fire can destroy, you may want to consider having it affected by a constant wind direction and generally have it favor traveling upwards if there's material to burn that way.

#7 Álvaro   Crossbones+   -  Reputation: 12365

Like
2Likes
Like

Posted 14 November 2012 - 01:21 PM

The title of this thread made me think of some software engineer in a Dilbert cartoon, who has lost the ability to do anything in the real world and posts here in response to a fire in the building. :)

#8 K1rl   Members   -  Reputation: 112

Like
0Likes
Like

Posted 14 November 2012 - 02:26 PM

lol @ Álvaro, I love Dilbert! Posted Image

Thanks for your thoughts kseh! I had been thinking along those lines, but because the fires spread erratically I can't predict a large area to fill at once. So I'd just have to run the fire function with 0 spread delay a nr of times, if this is fast enough. I fear for larger areas and another tricky problem I foresee is offscreen fires not burning back into view if the material is there. Posted Image

#9 AMenard   Members   -  Reputation: 175

Like
2Likes
Like

Posted 14 November 2012 - 02:35 PM

How about keeping your fire alive when offscreen minus the graphics...
By this I mean, you stop aimating them graphically when they are off screen and you implement a routine that calculate the progression of the fire on affected object keeping, say a ratio, of their burned factor over time.
Then when your player scroll back to that portion of the map you use this ratio to draw the affected object. Your computer can crunch number easilly in the background.
My blogs:

http://www.osrebel.com <-- En Français
L'information libre et la joie d'apprendre

http://www.osrebel.com/english <-- English Version
Free information and the joy of learning

#10 ankhd   Members   -  Reputation: 1178

Like
-1Likes
Like

Posted 15 November 2012 - 01:26 AM

Hello. you could try to set all particles up so all you need is to pass the current time and it can calculate the current position based on the time.
I think you need to keep a copy of the direction at origin and a initial position of the particle(fire) .

float t;
float3 Vel = initialDirW * Speed;

float3 position = (0.5f*t*t * Vel + (t*initialDirW)+ initialPosW);


final note. after writiing this I think It may not work, but ill post it anyway.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS