Lost my Keys's Forum Posts

  • > double click the layout

    >

    Yes. In the lower right corner, choose Project, then in that: Application 1 (or application name here) > Layouts, and double click a layout.

    Probably just your cap's .persist file was corrupt, or wasn't saved properly, or something. It's just the file telling Construct what event sheets and layouts to open the next time you open your cap. You could even delete the .persist file without problem.

    Hmm, always wondered what those .persist files were, they seem to get into everything like a small child. Maybe in v1 they could all be stored in the construct folder somewhere.

  • double click the layout

  • > He said it goes weird when using point collision, that's why I suggested the alternative. Besides, doing so would slow it down, and that would be best for all bullet hell games *grins*

    >

    Hmm... I guess you can read run-onish better than I. It looked to me like FS tried Per Pixel and Bounding Box, but I see how you might have been able to translate more with the Lolsetta Stone.

    My mistake

    Bah, now you got me wondering if I read it wrong too lol. When he said the main hitbox was just a pixel, I assumed he meant the point/single pixel collision method and didn't actually create one of a single pixel.. or maybe he did, gah hahaha.

    Edit: I'm gonna take a guess that the weirdness is along the lines of bullets going through things cause of there being so many things on screen and frame rate suffering. But I don't know enough about this timedelta thing to suggest a fix, assuming that's the problem anyways.

  • It might not be a good idea to make separate hitboxes for bullets in a bullet-hell shmup.

    If you want tiny, 1-px hitboxes then why don't you use Point collision? It basically turns the hotspot into the only collideable point.

    Or, if your bullets are only one frame, then you may be able to re-draw the collision mask for them.

    Moved thread to Help/Tech

    He said it goes weird when using point collision, that's why I suggested the alternative. Besides, doing so would slow it down, and that would be best for all bullet hell games *grins*

    No seriously though, why not do what a lot of them do and rather than change the collision of the bullets, shrink the collision area of the player, would achieve the same effect in the end, wouldn't it. I think Progear was one that did that (only comes to mind cause I was playing it earlier heh).

  • You could put it on an exceptions list. I find it hard to believe Ashley or the others would turn it into a virus, so it's probably just one of those cases where things can picked out as malicious when they're not. Rescan it with something like Kaspersky http://www.kaspersky.com/virusscanner and see what that comes up with.

  • lol! That's awesome! Without any effort I immediately made the noise that old C64 Aliens game would make, when one of the Aliens moved towards you, that scared me so much the first time I played it as a kid, that I switched it off for a week before daring to play again hahaha. Ahhh, memories.

  • I think if you make two objects, a much smaller one and use a bounding box for that, and then the larger bullet sprite, and no collision for that. Make them a container of each other, and spawn the smaller one, make that always invisible, and instance a copy of your actual bullet sprite on top of it. That should work.

    I think deadeyes platform tutorials mention something along those lines involving using another object as the collision box rather than the actual sprite. So you might wanna check those out as that's what you're looking for.

  • I'd like to insist on how SSAO is pointless in 2D.

    Allow me to explain:

    SSAO is occlusion, independent from light sources, based on the depth difference between each pixel.

    Construct is 2D (mostly). What's the depth difference within a sprite? Zero. Always. What if you want to have a heightmap with heights? well, then the depth difference will be always the same, since the normal never changes..... so, the occlusion will always look the same and you're better off baking it, EVEN IF YOU USE NORMAL MAPPING.

    And if you layer one sprite on top of another? well that's why I suggest drop shadow.

    I'll try upping the pixel shader version and see if it's enough. I'm bumping into a lot of limits there (registers too)

    Wall of text warning

    SSAO is a 2D effect using a depth map, it's faster but less accurate than full Ambient Occlusion.

    AO is a 3D effect and wont be seen in games for some time. It's faster than global illumination etc. But still too slow to be used in realtime.

    Nothing displayed on the screen has depth, doesn't matter what your using, the end result is always going to be 2D. Internally it's 3D. AO is calculated internally and takes into account all the fun light beams and so on and so forth. SSAO doesn't because it can't, it doesn't have access to any of that information. But it does have access to depth maps (I only used height maps as an example of how they look, they're inverted in most programs but the principal is the same). A depth map is the Z-Buffer, it's used to decide what's in front of something and what's behind, and it's very, very useful.

    A good use of depth maps is in post production. At that point all your resources are completed and the end results are nothing more than images. Often it's a good idea in post, to do certain effects such as fog, depth of field, or even placing elements in the correct positions in relation to the image. Now if you've just got the single stock image, you're kind of boned unless your elements were against a single color (like green/bluescreen) or using alphas to allow them to be cut out. But even then, to do things properly, a depth map helps. It can then tell the 2D program that a particular effect, lets say fog, should appear heavier where the depth map is pure white, and then falloff as it gets darker. You've just put fog perfectly into an otherwise flat image.

    SSAO works the same, and there's a number of plugins available in post production applications which do just that. After Effects and Shake come to mind as two that have them.

    -

    As for depth within a sprite. Your right, a default sprite in a default 2D world has no depth, being two dimensional.

    But what's stopping you from having depth? Consider a parallax effect, 10 layers all scrolling at a different speed. It's 2D, it has no depth. But what if the artwork on each of those layers were given a depth. The artwork in the background layers would be further away than those closer. You couldn't see the difference to look at it. But what if you then applied a DoF shader that takes depth maps into account? You've got visible depth.

    Now say you were to create a sprite of a lil guy running, viewed from the side. Shade him however you want, he's just a 2D image. But give him a depth map, where his arm is closer, like an inverted height map. Add an SSAO shader on that, you've got realtime ambient occlusion. You could do this in the same way normal maps are applied at the moment, so effectively doubling everything, or tripling it if you add the normal map required copies too.

    Now while this is entirely possible. I'm not saying it's easy. To accurately setup a scene in 2D to make best use of depth maps and SSAO or a DOF shader. You have to plan ahead, either build the scene in pre-rendered 3D, output the required images and depth maps. Or be very good at deciding where things should be in relation to the imagined depth.

    So I wouldn't say it's pointless, or impossible. But to set it up without forward planning can break the illusion entirely, and it wouldn't be very useful for everything (retro looking pixely games would have no use for it for example).

    Incidentally, you can do Parallax Occlusion Mapping the same way, with a shader coded to change the parallax effect based off of distance and angle from a center point, and using a standard height map for it's input rather than a depth map. Yes that would work just fine in a 2D game as well. But considering you'd be then having four clones of everything, to take into account a depth map for SSAO and DOF (and more accurate motion blur), a normal map, and then a height map for the parallax occlusion effect. You're going to be needing a decent machine just to run it at a sensible framerate.

    And now you've got me thinking, how cool a remake of Shadow of the Beast would look, with all the above. Oooooh.

  • There's pretty simple calculation that checks the size of screen and does some stuff and you get the light point exactly where you want as example at mouse. Or isn't this what you want?

    Sounds like what I was looking for, yeah. Mouse or Sprite. That would be great!

  • I don't think the canvas object is an option at the moment, it seems to be broken right now. But if you want to try it, just put the canvas object in it's own layer, make the layer invisible. Then when you want to take a screenshot, have the layer appear and the canvas grab the screen behind it. I think that's how it's done.

  • > The simplest solution is probably for someone to write an online plugin

    >

    Been waiting on that for months :/

    Also, Dataflash... If you test anything out, I'd be keen to see how it works out. If it's plausible for something simple, it may work for something more complicated.

    Keys

    Hmmm well that sort of confirms the IRC idea... though I would have no idea where to start with something like that. It's been so many YEARS since I've used IRC I would have to relearn all of that stuff just to get a room going with reliable bots... which would then need programming scripts etc etc.

    I am still determined to find a way... I work with the tools I have... and since I don't have a proper tool, I will dodgy something together and make it work as good as it can.

    Thanks for your input everyone... I think I have enough information thusly to realise this won't be easy, but should at least be possible to some extent. If anyone gets all excited and starts playing with this idea themselves, please share any results you find so we can all learn from it.

    ~Sol

    The mIRC part shouldn't be all that difficult. When I came up with it I only knew the very basics of scripting for it. So if I could understand it back then, you'd sail through it, lol. I do remember creating a bot that behaved so much like a human, people thought it really was. I was so proud hahaha. A quick search on google though appears to show it can do even more than what I mentioned. Making Dll's for it and the like. Chances are you could probably get damn close to real time online play.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Couldn't you just use a regular off the shelf method for SSAO (screen space Ambient Occlusion), using copies of objects with depth maps on them (which basically look and behave like height maps), which would effectively make up for the lack of any genuine depth in a 2D world. Since SSAO in 3D games uses a depth map in the same way, which is why it's so much faster than real Ambient Occlusion.

    I dunno, in theory it would work, because it's not doing anything that can't already be done.

  • This is why I wrote Heightmap Plus.... but sometimes heightmaps don't cut it and you really need to use a normal map.

    I plan to introduce a normalmap plus effect at some point, with an angle input to compensate effortlessly. You could do the math in events, but yeah it's a bit hard.

    That would be awesome! And very, very useful. I'll look into heightmap plus in the meantime. I saw it in the list but didn't look into those so much.

    *Le sigh* Wish I could code like that, doing little plugins and extra's would be far more useful to the majority, than artwork, which would have to be all specific for every user.

  • timer behavior, timeline object, key press and enabling/disabling groups.

    Wouldn't any of those do the trick?

  • >

    > The 120fps was just something I left it at, it works without lag at 60fps, 20fps, 900fps too.

    >

    well, it does not, when i set the fixed framerate to 60 it behaves exactly as when i turn the v-synced mode.

    also,

    >

    > V-Synced: [...] The best quality and smoothest display. Games should all use this option.

    >

    > The point was, turning v-synch off solves the problem

    >

    I'm confused

    Thank you Madster for explaining, but i don't think the lag is 2 frames, if my monitor draws 60 frames per second, the lag seems more like about 10 frames (well, now, after fiddling with the nvidia control panel). please also don't jump to conclusions that it's bad lcd, because the hardware mouse cursor does not lag whatsoever.

    Any ideas how to lower the lag even more, to the twoframes from the Madster explanation?

    Well I don't know what to tell you then besides filling a test layout up with lots of things, to simulate a completed game, and see if it still does it. Or just use the default cursor rather than a custom one (I know that isn't the perfect solution).

    Why don't you make some higher fps limit, but have your game run at 60fps or something, can't that timedelta thing do that? Then just not use it on anything involving the mouse pointer. Wont that solve the problem? Though judging by the number of games and people having this problem, it might just be one of those things you have to live with. Do what most developers do, blame Microsoft and the end users hardware, say it's entirely out of your control and not a problem with your game, then suggest turning v-synch off as a last resort.