fisholith's Recent Forum Activity

  • Hey , (...not sure how to a name with a space in it)

    Thanks for letting me know.

    I just updated the links, so they should work now.

  • Happy to help.

    Also, if you have a Windows computer you may need to install DirectX. Though installing NW.js for C2 should automatically prompt you to install DirectX if needed.

  • No problem.

    Compressing the png files will help with download times, but I believe when the game is running the images will be fully decompressed in memory, so prior compression won't have an effect on runtime performance.

    If you want to see an example of the rain cluster approach, it's what I used in a project I'm currently working on,

    Subscribe to Construct videos now

    . The graphics are based on the GameBoy hardware, so they are a bit simplistic, but only the spacing of droplets really matters, they can look like whatever you want. In that video I have two layers of rain, a foreground layer, and a background layer. The background has smaller droplets, falling a little slower.

    To give an idea of the droplet spacing used in the example above, the texture would look something like this,

                !
       !
                        !
            !
                  !
                          !
     !
                !   
                       !
          !
    [/code:16eaui5v]
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hey NiceJared, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    This may mean you're using a browser that doesn't support WebGL, or has it disabled.

    Some browsers have a setting labeled "Use hardware acceleration" or something similar. If this is disabled, WebGL might not work.

    An alternative is to export the project as an NW.js desktop application.

    A NW.js application takes your game and bundles the WebGL and HTML5 platform stuff in with it.

    This way you don't need to rely on a browser for those things, though your file will be bigger as a result.

    To try previewing your game with NW.js:

    In the "Projects" panel, click the project folder (top-most folder).

    Then in the "Properties" panel, in the "Configuration Settings" section, change "Preview browser" to "NW.js".

    Now preview your game.

    You may need to download NW.js for Construct 2 first from here:

    https://www.scirra.com/nwjs

  • Hey CreativeMind,

    Different devices can behave pretty differently depending on how they handle rendering. It's been a while since I've looked into this in depth, but I recall hearing that some even have a limit for the maximum number of overlapping drawable objects that can be rendered in a single frame refresh period.

    There's a good overview of Construct 2 mobile performance considerations in this article

    Performance Tips

    Another good general article is,

    Optimisation: don't waste your time

    That said, I can try offering some thoughts and suggestions that might help out.

    Rain is a bit tricky though because even the tips I'd normally think to give for optimization can be double-edge swords on mobile devices.

    Two possible approaches

    Particles will probably give you better performance than sprites, because particles exploit some render optimizations, and eliminate a bunch of sprite features you don't need to use like animations and collisions.

    You still end up with a lot of individual things that need to be updated moved and drawn though, if each rain drop is it's own particle. A workaround is to put a lot of droplets on a single particle texture.

    ("Droplet cluster particles" below)

    Another option would be to use a single tiled repeating texture and scroll it downwards, as it would only require 1-step to render it, instead of 1 step per particle. This takes up much more memory than a single raindrop texture, but probably not much more than any of the other larger textures in your game, like backgrounds and such.

    ("Scrolling tiled rain texture" below)

    Both of these workarounds ("Droplet cluster particles" and "Scrolling tiled rain texture") involve using images with large amounts of transparent area. Normally this is something you'd want to avoid on a mobile device, but in this case the transparency isn't just superfluous uncropped area, and the alternative blizzard of individual raindrops might be worse. Again it partly depends on the device.

    Scrolling tiled rain texture

    With the tiled scrolling rain approach, you risk loosing the randomized look of raindrops, so you might want a largish texture. If you want a more randomized look, you can use two tiled textures of different sizes, overlap them, and then scroll them at different speeds. The interplay between the different textures will help break up the appearance of repeating patterns.

    This also gives you the option of changing the angle of the rain drop graphics, which can't be done with particles as far as I know. (One of the optimizations used by C2 particles relies on all the particle textures maintaining the same angle, if I remember correctly)

    Also just a note, you wouldn't scroll the tiled texture in the same direction forever, just until it got to a looping point where you could snap it back to its starting point, giving the illusion of continuous scrolling.

    Droplet cluster particles

    If you want to try using fewer particles to create the same visual density of rain drops, you can use a larger texture with randomly placed raindrops on it. This takes up a little more memory, because of the larger texture, but if each texture has 30 droplets on it, then the number of particles needed becomes 30 times smaller. which should improve the performance of the rain effect. However, this depends a lot on how the mobile device renders things. As I mentioned earlier, sometimes, it's the number of overlapping objects that causes problems, in which case particles may not help you.

    Some care must be taken in drawing/creating this kind of droplet texture, because otherwise it will look like the droplets are falling in clumps.

    When drawing this texture, it's usually good to have a fairly uniform distribution of droplets, with about the same amount of space between them. Avoid placing two right next to each other or you'll see that unique pair on every texture. It can also be good to build up the droplets from the center of the texture outward, with the vary outermost set of droplets at about half the density of the more central cluster. This edge drop off in density helps the particles (each one a cluster of droplets) blend together more seamlessly, because there's not a hard all-to-nothing density transition on every texture. You can think of it like feathering, but with amount instead of opacity.

    finally you'll need the emitter to create enough of the particles (droplet clusters), so that any spot on the screen is covered by two particle clusters on average, kind of like house shingles. Since there will always be about 2 clusters overlapping any given spot, when drawing the texture, you should put the droplets about twice as far apart as you want them to finally appear in the resulting rain.

  • Thanks

    Also I just wanted to note that I fixed the dead link resulting from Dropbox's new "no more public folders" policy. The link should now work exactly as it did before.

    Finally for anyone else having to update their Dropbox links, the new link will end with

    "?dl=0"

    And it will take you to a download page, instead of opening as a direct download.

    If you change the 0 to a 1,

    "?dl=1"

    then you should get the original direct download behavior when clicking the link.

  • Hey Rco250jmx,

    To my knowledge, there's no reasonable way to change the styles, because they are developed by Microsoft, and are hardcoded into a convoluted cross-section of DLLs and other miscellaneous system files, which are not intended to be editable. So unfortunately as far as Styles go, you really only have the options provided.

    I created a visual reference sheet of all available styles (2nd image below) to make it easier to brows them.

    * "Visual studio 2012 Dark" (2nd from bottom) is good for dark themes.

    * "Carbon" (2nd from top) is also good for dark themes. It is not as dark as 2012 Dark, but is the only other Style with a non-white property bar background color.

    First a quick reference for the 3 most important styles, those being the default style and the only two dark styles:

    The 3 important styles

    All Styles

    As an aside since, , Arima, sqiddster, Katala, and Tetriser, discussed the usability of dark themes earlier in this thread, some of you might be interested in the Style reference sheet as well.

    Also, credit to Colludium who I think was the first to mention the " Visual studio 2012 Dark" Style in this thread.

    As you can see from the chart, 2012 Dark really is the best (and almost the only) Style choice to pair with dark themes.

    Hope that helps out.

  • Update - Release 4

    New features:

    * Preview selection colors now finally include the Condition and Action selection borders.

    * New scrollable embedded help with information on controls, interface, workflow, examples, and more. (M-Click to toggle XML view)

    * Color hue name display, shows name of nearest Primary, Secondary, Tertiary, or Quaternary color, for a total of 24 names evenly spaced around the color wheel.

    * Color Hue preview bar has a variety of display styles. (hover and Mouse Wheel to change style.)

    * Color Hue preview bar styles with variant hues or hue gradients can be right clicked to adjust the current Hue. This is handy for uniformly rotating the hue of several elements in quick succession.

    * Added optional toggleable Hue Zone modifiers. Press "W" to display the hue strips as separated bars. Press "Q" for partial desaturation.

    * 15 new themes come with the download, combined with the prior 25, for a total of 40 themes in all, including some variations.

    * Various bug fixes, and optimizations.

    * Happy Valentines Day, all. :)

    Download

    ThemeEditor_r4_(win64).zip

    ThemeEditor_r4_(win32).zip

    Themes Bundle - Fisholith Themes v2.zip

    (This is the Themes bundle, by itself. Note, the Editor downloads include this bundle.)

    Theme Editor r4

    New Themes

    fi_FlatLight

    fi_GameJolt

    (Like the Scirra Site theme I made for the first bundle, this is based on the GameJolt site colors. Also like the Scirra Site theme, no one asked me to create it or anything, I just kind of like the colors. This is probably overkill as a disclaimer, but better safe than sorry.)

    fi_GraySoft

    fi_GrayTech

    fi_GrimGreen

    fi_LinedPaper

    fi_Mint

    fi_MutePastel

    fi_Neodymium

    fi_NeodymiumComBlue (Neodymium with Blue tinted comments)

    fi_Oasis

    fi_RedTailBright

    fi_RedTailBright_selPink

    fi_StoneFlax

    fi_StoneViolet

  • ---- Rhindon

    Thanks, Rhindon, happy to help out.

    You may want to re-download the demo if you get a chance.

    I made an update that includes a subpixel model visualization.

    The subpixel model is shown at the right, and updates in realtime, as you adjust the opacity settings.

    It's basically a live animated version of the bottom row diagrams in this image.

    ---- 99Instances2Go

    Also, thanks for the info 99Instances2Go. I added an edit to the original post. You just solved a mystery that I'd been wondering about for a while.

    I guess if someone really needed an XOR composite mode in webGL they could make a shader for it. One of the other interesting things I found out while testing XOR in non-webGL mode is that the composite modes seem to composite every canvas pixel, instead of just the pixels inside the Source's bounding box. That would make some of the destination-centric modes a bit more useful.

  • Hey Rhindon,

    Blend mode exploration program

    I created a demo of the C2 blend modes that makes it easier to experiment with them.

    (Update 1: I made an update that includes a realtime subpixel model visualization.)

    (Update 2: I made a new version (v4b) you can download here, or try on Scirra Arcade.)

    (Update 3: Version (v4e) small fixes, and Scirra version now shows link to this post correctly.

    Win64: fi_BlendCompositeModes_v4e_win64.zip

    OSX: fi_BlendCompositeModes_v4e_osx64.zip

    Scirra Arcade: Blend composite modes sandbox

    The subpixel model is shown at the right, and updates in realtime, as you adjust the opacity settings.

    Overview

    (This post got a bit bigger than I was expecting.)

    I'm going to try and answer this in three parts.

    1: The quick answer (Basically TL;DR because there's a lot to R)

    2: What does "Additive" do?

    3: What do the other modes do?

    But before going into the details, I'll try to give what might be a more intuitive answer, even if it's less explanatory.

    --------------------------------------------- The quick(ish) answer ---------------------------------------------

    Terms: The term "Destination" means the background, and "Source" means the foreground object.

    The Additive blend mode

    Additive: Directly adds the Source (foreground object) and Destination (background) color values. If the Source object is 50% gray (middle gray) and the Destination background is also 50% gray, then Additive blending the Source into the Destination will result in 100% "gray" which is white.

    The transparent Destination problem

    All of the other blend modes are transparency compositing modes. (explained in more detail later)

    When Construct renders a scene, it goes through the objects in Z-order, from bottom to top, and pastes them one-by-one into the background.

    Each time it's about to paste an object, THAT object is the Source, and everything else that has already been pasted is the Destination.

    The bottom layer of most projects has a solid color like white. This is the first thing that will get pasted, and it will make the entire background (Destination) solid and totally opaque.

    The other blend modes rely on the background (Destination) to have some transparency. This is a problem, because If the Destination had a solid background color blended into it then it will be solid everywhere, and will never be transparent.

    We need a transparent blank slate (like a special layer) we can render on separately from the rest of the main game. So, after we blend some objects onto that special layer, we can then paste that entire layer into the game.

    A normal layer won't quite work, because even if the layer has a transparent background, when Construct goes to paste a sprite from that layer into the background, the background will be the rest of the game objects that were already pasted, including the solid background color from the bottom layer.

    It turns out we can create that special layer described earlier. Create a layer with a transparent background, and then in the layer's properties, set "Force own texture" to True. This will force the layer to render separately from the game, and it will start out totally transparent.

    The other modes

    Destination Over: Put the Source object behind the Destination. You'll see the Source object peek through wherever the Destination is transparent.

    Source Atop: This is exactly like blending onto a clipping mask. This paints the Source onto the Destination like a skin. Where the Destination is transparent the Source will not appear.

    Destination Out: Punch a transparent hole in the Destination, using the opacity of the Source. Where the Source is opaque the Destination will be made transparent.

    Destination In: Punch a transparent hole in the Destination, using the transparency of the Source. Where the Source is transparent the Destination will be made transparent.

    All the others: The other modes all do kind of weird stuff that's generally not very practical (at least as far as I've found), either because they're just the reverse of a more manageable mode described above,

    or because they don't appear to work, as is the case with XOR.

    (edit: 99Instances2Go pointed out that XOR doesn't work in webGL, but does work when webGL is disabled.)

    My understanding (and I may be wrong) is that this list of modes comes from HTML5, so many of them are included in Construct for completeness rather than because there is a common usage for them.

    --------------------------------------------- What does "Additive" do? ---------------------------------------------

    Additive blend mode

    A source image sits over a destination image. Each pixel in the source image is sitting over a pixel in the destination image.

    For each overlapping pair of pixels:

    Additive says add the Red value from the Source pixel and the Red value from the Destination pixel, and use that for the resulting pixel's Red value. Likewise, add Source and Destination Green values to get the resulting Green value, and same for the Blue values.

    So, suppose you have a Sprite that's 1 pixel by 1 pixel wide (pretty small) and it's RGB color is (50, 0, 50) dark purple, and it's on a gray background colored (10, 10, 10). If you set the Sprite to Additive blend mode, the resulting color you get from blending it is (50 + 10, 0 + 10, 50 + 10) which is (60, 10, 60).

    --------------------------------------------- What do the other modes do? ---------------------------------------------

    "Alpha"

    The term "alpha" in computer graphics, (in this case anyway) basically means "opacity".

    (As in "opacity" vs "transparency".)

    In the same way that an image has a red channel to tell each pixel how red it should be, an image's "alpha" channel tells each pixel how transparent or opaque it should be. For a given pixel, an alpha value of 0 means totally transparent, whereas alpha at maximum means totally opaque.

    "RGB blend modes" - vs - "alpha compositing modes"

    The term "blend mode" is a bit broad in a way that can be confusing.

    There are "blend modes" as in fun with RGB math. (normalish-color-blending)

    And there are "blend modes" as in "alpha compositing modes", which merge images in weird and not-so-weird ways based on their transparencies. (weirdish-transparency-blending)

    I will use the term "alpha compositing mode" for that weirdish-transparency-blending kind for the rest of this post to avoid confusion.

    So to clarify, RGB math blend modes (normalish-color-blending) is what you find in programs like Photoshop and Gimp.

    e.g. Additive, Multiply, Screen, Lighten, Difference, etc.

    They all do different RGB math, but they all treat transparency exactly the same nice and intuitive way.

    By contrast, alpha compositing modes (weirdish-transparency-blending), is more like working with clipping masks and hole-punches, and occasionally ... angry ghosts.

    They also have weirder names.

    e.g. Destination Out, Source Atop, Destination Over, ... XOR!

    Now you may have noticed that "Additive" is in the "RGB blend modes" group, and "Destination Out" is in the "alpha compositing modes" group,

    and yet, both are listed in the same dropdown menu in Construct 2. It's not incorrect to call all of them "blend modes", but it's an example of what I meant earlier when I said the term "blend mode" can be confusingly broad, especially when you're starting out.

    Some Background (so to speak)

    So another term for those "alpha compositing modes" is "PorterDuff" modes.

    Named for Thomas Porter and Tom Duff, the Toms.

    They came up with a simple system for describing the alpha compositing of images.

    Specifically they noted all possible simple alpha compositing modes, and named them.

    These are the 12 modes. (I'll abreviate Source as "s" and Destination as "d")

    s over

    s copy

    s atop

    s in

    d over

    d copy

    d atop

    d in

    xor

    s out

    d out

    clear

    So, there are 12, but Construct only includes 10 of them, omitting "d copy " and "clear", because those two are not especially useful. (We'll see why later.)

    In Construct "s over" (Source Over) is listed as "Normal", because this is the basic and intuitive "one thing is on top of another thing" compositing mode.

    What do "alpha compositing modes" do?

    So what did Porter and Duff figure out. Why are there exactly 12 modes?

    To understand we need to think about individual pixels instead of the entire image.

    Let's try to walk through the most basic "alpha compositing mode", which is "s over" or "Normal" as Construct calls it.

    We'll start with a Blue Source and Orange Destination image.

    Now let's assume our Blue Source and Orange Destination are just 1 pixel each.

    The Source pixel is sitting directly over the Destination pixel.

    Next, imagine that both pixels are half transparent.

    The Orange Destination pixel has an opacity of 50%.

    The Blue Source pixel has an opacity of 50%.

    What should the Resulting pixel look like?

    Let's start with an empty Result pixel.

    To add the half transparent Destination pixel, we'll slice the Result pixel in half, with a horizontal divider, and fill in the top half Orange, leaving the bottom half empty.

    The result pixel is now 50% Orange. (The top half)

    Next, To add the Blue Source pixel, which is also half transparent, we'll slice the Result pixel in half, with a vertical divider, and fill in the left half Blue.

    When we fill in the Blue for the Source pixel, we cover up some of the Orange from the Destination pixel, and we also cover up some of the left over transparency.

    In the diagram below, the very bottom left square shows this "sub-pixel" breakdown of the Result pixel.

    The orange slice on the top, and the blue slice on the side, partially covering the orange slice.

    Notice that the result pixel has been split into 4 chunks.

    * Source only

    * Destination only

    * Both (Source and Destination)

    * Neither

    In the example we walked through, we colored the "Destination only" chunk Orange, and the "Source only" chunk Blue, and the "Both" chunk we colored Blue as well, because in the "s over" (Source Over) mode, the "Source" gets to paint "Over" whatever lands in the Both chunk of the result pixel.

    Now, notice that if we turned the opacity of the Source pixel up to 75%, this would push it's slice over to the right so that Blue would fill 75% of the pixel, and there would be even less of the Orange showing through. If we turned the Source pixel up to 100%, the Blue would push all the way to the right edge and totally cover the paint from the Orange Destination pixel.

    That's the last important concept in the slicing-up-the-result-pixel analogy. When you change the opacity (the alpha) of a Source or Destination pixel, you change where the slices end up, and thus how much of the pixel each chunck covers.

    If that's the "Normal" mode What about the others?

    So, we just walked through 1 possible process for allocating Source and Destination colors to the 4 chunks of that Result pixel.

    What if we did something weird though, like put the Orange destination color in the "Both" Chunk?

    Well we'd get the "d over" (Destination Over) mode, where the "Destination" gets to paint "Over" whatever lands in the Both chunk of the result pixel.

    Why 12?

    So how many combinations can we come up with from this system?

    Well, if we don't allow Source and Destination to be allocated to chunks they should never be in, then we get the following:

    * Neither: This chunk will always contain nothing. That's it's 1 and only option.

    * Source only: This chunk can contain the Source color or nothing. 2 options.

    * Destination only: This chunk can contain the Destination color or nothing. 2 options.

    * Both: This chunk can contain the Source color, or the Destination color, or nothing. 3 options.

    So that's 1 * 2 * 2 * 3 combinations, which is 12.

    So why does Construct omit some of them?

    Well one of the combinations is allocating nothing to all 4 chunks. That one's called "clear" ... yeah.

    Not so useful, since it just erases everything in every pixel all the time. (I told you we'd see why later.) :]

    Table of alpha compositing mode

    So now that we've seen that each alpha compositing mode is just some combination of filling in pixel chunks with either Source, Destination, or Nothing, could we visualize that as a table?

    Yes!

            .------Chunks------.
    MODE:      S:   D:   Bth: Nth:
    ----------+----+----+----+----
    s over     s    d    s    -      (usually just called "Over" or  "Normal")
    d over     s    d    d    -
      xor      s    d    -    -
    ----------+----+----+----+----
    s          s    -    s    -
    d atop     s    -    d    -
    s out      s    -    -    -
    ----------+----+----+----+----
    s atop     -    d    s    -
    d          -    d    d    -
    d out      -    d    -    -
    ----------+----+----+----+----
    s in       -    -    s    -
    d in       -    -    d    -
    clear      -    -    -    -
    ----------+----+----+----+----[/code:2ao8g29a]
    
    Sorry for the long post.
    Hope this helps.
  • No problem, glad it worked out.

  • Hey claurent9,

    I spent some time trying to figure out what was going on, and to summarize my findings, you can drag the music files from the "Music" folder, into the "Sounds" folder, and that should solve the Firefox issue.

    What I tried

    I tried running your project in Chrome, Opera, IE, Iron, NWjs, and Firefox, and only Firefox seemed to fail to restart the music correctly.

    I added a hotkey to restart the music without restarting the layout, and that also failed to restart the music in Firefox, so the problem seems to be independent of the layout restart.

    I ran the project in debug mode, and inspected the "Audio" object.

    When the music plays for the first time, the "Currently playing" debug field reports the audio as playing, and shows the play progress in seconds for the audio file.

    If the music is restarted, the "Currently playing" debug field reports the file as playing and shows the realtime progress just as before, but no audio plays.

    So the Audio object thinks it is playing the audio file, but Firefox isn't creating any sound.

    To use debug mode

    1. Choose the "Home" tab on the ribbon, and click the "Debug layout" button.

    When your project starts up there will be a debug panel in the bottom of the window.)

    2. On the debug panel, on the bar, at the very right, click the diagonal arrow button "?" , to break the debug panel into it's own window.

    The debug panel acts like an x-ray view into the insides of all the objects in your game.

    Finally, I noticed that the music files were in the "Music" folder, instead of the "Sounds" folder.

    I moved the files to the "Sounds" folder (you can just drag and drop from one to the other), in case the issue was streaming related, and afterwards the music restarted in Firefox, without a problem.

    Possible cause

    If I recall, the difference between the "Sounds" folder and the "Music" folder is only how Construct plays them. For files in "Music", Construct tries to stream them, whereas files in "Sounds" will be fully downloaded and played directly.

    It seems like Firefox may handle streaming audio in a way that breaks when you restart it, at least in this case.

fisholith's avatar

fisholith

Member since 8 Aug, 2009

Twitter
fisholith has 1 followers

Connect with fisholith

Trophy Case

  • 15-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

19/44
How to earn trophies