deadeye's Recent Forum Activity

  • The wiki does need a description of containers, I'd be happy to help out. Note two other features of containers:

    - If you create or spawn one of the objects in a container, it creates instances for every object in the container, to keep the object counts the same.

    - Same with destroying - destroying an object in a container destroys all associated objects (so you only need one Destroy action on any one object to destroy a container).

    Ah, see? I didn't know that.

    I'll go ahead and make my Container description a little more generic and post it to the Wiki. I'll probably start on it later on tonight, which means done by morning at the earliest.

  • Thanks Exomarc, confirms my suspicion it's my fault

    Ah, well I suppose that's good news of a sort. That means that likely it's fixable. Hopefully it's not a terribly troublesome fix. Good luck with it

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think maybe he optimalized the whatsits by twiddling the thingumers.

    Just a guess.

  • I found out about this just today! Like five seconds ago!

    You know the tile jitter issue that was plaguing my game on some people's computers... apparently Game Maker has the very same issue:

    I find the best way to maintain a nice retro look in a scrolling game in Game Maker is to set the View Sizes like Hideous suggested earlier.

    What you do is set the view to something like 319 x 239 and then set the view port 799 x 599, if I remember correctly. The reason for the one pixel off is to fix a bug that exists in GM6 amd 7 that occurs with certain NVidia cards that leaves a blank pixel between tiles when the port is scaled. Strange stuff. Let me know if that works out for ya.

    That's the same bug! But obviously it doesn't occur in every game-making program, because it would be a more commonly known issue.

    So Ashley, what are your thoughts on this? Is this a reparable issue in Construct? Or is it just something that's always going to be there because of certain hardware?

  • Unfortuantly, I broke Construct and it broke the cap of the new levels I made for it... (1.5GB WOOT!!!)

    But that doesn't matter too much... I needed to have a better system of events anyway... (one sheet for generic movement core, included into all layouts...)

    That sucks

    But you can rebuild it. You have the technology.

  • >

    > >

    > > if u wonder y i talk liek this its becauz every 1st april i do

    > >

    >

    > Thank god it only happens once a year.

    >

    i tealk liek dis at xmhas

    Thank god I'm Jewish.

  • if u wonder y i talk liek this its becauz every 1st april i do

    Thank god it only happens once a year.

  • Also, what the hecks the Event Wizard?

    He's a tiny magical man who lives in your computer.

  • You're welcome, glad I could help

    You should add it to the wiki, methinks

    Maybe a more generic version of it, I don't want to clutter the wiki up with references to my game.

  • Hehe, nice try bud. I usually forget all about April 1st, but I already got fooled by another site, so I was prepared

  • Okay then From the top (no pun intended):

    First, create your sprite:

    <img src="http://i30.tinypic.com/21lmq7d.jpg">

    Easy enough. But it's likely your sprite is animated. If you use per-pixel collisions for detecting the background, it will cause problems because one frame might be clear of the background, but the next frame could intersect. Here's all the top frames visible at once:

    <img src="http://i29.tinypic.com/2rxtd0n.jpg">

    The tilted frames only deviate by a couple of pixels, but that's enough to make collision problems occur. Using Bounding Box collisions on the sprite would make the collision area too large, and would cause problems with player collision or look funny when it's being smashed. So we need to make a separate collision sprite as a surrogate:

    <img src="http://i27.tinypic.com/2nsqljo.jpg">

    I've sized it at a nice, "average" size for the top so collisions will appear more consistent. I've also added a registration point to the tops and the mask so that it'll be easy to line up the hotspots when I put them in Construct.

    From there it's just a matter of importing your top frames into one sprite, and your collision mask into another sprite.

    We want to do all the movement actions on the collision sprite itself (the topBody object in the game) and tell Construct to align the animated sprite on top every cycle. If you have only one instance of each, that's no problem, just put in the events and go. But if you want more than one at a time, you need a way to distinguish between sets of "sprite" and "body." Otherwise, when you do this:

    + body is overlapping weapon
    [ul]
    	[li]sprite: Destroy[/li]
    	[li]body: Destroy[/li]
    [/ul][/code:3rpst3l9]
    
    then that one body will destroy, but so will [i]all[/i] the sprites.
    
    To fix this, you can pair up the sprites with the bodies by using Containers.  According to Ashley:
    
    [quote:3rpst3l9]
    If any object is picked by an event, the rest of the objects in its container are also picked.
    
    So that means if I want to pick a specific body, and "sprite" is in the same container as "body," Construct automatically knows which sprite to pick.
    
    To put something in a container, click on the object and open the Containers section in the properties.  Click "Add object," and select the object you want to pair up:
    
    <img src="http://i32.tinypic.com/bjg5rk.jpg">
    
    Notice that the topSprite is highlighted yellow when the topBody is selected.  This is to indicate which pair it belongs to:
    
    <img src="http://i25.tinypic.com/104m446.jpg">
    
    When you're using containers, you have to make sure you have an equal number of contained elements.  If I have five topBodies, I need five topSprites to match.
    
    Anyway, now we can go back to making events.  If we want to align a sprite with it's specific body, just do this:
    
    [code:3rpst3l9]
    + objectBody condition
    [ul]
    	[li]objectSprite: Set position to objectBody[/li]
    [/ul][/code:3rpst3l9]
    
    Construct places the correct sprite on top of the body that it's paired with.  And if we want to destroy it:
    
    [code:3rpst3l9]
    + objectBody overlaps something dangerous
    [ul]
    	[li]objectSprite: Destroy[/li]
    	[li]objectBody: Destroy[/li]
    [/ul][/code:3rpst3l9]
    
    Construct only destroys the sprite that's paired with the body that is picked by the condition.
    
    I hope that made some kind of sense.
  • Well the SDK can create objects - so I think we could just add a 'Spawn blob' action to Physics. It would make the instance that had the action called the central node, and spawn other node objects automatically hinging them together, with customisable number, radius etc.

    I don't know when this can be done, but I think its the best idea!

    That would be pretty sweet, but there are plenty of other uses for defining which specific instance to target when performing actions. What do you think of my Qualifier idea, or perhaps some other method that I've overlooked?

deadeye's avatar

deadeye

Member since 11 Nov, 2007

Twitter
deadeye has 1 followers

Trophy Case

  • Email Verified

Progress

17/44
How to earn trophies