newt's Forum Posts

  • Actually you do have to be careful and balance larger tiles with smaller tiles, as even though repeated tiles take up less vram, if you have many little tiles it can add up in processing power.

    IE keeping track of a couple hundred small tiles can kill frame rate where a few dozen larger tiles wont.

  • Yes, but that way I would have to make event's for evey single art asset. That's what this idea is for, to avoid all that wok in a simple way.

    Im talking about a exe you make on your own, one that saves the x, y, angle, and some reference to each object in an array. You would then import that info into your game to tell your assets where to go.

    I'm not sure what you mean by every single asset, as it usually designed to reuse events.

    You would however have to add a few events to the game to parse the array.

  • It should be relatively easy to create an editor that does the grouping for you using Lucid's S plug.

    It allows you to create array's that remember x, y, and angle, and it has a function to create image points on the fly.

  • 4 different objects at 256 x 256 take up less vram than 1 object at 512x512?

    That just doesn't add up unless the big object is not exactly 512 x 512, or your video card doesn't support it. The latter being the most obvious of course.

  • I think what he's wanting is a plug that would automatically align sprites based on a center objects imagepoints from within the editor... doable without a plug via imagepoints, pv's, and set angle, at runtime.

    But here's the kicker, if said sprites are all power of two, there's really no gain in splitting the image up into smaller pieces.

  • I remember playing the demo to Ico:

    http://en.wikipedia.org/wiki/Ico

    While it's 3d with full color and everything, the way they did the monsters is a lot like the silhouette style.

    <img src="http://dl.dropbox.com/u/666516/215133689_WNJWX-L-2.jpg">

  • I was going to say you might save some for a Prof-uis license, but I just checked, and jeebus they're expensive.

    Anyway yeah some sort of incentive would be nice for the devs.

    I don't know how your going to deal with the closed source plugs side of it though.

    I mean we haven't had anyone come up with a plug to sell, but I know Lucid is planning on doing one. Not that he should be exempt from donations, because he's already contributed quite a lot, and probably will much more.

  • You've heard of sprite chains before, now I give you the Sprite String!:

    http://dl.dropbox.com/u/666516/sprite-string.cap

    Fun fact:

    If you send an expression a string that is meant to use a number it will convert it to a number.

    Because of this little "feature" you can use GetToken(string, N [, delimiter]) to create arrays from strings.

    While its a bit easier to figure out, I wouldn't suggest using this method for a whole lot of instances, as I've noticed a slow down on anything over 100 sprites.

    Probably because of the text conversion.....

  • Not sure if its another case of doing it wrong, or whether its something wrong with the vector object expressions vector.lerp, or arrays in pv's

    http://dl.dropbox.com/u/666516/vectorlerp.cap

    If I manually set both arrays it works fine ie vector.lerp(sprite.xy,{100,150},1-0.5^timedelta)

    But then if I put sprite2.xy as the second vector it goes haywire.

    I wouldn't think its an issue with picking since there's only one instance of sprite 2.

    Also would it be possible to pass strings as arrays?

  • The set pixels moved is a bit funky,as you should only need to set it once, but I doubt thats the main issue.

    Its hard to say, from the "plugin's non-event code", it could be from solid, or even the inputsystem plug. You might try getting rid of the include sheet and manually add those events to layout 3, but test each line after you add it. If that fails you might try getting rid of the inputsystem plug.

  • Well looks like something with layout 3 is interfering with your event sheet Input.

    My guess is its something to do with the attribute solid, since gridmovement is designed to avoid solids. Like if your trying to do some sort of ai with the object, and the includes telling it to go into a solid that could cause an issue.

    Might try pasting event 112 in the sheet, or a screen shot of it, and any events that might be related to it in layout 3 as well.

    In any case its a bug because of the crash, and it needs to be replicated, reported....

  • Might try something like this:

    [quote:1000bn3f]+ Sprite: Animation "fire" finished

    -> Sprite: Set animation to "Default"

    As a separate event.

  • Ok,are you using transitions?

    Then if that's not it have you ran the debugger?

    Barring any obvious signs I think your going to have to try removing objects from the 3rd layout, and then replacing them with something else. Might try the MagicCam first, and then move to the non default plugs.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well what happens? Like is it just the game or does the editor crash as well, or are there any error messages? Also can you run the game from different layouts, or is just on the layout the object is on? Whats is the last object, and have you tried other objects?

  • I think the biggest issues out there now are resource management with hwa, knowing the workarounds for "features", and the less than obvious issues DirectX 9 brings.

    A platformer, shouldn't be a big deal, but 2.5d on the other hand....

    Well that's more of a complexity issue rather than ability. There is actually quite a lot of built in functionality for that, parallax layers, z height, z index, etc.

    I would suggest figuring out what would be the hardest thing to implement, and testing that out first. That should give you a hint as to whether Construct is for you.

    Then the forum is always pretty helpful for specific stuff that might evade you.