This depends on how you set your game to display. See https://www.scirra.com/tutorials/73/sup ... reen-sizes

You could have a screen that cropped up and displayed only a part of your game or you could have the whole game scaled down to fit the screen with or without respect to aspect ratio.

Image quality would depend on how you set C2 to render. See the text below from https://www.scirra.com/manual/66/projects

Sampling

Choose between linear (smooth) and point (pixellated) sampling when resizing images. Linear is recommended for modern games with hi-res graphics, and point is better suited to retro games with blocky pixel art.

Downscaling

Adjusts the tradeoff between rendering quality and memory use when resizing images to smaller than their original size (downscaling). The options are:

Low quality: mipmaps are disabled (reducing memory use), but downscaled sprites may appear blocky or pixellated

Medium quality: mipmaps are enabled. Downscaling sprites generally looks better.

High quality: mipmaps are enabled and the spritesheet after export pads out all images to power-of-two sizes. This can significantly increase memory use, but can resolve two minor rendering issues: light fringing that can sometimes occur along the borders of downscaled objects, or a quality change in the last frame of an animation. Do not use this mode unless a rendering artefact is specifically observed and selecting this mode can be observed to resolve it: the increased memory usage can be very significant, and is not a cost that should be added for no reason. For more information see Memory usage.

----------

Does this answer your question?

TiAm Yes I understand. Ashley will have to go through a lot and I completely understand.

I already got a better solution in front of me, so I am not requesting for any change in C2 any more.

A screaming soul exploded inside me when the project manager requested for a change like this. A simple change from client's perspective could involve lots of gigantic technical changes and outsiders never see the internal technical pain. I've been there done that so I do understand.

Then you are doing it wrong in the event sheet. Screencap your event sheet and post it here.

What you are asking is similar to asking McDonald how to create a better cooking tools to cook better fast food. Ask Burger King or other folks and they will all have their own gorgeous and ugly ways in doing their own thing.

From what you have mentioned in the second paragraph, you are pretty much learning and experimenting on what you are after. Keep on doing that and you will see better ways that really tailor to your need.

See https://www.scirra.com/manual/108/array

[quote:2idq719v]

Download

Invokes a browser download of a file containing the Array's contents in JSON format. This is intended for offline development, e.g. creating level editors.

Load

Load the contents of the array from a string in JSON format. This must have been retrieved from either theDownload action or the AsJSON expression. It could also be retrieved dynamically from the AJAX object.

Does this answer your question?

First, I know what do you mean by Pong, but after you mentioned Monster... I started to get unsure about your Pong game...

What is the monster doing in the Pong game? Without understanding further comtext, we can't help you validly.

Use System Condition to test how many enemy objects are there.

From https://www.scirra.com/manual/124/system-conditions

[quote:28lwcnep]

Compare two values

Compare any two expressions (which can either numbers or text) with each other. They can be compared as Equal, Not equal, Less, Less or equal,Greater or Greater or equal.

Assuming EnemySprite is your enemy's sprite's name, you could refer to the Count variable of the EnemySprite.

For example, with the above system condition, you could put EnemySprite.Count in first expression and the number 100 in the second expression. Then, compare these two expressions as "< less than".

This means, whenever EnemySprite object is less than 100, the condition will be true. You could add your action to spawn more enemies in this condition here.

Then... how does it actually supposed to look like? Mind do some photoshop and post it for clarity?

[quote:2in4o65d] The problem is that the graphics look weird and 'warped' (darkened in certain spots but not others) at certain zoom levels when I demo this capx in my browser, including the normal 100% zoom browser view in Chrome. It's a problem that's hard to screenshot, even; when you look at the screenshot I took below, the problem may only be 'visible' at certain zoom levels of your browser.

From my guess from the statement "the problem may only be 'visible' at certain zoom levels', I think you wanna play around with the following configuration:

[quote:2in4o65d]Pixel rounding

