Ashley's Forum Posts

  • That's a nice plan, GMG, and has been discussed before. That's definitely on the cards.

  • I'm always interested to hear ideas! I'm pretty split on the zero-based/one-based thing though. On the one hand, 1-based is the most intuitive to non-programmers. On the other, the math often works out better zero based (eg. looping to set object positions from an origin), and the rest of computing works zero based (and one of Construct's goals is to teach the basic principles of programming and logic). There's also that if we change it to 0-based in C2, it will create confusion for a lot of users moving over from C1. One thing's for sure though, that one standard should be agreed and everything should use it!

    Despite the initial pain I think moving to 0-based in C2 is the best thing to do. 0-based indexing is easy enough to get your head around, and is closer to how computers and programming really work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You could also try looking at the implementation of the system expressions in System.cpp:

    http://construct.svn.sourceforge.net/vi ... iew=markup

    The ExpRoutineTable array at line 436 maps the expression string (eg. "lerp") to the routine (&SystemObject::eLerp) - if you then search for SystemObject::eLerp (without ampersand) you'll find the implementation:

     3887 long SystemObject::eLerp(LPVAL theParams, ExpReturn& ret)
     3888 {
     3889 	// Calculate linear interpolation:
     3890 	// lerp(a, b, x) = a + x(b - a)
     3891 	double a = theParams[0].GetDouble();
     3892 	double b = theParams[1].GetDouble();
     3893 	double x = theParams[2].GetDouble();
     3894 
     3895 	return ret = Lerp(a, b, x);
     3896 }
    [/code:1y4dyv82]
    
    You can use that to find the implementation of any system expression.  Does that help?
  • There is no specific order of bug fixes other than really severe ones get quicker attention and obviously simple ones can be fixed quicker too. Some will probably never be fixed like the ELSE picking bug, because the engine simply is not designed to be able to do picking like people want there. Those should probably be closed off as 'won't fix' or 'postponed' (for C2). I've considered removing it, but that'd probably cause more problems than it fixes.

    There's still around 200 bugs open on the tracker and I doubt they will ever all be fixed. Parts of Construct are very old and not written well because we were still learning how to program when the project started! Those parts are extremely difficult to change.

  • The usual way is to have a sprite which you set the width to distance(gun.x, gun.y, target.x, target.y) and the angle to angle(gun.x, gun.y, target.x, target.y), which effectively draws a line between the two. (Note this does not reference the angle of the bullet at all)

  • Interesting to see a new game creator coming about, but it's still very thin on details of the creator application itself. The StencylWorks page now says it's directly inspired by Scratch - is that an edit since you guys saw it? Still, I'm a bit disappointed since I always thought of Scratch as being an educational tool or toy (no disrespect meant to the Scratch folk though, looks like they're doing a good job). Stencyl might fall in to the awkward system of having a rudimentary event system with scripting for everything else, like GameMaker (where I think the pros consider scripting the only decent way to make games).

    The games from a technical standpoint seem very simple and since I'm used to V-synced floating point scrolling, the Java scrolling looks pretty shakey to me. (if it's software rendered that's going to be hard to fix)

    The java/web-play system is cool and we don't have anything like that, but Multimedia Fusion does now, so I think they'll have a tough time persuading any MMF users to move over, especially considering how simple the games look.

    I still don't like their secracy. Their entire userbase is incredibly overhyped, so I wonder how much down-to-earth reviews they really hear.

  • That's a good summary, but the vertex stuff probably isn't worth worrying about. Vertices are actually only stored temporarily (they're re-sent every frame), not in permanent texture memory, so it works a bit differently. You only need to worry about textures.

  • Everyone chill! It's an important feature to have unicode, and it's especially crucial to non-English speakers, since it can be difficult or impossible to make a game in your native language without unicode support. Imagine trying to make a platformer for your friends in a program that doesn't support English, only Hindi characters.

    aolko, you do not understand how difficult it is to add unicode support to Construct. There are hundreds of thousands of lines of code, it's much more complicated than flipping a switch, and we only work on this in our spare time. So, in short, there will not be unicode support before Construct 2.

  • Construct 2 will be unicode; before then we can't really change it.

  • You need to use a naming convention to organize your global variables so you can do something like set global variable Gvariable&str(random(10)+1) to random(1). All your global variables you want to be included should of course have the same beginning then you use a number to tell them apart (eg. v1, v2, v3 etc). Remember to right click on set global variable prompt and choose "use expression" so that you can set the variable to an expression. When you start using naming conventions more, you may want to start looking into the text manipulator so that you can use the useful "replace" action. I'm sorry I can't post an example cap for you.

    I'm not sure that will work. I'd go with either a global array, or store a temporary value generated by random(), then have a series of subevents along the lines of: random value = 0, use global('abc'), random value = 1, use global('def'), etc. (Don't put random() in each line or it will generate a new random number for each line!)

  • Gah, I don't check the forum for 2 days and this happens!

    This is locked now and moved to Open Topic (it's not help/tech support).

    To clear up some of the discussion points:

    1) AFAIK Prof-UIS does not factor in to this at all, it's just a UI library which can be used in commercial apps too (don't know if Construct being GPL changes this, but I'd guess not)

    2) The GPL specifically states it is allowed, but pointless, to sell GPL software. Sure you can sell it, but you'll never get a high volume of sales, because you rely on the fact the buyers don't know they can in fact get it for free. Anyways, no issue with selling it here.

    3) The only grey-area issue is the bundling of tutorials, games and artwork from the forum. These are NOT automatically GPL covered as spelt out here, so there is no automatic permission to sell them. In many jurisdictions such as the UK, copyright is also automatic, so you are not required to explicitly state that the work belongs to you or is copyrighted to you for the work to be protected by copyright (eg. artist's paintings don't usually have 'Copyright (C) 2010 ...' in the corner ). However, since it could be argued only Construct itself (which can be sold) is being paid for, and the rest of the content is free on the internet anyway and simply supplied as a free add-on bundle, it becomes a bit of a grey area and I don't really know what the rules are. To be honest, the odd stray ebay auction is not going to get much attention if you complain.

    The issue of collecting up free games on the internet and selling them has been around for years, and it's pretty much a right of passage for an indie gamer to find some of their work suddenly for sale somewhere at some point. It's a well-known fact (or should be if people here didn't know) that this will happen. To protect yourself you essentially should just put your full credits (name, website, email etc) in your games/tutorials, a message saying it's freely available at such-and-such a URL, and maybe that if you paid money for it you got made. That should be enough to give the right idea to someone who paid money for it, and maybe clue them in enough to start looking for a refund. Leaving work empty of credits leaves it open to exploitation, and removing credits from a work in order to sell it is a much more serious issue.

    Hopefully that clears it up. To be honest, if you see anything else like this, just leave it. You probably can't stop it, and even if you do, someone else will. Start protecting your work.

    As for the response, I'd have hoped for more maturity. Vigilante justice is never a good idea, even less so vigilante justice before proof of guilt. Next time try to keep cool. I've specifically edited out a post inciting that the buyer's reputation be deliberately reduced; that's very poor conduct indeed. Please, never respond with dirty tactics or name-calling - it's important our community appears respectful and mature, and we're not doing a great job of that right now.

    Edit: In retrospect, I can't see if the product sold actually does bundle anything from the forums, other than comments from people here. Even if it does not, the point still stands, you should take preventative action in case.

  • The bug with collision masks not being right for animations should be fixed in the next build... are there any other problems?

  • I bet LMK has had that image for ages and just really wanted to use it

  • Hardware accelerated graphics cannot be stored in standard RAM, only VRAM. Construct already stores all textures PNG-compressed in standard RAM, and loads them in to VRAM when needed. The default is to load everything in to VRAM on startup, but you can set the texture loading to go layout-by-layout, so a large animation is only loaded in to VRAM when on that layout.

    Loading animations frame-by-frame is not really plausible - the time it takes to decompress a PNG from system memory then upload to the video card, done for every frame, would create a noticable delay. It'd probably totally kill the framerate; this is why Construct loads entire layouts in to VRAM as a minimum.

  • Ergh, I think Microsoft have released another security fix to the Visual C++ runtime which is breaking things again. This is really annoying. I'll see if I can fix the setup for the next build.