Sounds cool, CharmyBee. Wish I could help you out. Always a reason to learn HLSL, or whatever it is Construct uses. Can you post a screen of what this effect looks like? I'm curious.

Here's a possible solution: have a screen-resolution sprite overlay with your TV effects on it, like the coloured pixels and maybe even a shadow around the edges - the image probably doesn't even have to be screen resolution, as it probably won't hurt to scale this up a deal - and apply a couple effects to it, like dodge, soften or whatever. That probably won't do it completely, but maybe with a few other sprites of the same size with various effects, maybe even a bowed distortion... basically a fullscreen HUD overlay to make the image beneath look like it's behind the screen of an old TV. Maybe? Would require a bit of artistry, but that's all I can think of at the moment.

Heh, you could even animate a tiny bug landing on it and crawling around. Subtle stuff is cool.

Nice.

I wish I could remember. Likely a search on sourceforge for game creation tools.

The glitch isn't going to show up in that .cap because force own texture is enabled on the layer; the far right column is just a way to see what the normal maps are doing, and it (intentionally) will show the transparency bug even with that setting enabled. Also, with the first (yellow-tinted) normal map, the black definitely seemed promising at first, but essentially you just turned it off. Turning up the intensity makes it come back.

I'm basically using two normal maps here, the second one the inverse direction of the first one, so that I can control shadow/ambient color as well as the color of the "light". I thought it would be cool for a scaling daytime effect, even in the case of when I was dropping the effect to canvases. (In that case, I would simply set up the atmosphere and daylight before loading.)

Weird that canvases don't work with these things at any resolution other than full screen then; that is the only way I could get them to paste the normal map effects without offsetting them inexplicably. Even if it's just a little bit off proportion of the screen, it messes up.

I can see this working for a smaller-level'd game then, that's at a low resolution and only one screen per room... as it is I'm not set on making a game that uses many canvases or uses lots of realtime bumpmapping, these are however bug-like behaviours I have encountered, though like many others who do receive response in this section I am simply not sure if they are, in fact, fixable bugs, or not. There are always ways to work around them!

Thanks for looking at this with me; I think perhaps the main problem here is that Construct's use of normal maps is intended to be minimal, and I'm trying to make a graphically intensive game with it; it's a shame this doesn't really work as expected, but you know, I can just as easily create a game with raster graphics, all baked lighting, and if it means more people will be able to play it (seems common for people here to have outdated hardware?) then I guess that's fine.

Yeah, they seem almost unpredictable. I messed with my layout width some more and wound up with nothing again. Or it would bake to the second canvas but zoomed out to 100% whereas the rest of the layer was at 10%... that and it just takes forever to render out more than three canvases (and it doesn't even work in the end).

The confusion this causes is discouraging, so I guess it's time to take a break. And either completely redesign what I had in mind for level size or just scrap this method entirely.

Or, you know, just not use normal maps. There's got to be a more efficient way to generate this sort of static imagery at runtime though, will just have to figure it out I guess.

Sucks that your computer can't run it, that's pretty weird. I got a 3x2 level working, which I think is more than enough to create a small prototype/demo game in. If I want to do a larger project, I'll just stick to a flat graphical style; it's probably my own fault for trying to make Construct do things it wasn't meant to do. No hard feelings, in the end.

I hope I'm not being rude to anyone here. The lack of response is sort of troubling. Thanks again for all your suggestions lucid. Maybe you're familiar with this new problem now? Sorry to be so full of questions... but since Construct is still mostly undocumented and in beta, I don't see the harm in putting problems out there. Maybe I'm not getting much of a response because this is in Uploads rather then Tech Support...

I've decided, for the sake of greater visuals and better performance, to bake all the dynamic lighting to canvas at the start of every level. Everything was going beautifully, until I found that canvas objects cannot be anything other than the screen resolution when dropping these sort of effects to them. (If this isn't a known fact, just try resizing one of the canvas objects in this cap and running it.) This was fine, I just resized the level and did an array past of canvases. Easy.

However, it's only baking to the first two... I wonder why?

Edit: This is interesting - if I set the layer's zoom (before running/compiling) so that it will all fit on the screen, it catches everything. If any bit of the third canvas object is off screen at startup, it ditches the whole thing. I guess I could start zoomed way out and just set it to zoom back in at the end of baking... but I have no idea how to check if it's done. Setting it to zoom back in at the press of a button when I can see that it's loaded completely works.

Edit2: Got it. With Layer 2 set to 1% zoom in the editor, set it back to 100 with an Else + Trigger once beneath the "for each" event... apparently posting a question gives me a boost to figure it out on my own real quick. /eyeroll

Thanks lucid, and nice example, but it's actually not at all what I meant.

