CJK's Forum Posts

  • Thanks so much, Ashley !

    I have a crazy time this week, so I'll probably do it during the weekend.

    All the best,

    Greg

  • Hello,

    I came up with an issue about paths in NodeWebkit infterface, but I'm not sure if this can be considered a bug, or maybe I'm just doing something wrong?

    When you query NodeWebkit plugin about the User Folder / Home Directory path, on Windows, your'e getting something like:

    (Win8 output)

    \Users\UserName

    The problem is, it does not contain drive name! So, when I run the application *with unpacked resources* (= with package.nw unpacked and deleted), this is the only case when the app actually runs from within the folder where I call it from. Now, when I call it fro D drive (or any non-sytem drive), any calls to user folder end up referencing the local drive!

    This effect is invisible in preview, it is invisible when running the app right after export, but it persists if you use unpacked resources (as I do, having 300Mb+ of audio/graphics). In a "typical" case the NodeWebkit will first unpack package.nw to a temp directory on a system drive, so the problem will not be visible either.

    Any suggestions on how to deal with it? The only idea I came up with is checking if 2nd character in path is ":", and if not, add "C:", but that would be hard coding, which is a bad idea anyway :-(

    Thanks for all suggestions,

    Greg

  • Hi,

    I think you might want to use some shuffling or helper storage, to avoid getting into the same room twice. Two ways (there are certainly more):

    1) create array of size 250

    2) fill it with consecutive integers

    3) shuffle random pairs of a hundred or more times

    4) make the player go from room to room, according to the (shuffled) order of elements in your array.

    Way #2:

    1- draw random integer as in examples you've seen above

    2- if integer is already in the helper container (#3 below), repeat drawing

    3- store the number in a helper array/string etc

    4- proceed to the selected layout

    Hope it helps,

    Greg

  • ays I need to buy a license. I am guessing there is no way around that?

    Node Webkit is free to use, independent of C2 - you can grab it and manually package any HTML5 app into a NW package - Construct2 simply does automatically for you all the tedious setup work ;-)

    Considering the ratio of incredibely useful features to a very reasonable price, I'd say it's better to buy a license for C2 than to waste time with manual export to NW ;-)

    Cheers,

    Greg

  • Hi,

    One difference might be that the preview does not use compressed data.

    Have you tried checking the speed with uncompressed data in the exported package? Just unzip your .nw file (and delete the .nw), and see if it makes any change.

    Greg

  • Hi randy70,

    For me, rexrainbow's CSV plugin works *like a charm* - I've been using it for over a year to load the kind of data you've mentioned, and I'm not gonna look anywhere else ;-). [Thank you, @rexrainbow !]

    This + ajax gives me a huge flexibility - all configuration in external data files, whether over the web or in nodewebkit.

    Take a look at the examples that you can find on rexrainbow's pages - this should give you a headstart.

    Good luck,

    Greg

  • -1 to this idea.

    Please do not enforce further auto-packaging of the EXE for everyone using C2 ;-(

    You can achieve such effect with some external exe compressing tools, I believe. Or with any installer - INNO setup, NULLsoft installer etc.

    The way NWKit works right now, is - from my perspective - really comfortable - you can unpack the package.nw (which is a ZIP file anyway) and have direct R/W access to your assets at runtime, without any issues.

    Does it matter? It does when you have 300Mb+ of audio/images. Running the app with a compressed set of assets adds a big couple of seconds to the startup time - annoying on slower machines. And much easier with updates, at least at dev stage.

    Cheers,

    Greg

  • Hi,

    Create the sprite at design time to ensure the width is available for the engine; otherwise, try waiting until the next tick, when all created sprites are available for the engine.

    <img src="http://clevergames.pl/downloads/c2forum/create-width.png" border="0" />

    Cheers,

    Greg

  • Hi unplugged

    As I once had a need for this, too, I just tried a more visual approach, where the neighborhood is determined by a collision area of a shape.

    pick_dense_neighbourhood.capx

    Cheers,

    Greg

  • Interesting!

    Does it mean we can hide/skip the Ludei splash screen with it?

    Greg

  • Hi,

    I have been confused by this on several occasions, where I could not understand the source of surprising misbihavior of my apps.

    It's not just textboxes - I use heavily CSV files as input, and keep bumping into this ;-)

    If a variable is a number, I would say it should automatically attempt to cast an assigned value onto a numeric value.

    Greg

  • Hi,

    144 had Node-Webkit export broken. I read that 144.2 had it fixed.

    I'm running 143 and here fullscreen works both in preview and in export.

    I mean Browser's "requrest fullscreen" function, as I haven't tested the recently added Node-Webkit init flags that control the window layout - maybe you mean these?

    Cheers,

    Greg

  • verything works again!!

    Not everything, I'm afraid.

    Node Webkit export behaves differently. My app does not start at all with the new NodeWebkit, after export. I wonder whether somebody else experienced the same with r144?

    Cheers,

    Greg

  • Hehe.... Mine was 270Mb, so I started compressing OGG to lower bitrates - going down from 192 to 96 saved me over 120Mb so far. ;-)

    Cheeers,

    Greg

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi,

    As far as I understand the system:

    1) You can import graphics of any size, and resize it in image/sprite editor - the change is irreversible, and the resulting size will determine the memory requirements of the sprite, the performance and the quality.

    2) You can import e.g. a larger graphics and resize the instance size in Construct window/main editor. This change is reversible - it is just scaled in viewport, and this change, as far as I understand, has much smaller influence on the performance. If you scale down the sprite this way, it still takes all the memory required by the real size of the image (=the size in the image/sprite editor), but as it is smaller on the screen, the processing of each frame is faster.

    Cheers,

    Greg