-Silver-'s Forum Posts

  • I've been using a really powerful animation system to apply bones to tree models, create realistic 'swaying in the wind' animations, and then export them as PNG files to later import to Construct. After testing out the animation with just one tree though, I've noticed a huge difference to load times when clicking 'run layout' to test things. This could be down to two factors, and is probably a combination of both.

    1) I'm using a total of 20 frames for a swaying animation, at an animation speed of 10 (10 frames per second?) so it looks pretty smooth for an atmospheric effect. Is that going to cause a lot of slowdown? Knowing that every tree on a map will have at least one 20 frame animation, and possible a second 20-30 frame animation for stronger winds? I'm using big maps. Maps with over 100 trees are going to be common.

    2) The size of the trees in pixels are 512x512, and 1024x1024. I remember reading that some GPUs find large image sizes difficult to render, and that performance is significantly improved if you break the images up into smaller tiles, then piece them back together in the editor. Would images of this size cause slowdown? Or is this just concerning tiled backgrounds on large maps? I have a GPU with 1GB of VRAM, but I'd like it to run on cards with 256mb smoothly enough.

    Any feedback on improving performance would be greatly appreciated. It's frustrating having to wait upwards of 60 seconds with a 'Construct is not responding' message every time I want to test my layout. Clearly, i'm doing something stupid

    Thanks for reading! ^^

  • Describe the homing attack in sonic games

    2:05 in this video:

  • What you should probably do is make your own level editor to make the process easier, then have the level editor export an array with tile's locations that can be loaded by the game.

    As a bonus, you can release the level editor with the game and people can make their own levels!

    This is a very interesting idea. Could you expand upon it? How would we go about creating a level editor to work with Construct?

  • I'm using Photoshop CS3 for mine, but there are plenty of great free applications available. A few examples to get you started:

    Graphics Gale is popular for pixel art. http://www.humanbalance.net/gale/us/

    GIMP is a popular Photoshop alternative. http://www.gimp.org/

    Krita is a popular and praised Photoshop alternative designed for the Linux OS. http://www.koffice.org/krita/

    Pixen is a popular artist's and animator's program for the Mac OS. http://opensword.org/Pixen/

    So whatever your OS of choice, there's plenty of options! A graphics tablet such as a Wacom also helps with image creation a lot, but I've still seen a lot of great work produced with a mouse and keyboard. Ultimately, it's all about your own artistic competence of course. These programs don't create the art for you. They're just another artist's medium.

    Have fun!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh wow, so maps around 20'000 pixels should be fine.

    Thanks for clearing that up for me

  • Just a quick question.

    Is there a maximum size that a layout should be set at? And is there a maximum object count? Recommended sizes and counts, rather than absolute limits.

    I've been planning on running pretty big layouts, hand painted in Photoshop for a tiled background with hand-painted sprites placed on top for interactive elements such as buildings and trees. I've been working on a layout of 16000 by 6000 pixels so far, and am planning to have a lot of trees set on top as sprites, with events running every tick to check whether the player is behind them and to lower their opacity if he is, and with the intention of having them all animate to sway in the wind.

    Presumably the performance will vary from system to system. But is there a recommended layout size and object count to cater to a broad range of computers, and is that above layout likely to be too taxing?

    Ok... that didn't end up being such a quick question, but hopefully it isn't too hard to answer! Thanks for reading <3

  • Do you get it? I don't know if I'm being very clear as I am also not a developer

    Fantastic explanation, thanks!

    I've tweaked the multiplication factor to 0.2 for the larger trees, and I've set the lowest opacity value to 20 so that the player will still have an idea of where the tree is without having his view obscured. You and Pixel have been great tutors!

  • Generally I like your approach. Without checking the Z ordering (like you mentioned) it appears a bit odd when even trees that arent in front of the player get faded. So that should definitely be added.

    Oh, why did you use an always event there? You can just loose it and it works the same, btw.

    I imagine getting rid of the 'always' event would help performance too? I'll see if I can work out how to check for z ordering with this method.

  • Pixel and Gamma, I love you both.

    I've got the collision with the trees working, sending the player to the front or back as needed with Pixel's advice, and the tree opacity blending looks gorgeous using Gamma's method.

    Can you explain the numbers used in the events a bit for me Gamma? Unfortunately, I'm an artist and literature student, so numbers bamboozle me to no end. I've been experimenting with altering them to increase the range at which the erasing effect begins (since my tree models are pretty huge), but haven't had any luck yet :S I think it would help if I had an idea what the numbers did.

    Many thanks for the assistance.

  • > Thanks for all the advice! I'll definitely use transparency instead of a complete invisibility, so I'll see if I can get that working with the canvas. If not, I will just have to turn the whole tree transparent instead, which still does the job.

    >

    > Thanks again.

    >

    Just to clarify what I was getting at in my earlier post... here's a simple example:

    http://dl.dropbox.com/u/2306601/treesee.cap

    Wow, thanks for taking the time to put that together! For some reason I'm struggling to get this to work when I edit the tree's layer mask though... I want the tree base to be solid so that the player cannot walk through the trunk, but is still able to walk behind it. So I've made the tree a solid object and erased everything from the layer mask except for the base. The collision detection works, but the player doesn't disappear when he walks behind it and the circle doesn't show up.

    If I remove the 'solid' attribute from the tree then the player disappears behind the parts of the tree with the layer mask, appears correctly in front on the tree, but still shows up on a higher layer when he should be behind it whenever he's not in contact with part of the layer mask. And, of course, he can walk straight through the trunk...

    I guess I'm doing something very wrong here? Should layer masks for trees not be deleted at all to achieve this affect? And if so, how can I make the trunk a solid object? Using an invisible block at the base could help I imagine, but would lose the exact pixel collision.

    Hope that's not too confusing :S

  • Thanks for all the advice! I'll definitely use transparency instead of a complete invisibility, so I'll see if I can get that working with the canvas. If not, I will just have to turn the whole tree transparent instead, which still does the job.

    Thanks again.

  • I'm playing around with hand-painted environments for an RPG, and have got a lot of trees ready to map with. The trouble is, if you're standing behind a tree, you obviously can't see your character, or any enemies he may be in combat with. If you're in woodland or forest... it's going to be impossible to play.

    So would it be possible to make an invisible circle around your character that erases parts of the trees it comes into contact with? Giving the effect of seeing into the section of woodland your character is standing in, without just erasing all the trees completely?

    Hard to explain so here's a visual example I've mocked-up:

    Default tree: http://i216.photobucket.com/albums/cc212/darkstorne/canopyeraseexperiment.jpg

    Tree with erasing effect: http://i216.photobucket.com/albums/cc212/darkstorne/canopyeraseexperiment2.jpg

  • Linux is the only other viable platform to run the development tools on... other than Apple.

    That's one of the reasons it should be given higher priority.

    Plus you need to remember the devs are only thinking of having one other non os to export to.

    Bringing in Linux's user base might actually help to get some of the other formats ported.

    Is that the topic of this thread though? The poll is asking what platform we'd most like to see our games run on. The simple answer to that from a serious developer's point of view is easily: Consoles.

    If the poll read: which platforms would you also like to be able to run Construct from to develop games, then Linux and Mac OS systems would easily be the best answer. But unless I misinterpreted the poll, that's not what is being asked in this thread.

    So essentially: If this engine's aim is to become a viable tool for serious Indie game developers interested in creating video games for a living - then console porting is an important feature to add.

    On the other hand, if the engine is only aiming to cater to a handful of people who create games as a hobby and past-time, and would like to see their games run on their OS of choice as well as Windows, then Mac and Linux support could be the answer.

    So it entirely depends on the goals of the engine and its creators. If console porting doesn't get provided in the next release, then developers like myself can easily look to other engines like Torque. Construct seems to be a great engine that's easy to pick up and more than capable of making great Indie games, so I'm very interested in seeing which way the engine will be heading in the future.

  • Linux at the bottom

    Sounds like all of you want your games to run on the platforms from where you can get money.

    That's exactly what we want. As a serious Indie developer who is looking for the best way to get his games to as many people as possible, to turn as big a profit as possible, and to get his development talent noticed by larger companies, I'm looking for an engine that provides porting to consoles.

    I'm not saying that Export to Consoles shouldn't be there, but it should be given lower priority than linux and internet platforms, since there are a lot of people out there who are running linux.

    You're arguing that Linux is a higher priority because of the large numbers of people who use Linux? Over the number of people that use consoles? I'm confused.

  • I suppose the topic of the thread should have said "What platforms do you want Construct2 to run on, and what platforms do you want to be able to export to?"

    Obviously you cant run C2 on consoles, or xbla, and a browser.... that's just scary.

    Oh of course, that's the line of thought we're all on. The title of the poll is what platform do you want your games to run, not what platform do you want Construct to run on. So I'm assuming this is regarding porting ability first and foremost.

    If Construct is looking to grow and establish itself as one of the best, if not the best, Indie game development engine, then porting to consoles is an essential tool to provide. Torque is another engine that can provide this feature, as well as porting to Wii and iPhone, but charges between $100 - $1,500 depending on the number of porting licenses you're after.

    If Construct could start offering these porting capabilities too, then they can charge a competitive rate and share that market. I would happily pay for a license in order to port my games, and wouldn't expect those licenses to be free, even if the engine itself remains free-to-use.

    EDIT: Look at what has just been posted on Kotaku: http://kotaku.com/5647455/xbox-live-indie-clips-radiangames-inferno Xbox Live Indie games get a lot of press when they're made well.