Ashley's Forum Posts

  • You can't, there's no way to load textures from disk yet!

  • I'm not sure what you mean - have you looked at the SDK docs or the other plugins and behaviors that come with Construct 2? All the properties are right there in this.properties, available in onCreate().

  • #1 is done for the next build, but I don't think we should do #2, it's not a standard way of showing properties - shouldn't using groups be fine?

  • Not all fonts are supported by the Construct 2 editor. It doesn't matter though, because very few people who play your game on the web will have that particular font installed so it won't show anyway. Use Web Fonts instead.

  • This could be a very complicated feature to add to the platform behavior itself - it's already one of the most complex behaviors, and it currently does not care what it is standing on. For example, you could also stand on a single pixel, so by the same rule you can land on a very steep slope. I'll see if it's straightforward to fix the Platform behavior to drop down in this case, but it might not be, so it would be best to work around this with events or careful level design for the time being.

  • The images go in to RAM and also in to VRAM (graphics card memory) if the rendering is hardware accelerated, which it usually is these days.

    They get decompressed to the same size as the image saved as a 32-bit bitmap, so yes, a 1000x1000 pixel image will always take about 4mb of memory alone. This isn't much when both your computer and graphics card have gigabytes of memory, but bear in mind 4mb is still a lot for a single image on mobile.

    The various compressed formats just package the data in to a smaller filesize. Compressed images cannot be drawn though, so it's normal to decompress the images in to memory whenever they are loaded.

    We have plans for a feature to load textures layout by layout (like Classic can) somewhere on the todo list, to save memory with very large projects.

  • Eh, I'll add it to the todo list, but this one requires lots of fiddly changes all over the codebase.

  • More info in the FAQ.

  • Nice! Are you sure you don't want to give it more VRAM? Most cards these days have 128mb+.

  • I'm not sure I understand, can you explain what you're asking in more detail?

  • Oops, sorry. Fixed for next build.

  • There's no clear time to know when the preload has finished: do you count "finished" as "enough has downloaded to stream to end without stopping" or "all data has downloaded"?

    Since audio streams, it's best just to start the game without waiting for preloads to complete.

  • This is actually a bug which should be fixed in the next build.

    FIX] System 'Every X seconds' drifted off in accuracy over time, should be more accurate now

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Reproduce the issue in a new project which you can share. Otherwise we cannot help you.

    Also this sounds like it's most likely to be a problem in the iScroll plugin - I cannot imagine how any official Construct 2 feature would make a non-GET request to the preview server. Does iScroll POST or do any other requests to the current server? Anything other than GET is not supported by Construct 2's preview server.

  • SVN provides 'merge' functionality to combine changes if two people make conflicting changes. It's a normal part of source control. For example: one of you commits a new layout. There is a new tag in the .caproj showing it. The second person has also added a new layout and wants to commit. SVN won't let them commit because there are new changes to the .caproj from the other person, so it should force you to update first. When you update, you'll get a "conflict resolution" message: they have a different tag to the one on source control. It's pretty simple, you basically double click somewhere to say use both tags, and you're done. This is how SVN is typically used, there's nothing special about C2 here.

    Don't add .uistate files to source control. There is a comment in these files describing why:

    his is a UI state file - its content describes the user interface settings when the layout was last open. It is entirely optional and the project will load without it. If you are placing the project under source control, you probably do not want to add any .uistate.xml files to the repository.

    They just store what windows you had open last and stuff - it's just for you personally, and you don't want to share that information with the rest of your team.

    ill Construct 2 sometime implement a way for two or more people to work live in the same file (a la google docs)

    Probably not in the forseeable future - this is an extremely complicated feature to implement. We have a lot of other things to do, and in my experience SVN works really well for cooperating anyway.