You say “back in the day”… how do people usually achieve what I want these days? I thought of just having a function that is called every frame that randomly places a few drops of various sizes within the area of the cloud, grouping them, and apply gravity and a collisions event listener. Is there a drawback to doing it that way that I am not appreciating? I just read about emitters and felt I should use them!
This is my static water…
I would love to make it a bit more dynamic
(ignore the dodgy rain… playing with emitters)
Well, for what you want, emitters actually don’t seem like the proper solution. Emitters are ideal for beautiful visual effects like fires, flames, weather, etc. If you check out the sample I mentioned, you’ll see what I mean.
In your case, I would suggest using the LiquidFun approach which is physics-based. This lets you create physical particles which blend and meld together like water and other viscous substances… but they are not to be confused with “particles” from emitters (they are two very unique approaches).
There are demos of this too, if you’re interested in learning more.
Brent
Yeah I know… btw got a decent rain emitter working now. Thanks!
Adrian,
Do you have a distinct “water layer”? Or is it all just isometric parts laid out in a single z-axis-ordered layer?
Yes, everything is on separate layers and these are grouped into a master layer for pinch/zoom/pan.
masterDisplayGroup:insert(undergroundDisplayGroup) masterDisplayGroup:insert(waterDisplayGroup) masterDisplayGroup:insert(landDisplayGroup) masterDisplayGroup:insert(boatDisplayGroup) masterDisplayGroup:insert(pathDisplayGroup) masterDisplayGroup:insert(roadDisplayGroup) masterDisplayGroup:insert(carDisplayGroup) masterDisplayGroup:insert(trackDisplayGroup) masterDisplayGroup:insert(trainDisplayGroup) masterDisplayGroup:insert(eyetoolDisplayGroup) masterDisplayGroup:insert(graphDisplayGroup) masterDisplayGroup:insert(buildingDisplayGroup) masterDisplayGroup:insert(planeDisplayGroup) masterDisplayGroup:insert(overlayDisplayGroup)
If it helps Perry has my source at the moment.
Maybe email is easier - adrian@spheregamestudios.com
Ah, just what I hoped to hear (“waterDisplayGroup”). While you can’t make a particle emitter “isometric” by its own nature, you could make it emit particles like blurred circles/squares or wavy textures which are made isometric in Photoshop or whatever. And then you could emit them across a large rectangular area in the water display group, and have each particle undergo a subtle motion or up-and-down scaling to provide at least some level of “waves in ocean”.
I’d have to tinker around with the concept using Particle Designer to see how far I can get, or how realistic it might look, but it’s certainly worth a shot.
I did have this working and it did give a watery effect but it was a massive performance hit on all but s7 level devices so I removed it
function addWater() waterDisplayGroup:scale(1,0.5) waterDisplayGroup.y = \_tileH/2 -- Create container for visual objects, width is sine 45 deg = 0.704 local containerWidth = \_tileW \* (\_maxTilesX - 1) \* 0.704 local waterWidth = containerWidth + 100 local water1 = display.newRect( 0, 0, waterWidth, waterWidth ) waterDisplayGroup:insert( water1 ) water1.rotation = 45 local water2 = display.newRect( 0, 0, waterWidth, waterWidth ) waterDisplayGroup:insert( water2 ) water2.rotation = 45 -- Set defaults for repeated textures which follow display.setDefault( "textureWrapX", "repeat" ) display.setDefault( "textureWrapY", "mirroredRepeat" ) -- Apply repeating textures and filters to objects water2.fill = { type="image", filename="images/water-fill.png" } water2.fill.scaleX = 0.01 water2.fill.scaleY = water2.fill.scaleX water2.fill.rotation = 15 water2.alpha = 0.4 if \_dayOrNight ~= "day/" then water2:setFillColor(0.3,0.3,0.3,1) end water1.fill = { type="image", filename="images/water-fill.png" } water1.fill.scaleX = 0.01 water1.fill.scaleY = water1.fill.scaleX water1.fill.rotation = -10 water1.alpha = 0.9 if \_dayOrNight ~= "day/" then water1:setFillColor(0.3,0.3,0.3,1) end water1.fill.effect = "filter.wobble" water1.fill.effect.amplitude = water1.fill.scaleX \* 2 water2.fill.effect = "filter.wobble" water2.fill.effect.amplitude = water2.fill.scaleX \* 2 -- Set defaults for repeated textures which follow display.setDefault( "textureWrapX", "clampToEdge" ) display.setDefault( "textureWrapY", "clampToEdge" ) -- Begin repeating transition function local function repeatTrans() transition.to( water1.fill, { time=4000, x=water1.fill.x+0.5, onComplete=repeatTrans }) transition.to( water2.fill, { time=4000, x=water1.fill.x+0.5 }) if ( water1.alpha == 0.9 ) then transition.to( water1, { time=3000, alpha=1, transition=easing.inOutQuad } ) transition.to( water2, { time=3600, alpha=0.6, transition=easing.inOutQuad } ) else transition.to( water1, { time=3000, alpha=0.8, transition=easing.inOutQuad } ) transition.to( water2, { time=3600, alpha=0.4, transition=easing.inOutQuad } ) end end repeatTrans() endDo bear in mind my display group is 9,360x4,680px so I hit lots of limitations on rendering speed - what Perry and Vlad are currently looking into.
Oh yes, the “wobble” filter is cool… but it can be a beast of performance, and at the size you mention, I’m not surprised.
Have you ever checked out the “PatternFill” sample in the SampleCode > Graphics folder? That’s a demo I created awhile back which IIRC uses just 2 semi-opaque water textures, animating atop each other. Perhaps you could do something like that, just adjusted to be isometric by using quadrilateral distortion of the x1,y1-x4,y4 points.
Brent
Hmmm… scratch that… the demo uses the wobble filter, lol. But maybe you could just transition the elements around without the wobble and still get a nice effect.
I just checked that and it is spookily very similar to my posted code (I think it was from a post somewhere). But unfortunatly that uses wobble too!
When you apply _displayGroup:scale(1,0.5)_on the size I use it dies a death on devices. The hit was well over 10 fps.
I’m really hoping you can work some magic with particle emitters as standard Corona code just doesn’t scale on the size I need.
Hope you like a challenge! 
I think animating the water tiles themselves (IE cycling through a set of images) is your best bet.
It depends entirely on how you have your map and images set up though.
For example, is your water layer using individual images per tile, or frames from an imagesheet per tile?
That would let you know whether you had to do it manually or could use an animated sprite.
Also, whether you cull the tiles offscreen manually or not could determine what approach might be fastest.
In fact, if water is your base layer, it wouldn’t even need tiles, it could just be a single image that has a texture repeating over it of the same size as the tile, which means you could either:
-
Cycle through a series of fullscreen images or
-
Set up a rect that is fullscreen and fill it with the tiled image, and then cycle that image and change the fill offset to animate.
Much depends on how you are actually drawing the screen though, so I’d need more info to be able to help.
Hi rakoonic,each water tile is individual (and is a frame on an imagesheet with all the other ground textures. Off screen tiles are culled manually in code.
I did try having the water as a single 960 x 1600 image (and also tried animating it with wobble filters) it but it looked weird when the ground moved but the water didn’t. Also it didn’t scale well when the game is pinch zoomed. So I settled on individual static tiles.