deadeye's Forum Posts

  • Squeemish, you should seriously consider cutting that track up into smaller tiles. With a sprite that large you're allocating space in VRAM for a 4096x4096 texture. It's taking up way too much space, especially since you're only using the top portion of it... most of that image is wasted space.

    Sure, it runs fine now, but when you start adding more graphics to your game you're going to choke your graphics card to death. Some people probably won't even be able to run your game, or they'll experience crashing due to running out of VRAM.

    My advice would be to make smaller pieces of track that you can fit together like tiles. Not only will that save a crapload of VRAM, but it'll make things easier if you want to make new levels as well, since you can build new tracks out of the same pieces. It might take some work getting your custom collision masks just right so they line up, but it'll be worth it in the long run.

    Oh, and make sure your tiles are a power of 2 square, and I wouldn't go any higher than, say, a 256x256 sized tile for a game like this.

    Anyway, good luck with your game

  • Oh hey, I found it

    http://dl.getdropbox.com/u/529356/dragandtoss.cap

    And yeah, it was simple... I just couldn't remember the exact method. Doesn't need Drag & Drop behavior, either.

  • Argh, I had a sample .cap I made a long time ago where you pick up and throw a physics ball with the mouse, but I can't find it. As I recall it was really simple to do, too.

    I'm too braindead right now to recreate it, I might have a go later on.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I... have no idea what is going on in that .cap

    I will say this: Resizing physics objects often leads to bounding box problems. This is a known issue.

    What I believe is happening is that the bounding box for your, uh, giant bear macro is glitching out. When you change from large to small, the bounding box is still large, and the small bear macro pushes out of solids away from the black platforms.

    What I would recommend is that instead of changing the size of your object, you should destroy your physics object and spawn your larger object in it's place, and vice versa. That way you can preserve your bounding box.

    In a future build this probably won't be an issue.

  • You do not have permission to view this post

  • Congratulations Sol

  • You do not have permission to view this post

  • There's a website, and some promises. It's another open-source game making startup... what's not to talk about? Sure, it'd be nice if they had some screenies of the IDE or something but, jeez... it's news, and it's relevant. Talk away.

    Also, I kind of like the name "Black Crystal." It's so... teenybopper goth. Like, I might sneak out of my parent's house in the middle of the night to meet up in the graveyard to light candles and drink a wine cooler with it.

  • <img src="http://img238.imageshack.us/img238/5692/invader.gif">

    <img src="http://i43.tinypic.com/a1luus.png">

    You... you TRAITOR!

    Fine, go to her... go to your Black Crystal *****

  • You do not have permission to view this post

  • I am looking forward to bananas in the new build, bananas will help quite a bit for the game I'm making about bananas.

  • People have made Pong before, but I don't believe 8 Direction was ever used to make an opponent.

  • Looks like it might be a bug with the 8 Direction behavior, sliding around solids like that when it shouldn't. Would require some more testing to confirm.

    Anyway, here's a sort-of fixed version that will at least keep your opponent's bat where it should be:

    http://dl.getdropbox.com/u/529356/pong.cap

  • You do not have permission to view this post

  • You do not have permission to view this post