fisholith's Forum Posts

  • Problem Description

    Overview

    In r262 and earlier, Crop mode behaves as expected, but from r263 and onward Crop mode behaves quite strangely in fullscreen, at least on my computer.

    It seems like in r262, "Centered" and "Crop" both act like a "Crop"; and in r263, "Centered" and "Crop" both act like a "Centered".

    (See below for screenshots of the effects described.)

    Details - r262 and before

    In r262 and earlier, the action Browser > "Request fullscreen - Stretch (crop)" mode did no scaling of the game visuals when the window size changed or went full screen. Instead the game visuals stayed at a fixed scale, and the changing size and shape of the window would simply reveal more or less of the layout.

    Also in r262, the action "Request fullscreen - Centered" seemed to produce exactly the same effect as the "Stretch (crop)" action. Though if I understand correctly this was not how "Centered" was intended to work.

    Details - r263 and after - (Where the possible bug began to appear)

    In r263 the fullscreen "Centered" mode was updated to behave as originally intended, such that the game would be rendered unstretched in an "Original Window" sized rectangular area in the center of the monitor, and the surrounding area would be filled solid black.

    However an unintentional change may have also occurred in r263, as now the action Browser > "Request fullscreen - Stretch (crop)" also started behaving like the newly updated "Centered" mode.

    So the "Stretch (crop)" action no longer fills the screen with the unstretched game, but instead restricts it to render only in an "Original Window" sized rectangle surrounded by solid black.

    Additionally, when in fullscreen Crop mode, the System object's WindowWidth and WindowHeight expressions return the width & height of only the "Original Window" sized rendered area.

    (Conversely, when in fullscreen Crop mode in r262, the WindowWidth and WindowHeight expressions would return the dimensions of the current screen resolution, as the game would fill the entire screen.)

    Attach a Capx

    https://www.dropbox.com/s/azvikt5jc23j2kf/r262%20r263%20Crop%20mode.capx?dl=1

    Description of Capx

    This capx makes it easier to test out what I describe above.

    It demonstrates the Browser action "Request fullscreen - Stretch (crop)".

    Controls:

    Mouse:

    Left Mouse = Fullscreen.

    Right Mouse = Exit Fullscreen.

    Middle Mouse = Exit Game.

    Arrows: Move player / camera.

    Images of the capx:

    r262 Windowed, just for reference:

    r262 Normal fullscreen Crop behavior:

    r263 Strange fullscreen Crop behavior:

    Steps to Reproduce Bug

    Run the capx.

    Left click in the game.

    Observed Result

    r263 Strange fullscreen Crop behavior:

    (Note that the updated "Centered" mode in r263 looks identical to this new behavior.)

    Notice that the WindowWidth and WindowHeight readouts are showing the values of the default original window size.

    Expected Result

    r262 Normal fullscreen Crop behavior:

    (Note that in r262 "Centered" mode looks identical to this.)

    Affected Browsers

    • NW.js: YES
    • Chrome: YES
    • FireFox: YES
    • Opera: YES
    • Iron: YES
    • Internet Explorer: (Doesn't go fullscreen at all, probably because IE is IE.)

    Operating System and Service Pack

    Win7 x64 - Pro

    SP1

    Construct 2 Version ID

    Release 265 (64-bit)

    Built at 17:20:47 on Oct 15 2018

    265 Release Notes

  • Thanks for the quick reply! :)

    So I just tried changing the action from,

    "Request fullscreen - Centered"

    to,

    "Request fullscreen - Stretch (crop)"

    (Looks like this now)

    (Tried posting the image several times but it doesn't show up, so linking instead.)

    i.imgur.com/nLuE9q1.png

    but I get exactly the same issue, an original-window-sized rendered area with solid black fill out to the edges of the monitor.

    I got this testing in both r263 & r265 just now.

    After that, I rolled back to r262, to see how the "Stretch (crop)" would work there, and I get the behavior I'm used to, where the game fills the screen.

    So it looks like the fullscreen actions "Centered" and "Stretch (crop)" both do the same thing, at least on my computer. In r262 they both make the game fill the screen, and in r263, they both make the game stay window sized and black-fill the rest of the monitor.

    I tested in NW, Firefox, Chrome, and Iron. I also tried disabling my second monitor and re-testing, just in case that was somehow involved, but there was no difference when using 1 monitor or 2 monitors.

    Updated capx:

    I updated the capx to use the "Stretch (crop)" action:

    dropbox.com/s/wn1h3d2lqwcvwbh/r262%20r263%20Crop%20mode.capx

    Just noticed something:

    Is the "Centered" action actually supposed to do the centered window and black fill that I'm seeing in r263? That would make sense going by its name. The problem I'm running into is that "Stretch (crop)" is also doing the same thing in r263.

    It seems like in r262, "Centered" and "Crop" both act like a "Crop"; and in r263, "Centered" and "Crop" both act like a "Centered".

    Is it possible that's what's going on?

    I could also be overlooking something, so I don't want to get ahead of myself.

    Is there anything else you can think of that might be worth testing?

  • Hey there Ashley, I don't want to bother you, but I was wondering if you had any suggestions regarding this change in Crop mode functionality.

    I'm not sure who else to ask, since I believe this change occurred between r262 and r263.

    Overview:

    In r262 and earlier, Crop mode behaves as expected, but from r263 and onward Crop mode behaves quite strangely in fullscreen, at least on my computer.

    One way to describe it is that it doesn't actually go fullscreen, but instead just stays the default window size and blacks out the surroundings.

    Example capx:

    This is a capx that makes it easier to test out what I describe below.

    dropbox.com/s/azvikt5jc23j2kf/r262%20r263%20Crop%20mode.capx

    If you preview it from C2 version r263 or later you'll see the strange fullscreen behavior.

    If you preview in r262 or earlier fullscreen works as expected.

    Example capx - Images:

    r262 Windowed, just for reference:

    r262 Normal fullscreen Crop behavior:

    r263 Strange fullscreen Crop behavior:

    Notice that the WindowWidth and WindowHeight readouts are showing the values of the default original window size.

    Details:

    In all my games, I've been setting the property "Fullscreen in browser" to "Crop" mode.

    Up to r262, Crop mode did no scaling of the game visuals when the window size changed or went full screen. Instead the game visuals stayed at a fixed scale, and the changing size and shape of the window would simply reveal more or less of the layout.

    So going fullscreen in crop mode, would just show more of the layout, and the layout would remain at 1x scale. (Or whatever scale it was at prior.)

    From r263 onward, Crop mode still doesn't adjust the game's scale when the window size changes or goes full screen. However now, when a game enters fullscreen, the new area revealed by the expanded "window" is solid black.

    As a result, the game is only rendered in a centered rectangular area, with the dimensions of the "Original Window" width & height, and it's surrounded by solid black out to the edges of the monitor.

    (By contrast, in r262, the game would be rendered out to the edges of the monitor, with no black letterboxing.)

    Additionally, when in fullscreen, the System object's WindowWidth and WindowHeight expressions return the width & height of only the rendered area, which as mentioned above is the "Original Window" width & height.

    (Conversely, when in fullscreen in r262, the WindowWidth and WindowHeight expressions would return the dimensions of the current screen resolution, as the game would fill the entire screen.)

    Possibly related:

    The only thing I can think of is that it might somehow be related to the fullscreen 'Centered' change in r263.

    "Browser: Request fullscreen 'Centered' incorrectly did 'Letterbox scale"

    scirra.com/construct2/releases/r263

    Otherwise I'm not sure what caused the change in the Fullscreen Crop behavior.

    Anyway, if you get a chance, I'd be interested if you have any thoughts, or questions.

  • Yes, dop2000 has a good suggestion there, and of the two solutions that's more elegant, as long as you don't need the enemies to spawn for some other reason.

    The main difference between blocking new enemies from spawning, and randomly culling excess enemies, is how the enemies will be distributed in the play area.

    Random culling

    If you randomly cull enemies, they will uniformly thin out as more are spawned, so that on average there will be a higher density near their spawn point and a lower density near the player, (which I assume they move towards).

    Hard Spawn Limit

    If you block new enemies from spawning, then a hole in the enemies will appear around the spawn point as they stop spawning, and the density of enemies near the player will stay unchanged.

    Feathered Spawn Limit

    There's also a sort of hybrid approach to limiting enemies, that might give you the best of both options, no culling of existing enemies, but with a smoother distribution of enemies.

    If you want enemy spawning to thin out as you approach 350, so that they don't just stop spawning abruptly, you can randomly "feather" off the spawn-success-rate of the enemies as you near the limit.

    For this you need a "soft" limit like 300, above which the thinning out begins

    When an enemy tries to spawn, it will always succeed if the count is under 300, but if the count is over 300, there's only a random chance it will succeed.

    This success chance will fade from 100% (when the count is exactly 300), down to 0% (when the count is 350).

    So for example, at 325, half way from the hard limit (350) to the soft limit (300), the chance of success would be 50%.

    at 340, which is 20% of the way from the hard limit (350) to the soft limit (300), the chance of success would be 20%.

    To do this, find the event that spawns the enemies, and try adding the following condition,

    Compare to general values (found in System object):

    random( 300 , 350 )

    is greater than

    Enemy.Count

    Now an enemy will only spawn if this random number between 300 and 350 is larger than the current enemy count. The larger the enemy count the less likely the random number will beat it.

    So, if the count is 325, the random( 300 , 350 ) has a 50/50 chance of beating it.

    If the count is 350, the random( 300 , 350 ) can never beat it.

  • Hey greenleafvt, :)

    To do path finding, you could do regular 2D path finding on a top-view standard grid model of your isometric world.

    e.g. If you're isometric world is a 3x3 grid (viewed isometrically of course) with the center grid cell filled by a house, then the 2D model would be a 3x3 grid with the middle cell marked solid.

    ░ ░ ░

    ░ █ ░

    ░ ░ ░

    This gets trickier if you have overlapping walkable terrain, like a bridge with an underpass.

    Even so, you'd still want to look for a solution that does path finding in a simplified model of the world, rather than isometric space itself.

    Depending on how your isometric world data is stored, the raw data may already be in a simpler 2D grid format, in which case you may be able to use that directly.

  • Hey again imothep85, :)

    There is a condition in the System object called "Pick Random Instance".

    You could use an event like:

    If enemy count is over 350, pick a random instance, and destroy that enemy.

    Remember, all your events only run once every tick (once every frame).

    So, this event will only destroy a maximum of 1 enemy per tick (per frame), and if you're creating enemies faster than that, they will still pile up.

    To make sure you always destroy enough enemies to get back to the limit, you can add the "For" loop condition, found in the System object. This will repeatedly trigger the same event several times in a row.

    Set the Start index to 1, and End index to the current count of enemies minus your limit (350).

    If you have 354 enemies, then the For loop will start at 1 and count up to 4, (350 - 354 = 4), re-triggering the even each step.

  • Hey imothep85, :)

    You can use a global variable to keep track of whether the item has been created yet, and then randomly try to create it each time a new level is started, but only if it hasn't been created yet.

    e.g.

    Create a global variable named "isRareItemSpawned" with an initial value of "0".

    "0" means "not yet".

    "1" means it has been spawned.

    Use an event like the one below to spawn the item:

    Event:

    At the beginning of a new level,

    If isRareItemSpawned = 0,

    Compare two values, is "random( 0 , 100 )" less or equal to "2". (don't use quotes)

    Action:

    Spawn the item somewhere in the level.

    The "Compare two values" condition can be found in the System object.

    The "random( 0 , 100 )" expression will create a random number between 0 and 100, so it has a 2% chance of being less than 2. That's 1 out of 50. If you want to make the item even more rare, you can instead use 1, for 1%, or 0.5 for an even smaller chance.

    Hope that helps out. :)

  • Any thoughts on what's going on here?

    In my game, I use the Browser object to request Fullscreen in "crop" mode, and in all C2 versions from r262 and earlier this worked as expected.

    In r263 and all later versions, Fullscreen in "crop" mode acts much differently, or at least it does in my game, and a few test projects I made to check that it wasn't just my game.

    Image 1: The game in a window, before going Fullscreen:

    Image 2: The game in Fullscreen "crop" mode, as previewed from r262, working as expected.

    The rendered area extends to fill the entire screen. The apparent scaling I'm doing in events.

    Image 3: The game in Fullscreen "crop" mode, as previewed from r263.

    The rendered canvas area remains the same size as the non-fullscreen window, and the rest of the monitor is just filled black.

    The blocky pixelation is occuring because my game's events expect the scene to be scaled up in fullscreen mode, and there's a post-process pixilation shader that gets likewise scaled up to match it. In this case though the larger "fullscreen" pixilation is being applied to the window-sized scene, which hasn't actually been scaled up, due to the new Fullscreen "crop" mode behavior.

    I saved the game in r265, and I now get an error when openning the project in r262. With the Fullscreen issue, I'm not able to work in r263 and beyond at the moment.

    Is there a way to manually edit a project's xml data to allow it to open in an earlier version of C2?

    I've made nearly no edits to the project in r265, so I think there shouldn't be too much worry about backwards compatibility.

  • [SOLVED]

    Wow, okay so I got the latest version completely working again, and it's got to be one of the weirdest issues I've ever encountered, with an equally weird solution.

    Firstly, thanks dop2000 for your awesome suggestions, especially the JavaScript console error log, as the errors got me looking at the files, which in turn is how I finally noticed that weird missing/blank "Date Modified" meta data, and that was (for some reason) the key to the whole thing.

    So here's a breakdown of the problem, the cause, and the solution, in case this info manages to help anyone else out of the same weird predicament.

    Short version:

    Problem

    Error on previewing game. "Failed to execute 'drawImage' on 'CanvasRenderingContext2D'"

    Also Javascript console has tons of "Error loading image" errors.

    Cause

    Image files in project folder are glitched, such that hundreds are missing a "Date Modified" value.

    Solution

    Use a program to force all glitched files to have a "Date Modified" value.

    I used a freeware program called "Flexible Renamer" to set their "Date Modified" values to match their "Date Last Accessed" values.

    After this the game previewed and loaded with no problems. :)

    Detailed version:

    Problem

    My game project opens in the C2 editor with no apparent problems, but when I try to preview the game, it starts loading, and before any imagery appears, it freezes and pops up the following error message (previewing in NW.js or Chrome or Opera):

    So what I gather is that somehow the metadata for about 1000+ files got glitches so that only the "Date Modified" field was missing.

    This seemed to be mainly asset files, like images and audio. The xml files were unaffected.

    Javascript error!

    Uncaught InvalidStateError: Failed to execute 'drawImage' on 'CanvasRenderingContext2D': The HTMLImageElement provided is in the 'broken' state.

    http://localhost:50000/preview.js, line 1900 (col 11)

    Alternatively, when previewing in Firefox, I got this less informative version of the same error:

    Javascript error!

    NS_ERROR_NOT_AVAILABLE:

    localhost/preview.js, line 1900 (col 0)

    (image: i.imgur.com/q3cnVDg.png)

    When I looked at the JavaScript console (I used Firefox) to see what errors had been recorded in the background, I found hundreds of

    "Error loading image" errors logged, essentially one error for every image in the game.

    Error loading image 'http://localhost:50000/enturretradius_os-default-000.png':

    (image: i.imgur.com/UPn8vP7.png)

    First attempt to fix it

    So, I tried replacing the "loading-logo.png" image with an older copy of my game.

    Now when I previewed the game, The logo image appeared, and there was no error popup, but the loading bar under the logo was red, and it only partially filled before freezing.

    (image: i.imgur.com/qx7eFcq.png)

    Checking the JavaScript console, the same procession of "Error loading image" entries were logged.

    (Though I suspect that there was probably previously an error for the logo image that was now resolved.)

    Cause

    In Windows Explorer, I went to inspect the actual image files that were failing to load.

    The "unloadable" images could be opened and viewed with no issues, but they were bizarrely all missing a "Date Modified" value.

    In Windows Explorer, the there was just blank space in the "Date Modified" column for those files.

    In the file properties the "Date Modified" entry was just "12:00am" with no day, month, or year.

    Weird.

    I'm not sure how or why these files eneded up like this, but I'm wary that it might be a hard drive problem.

    Backup your stuff to be safe.

    Solution

    The ugly solution:

    First I tried overwriting all my images with copies from an older version of the game, and this did kind of work, as I got far fewer errors in the java console. I'm pretty sure that if I'd replaced them all it would have allowed the game to launch, but it was an ugly solution, because I had changed the names of some of the objects (changing their image names), and I had new objects and images, and some images I'd edited. So overall, I'd have a lot of extra work getting this horrible hybrid of my new and old project back to a fully up-to-date state. I ultimately decided not to go this route, and instead worked out the good solution below.

    The good solution:

    It turns out it really is just the "Date Modified" value that needs to be fixed for the unloadable files.

    I use a freeware program called "Flexible Renamer" to do this, as it can edit files in large batches pretty easily.

    These are the steps:

    1. Make a backup of your project folder before continuing.

    2. In Windows Explorer search the project folder for "*" to get every file and folder in the search results.

    3. Sort the search results by "Date Modified" to roughly group all the files with missing dates.

    4. In Flexible Renamer, select the "Specify File" tab, and then the "Attributes" sub-tab.

    5. In the "Target" section enable "Files", and "Recursive Sub Folders".

    6. Set "Timestamp" to "Make the same".

    7. Set "Base Date/Time" to "Date Accessed"

    8. Set "Apply To" to "Date Modified".

    9. Back in Windows Explorer, select all the files that are missing "Date Modified" values, and drag them into Flexible Renamer's file area.

    10. In Flexible Renamer, click the "Start Modify" button.

    Done.

    You can redo the file search again, just to make sure you didn't miss any date-less files.

    You can also try previewing the project from construct, because the JavaScript console will tell you the names of any files still broken.

    After this all the files in my project folder had "Date Modified" values, and the project previewed and loaded without any problems.

  • I've tried NW.js, Chrome, Firefox, and Iron.

    (I usually do all my work previewing NW.js)

    Also, wow, I can't believe I didn't think to check the debug console, good call, dop2000!

    ... So I checked it and just as the freeze happens, I get an avalanche of errors, each saying a different image file can't be found. Essentially every image in the game can't be found. Only the logo image loads, and even it didn't load until I overwrote it with a backup version of the logo from an older project.

    On further inspection of the files in the project folders I noticed something very strange.

    The last version that works has all normal looking image files.

    For the next version after it, which spews the avalanche of image errors, all the images and audio files are missing "Date Modified" meta data.

    I mean literally missing,leaving a blank in the column where they would normally appear in Windows explorer. I've never seen that before.

    Opening properties on one of these files, the "Date Modified" field just shows "12:00am", and no date, as you'd normally see.

    All the image files still open and display normally though.

    Interestingly, the only file that has a "Date Modified" value is the logo file, which got filled in only after I replaced it with an older image file. And that's the only image that loads, that I know of.

    I'm starting to suspect there may be some hard drive problem, but I'm not sure. It's all pretty weird. I backed up the last several versions (working and not) to separate drives just in case.

  • Hey thanks for the info dop2000. :)

    I've seen a few references to the logo png, like in the other post I linked, though I wasn't sure if that was related to my case, but it looks like it might be in part.

    I tried copying an old logo png over the current one, and even though they appear identical, my game loads slightly farther now and no longer gives an error.

    It will now show the loading image, partially fill the progress bar in red, then freeze. The red loading bar usually indicates some kind of loading failure, but I don't know what problems do or don't trigger that color change.

    In Debug mode, it seems it loads to 17% before freezing every time.

    This is what it looks like.

    So this is farther than I was getting before.

    Is there any kind of weird event that might have corrupted an image file?

    i.e.

    If C2 crashed while the image editor was open, or crashed as the image editor was closing and updating the file? I don't recall a crash off-hand, but one might have happened.

    Or maybe if the computer went into sleep mode when the animation editor was open and didn't quite restore correctly, on waking?

  • (edit: See [SOLVED] post below... )

    The game I'm working on had no issues launching in preview mode a few days back, and today this same project now crashes on preview.

    I've made no changes to the project file.

    When attempting to preview, the game begins to load, and halts at a black canvas with the error shown below.

    Javascript error!

    Uncaught InvalidStateError: Failed to execute 'drawImage' on 'CanvasRenderingContext2D': The HTMLImageElement provided is in the 'broken' state.

    Still investigating this, but I figured I'd ask, just in case anyone knows off hand what might cause this.

    Things I tested

    This error occurs in Chrome, Firefox, and NW.js.

    Several older versions of this same project also now crash on previewing, with the same error, so I don't think it's a change in the most recent version of the game.

    I tried making a new blank project, and that seems to preview just fine.

    So I think there is something in my game that's triggering the problem, but the fact that older versions also trigger this error (which I don't recall ever seeing before ) is strange.

    I did find a 10 month old version of the game project that seems to preview just fine, so whatever it is, doesn't affect all copies of the game.

    I'll be looking to see if I can spot the difference between versions.

    It seems like there must be some resource, object, or image in the game that is suddenly not playing well with HTML canvas for some reason.

    More info

    I can't think of anything that would mess with this.

    I did rollback my graphics drivers in the last few days, I would think that'd be pretty separate from HTML 5 though, and in particular separate from the minutia of changes in older versions of the game. Still, it's the only thing that comes to mind. (edit: Just tried installing the newest drivers and I still get the same error, so looks like drivers aren't the issue.)

    I also tried updating Construct 2 and that didn't seem to change anything.

    I'm using Windows 7 x64 Pro, Nvidia GTX 780, Construct version r265

    Related posts

    I found one other post that mentions this error message, but it seems to be in a differnt context, using web proxy preview, so I'm not sure how much it overlaps with my case.

    construct.net/en/forum/construct-2/how-do-i-18/invalid-state-error-81533

    Any thoughts or suggestions are welcome.

  • Hey heater19 and justifun, :)

    This is the latest themes bundle:

    Themes Bundle - Fisholith Themes v2.zip

    My themes bundle and my Theme Editor are downloadable in the first post of my Editor thread:

    construct.net/en/forum/construct-2/works-in-progress-feedback-requests-24/color-theme-editor-for-c2-rele-111846

  • Hey Ashley,

    Thanks for the reply, and for explaining some of the inner workings, it's always interesting.

    The storing of global vs instance data is an interesting aspect.

    It sounds like maybe making an in-event-sheet wrapper function (via Function object), for enabling and disabling physics collisions might be a good alternative then. The wrapper could automatically update our own external collision relationship list, that could be stored on-save and later used to reload the relationships via "on load complete".

    Anyway thanks again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey —, thanks for the reply.

    It does work, and it's one of the two options I can think of for dealing with the Physics save/load behavior.

    Using "On load complete" to manually reconstruct the prior "collision relationships list" is a workaround I've spent some time looking into. It gets a bit trickier in larger projects with conditionally disabled collisions, but it's still workable.

    In essence you have to store your own hand-made parallel "collision relationships list" in a dictionary object or something similar. You update your dictionary-based hand-made list every time you update the real Physics object. Since that dictionary object will be restored correctly when the save state is loaded, you can get the collision relationship data out of it and use it's entries to reconstruct the correct collision relationships in the Physics object.

    The other possible workaround, (much more self-contained, but much more iffy with update compatibility), is to modify the physics objects runtime JavaScript.

    The "instanceProto.saveToJSON()" function is responsible for serializing the internal state of the object into JSON. I think it should be possible to add the collision relationships list data into that outgoing data.

    Then in the "instanceProto.loadFromJSON()" you would have to extract the info and feed it back into the Physics object to reconstruct the collision relationships state.

    This is how most objects store and recall their collision state info, and it's what would be changed in order to resolve the save/load behavior described in the bug report.

    There are compatibility downsides to making unofficial modifications to the JavaScript of an official plugin though, so I don't really recommend it.

    Anyway, thanks again for the suggestion, drg81. I think the "On load complete" method is the way to go for the time being.