peopleFission's Forum Posts

  • Thanks very much for your effort and thoughts, Nimos, I will definitely look into your points about NWjs.

    Happily, the issue is not about the manipulation of the images once I have paths to them. All that stuff is solid, tested, and working. You see, while the game needs to know about large sets of images, it actually only uses a subset of them in the game. As it happens, I use an approach similar to one you suggested where I populate frames of a sprite with images from the user-picked files. All of this works 100% (notwithstanding another bug whereby Android doesn't render every type of jpg a person might have; only some - but that's a completely separate issue we can forget about for now).

    The issue at the moment is allowing the user to designate a folder full of pictures (a few taps on the screen); rather than having to pick every single image individually which might mean 900 taps.

    I can envisage a solution as a tweaked or expanded version of 'File Chooser'; or something done with javascript (perhaps presented to C2 as a plugin); or - and this is my hope - a solution that is essentially someone pointing out that I'm doing something wrong or perhaps directing me to an existing plugin or javascript module of some sort.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi copilot. There are many 3rd party file system explorers, galleries, art packages and so on. 'Folder + contents' access is not an issue at the android level per se (though I don't doubt for a second that the tech used to build such software was something other than embedded browser+HMTL5+javascript).

    I have questioned if maybe the browser/HTML5 environment in Android is somehow walled-off to a greater degree or in a different way that cripples arbitrary, user-approved file system access. This is the case in some respects, however, it shouldn't be a factor for my specific issue as the underlying access - ie. reading user-defined arbitrary files - is demonstrably a working feature; I just can't empower the user to pick a folder of files. By the transitive law, there's no security benefit to ruling out folders when a user can pick n files within one, so I just don't understand where the hitch is.

    It's as if it's an oversight in the way the file chooser object works; rather than an Android block. I don't know enough to actually make a conclusion though.

    I only really know two things at this point: my game is screwed if users can't designate their photos en mass for use in the game; and that I can't see a sound reason for this to be an actively made limitation of either C2 or Chromium or the Android file system object that 'file chooser' makes use of. To me, this suggests that there's an oversight somewhere OR room for a better plugin.

    I'm hoping for a kindly expert to straighten me out. I am baffled. The best I can do at the moment is let my players pick images from their photos one at a time. Users just aren't going accept that.

  • Are you saying with certainty I can't achieve this and that you know this to be a wilful design limit of the platform?

    I would find that bizarre in the extreme. I am not swayed by the reason being "security" (in fact I wonder if you yet fully understand what I'm asking as an arbitrary file can be selected; just not an arbitary set of files). "Security" as a reason is doubly ridiculous if the official 'more secure' alternative involves hosting files in farm under, for example, US law. (I'm not your average bear on this subject; my day job is infsec consultancy for international banks).

    I paid £80 for a Construct 2 license so that I could publish to Android. It seems a reasonable expectation that I could have the users of my software use their pictures in their games. If this is not possible - by design or otherwise - then I'll be seeking a refund from Scirra. Even as I type this, I am hoping someone might be able to suggestion a means by which a user can point at a folder. I was doing that in platforms from coverdisks in 1992. I wonder if perhaps I have somehow misrepresented my question. I'll go over what I've written.

  • Hi Newt. That's not the bit I'm having difficulty with.

    I can't find/create a feature by which a user can select whole sets of images at once by selecting a parent folder or being presented with some sort of 'select all' option.

    Imagine the user has 900 images in an arbitrary folder on their Android device. To use these images in my game the best I can do at the moment is let the user tick each image with the UI that the 'file chooser' object in multiple mode throws up. Thats a LOT of scrolling and tapping and ticking. It kills the game.

    I need to enable the user to select 'this folder full of images' or, if the file system is abstracted (which is a sad, regressive thing about phablet environments making people less computer literate than they were 10 years ago, in my opinion) enable them to select 'this set of images my phablet has wrapped up for me as a set'.

  • I'm struggling - in fact I'm totally stuck - trying to implement the following feature set:

    On Android;

    Allowing a user to specify an arbitrary local folder;

    Populating a struct with paths to each image file within (including subfolders);

    So that I can use the struct later to make 'load image' calls etc;

    And use the images in my game.

    I'm aware of the 'file chooser' object. This is fine for pointing at a single image, but I can't work out how to use it - or find/create an alternative - so that I can let a user point at a folder full of images. I can let the user select multiple files within a single folder, however this requires the user to actually select each file, file by file. The game is designed to incorporate hundreds of arbitrary/user-defined pictures, possibly from several disparate locations.

    My game stands or falls on my ability to implement this feature.

    Any help and all discussion appreciated.

  • Ah, a core issue here is - now knowing - that 'goto layout' creates a new instance of it; it doesn't return to the 'old' one.

  • It makes the situation a bit less inconvenient for certain types of object. It doesn't affect the architectural issue as a whole (I don't think - but I'm new!).

  • I have a very similar issue with frames of sprites that I populate with C2's 'load image from URL'.

    The sprite shows the frames no problem in C2 preview and the XDK simulator, but on my Galaxy S2 Android 4.1.2 or Nexus 10 Android 5.0.1 I merely get a black rectangle.

    The twist that baffles me is that my game logic later does maths on those frames and their dimensions and populates a data dictionary with values. All that logic takes place and I can verify that the values are measured correctly based on knowing the image that was loaded into the frame.

    It's as if the final hurdle of drawing the image fails. I thought it was perhaps an issue with the browser that wraps round my build (is that what Chromium is?) but maybe its further upstream ?

  • Argh, my issue is a result of code required to mitigate the bugs with Touch object. One has to code manually to debounce it (necessarily using a global variable) or touch-triggered events are triggered multiple times.

    For the case where I want to restart a layout (new game) I can debounce in a diff way, using button UI visability (this isn't always possible when managing touch events using multiple instances of identical sprites).

    However this has revealed to me that what I'd really like is a new variable scope: layout variable. Or at the very least, to be able to set local variables for root events instead of globals.

    There's no method to create a new instance of a layout; only a reset. This means one is almost always going to require a global variable reset to achieve a meaningful reset of the layout. So for the common situation where you need certain values to persist that can't be implemented as constants before the user makes choices (eg, number of players) one will have to use a data dictionary or something. I mean that's fine, but a) one won't know this at the design stage and b) its very inelegant, and begs the question, "why not use a data dictionary for everything that needs to persist?"

    Not only that, but the likelihood that you'll need to reset global variables in order to meaningfully achieve a layout reset means that other layouts are necessarily affected, further forcing me to use a data dictionary for anything I need to persist. Surely that can't be considered optimal at any stage, design, code or run time?

    This status quo implies the following issue I don't even have a solution for: how do allow a player to back out from a game into a menu, then start a new game? I can only code for a 'go to layout' action from the menu, which gives no option to reset the old state; and there's no event for 'on layout changed' to use as a basis for triggering a reset.

    It seems to me that I am currently forced to manually include data dictionary storage and instance management for pretty much every aspect of every layout I might ever need to reset the state of. Please tell me this is not the case and I am a lunatic!

  • Thanks for the additional info. I'm not asking this out of total inefficacy; but because my muddle indicates that there might be some fringe cases where these obvious/stated/implied aspect of restart layout are contradicted. I need to check it's not me screwing something up, and yet fully expect to find that is.

    So the other things I need to check-

    What of the local variables for events on the layout being restarted; and for layouts included?

  • I read the manual.

    All globals, or just the ones initialised in the layout being restarted? Does this include globals initialised in 'included' event sheets?

  • I got in a muddle. Can a kindly person clarify the precise nature of "Restart Layout" for me, please?

    So when within a layout that:

    1) has an "Includes" definition referencing an event sheet with globals and global constants an events with instance variables;

    2) has global constants;

    3) has global variables;

    4) has events with instance variables (and is deterministic such that multiples new instances of things will be created, meaning even more instances if the previous processing of the layout leaves it old stuff behind to whatever degree);

    Which of these categories/subcategories will be affected/changed/reset?

    I'm actually worse off for the simplifications in this case: please give me the real deal.

    Thanks folks.

  • I think this is a great question, respectfully and fairly put.

    I am 150 hrs into my first C2 project and while I am really positive about C2, deployment to android is inelegant to say the least, and the performance of the Intel XDK output just isn't fit for purpose (I've been trying for three days to get 'missing' images rendered in production even though the game runs flawlessly in C2 and the XDK emulator [simulator]).

    I'd really appreciate reading/knowing more about C2's roadmap in this area and the views of the veteran developers.

    EDIT: Just realised, this is more of a question about C3, I guess!

  • I might be having problems similar to yours, notnsane, though it's hard to say.

    My game uses the sprite object 'load image from URL'. The files are actually local to the project, a handful of imported jpgs. Everything works fine in C2. The images are found, loaded and rendered immediately when they should.

    I export as Cordova and load the project into Intel XDK, where everything is present and the game runs fine and the images load on all the emulated devices I tried.

    I build the apk and install on my S2 and Nexus 10. The images are never shown. No corruption or placeholders or anything, just an absence of the images where they should be clearly present.

    This is my first project of maybe 200hrs; just bought the £80 C2 license (with intent to deploy to Android). Kinda pissed off (not that I hold C2 directly to blame (notwithstanding the absence of a native export-to-apk feature)).

    Extra bit of history: at first the images didn't show in the XDK emulators either, just C2, but I tracked that issue down to how I was forming the URL for the images. In C2, using "\" to prefix the filename (as per many - though not all - standards) was handled properly. Intel XDK didn't like it. I do wonder if there's some sort of magic I need to wield, path/filename wise for the apk version.

  • Been tinkering for a few hours.

    I'm pretty sure the answers are:

    1) All resizing/rescaling uses the original loaded image raster or original frame raster each time.

    2) No, original rasters of loaded images and frames are not affected by making changes in other frames.

    But my answers are based on visual inspection (using images that should give the game away).