Ashley's Forum Posts

  • First of all, some tips:

    • script didn't run at first because you don't declare 'i' and 'len' before using them in some places (remember C2 scripts run in strict mode)
    • don't use 'this.memberFunction = function(...' to make member functions. Add them to the prototype, e.g. 'behinstProto.memberFunction = function(...'. If you assign a function to this.memberFunction, each instance of the behavior gets its own copy of the function which wastes memory.
    • those conditions are pretty expensive O(n^2) - you might want to build in, or at least encourage users to use, some kind of timed update (like every 500ms, rather than every tick). IIRC the Classic turret behavior updates the range checks every 500ms.

    The main problem:

    You wrote in a comment "C2 will invert the picking automatically for us". It doesn't! It only inverts the result of the condition function (return true/return false). C2 has no idea what the body of your function does and has no control over it. The way you've written it, you pick objects within range to the SOL even when the condition is inverted. You have to handle inverted yourself in this case, which is done like so:

    // Get the inverted status of this condition
    var cnd_inverted = this.runtime.getCurrentCondition().inverted;
    
    // ...
    var i, len;
    for(i = 0, len = instances.length; i < len; i++)
    {
         obj = instances[i ]; // forum makes this italic if i don't put a space
         
         // 'xor' handles the invert flag
         if (cr.xor(this.withinAngle(obj.x, obj.y), cnd_inverted))
              picked.push(obj);
    }
    
    if (picked.length)
    {
         sol.select_all = false;
         sol.instances = picked;
         return !cnd_inverted;  // C2 inverts the result
    }
    else
    {
         return cnd_inverted;  // C2 inverts the result
    }
    

    A little explanation:

    XOR computes invert, because of its truth table. See:

    A = object met condition

    B = invert status

    A - B - Result

    0 - 0 - 0

    1 - 0 - 1

    0 - 1 - 1

    1 - 1 - 0

    So if you XOR your picking condition with the invert status, you'll pick it correctly for all combinations of object meeting the condition and condition being inverted. That's what I've done above.

    The next trick is remember C2 inverts the result of your condition function if the condition is inverted. If the event is inverted and we picked no objects, and return false, C2 inverts false to true (because it's inverted) and the event runs. Woops! So to counteract this, the returned value from the condition has to be inverted too. In other words, if nothing was picked, we want to return false if the condition was not inverted, or true if the condition was inverted - i.e., the invert flag itself. And vice versa for if we did pick objects.

    Hopefully that makes sense - once I made those changes to all three conditions, it seems to be working ok now!

  • Oops, 'spawn' only picks the last 'bullet' that was created. I've fixed for the next build - it'll pick all of the instances created, so all bullets are affected.

  • I've made one more shotgun fix for r51.2. Should be out today or tomorrow. Have another go then...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I didn't know some systems didn't have Arial installed. What OS and language are you using? If it works OK after loading anyway, maybe I can just remove that message.

  • If you crop each frame that you import, it will remove any wasted space. (You might need to wait until we have hotspots for this to work smoothly though.) Once each frame is cropped, AFAIK the download size is not much more than a sprite sheet and the VRAM usage is about the same as well. Modern graphics cards support non-power-of-two textures so there's no memory wasted by having lots of different frames.

  • We're working hard to get this and a whole bunch of other features in C2. Just hold on a while and we'll see what we can do!

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Closest thing I can think of would be renaming all your images to random strings and updating the references in the runtime.

    I'll do this in a future build. I don't think there's much to be gained by obfuscating the images themselves. While they would only need to be de-obfuscated on startup, it could pause for several seconds while it processes everything, and like Candescence says it doesn't stop the "printscreen attack". So I think just making it a little harder to track down images should be as far as it's sensible to go.

  • Hey, thanks for the feedback! Here's a few answers to some of your questions:

    -so what are the exact system requirements of c2 ?

    The only system requirement should be Windows XP SP2 or newer. I guess you got the error on a Windows XP SP1 machine. Perhaps you could check that and let me know? C2 uses several features only introduced in XP SP2 so it would be extremely difficult to support XP SP1 or earlier.

    tml5 performance isnt optimal.

    Firefox 6 (the latest), IE9 (the latest) and Chrome 14 (next one out in ~6 weeks) all have hardware accelerated rendering - so you should get very good performance with them. However, if you have an old graphics card or out of date drivers, the browser may fall back to software rendering which is slow. Make sure you have the latest graphics card drivers! In 6-12 months or so I imagine the majority of Internet users will be using a hardware accelerated browser.

    can you give some information what you expect to be last date of the first version of the .exe exporter somehow ?

    We honestly don't know what to say - we're stretched to the limit with finishing features in the editor and HTML5 exporter. Once that's done it will take more time to get an EXE exporter done if that's what we decide to do next. So I don't want to say anything in case anybody holds us to that!

    so can you please give some estimation on how the opengl exe exporter would run compared to cc on older hardware (for example p3 1ghz, gf1 or 2, athlon 1200 radeon 7k, 8k)

    would there be any fps loss to cc games or to other opengl games that run good on such hardware (e.g. idtech3, cs, or with dx ut2003) ?

    An OpenGL runtime should be equally as fast as the DirectX one (it's the graphics hardware that sets performance, not the API). OpenGL is much more compatible than DirectX though. You won't need any updates at all, for example. Most computers can run OpenGL without any modification at all.

    what would be the estimated system requirements (opengl version, drivers, os ...) ?

    Same as C2: Windows XP SP2+ (don't know about Mac, haven't looked yet), and OpenGL 1.1 which has been pretty much universal since 1997.

    how secure is my gamecontent exactly ?

    r51 obfuscates javascript so it should be nearly impossible to reverse engineer a HTML5 game on the web back to its C2 project. However, due to the nature of the web, your images all have to be uploaded to the server too. Copyright law is on your side though: in most countries, you do not need to do anything to copyright your work, it is automatically copyrighted to you, so it is illegal for anyone to copy and use your images.

    Hope that helps - let me know if you have any more questions!

  • So finally you can make full games with C2?

    Well, try the Space Blaster demo!

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post