Vrav's Forum Posts

  • Here I am trying to make something too complicated again. What started as an experiment with containers (which are no longer even being used) turned into a one-shot brush painting toy. Told myself if I could get the ink to paint nicely, I'd do graphics for the brush, ink bowl, paper and all that. Unfortunately, despite trying various solutions, I couldn't get it to fill in the gaps made during a speedy stroke. It was fun, but I give up for now. Perhaps to try again some other time!

    <img src="http://img.photobucket.com/albums/v325/mwahaha/screenshot/brushfail.png">

  • It's just an interesting technique to know, for a person who is not really math oriented. Adding knowledge to one's repertoire to allow for more convenient problem solving, that sort of thing.

  • Oh, math. Now I must study linear interpolation.

  • So, entries can be made by a team? Sounds fun.

  • It's become something of a habit to rename things with F2, so I keep clicking on the icon-looking objects in the "object pane" (all I can think to call it; is to the left of layout editor by default) and hitting F2 to rename them. It would be cool if this worked; it is always a pleasure when an application works as one has grown to use others intuitively. I do like that middle-clicking tabs closes them; that's the sort of thing I'm talking about.

    Randomly, I guess I will also state that the Construct UI does not display very well with alternate Windows skins/colors. It's one of the only applications to make readability this awkward. Perhaps nothing can be done, but, here is a screenshot.

  • If everything else that was in the same container as the object with dummy behaviour, per dummy object, was aligned properly according to size and angle and everything at runtime on demand, that would be neat. But the uses here are become somewhat limited; it is probably best to simply event script these things as needed.

    For this sort of object arrangement, it would be useful if there were a "This," or "picked object," etc to use in equations - instead of Object.X, operate more vaguely on the object that is currently being placed. Then an event could run through each object in a family, and set each of them up the same - that is, instead of setting the width, height, angle etc of objectA, objectB and objectC individually per dummy, to be able to, as it runs through each dummy object, also run through objectA, B and C as a family and orient each, with the same few events.

    If there is already some way to do it, using containers or something, that would be cool. I keep reading that things done to one object in a container are done to all other objects in that container, but does this also include positioning, scaling and rotation? Maybe I have just not tested this thoroughly enough, hmm...

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.