procrastinator's Forum Posts

  • Ahhh nice!

    If you had a LARGE layout, for example, 10000x10000 and let's pretend you had 100 zones, laid out in a grid like fashion. So each zone would take up 1000x1000. Each zone would have its own invisible trigger (an invisible 16x16 rect scaled up to 1000x1000 to save on memory).

    You would dynamically create each zone rect at start of layout. Add an array to the rect in a container. So when each rect is created, the array is created with it. Loop through all the rects and store each zone's ship positions / types in the array and then destroy the objects / ships (except in the zone the player is currently in).

    When the player leaves each zone and enters another (basically testing if the ship overlaps that zone's rect), the one the player leaves would save the positions and ship types in an array that's attached to that zone at the time of leaving, and then destroy those objects. If a ship is onscreen but is attached to the previous zone, then don't destroy it, instead attach it to the new zone. This way you'll only be dealing with the ships in the current zone, plus any others that straggled into the new zone. Then you won't have ships suddenly disappear when entering the new zone. It seems simple enough in my head, but I imagine it could be quite complex when you get down to it.

    Does that make sense? It does to me, but I'm not sure if I've explained it correctly. Sleep deprivation and all that ;p

  • dt can be confusing at first, but you don't really need to know how dt works. The best way to think of dt is how many pixels you want an object to move in a second. So in the example C-7 gave (X+150*dt), the object would move 150 pixels in a second, and that's why it's consistent across all computers / devices.

  • I think where C2 is inefficient is objects that have animations (they'll still animate offscreen - even if under the hood it's just keeping track of the frame number and increasing that - 1000 objects is still more than the few that's onscreen) and objects with a behaviour like the bullet behaviour will still move around offscreen and so on. I don't think an invisible zone trigger would matter in those circumstances, since you have "inverted if object onscreen" event to control those. Of course, having an invisible zone trigger would mean you could have some turret fire at the player even if it's 500 pixels (or whatever) offscreen.

    Is it just an asteroids game? Or a bit more complex?

  • The main reason for it screwing up is the physics is already applying it's own force / impulse upon collision. Also, your overlapping at offset is wrong..

    Remember overlapping at offset is how many pixels ahead you want to check, so basically you're adding the X and Y positions to that. You only need Sin(Box.Angle)*16 for X Offset and -Cos(Box.Angle)*16 for Y offset.

    Also, you're creating a new marker everytime the LMB is pressed (every 0.125 secs while LMB is down to be exact), but you're not destroying them. Just a minor thing, but you'd end up with thousands of markers after a while ;)

    Here's a fixed capx.. no more screwy bouncing around ;) Not sure if it's exactly what you want, but at least the physics is sorted. If you want it to bounce more, then just set elasticity to a higher value on the walls.

    CLICKY HERE

    Hope that helps.

  • You're right, I did mean tile based games. I just assumed that, because you brought up placing objects in the layout. I'm not sure you'd see much of a performance gain by doing just what C2 does - tracking every object. It would probably be slower to access an array 1000+ times in one go rather than just letting C2 do its job.

    That's not to say that splitting the whole level into segments and only dealing with the objects in that segment (array) wouldn't have a positive effect.

    The main reason it works for tile based games is because you're only accessing a small portion of the array at a time. That's why splitting it into segments could work, but that depends on the game really.

  • Usually happens to me if I have C2 open for a long time, like >3 hours or something.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It does sound like it's setting the position unconditionally, meaning it will Set Position every tick.

    Create an instance variable "reset" and when this is true, Set Position. Then set it to false afterwards.

  • Construct Classic for me too. Worked on a game that had well over 100 events. It broke when CC was updated and it wouldn't load the project. There were so many bugs in the version I had saved with that I either had to redo with the new CC, or just suck it up and keep going. Well, I just gave up ;p

  • Yeah nothing wrong with helping a friend out. As has been mentioned, don't devalue your own work in the process.

    Pixel perfick's suggestion is a decent one. Just don't overpay!

    Good luck though. Hope it makes you a vast amount of money ;)

  • It's a shame they don't spend more time getting FF to run html5 as nice as Chrome ;p

  • I have a basic tilemap loader going using xml files exported from PyxelEdit. I'll try and work up a scrolling example tomorrow (remind me though ;p).

    For a simple example that I can explain now, I'll use Gradius. You'd store the whole level in an array. Draw all the tiles that are "onscreen" in the array. When scrolling through the level, every X seconds you'd use an offset in the array to draw the new column offscreen, and increase the array position by 1. When the tiles.X are less than -TileWidth (offscreen to the left), then you'd destroy those. So a level that would potentially have 1000s of tiles, you're only processing / moving a couple of hundred or less. This is why C2 isn't efficient with tiles placed in the layout as it processes / moves all of them.

    Hope I explained that ok. I'm pretty tired mentally right now ;)

  • It matters when you have a huge map made of tiles. Creating them just offscreen as it scrolls means you control how many objects are created. Whereas, creating that huge map in the layout is a huge performance hit.

  • On first glance at the code, you have overlapping at offset (1,0) on both the X movements and Y. This would only check 1 to the right all the time.

    checking to the right

    if overlapping(1,0)

    if player.angle = 0

    checking to the left

    if overlapping(1,0) <- should be (-1,0) - checking to the left

    if overlapping(1,0)

    if player.angle = 270

    ^ you're still checking the X coord.. needs to be overlapping(0,-1) to check above the crate

    same with down - overlapping(0,1) to check 1 below the crate

    Don't have time to go through all your code, but I'm sure you'll see a difference if you fix those ;)

  • I put together a small simple thing the same as what you have and it spawns fine. The other ball goes off in a random direction, as I wanted. Is startingSpeed set ok? Sounds like that's where the problem lies. Make sure you're not setting it to 0 or something somewhere. Unless it's stuck in the block?

    And yes, very smart decision to start on simple smaller games. How refreshing it is not to see someone try and do a full RPG as their first game ;p

  • scirra.com/manual/124/system-conditions

    Pick nth Instance is what you want. About halfway down the page.