CaptainOblivious's Forum Posts

  • I would like some automations available in the directsound object regarding music. Some features that would greatly benefit me would be

    Autoplay music to channel - allow me to control which channel the music plays on. Reserving and controlling channels without having to always add play events will greatly simplify things.

    Auto fade music / channel to (volume) for (time).

    Auto fade out music / channel for (time) and stop playing.

    Autoplay with fade in for (time).

    And if it were a perfect world, a little bit of math applied to the automations could provide

    Fade Style:

    Linear

    Exponential (slow rise/fall)

    Exponential (fast rise/fall)

    Anybody have any more to add?

  • Hmm. Cannot reproduce it on \\Araquiel (XP sp2), or \\Cortana (Vista sp1). Your image serves as enough proof though. I'll file this on SourceForge.

  • I still can't reproduce the bug myself.

    What Operating System name and version do you have?

  • O RLY? Yes, we have found a major bug with the paint bucket tool.

    Do you want to file it on SourceForge or shall I?

  • Okay, I did a couple of tests then. As I suspected, the sub-32 PNG is lossy when imported. Copy/pasted into Fireworks so I could compare the gray area around the triangle. They are very slightly different shades of gray, the reason why the bucket will not fill it all in.

    Hey, at least we have a work-around. Just use the highest quality PNG, and Construct has no issue. The fact that this replicates in MMF as well tells me it's something to do with PNG, not Construct anyway.

    Doppel: The square selection tool doesn't work at all for me. Screen shots, steps, and reliability of reproduction (happens every time?) would help the devs improve this system.

  • Use this file and see if the paint bucket tool now works.

    http://www.strouperman.com/Special/triangle2.png

    If the paint bucket tool doesn't work for you when it works for me, using this 32-bit PNG, then you've found a bug with the way the tool operates.

    If it works just fine for you, then maybe the non-32-bit PNG is becoming lossy in its transition to Construct, as a separate side effect from the gray back ground.

    I'll keep my F5 key primed...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Calm down, bro. We're all working toward the same end, here.

    I loaded your PNG into Construct and reproduced the gray background error. I then loaded the same PNG into Multimedia Fusion, and produced the same results.

    So I loaded the PNG into Fireworks, and resaved it as PNG making sure it was 32 bits.

    I loaded this 32-bit PNG into Construct, and Construct retained the transparency. I was also able to fill any color I wanted in and around the triangle.

    SO, the problem is with your PNG image. I can't tell from here, but I don't think it's being saved as 32-bits. It's saving transparency, and Windows and FIreworks notices it, but both the infant Construct and the closed source giant MMF either misread it or, as if by law, fill the transparency with gray.

    I want to be double sure that you know I'm not putting you or your bug report down, and I'm not at all calling you stupid. I've verified your claim, and suggested a feasible work-around. The problem seems to be inherent with the way PNG is decoded across the board, not necessarily a bug within Construct. I'm no programmer, so perhaps Ashley could better explain this behavior when non-32-bit PNGs are loaded.

  • That's all fine and good, but your example image is a BMP. This filetype does not support transparency. Try loading a filetype that does, such as PNG 32 or GIF w/trans.

    I do see the problem you're having with the way Construct is making its selections. It's either inaccurate, or it's feathering it slightly in an attempt that is generally used to smooth the jagged edges when deleting an area. In either case, work around this (bug? feature?) by providing the transparency information yourself via your import file.

  • I have been using transparency just fine. As nice as it is to have an image editor in construct, I feel it really shouldn't be expected to carry the whole weight of the job. This program is primarily a programming tool, not an image manipulator.

    What I've been doing is using Fireworks (similar to Photoshop), creating my layered and sfx-riddled images (features missing from Construct's image tool - for good enough reason), and THEN saving them to flat PNG 32. Construct loads these perfectly fine on all three machines I have set up here.

    Having the original project files also helps me make changes to an image's layers, as opposed to pixel-by-pixel in Construct.

    If you do not have a powerful graphics program on hand, may I kindly suggest the open source GIMP.

  • Allow me to introduce myself. I'm Ben Ritter, and I'm a veteran of the similar, closed source ClickTeam products like Multimedia Fusion. I'm making the switch to Construct, and I thought I might help the documentation and tutorial efforts by keeping a development journal detailing the features of this young but awesome program, and my solutions to common Construct tasks.

    I also make my living as a graphic artist, not a programmer, so my experiences here might be useful for the Construct devs to get some insight on how a visually-minded user like myself approaches their program.

    ---

    For my own enjoyment, I'm resurrecting an old MMF project I barely started years ago in high school. A Star Fox fan game.

    Over the course of development, I will be twisting Construct's abilities to suit my unique vision for it. A combination flying shooter, Construct will have to seamlessly switch between above- and side-view scrolling, while handling branching paths, differing environments (space, air, water, and the transition between them), and complex AI and scripting - all the while maintaining a fluid presentation at a high graphical level.

    ---

    Let's take this a step at a time. For just about every level, I'm going to need an infinitely repeating background. Eventually, I will advance this to allow changing backgrounds fluidly on cue to show level advancement.

    Construct has already done a lot of the difficult sorting work for me - and I am very thankful as this was an arduous task in MMF. I need to plan ahead of time what elements are background, what are foreground, and what will need to be always kept on a heads up display. At minimum, this will be three layers. I will have to experiment how z position is affected between layers to figure out how to do enemies and the like. Our background will go into the lowest layer.

    Other tutorials I've seen across different platforms make a large canvas and move the camera and character. I'm going to go with an option that gives me much more control over the presentation of my applications by keeping a static canvas and moving all the backgrounds themselves.

    The tiled background object is well suited for this task. In MMF, this would require multiple instances of a single active background, but the tiled background can be stretched as needed, saving memory and processing.

    The challenge here is to make everything seamless. In my case the tile I have is slightly smaller than the canvas. In order to have seamless scrolling of our tiled background, we must set the size in exact multiples of the width and height of our tile, meeting or exceeding one screen in any direction.. essentially 3x the width and height of the canvas minimum.

    Now we need to set a movement to our background. I do notice the "Wrap" movement has functions that automate what we are trying to achieve, but playing around with this virtually undocumented function only ended in frustration for me. Instead, I will be using a "Ball" movement, opting to define the wrapping myself.

    THIS IS IMPORTANT. We are not wrapping to the canvas size. We need to wrap to the TILE SIZE. Even if your tile is significantly smaller than your canvas, you will not be able to detect the transitions. If you wrap to the canvas size, you will clip your movement and the result will be unpleasant.

    First, declare your setup events.

    START OF LAYOUT -->

    Tiled: Set angle of motion to (desired angle);

    Tiled: Set speed to (desired speed - a nice benefit to having a static canvas);

    Tiled: Set X to (negative the tile width);

    Tiled: Set Y to (negative the tile height);

    This will set up the tiled background with at least enough tiles centered on canvas to move one whole tile in any direction. The reason out positions are negative is because the default hotspot is on the top left of the tiled background. We are placing it above and to the left of canvas 0,0. Now we set up events to reset the master position when needed.

    TILED X is Greater or Equal to 0 -->

    Tiled: Set X to (negative the tile width - same as above);

    TILED X is Less or Equal to (negative 2x tile width) -->

    Tiled: Set X to (" " ");

    TILED Y is Greater or Equal to 0 -->

    Tiled: Set Y to (negative the tile height - same as above);

    TILED Y is Less or Equal to (negative 2x tile height) -->

    Tiled: Set Y to (" " ");

    If you add some basic controls to change the direction of movement, you will see that any angle you can throw at it will remain seamless. Because we have separated the X and Y resets, the background can shift somewhat in one direction and hold that shift as the object wraps in another. In fact I will be using this feature later, shifting the background in relation to player movement to add parallax.

    It would be ideal if in the future one object could handle all of this for us. In the meantime, this took less than ten lines of code and it withstands vigorous testing so far.

    To add some flair, you can layer one background on another, copying and adjusting the events between them. Make one faster than the other, and you multiply the parallax in the process. Very cool.

    ---

    This chapter of my dev journal concludes. I encourage you all to comment with your suggestions and ideas to improve upon this technique - or even prove me wrong if you can. I will also clarify and edit this as needed so long as you point out where I'm lacking with description.

    In future editions, I plan on providing source code and pictures.

    Until next time!

    ~Captain Oblivious