Ashley's Forum Posts

  • Well, if you're using something like 640x480 on a widescreen monitor, it's either got to stretch it or add bands to the sides. You could detect the user's desktop aspect ratio on startup using the System Information object, and use the Change Display Resolution action to go to the best resolution in that aspect ratio. Then you can go fullscreen and it keeps the user's aspect ratio. However, the runtime will stretch the display to fill the extra room unless you set the resize mode in application properties to "show more content".

  • Well before you go ahead do some calculations and figure out if when the game is done, will one layout's complete textures even fit in system memory? Will the system requirements be too high to be useful to anyone?

    You should come up with satisfactory answers to these questions before you make your game. There's no point launching in to creating a game which is impossible to run.

  • It will still take up VRAM.

    [quote:2x55o1z8]Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.

  • If something is locked you can't select it, so what use is an "unlock selected" option?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Woah. That's big. I had a look at the .cap you sent David. You just can't get away with that many graphics in an application. Remember if either dimension of the image is over 256, it'll get put on a 512x512 sized texture by the graphics card, and after a quick look, I think every animation frame is going to be put on a texture that big. After a few calculations, you're basically going to try and allocate about 800mb of textures. Some people still have 64mb graphics cards, and not everyone even has that much system memory. You need to entirely rethink how you do your game and probably cut down the animation frames by at least a factor of ten.

    I think one graphics card, the nVidia GTX 295, has a slim chance of fitting all that in VRAM (and this is just the beginning of your game I assume). It costs �400. You're going to have a tiny target audience if you carry on this way

    Using separate objects won't help. Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.

  • The main documentation is on the wiki.

  • Try out the Timeline objects, and try adding the Fade behavior to a Sprite.

    BTW, it's spelt "entertainment", just a heads-up for your all-important title screen

  • It fades in no problem, the problem is that it always disappears after that no matter what I do.

    Oops, that was a bug. If you disabled the 'Destroy afterwards' option it didn't destroy but left it invisible. Fixed in next build.

  • Sounds like a bug. Post it to the tracker.

  • 1) i just don't get how to make levels/rooms/stages,i heard that i must use layers for that

    Layouts, not layers.

    Have you tried a tutorial and read the FAQ?

  • Thanks for getting in touch. That sounds cool! As you mention documentation is sparse and we're relatively unknown right know, mainly because we have yet to emerge from beta and release our first officially stable build, 1.0. However, hopefully in a few months, we'll either have arrived at, or be much closer to, a well documented, popular game creator.

    Sharing your teaching materials would be fantastic, since it would probably help a lot of people out, and being open source, would be very much appreciated

  • 1)Can a single complex script replace all events?

    Generally, no. Python can access objects, but not all features are available through python yet (eg. behaviors). This is why I state Construct is an event-based tool, the event features are mature, and the python features are still "beta".

    [quote:1nacvv14]2)What are the limits of what the script can do? Can it call new sprites into being? Load new resources into the game?

    You can create objects, and you can use the script versions of the event actions which load resources from files.

    [quote:1nacvv14]Will it allow you to use C code (I found a wonderful bitmask pixel-perfect collision detection library that even reports the coords of the impact)?

    No, that's something completely different, although you can use C++ in the Plugin SDK and make a new object. By the way, Construct has an MMX-accelerated pixel perfect rotatable bit mask collisions engine, and I don't know of any faster engine. I'd be interested to know which engine you're talking about because if it's faster/better, I can think about improving Construct's collision engine. Also, normally it is not possible to accurately report the co-ordinates of an impact since a collision usually involves one or many regions of overlap, and even just taking a simple average causes the collision engine to be slower, because it can't stop as soon as it finds one case of an overlapping pixel.

    There's nothing in your game spec that can't be done. You just have to put in the work hours to make it.

  • Looks interesting, especially that they opt for an event based system as well. It seems pretty basic, but I guess it does the job for mobile gaming. Still, mobile gaming is a trickier thing for Construct to achieve, I don't think we'll be deviating from our original aim of DirectX accelerated desktop games for some time.

    Also I don't think it looks particularly similar to Construct, I'm guessing they don't even know we exist.

  • Aquaria, on the other hand, has a disproportionate number of detractors.

    I suppose that might just be a side effect of it's success. It could also be that because it's professionally made, it gains a wide audience, and from a wide audience comes critics, since you inevitably can't please everyone. I have a feeling if you look for them, you can find detractors for any game

  • Some interesting points raised, thanks for your input everyone. I think it's interesting megatronx that you say retro games are "fun, fast, challenging and simple to control" - none of them are attributes specific to retro games - non-retro games can be all of those things too.

    I like your analogy for graphics and gameplay, deadeye - "pepper on the steak". Poetic