Hi all,

I've been working on a C2 game for a while now, called "Down Ward"

You play as Gable, a little owl, as she sets out to rekindle the dormant relics of a land long abandoned to ruin.

A video:

Some gifs:

i.imgur.com/ECoLvnr.gifv

i.imgur.com/fSq4zfA.gifv

i.imgur.com/5VQXadf.gifv

The game:

Down Ward - Play/Download

If you're interested I also launched a Kickstarter,

Down Ward - Kickstarter

(Please let me know if posting a Kickstarter link in this forum is a problem, I don't want to be breaking any rules.)

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 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.