Ashley's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

  • Construct is mainly an event-based programming tool, as you will see if you look through the examples and tutorials. Python is designed to circumvent the limitations of events.

    However, I'm making a fairly large RTS in Construct, and I get by fine with simply a combination of families, containers, and private variables. Look them up on the wiki for more info. And as newt said, definitely check out the RTS basics template.

  • The .cap file linked in the post is no longer online.

  • I was wondering recently why retro, low-res games are so popular in the indie gaming community and was hoping some of you could offer your opinions.

    If you look around, an awful lot of games are deliberately pixellated, use tinny square sound effects like early consoles, and have similarly simple gameplay (ie not too many objects, as if the game were even designed for NES style hardware with limited processing). I understand that many people see NES/Megadrive/retro games as the 'glory' days of gaming when gameplay, not graphics, mattered (and disillusion of modern commercial titles) - but it seems disproportional. Why do so many people, the majority of indie game makers it seems, ignore the new creative possibilities modern technology allows for? For example, you can trivially create a thousand objects and barely see an FPS hit. Or you can mix a hundred sounds playing simultaneously and it has almost no impact on performance (none if your audio mixes on another core, which XAudio2 does). Or you can run several advanced layer effects and a modern graphics card won't even get lukewarm. This just makes me think of all the cool things I could do to make games more interesting.

    I can think of a few reasons people stay retro. Low-res artwork is probably easier to do, as for the sound. Some people still use really crap computers, and you know your game can run on that as well. Maybe some other tools like Game Maker really start to creak under their own inefficiency if you try to get that far. Or just to try and reach in to the previously mentioned 'retro glory'. But of course the fact a game is retro doesn't necessarily mean it is good.

    What do you think? If you still make retro style games, what is it that makes you want to keep to that style? What are the main detractors to hi-res gaming?

  • What version pixel shader does your hardware support? Does the error message give the details of the error in the .fx file? Which effects are you using and does it work if you remove all effects?