Still no answer on whether or not this is something that can be fixed, the transparency not staying transparent at a certain combination of values, I will instead ask, is it possible to create a game with collision detection and interaction between objects, basically a normal game, with every sprite (or group of non-overlapping sprites) on its own layer? Seems like the only way to have a fully normal mapped game at this point.

If it's nothing to the engine so long as layer orders are correct, I guess that's fine, even if it means creating a new layer for each character, every branch of a tree.

Hey, this is pretty cool. I like it.

Doing some other tests, I find it can be used to create a cool sort of 'wash' effect over isolated objects - since the light is a point light after all, not directional...

I think that's where I misunderstood.

It still does it even with just the 'bumpmapping' effect.

I created the normal map the same way any other normal map for a 3D model is created: baked from a highpoly model to a low, in this case just a plane. Thanks, I am interested in seeing how normal maps can be used in a 2D game... if only transparency were fully functional, you know?

And thanks again! Mask object, that's what I was looking for. It wasn't opacity, wasn't alpha testing... masking, duh.

Uh... how's the mask effect work? It must be something completely counterintuitive; I think I've tried every combination of white, black, transparency and 'activate mask'.

edit: Nevermind, got it. Didn't even need a mask effect object, just had to enable 'force own texture' on the layer. Success!

Not sure what's causing this, but normal maps lit at certain angles don't seem to like having transparent pixels. If you move the mouse to the corners (or beyond) in the example .cap, you'll see it pretty strongly. It seems to happen closer to the source at lower Z angles, so I could circumvent it by increasing the Z height depending on XY distance, which would actually be a nice 3D effect... but I'm still curious if this is a bug, something I've done wrong, or just inherent.

<img src="http://img.photobucket.com/albums/v325/mwahaha/rand-om/normals-opacity.jpg">

I guess I should also say that light positions can't be checked at runtime, otherwise it would be easier to investigate. In the end, there are ways around it, including just not using transparency; it's just weird and undesirable; if there's some solution, that would be awesome.

Deadeye, not at all, though I appreciate your being humble. It was a useful honesty, because now, for example, I know that in a final game I'd have to demonstrate to the player that crouched jumping is much more useful than a standing jump. I could animate the player to crouch before every jump, and have them all the same strength, but I felt like including that control. Have you ever tried jumping from a standing position? I can barely do it, heh. But it could be useful for hopping off ledges, etc. As for TimeDelta, I'll double check my events to make sure. For some reason I put "every 10 milliseconds" on a lot of automated events, only using always (every tick) on events that change the value of some variable, such as max speed or jump strength, based on some equation. I don't know what's best performance-wise, though.

revolther - that's actually an interesting idea; simplistic robot, with little latches running about dodging things. The fun part in a game like that would be programming all sorts of hazards to avoid. The autojump in this just works, intrinsically, to allow the player to exit the pool. It's pretty basic: if there's a box in front of the player's feet, and that direction is being pressed, jump. In that test build I think you can actually hold left against the far, low wall in the second level and just hop indefinitely, getting nowhere.

I've changed it so that isn't possible (by raising the bottom of the boxes so they aren't detected), but for example in the pool the reason it works is because after the first hop, the upper protrusion catches the top of that block, which makes the player object think it's on the ground, so it still sees the box, and hops again. It also really relies on the stepped nature of the lower bounding box to catch and hop again if the first jump falls short. I like it, but I'm not sure how to integrate it into a new hang / climb system; maybe it will just work, I don't know yet.

Much of the world interaction requires a good bit of meditation and deliberation on my part to make sure it all works together right. It's sort of daunting, I don't know. I'll probably just work on graphics for a while and then come back to working on the code, etc. I've tried different variations of speeds dependent on crouched height; I can't seem to find something that I like, and since every one thing affects the next thing, it's sort of a balancing act. But I'm not too worried, because it's mostly a cosmetic thing, as I don't plan on making the game very hard - not a lot of deadly enemies or pitfalls, mostly just exploration.

The animation should be interesting. It keeps me up at night. I plan to divide the player into two segments, upper and lower, which animate independently... if you've ever played Quake3, players in that are animated with upper, lower and head - I might separate the head myself - which all animate independently, even though they aren't using full body skeletal animation. Technically, they are, but only the three bones. Maybe I'll use Construct's bone system to connect some of the parts? I don't know, I guess I'll find out when I get there, haha.

In the meantime I've got a couple simpler ideas. To start, I think I'll try to make a platformer with climbing and hanging that doesn't use the segmented body or crouched height stuff; that's what's making this other one so complicated to animate, just thinking about it.

Sorry for the novel. It's easy to go on and on about something like this...