machrider's Forum Posts

  • Hmm.. I didn't think of that. I'm going to have to try that out and see how well it works, maybe later. I still think a mouse speed option would be good thing to add, in terms of efficiency. But I guess that works too.

  • There doesn't seem to be a way to get the x or y speed of the mouse. I think this would be a good feature to add to the mouse and keyboard object.

    I was going to try to make a miniature golf example where you putt using the mouse. The faster you move the mouse, the harder you hit. It could also be used with other game types like billiards (although the ball physics might be difficult, but then again I haven't tried it) and all sorts of pretty unique ideas and gameplay types (maybe using the mouse for boxing or sword slashing for example).

  • There's also another bug I found. The eraser tool only does 2 pixels. It cannot be shrunk to 1 pixel.

    I guess I'll file that on SourceForge myself. That's easy to describe compared to this bug.

  • I still can't reproduce the bug myself.

    What Operating System name and version do you have?

    That's strange. I'm using Windows XP Professional SP 2.

  • 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?

    I'm.. no good with these things. If you want to, that would be nice.

    Thank you very much for your help, I really appreciate it.

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

    Well, in that file. The transparency is already there. I don't need to use the bucket.

    OH WAIT, hold on a second. I just found a bug. If I fill in the outside with say blue, it does the same thing I said in the first post.

    <img src="http://machriderx.googlepages.com/Clipboard01.gif">

    Bingo!

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

    Okay, sorry. I edited my post, I did sound a bit angry there for a second but I realized that it was for no good reason and changed it, probably before you posted this, but sorry anyway. I see you're trying to help, that's good. I shouldn't have automatically assumed otherwise. However, people have been shooting down bug and feature requests recently due to some sort of feeling that Construct won't have x support if Ashley fixes or adds y. But, you don't seem like one of those people.

    Hmm.. the type of PNG image is the problem then. I guess I need to save it to 32-bit then. I think it should be able to read non 32 bit PNGs as well though.

    However, that still leaves the problem with the paint bucket in Construct. I know, maybe I should flat out not use it at all, but sometimes for last minute adjustments to things, I think built in image editors come in handy. I don't think its me using it wrong, I know its a bug because I've never seen any other program act like this when using a paint bucket tool.

  • 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 know that! I used both formats.

    When I copy and pasted the file from Paint where I drew the triangle (or saved it and imported as BMP), Construct gave me the weird behavior I described above.

    When I saved it to PNG and set the transparency to green, it imported it with a gray background.

    Maybe I should have uploaded that as well, here:

    http://machriderx.googlepages.com/triangle.png

    Also I am not using the selection tool! I am using the paint bucket tool and filling with the transparent color and it does this. Don't you see something wrong in that?

    And believe me, this isn't a feature. This is a huge bug. It may not affect you, but that does not mean that it should go unnoticed.

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

    I have an image editor on hand (several of them in fact). The problem is importing from that image editor (or ANY image editor I've tried) into Construct. I'm not using the built in editor to draw or manipulate anything. Please read my post again.

  • It does have PNG transparency. But sometimes it imports the files as if they're on a black background, which is somewhat annoying.

    That's probably why I didn't notice. It just shows up as a gray background for me. This needs to be fixed too.

  • The image editor in Construct is really buggy. One thing it seems to have trouble with is deleting colors, or making things transparent. This makes importing images very difficult.

    When I try to paste a sprite, and remove the green (or white, or other color) background, a lot of weird things happen.

    For example, I'll try to set everything to 0 in order to make a transparent color. When I go to the paint bucket and try to fill the green areas to transparent, it fills everything except for a few spots on the outside and inside of the sprite. The previous color still remains except around the outline of the sprite.

    Here, this will explain what I mean:

    <img src="http://machriderx.googlepages.com/constructbug.gif">

    See what I mean?

    That wouldn't be so bad if I could just erase the green stuff on the outside (and inside).

    In fact, that's what I've tried to do. I've tried both the magic wand and select color tool to select the nasty outside color residue and delete it. But, when I do that, it ends up just fading the color a bit and leaving a slightly less green outline on the outside or smudges the pixels as if it were doing some sort of anti-aliasing (even though there doesn't seem to be an option to turn this off).

    I really hope this gets fixed soon, because it's really annoying.

    Also, I would like to make a suggestion. I think it would be a good idea if Construct recognized PNG transparency. That way, the sprites I want to import could already have the correct transparencies rather than having me to remove all the transparency color junk myself.

    Edit: By the way, if you want to try to reproduce this bug yourself, try importing this file into Construct (although from my experience, any sprite I try does the same thing):

    http://machriderx.googlepages.com/triangle.bmp

    And then set the color to 0,0,0,0 and use the paint bucket and see what happens.

  • [quote:3f1dz6gd]but will require loads of work

    Yeah give Ashley more work :/

    And making people lazy is not good... i know construct is about "no scripting to create" but it can be done easily in array.

    No offense, but will you and that other guy please shut up about that already? You're really getting on my nerves. I understand that you don't want this feature, fine, but that doesn't mean you have to keep making jabs at me even after I decided to drop the whole issue.

    I already explained what I meant. Maybe you didn't notice, but that "call me lazy" bit was sarcasm. I said that in response to being told to try to make a game using C++ w/ Allegro.

    Also, I don't understand why anyone would be against something that speeds up productivity and reduces the clutter and extra work of making a game, especially with a WYSIWYG program like Construct. I was just trying to emphasize how absurd I thought that was. I mean, it's like telling everyone not to use the built in movements but instead make your own platform movement, or own physics engine.

    If you still don't understand what I'm trying to say, I can explain it again (for the third time) if you want, but right now I think we're just beating a dead horse.

    Also, I admit. I forgot my basic math there for a second. I don't know how that slipped my mind. But that doesn't change the fact that I still would much prefer to use a tilegrid object than create a huge clusterfrick of an array just to make a grid. Especially when I can have the whole making of the grid part set up already and focus on actually making the game, where the effort actually counts.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Make sure you have the animation bar enabled under the Home tab. That had me confused for a bit when I first started this program.

  • In fact, I think rather than a grid object there should be something integrated into Construct itself.

    If you notice, on the layout tab, you can toggle a grid on and off and edit the size of it.

    Rather than this grid just being just something that is part of the UI of Construct, you should be able to use it in the event editor.

    Like there is an option to move things according to X (or Y), there should be an option to move things according to the grid (to the next square, or specific square in the grid, etc).

  • So if it's possible to make in Construct, and reasonably easy to do so with a little effort, then why request it as a feature? I just don't see the reasoning behind it.

    It isn't reasonably easy to do. If it was, I wouldn't be requesting it.

    You can make a pseudo (fake) grid engine with a lot of work and a bunch of events where you manually have to calculate where the center of each square on the "grid" (each and every single x/y coordinate) is to move your character (which would likely result in an event sheet that takes up the whole screen) but that's just tedious and haphazard, and not to mention just isn't practical.

    Also, that C++ and Allegro comparison that was made before is irreverent. If you were using C++ or any actual language, you'd be able to code an actual grid engine that loads tiles from a tilesheet, moves things according to the grid automatically, etc.

    Construct by itself does not have that ability unless someone codes it in via the plugin SDK or editing the source code.

    Since I cannot code, I am requesting that someone help out and add this functionality.

    And that's what should happen. I don't see why anyone is objecting to as basic and essential as this. Even MMF has a grid object.

    If you won't use it, then fine. Don't use it. I actually think you need it more than you're realizing.*

    And about the rest of what you said. I'm not saying for Construct to make a game for me. I am saying that there is no way in hell I can learn something such as C++ and believe me I've tried. I need menus to click on, I cannot remember syntax or languages for the life of me. Call me lazy if you want, but I am not going to learn C++ anytime soon.

    *Edit: Another thing you might not realize is this. A Tile Grid object can directly be used to make a level editor for games. In fact, by requesting this, you are also requesting the ability to add level editing to games. If you've used MMF before you'd know that it's almost essential to have a grid object for such a thing.

    If you're not familiar with what I'm talking about, The way it works is. The user uses a preset series of parts (different tiles for slopes, straight surface, etc) to create a level. The data of where each tile is stored and which one is used is stored in an INI file which then can be distributed as the level. Then through a series of events, the grid object loads this data and arranges the tiles accordingly to each square where they were originally.

    This is one of the many uses a tile grid object has. It isn't something you can just make up in the event editor. You may be able a pseudo tile engine for an RPG or haphazardly for a strategy game (like Advance Wars), but not everything else it is capable of doing.