next »

[eigenbom]

Wow! I think that looks really good.

Of course, you don't need to make the lighting system recalculate every frame. Just on level load and with light source changes.
Still, I guess it'd be a pretty big issue if you were able to carry a torch around or something in-game, so hmm!

Anyway, I myself feel encouraged to try a lighting algorithm. 

thanks! and yeh that's true about recalculating only when something that is light-affecting changes. You could also speed it up by using a quad-tree or something and only update the nearby zones. In fact, this is probably what I'll do.

As for the torches, you could just do a separate light calculation for each torch and blend it with the sun-light layer, this wouldn't be too slow if the torches had a small light radius. (But then the algorithm depends linearly on the number of torches, yikes!)

One other option (because I need more!) would be to raytrace and bunch of rays from each grid cell -- this could be done in parallel (and on gpu).

And yes, you should code up some lighting algorithms!

[BlueSweatshirt]

Making one now. So far, 4 nested loops and it's buggy. But it's damn beautiful.(and surprisingly lag-free  )

Works pretty well. The first screenshot will refresh at 60fps without lag, but the second one sees about a 20% frame drop. Sadly the nature of the algorithm makes the lag increase exponentially for the size of your lights and how many lights are present. I need to optimize my routines and reduce all these trig calls!
Also sorry for semi-thread-hijack.

Code:

		public function refreshLighting():void {
			var amount:int = (walls.width/16) * (walls.height/16);
			while (amount >= 0) {
				lightMap[amount] = 0;
				amount --;
			}
			var LIGHT_CONST:int = 5; // environmental const for light fading I suppose
			for each(var light:Light in lights) {
				var lightDist:int = light.intensity / LIGHT_CONST;
				var dirtyRect:Rectangle = new Rectangle(light.x - lightDist, light.y - lightDist, lightDist * 2, lightDist * 2);
				for(var i:int = dirtyRect.x; i < dirtyRect.right; i++) {
					for(var j:int = dirtyRect.y; j < dirtyRect.bottom; j++) {
						var intensity:Number = FP.distance(i, j, light.x, light.y) / (lightDist); // percent distance from center, will create circle effect
						var attenuation:Number = 1;
						if (walls.getTile(i, j)) attenuation = 0.8;
						var tracePt:Point = new Point(i, j);
						var traceAngle:Number = FP.angle(i, j, light.x, light.y);
						var traceXC:Number = Math.cos(traceAngle * Math.PI / 180);
						var traceYC:Number = -Math.sin(traceAngle * Math.PI / 180);
						while(Math.abs(tracePt.x - light.x) > 1 || Math.abs(tracePt.y - light.y) > 1) {
							tracePt.x += traceXC;
							if (walls.getTile(int(tracePt.x), int(tracePt.y))) {
								attenuation = 0.4;
								break;
							}
							tracePt.y += traceYC;
							if (walls.getTile(int(tracePt.x), int(tracePt.y))) {
								attenuation = 0.4;
								break;
							}
						}
						setOnLightMap(i, j, (Math.max(1 - intensity, 0) * light.intensity) * attenuation);
					}
				}
			}
		}

I should note that I achieved the effect in the first screenshot with a light const of 10, and the second with a light const of 5.

Particularly what kills things is that second while loop, which traces back to the center of light and blacks out the surrounding area if there is a block present. It's an extremely inefficient way to do it, but at the moment I haven't figured out a way to fix that without losing my circular light pattern, which I like.

[eigenbom]

@Jakman Yeh I <3 simple solutions to problems that are fast enough. Your method looks good, you might be able to speed it up by a constant using Bresenham to trace your lines, but it wouldn't be much. (And it would complicate it heaps. )

Update: I'll hopefully be doing a post a day for the 30day world building comp. So subscribe to my blog if you're interested. And I may cross-post here. Anyways, my first post is here, in which I'm trying to set up a base lore for the world in which Moonman takes place.

[eigenbom]

Update: more experiments with light. this time: raytracing! good results, but slow.

[Happy Shabby Games]

Great stuff: "For the inhabitants of Oed’s only moon, Lunem, it was heaven, luminescence, and the logical conclusion to an illogical life.". The lighting is looking nice too. Best of luck 

[eigenbom]

Cheers dude, thanx for the encouragement, it means a lot!

Update: Did the first iteration of integrating the lighting system into moonman. At the moment its just the simple boundary expanding algo I posted above. The dithering is awesome but merely a post resizing artefact.

Here's a screenshot, and a video.

[Evilized]

Moonman looks epic already, the simple graphics make this game look awesome. giving me some sort of retro feel.

[Franklin's Ghost]

The new video is looking great, loving the lighting and seeing how you are approaching it. Looks like it's working really well so far.

[eigenbom]

Cheers guys! Glad you enjoy the devlog.

[J. R. Hill]

Looking good in action!

[namragog]

I'm REALLY liking the dithering. Keep that style! 

[eigenbom]

I'm REALLY liking the dithering. Keep that style! 

I like it too, but it was done by GIMP during the indexing for gif compression. I was researching a little about it, and it turns out that Floyd-Steinberg dithering is tricky to do on the GPU. I might do some tests to see if I can, in real-time, copy the framebuffer to ram, apply the dither on CPU, then recomposite. I doubt it'll be quick enough though. And besides, I'm trying to simplify the graphics, not add on more and more... :D

[eigenbom]

Update: Finally got round to pulling the last months changes in SFML2 into moonman, unfortunately this broke a few things, so I spent a few hours fixing it, and it's still not quite back to normal. The consequences of using libraries in beta I suppose!

I originally planned on using SFGUI to do the gui stuff, the demos are quite good, but after looking at the documentation, I realised it was far too complicated for my purposes, and I didn't want to be wrestling with more in-development and volatile dependencies. So I bit the bullet and started to roll my own simple gui system, in which I'll implement exactly what I need and no more, and use dependencies already in moonman, like boost::signal to connect widget events. Anyways, here's an awesome screenshot of the menu widget, with click events being caught and sent to the logger. Amazing stuff! :S

[BlueSweatshirt]

A start is a start is a start. 

If you need any ideas I can toss you the source code of the minimalistic gui lib I made for use with Flashpunk.

[eigenbom]

A start is a start is a start. 

If you need any ideas I can toss you the source code of the minimalistic gui lib I made for use with Flashpunk.

Hey sure, thx! I'm definitely interested to have a gander at your design ...

[eigenbom]

Update: Worked more on the GUI system today, and now have a working title menu. You can navigate the menus with the mouse (and esc), and the title screen emits signals, like "exit" and "displaySettingsChanged" when these things occur. So now you can change the resolution/fullscreeniness at run-time through the menu. The game background is rendered behind the menus too.

I've also started a prototype of the hotbar, where you will drag the ten most useful items which map to the number keys on top of the keyboard.

[eigenbom]

Update: I rested from code today and did a couple of GUI mockups. I'd be interested to hear which one you guys like better, if either, and any comments/crits ... Some points to consider:
- Gui overlaid on scene (2nd image) or separate (1st image)?
- Have depth+shine to UI elements (2nd) or flat (1st)?
- In 1st, use full black or transparency?

I guess I'm leaning towards the first one, because it's visually simpler.

[rek]

It's hard to compare when the second one doesn't have the black text bar behind it, but I like the second one better.

[eigenbom]

@rek here u go..

[BlueSweatshirt]

I think I liked the first one better. Despite technically being bigger, I guess, it feels cleaner and I think is easier to read.