By default Construct 2 objects can be drawn at sub-pixel positions, e.g. (100.3, 200.8). If the browser is using linear filtering, this can make fine pixel art appear blurry. If Pixel rounding is set to On, Construct 2 objects round their position to a whole number before drawing, e.g. (100, 201). This prevents any blurring, and can also prevent "seams" appearing on grids of objects. Note this does not affect their actual X and Y co-ordinates, which can still be between pixels - it only affects where they are drawn on the screen.

Fullscreen scaling

Only has an effect when a fullscreen mode is in use (when Fullscreen in browser is not Off). High quality mode renders at the full resolution of the screen. Low quality mode first renders at the project Window Size, and then simply stretches the result to fill the screen. Low quality mode often improves performance on low-end systems and is often suitable for retro-style pixellated games with Point sampling. However text, downscaled sprites and WebGL shaders appear with better quality and detail in high quality mode.

Sampling

Choose between linear (smooth) and point (pixellated) sampling when resizing images. Linear is recommended for modern games with hi-res graphics, and point is better suited to retro games with blocky pixel art.

Downscaling

Adjusts the tradeoff between rendering quality and memory use when resizing images to smaller than their original size (downscaling). The options are:

Low quality: mipmaps are disabled (reducing memory use), but downscaled sprites may appear blocky or pixellated

Medium quality: mipmaps are enabled. Downscaling sprites generally looks better.

High quality: mipmaps are enabled and the spritesheet after export pads out all images to power-of-two sizes. This can significantly increase memory use, but can resolve two minor rendering issues: light fringing that can sometimes occur along the borders of downscaled objects, or a quality change in the last frame of an animation. Do not use this mode unless a rendering artefact is specifically observed and selecting this mode can be observed to resolve it: the increased memory usage can be very significant, and is not a cost that should be added for no reason

source: https://www.scirra.com/manual/66/projects

Since you are doing ASCII/ANSI graphics, you may wish to turn Pixel rounding on and set Sampling to "Point".

See if this is what you want.

[quote:pp78fjeq] I don't understand how you could possibly need so many thousands of individual images? What are you doing?

Ashley, like we've said. We are doing pixel arts like this: http://probertson.tumblr.com/post/82062 ... animations

If imported to C2, each Sprite object could contain up to a hundred of frames or so. (But with exported spritesheet image, those hundred frames should become just a huge 512 x 512 or two instead. And that is completely fine.)

[quote:pp78fjeq] The editor could spritesheet images for preview, but that would be a big architectural change and could slow down preview.

We have tried some experiment on loading time.

On our project, we tried previewing and see the time it takes from hitting "preview" button to when the game finish loading and play. (If the loading percent becomes red, we just try again until it gives in)

• Preview Chrome: 1:13 minute
• Preview Node Webkit: 1:05 minute

But here's the funny bit, we have tried exporting Node Webkit, (disable minify and image compression) and it took 42 seconds. In addition, when we run the exported Node Webkit, it took only 10 seconds to finish loading.

In other words, it seems we can test our game faster than preview by exporting node webkit and run it right now. And yes, this would also avert the red percent loading error issue entirely as well.

Could the big architectural change slow down preview? With the above result, I don't think so. In fact, in this case, I could just well go with using the faster exported node webkit instead. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

We have also tried Preview Firefox, and it took 27 seconds...

I see that preview Chrome and preview Node Webkit took the longest on the first 0-20% (loading images perhaps?), but for exported Node Webkit and Firefox, the percent just "zaps" through to 100% in seconds. In fact, Firefox seems to kick the number up the fastest (only 8 seconds to 100% after the percent shows up, in fact). Does Chrome has inferior loading speed to Firefox or something?

I would like to put using and managing sprite sheets for preview just like exported projects and better sprite sheet management here.

More info:

You may wish to see https://www.scirra.com/manual/146/effects

To change color of any tile, you can apply "Adjust HSL" effect on your tile object which allows you to adjust hue, saturation and luminosity to each individual tile object.

If you require more assistance, feel free to ask.