deadeye's Forum Posts

  • Okay. Are you still set on using physics for your player movement? I assume the angle you want to move in is the angle in which the player is facing, like in your .cap.

    If so, this might help you:

    http://dl.dropbox.com/u/529356/physicsMove.cap

    v0.99.82

    Use arrows to move. This uses "Set Force towards Position," which is the easiest way I think to set up movement like this with physics. The position in this case is an image point on the player sprite itself. Open the sprite in the image editor to see where the image point is placed. There is also a second one at the back so you can move backwards.

    You might notice though that it's still pretty floaty. It would take some tweaking to get it so the player doesn't slide around like that. Also, the elasticity and friction have all been set to 0 for both the player and the walls to keep from bouncing when you hit, or rolling when you sideswipe a wall.

    Your might want to look at 8Direction or Custom Movement though. They both support collisions and can be customized for this kind of movement pretty easily, and you won't have any of the drawbacks of using physics for your player movement.

  • Thanks for the info about the layers but the input box is still screwed up.

    Hmm. Strange.

    Well, looks like some kind of bug. That's really weird though, I could have sworn it was working fine when I tested it. You might want to add that bug to the tracker.

  • So get .82 v<img src="http://www.scirra.com/forum/images/smilies/icon_confused.gif">v

    It's always a good idea to have the latest build, even if you're just using it for testing. If you still want to make your game in .62 that's fine, you can have more than one version of Construct installed at a time.

    Generally I assume that everyone has the latest build, it makes it easier on me when making example .caps.

  • When you're making a HUD like that it's a good idea to make it on another layer above everything else.

    Like so:

    http://i46.tinypic.com/2qlqtyd.png

    The Edit Box you made was scrolling along with the rest of the screen because it wants to stay in the same relative position that it started in. Windows controls like that work funny. It's best to avoid them if you can. Anyway, since you had it placed outside of the viewable area you would never see it because it was always scrolling away.

    If you make a separate layer for your HUD like I showed in that pic it will work fine. Oh, and setting the scroll rate to 0% means that the HUD layer won't scroll with the rest of the layers, it will always stay in that position.

  • Ah, I knew I forgot something

    It's 0.99.82

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • jpg hijack Q:

    So say I had a jpg pic. Should I load it in to photoshop and re-save as a png? Or has the dammage been done since it started as a jpg?

    The damage has been done.

    To be safe you should probably just save all of your artwork as .png to begin with. Or .bmp. But .png supports alpha transparency, and Construct imports the alpha just fine and converts everything to .png anyway so, yeah, no reason not to use .png.

    >

    > As for removing the sprite from the game and the .exe not changing size... did you remove all instances of the sprite, or just one copy of it?

    >

    All. Definitely all. In my simple test, there was only one layout and one object.

    These were the sizes of the .exes in the test project:

    Completely empty layout: 657kb

    Layout with large sprite: 3.54MB

    Layout with large sprite deleted: 3.34MB

    In my large project, the file sizes didn't change at all when I removed several huge objects.

    That definitely sounds like a bug. Try this: Delete the large sprite, then save and close. Then reopen the .cap and export an .exe and see what that filesize is. It could be that it's just a memory issue with the IDE. It does still have to save the object in memory in case you want to undo the delete, after all... maybe something is getting fudged between that and exporting a build.

    At any rate it's probably going to have to go to the tracker, but getting as much info as you can on what's going wrong will help the devs figure it out.

  • Construct compresses all images as .png, it doesn't matter what format you're importing.

    But if you're importing a .jpg, then yes it will likely be a larger filesize than if you're importing a .bmp because jpeg compression is crap and causes extra color information due to artifacts. Png compression is optimized for areas of similar color, if you have lots of little changes in color information then the file size is going to go up.

    Example:

    http://dl.dropbox.com/u/529356/bigred.PNG

    This image is only 9.6kb, even though the physical dimensions are large. There is no change in color info from one pixel to the next.

    http://dl.dropbox.com/u/529356/smallSpray.PNG

    This image is 33.6kb even though it's got much smaller dimensions than the first image. The reason is that there is a lot of change in color info from pixel to pixel. That's almost four times more disk space.

    When you use .jpg compression, it causes little blurry artifacts at the edges of where colors change, in essence making a whole lot more colors than were there before. In short, .jpg is terrible for games and you shouldn't use it. Not only is it inefficient, it's ugly.

    As for removing the sprite from the game and the .exe not changing size... did you remove all instances of the sprite, or just one copy of it?

  • I don't think they mean Path as in Pathfinding, but rather drawing a set path for objects to follow. A Pathfinding plugin like you're describing would be something totally different.

    Anyway, if it's at all possible I think the IDE side of things should link the waypoints for you automatically. It would make the plugin much more intuitive for new users. One would sort of expect it to work that way, after all. Having to link your waypoints using events isn't very user friendly.

    You could use the same sort of method that making custom masks for physics objects does, by having an "edit path" link in the properties.

    Also, support for two kinds of paths would be nice... Loop (which would work exactly like the mask editor for physics, where it auto-closes a shape) and Line, which would basically make an open line.

    As for movement along the two kinds of paths, Loop would default to tracing the path in one direction repeatedly and Line would default to a ping-pong sort of behavior back and forth from end to end. Again, I'm just thinking of ease of use here, as these are pretty much the most basic sorts of things that people are looking to use Path movement for.

    I think a Path movement should also have an option to "Orient to Path," like Flash does. As in, the object will point along the path in the direction it's moving.

    Oh, and some Exact and Interpolated settings. Exact would follow the path exactly as you drew it, with sharp corners. And Interpolated would make nice beziers through the corners.

    Just throwing out ideas here, take them for what you will

  • I got past three or four areas and when I went in a door the game crashed

    Really nice game, though . I love the music, it's very nice. The controls are also really smooth.

  • I opened 2 projects and selected 2 items from one then copied and when pasting in to the other project it crashed Construct.

    I just did what you said and it worked. Did you have both projects open in the same Construct window, or did you have two versions of Construct running in separate windows? Because you have to have only one copy of Construct running at once, something about memory.

    Anyway, I don't think copying objects from one .cap to another is fully supported yet, I believe David is working on it. There does seem to be a bit of an issue. I selected everything in one layout to copy, and pasted it all into another .cap and it worked for the most part except the texture on my player (a ball) got pasted with a texture from another object (the ground). But when I copied the ball again from the first .cap and pasted it on it's own, it copied normally and the original I copied apparently updated itself too because the player/ground hybrid turned back into a ball . Weird.

    I was able to copy all objects and all events from one project's layout to another project's layout and it worked fine. You still have to manually set things like layout and app properties, and create any globals or layers you need, etc.

    But long story short, no you can't really do this yet. It's not an actual feature, more like a work in progress.

    Edit:

    Also, apparently saving this copied .cap made a really funky .persist file, it made it so that I couldn't see the layout at all. When I deleted the .persist it opened normally. But yeah... you probably really shouldn't be doing this yet because it's not very stable.

  • How do I get a physics ball to "bounce" off a wall?

    You don't have to "get" it to. It automatically does it.

    And: what's the physics equivalent "move at Angle"

    "Set force towards position," or "Add force towards position," or "Set Velocity." Here's a method using Set Force:

    http://dl.dropbox.com/u/529356/physics%20ball.cap

    Just one event, one action, and as you can see all the collisions are done for you. That's what physics does... it just calculates speed, force, and collisions.

    If you're making a game where you're manually moving a player around then you might want to look into Custom Movement instead of Physics, though. Physics is more for manipulating things indirectly, like pool balls or pinball or knocking walls down with cannonballs and stuff like that. It's not very good for direct player control in most situations because it's unpredictable... things go knocking around in all sorts of crazy ways.

  • ... any hint on time frame deadeye? Fans await

    Soon, hopefully. Patience

  • I was joking too! Read my joke, it's a funny joke! I thought so anyway

  • You are correct. It does not resize the canvas. It appears to resize the contents of the canvas instead.

  • I don't think we should change the name to Builder. I did a google search for "Builder" and there was not one mention of Construct in the whole list!