Colludium's Forum Posts

  • Interesting - — bremen I'm sure that's how it's supposed to be done now you mention it!

    I've always used on-start-of-layout : show banner ad and then refreshed it using every-45-secs : refresh-banner-ad (ie I have never bothered with the preload call). This now makes sense because I sometimes don't see the first ad displayed right at the start of the layout.....

  • bremen, I've got a dumb question for you - so apologies if this appears to be patronizing! Have you set up to refresh your banner ad in the events every - say - 30 secs? I also find that my ads are very quick to appear over wifi but might take a bit longer over mobile network.

  • baodingball,

    I know - it's all a bit confusing at first, but you'll quickly pick things up I'm sure. I think you should be using Webstorage link to Webstorage in Manual rather than Node Webkit (maybe the word Web is confusing things here) if you're using a browser or wrapper on mobile. To keep things easy to read and understand in your event sheet, I suggest you first load the array into a string variable and then save that variable to Webstorage. Then, on game resume you do the reverse - load the Webstorage string into a variable and then load that into the array. You've already got the basics, looking at your event sheet, but the node webkit isn't going to work for you here.

    Something like this:

    On game end:

    1. Set MyVariableString to MyGameArray.AsJSON

    2. WebStorage: set local value ( Key: "SaveData" , Value: MyVariableString )

    On game resume:

    1. Set MyVariableString to WebStorage.LocalValue("SaveData")

    2. MyGameArray : Load (MyVariableString)

    In my limited experience I've had no problem using this technique to save data on android and ios using cocoonjs and phonegap (and, I think, Intel XDK as well - the old one, mind, not Crosswalk which I haven't tested extensively yet).

    I hope this helps - let me know if it's not clear!

  • digitalsoapbox - I totally agree with how great C2 is and I know I'm being a bit picky by mentioning these little things... And your point about this sort of thing happening with other software is very valid. It's just that C2 is so nearly perfect....

  • digitalsoapbox,

    To answer your questions:

    1. This plugin allows the sprite font to be displayed correctly in the editor, as described in the first post. That is the only real benefit to using this over the native one that I can see and was the reason why I started to use it. I know that the array/JSON technique works just fine - as per the tutorials etc - I don't really understand why you asked the question and think you maybe missed the point of the plugin...?

    2. It's not the end of the world for me, but it would have been if I had spent the last 3 months using this plugin throughout my project.... My point about 3rd party plugin support is about my concern that a critical plugin might get broken by a C2 update. If you've spent months on a project and then it's trashed by scirra's lack of support of these plugins - well, that's not a good thing! I am not saying that spritefont+ is necessarily one of these plugins, but this is just an example of the risk anyone takes by using a 3rd party plugin with C2. Of course multiplayer is going to be great...

  • +1 for making this the default way of handling sprite font.

    Also, r164 has completely broken this plugin - if I preview a game that doesn't even use it I receive a host of javascript failure messages (removing the plugin and it runs fine) .

    And I would just like to add that this breaking of perfectly excellent plugins is the reason why these features should be incorporated into the main program instead of being left to 3rd party developers to sort out. Thread drifting rant over... Happy now....

  • Thanks Ashley!

  • TiAm,

    When I turn off WebGL on my 'little test' the draw calls cpu use for drawing the 99 instances of an object goes up to the same amount as required to draw the 99 different objects. Although I was generally aware of this principle before I must confess to being surprised that WebGL was so beneficial. If I get the chance later I'll try this on mobile chrome and see if there's any difference on a mobile browser.

    So, if there will be no WebGL in the final product then there's nothing to be gained by going through the pain of trying to minimise the number of individual objects in a project - the only thing that can save cpu demand here is, as was already apparent, minimising the number of objects on screen.... Which is interesting to me because I already find that just by enabling WebGL on my old laptop (only 6 years old) the performance can sometimes become a bit choppy. So my personal policy has been to avoid WebGL when designing for a market that could be using older hardware.

    Thanks —, some good advice there as always.

  • In the Touch object, select mouse input to Off and give it another go. Certainly with phonegap you get double triggers if the mouse input is enabled and I suspect it's the same here as well (I haven't the time to test it through to completion using the xdk). I only use the mouse input for debugging on my computer....

  • Here are some results from my testing this....

    So, I made a quick demo. There are 2 layouts, each with 99 custom movement objects of the same image bounded to the screen by obstacles. Layout 1 has 99 different objects while Layout 2 has 99 instances of the same object.

    Draw Calls results:

    99 different objects: 5.8% cpu

    99 instances of same object: 2% cpu

    Now.... when I delete half of the objects on each layout:

    50 different objects: 3.8% cpu

    50 instances of same object: 2% cpu

    So there is quite an overhead for drawing different objects v the same object and a constant and significant minimum overhead on my computer at least for drawing anything on the screen. I didn't have the energy to create different images for each object to see what, if any, that sort of change might make on the draw calls. So, for my laptop at least, although the draw calls demanded 3 x the processing power to draw the different objects, the increase was still only 4% in magnitude - not a problem for most desktop games I am guessing, but such an increase could cause a slow down on a mobile device.

  • I started with Assembly on my old Commodore 64. That was terribly long winded - as soon as I found out how hard it was to simply make a sprite move across the screen I pretty much gave up!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think you're a bit confused about Node Webkit - that is a wrapper to create stand alone versions of your game for Windows / OSX / Linux - as an export option it's got nothing to do with android or saving data!

    That aside, at the bottom of the Array page in the manual is the AsJSON expression - use that to return the contents of your array as JSON format, which you can then save using webstorage. If you want to load the array from webstorage, load the saved string into the array using the Load expression. Have a search of the tutorials for these features and you'll be able to find some examples of how to do this.

  • vtrix,

    It would be interesting to compare the performance gains / losses between using 1 instance as you say and using dozens of different instances. Without having tried it (yet) I imagine that there's a trade off where the performance gains of one way will eventually out weigh the gains of the other - such that a given layout style and number of sprites will have a range of number of instances that will give an optimum performance. I also am not sure exactly what draw calls are - are they only measured in the debugger profile page or do they also have an impact on collision checking and are indirectly measured in the event analysis?

    I have a couple of embryonic games I'm working on - the intention is that I will ultimately release them on mobile and desktop, providing I can keep my focus (!), so I frequently test them both export options. Even for my most visually demanding scenes I don't see the draw calls using that much of the cpu time (up to 20% of the total cpu demand), so I simply don't worry about it yet. I frequently see that events associated with collision checking and sprite control are the most demanding so they get most of my attention...

  • —, perhaps a little too harsh with the "your second language grammar is not as good as mine" banter.... How do you know he wasn't trying?

    Ribis, as answered above - you're much better off keeping your objects and behaviors as separated as you can. It will make your project easier to understand when you look at the event sheets and will make behaviors and instance variables much easier to manage.

  • STARTECHSTUDIOS & Juryiel - those are both very interesting solutions to the Unity code writing nightmare. I think you've both found me something to tinker with over the next couple of weeks as a means to avoid working on my C2 game, which I'm feeling a bit bogged down by... I tried Playmaker a while ago and, as will all things Unity, that seemed quite complicated but also quite a comprehensive solution to the 'I don't want to learn code' issue. Maybe one of these are what I've been searching for...