Lost my Keys's Forum Posts

  • >

    > Construct does not use DDS internally, so the file format you use won't affect this.

    >

    Ahh, so it really doesn't matter if I use png's or other supported formats instead of .dds then, as far as construct is concerned anyway? I'm so used to using that format for anything realtime related that I didn't think to ask before.

    Don't mean to hijack the thread, but since the issue was resolved I figured it wouldn't hurt.

  • I tried resizing the sprite borders to the power of two and it works wonderfully! Using 32x32 instead of 32x24 fixed the clipping. Thanks for the hint. Though being forced to use square shaped borders kills a lot of possibilities with the tiling. I'd still like to see the possibility of being able to tile non-power of two shaped sprites without the pixel clipping problem.

    Glad it worked!

    I don't think you're going to see none power of two textures working flawlessly for some time to come, not in real time anyway (pre-rendered it doesn't matter). Newer cards can handle it, but it's extra strain for them. Older cards however will probably just balk at them. Honestly being forced to use specific sizes isn't as bad as it seems.

    [quote:2q2kf0ak]I wonder if it makes any difference in the clipping problem if you load the textures externally instead of internally. The external resource management is far from ready in this project but we'll get there.

    Well no, cause this is a DirectX thing, and a computer thing, they've been using these set tile sizes since the beginning, and then when textured 3D games came along, those too used them. While I admit, some programs DO have different sized tiles available (I faintly recall some creator program from way back that allowed strangely sized tiles), but it's few and far between, and probably unheard of with modern methods. Like I say, it's just easier for the hardware to handle textures of those specific sizes.

    There are a few tricks you can use though, unlike most 2D games or creator programs, construct doesn't force you into working in a tiled environment. Yes your textures should be power of two, but your tiled backgrounds can be whatever random size and it appears to make no difference. Also, overlaying other tiled backgrounds on top is perfectly acceptable and works just fine, even if they too don't follow a grid pattern.

    Using that as an example. Say you've got your tiled floor, and you wanted a few manhole covers, but each one is rotated differently to the next (to avoid obvious repetition), traditionally you'd probably have to make new tiles for each and every one. With construct you just create a clone/instance of your manhole cover, rotate it and place it where you want. Do the same with a bunch of other random objects, leaves or trash or rocks or whatever and you can very quickly and very easily remove any obvious repeating pattern, just like how decals work in 3D games. From an artists point of view, that's an awesome part of construct, and being as they're instanced, they effectively only exist as a single entity, so that cuts down VRAM usage too.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks for the quick reply.

    Still makes me wonder why the last pixels are clipped. I've been under the assumption that no matter what size the sprite/texture is it's dimensions are always stretched to the power of two in the GPU memory. What I meant is that if I'm tiling a 256x256 texture and I want to display properly without the clipped 1px lines on the sides I'd have to change the dimensions to 257x257 to correct the tiling and thus using 512x512 worth of memory. This is what I meant with the unacceptable solution.

    All in all the problem is fixable in the demonstrated way but it makes accurate level designing a lot of trouble since the things are not working the way they should be.

    The reason for the power of two thing I think comes down to how binary and bits and all that fun stuff works. A 256x256 texture should tile perfectly *runs off to test it quickly* Yep, 256x256 tiles just how it should, then I tried 255x256 and it was suddenly missing a single pixel line. So yeah it's working as it should.

    If you change your artwork to fit in the sizes given in my other reply, even if it means cutting out a few rows or columns of pixels. Then you should find everything is tiling correctly for you. For the most part you shouldn't have a problem with doing that, and if you round down to the nearest acceptable size, you'll probably save on memory. As you say, if you go over, then it gets rounded up, which you want to avoid (load in a 1024x1030 sprite and see it try stretch to 2048).

    As for memory usage, I really wouldn't worry too much with something like this, unless you go crazy with hundreds of huge animated sprites and backgrounds, it's unlikely to make much of a difference memory wise. So if you HAVE to go over and round up on one or two textures, it wont be so bad (unless they're absolutely huge lol). Also the tiling object greatly cuts down resources required, and I don't think when it comes to the actual OBJECT size, that it matters how big they are, beyond the capability of the target machine to move large objects about. So a 32x32 textured sprite that's stretched to 1680x1050 would as far as the computer is concerned, still be a 32x32 texture.

    Anyway I babbled lol. Have a go though, change your sprites to match the numbers and see how it works out, you shouldn't have any problems then. I just tested it, same version as you and it worked just how it should. So you should be ok.

    You could also get into the habit of using .dds files, I don't think they even allow you to save in any size other than the correct ones. I don't know for sure with construct, but in other DirectX applications, using .dds is the better choice and tends to give improved performance. There's a very cool loader/saver plugin for Photoshop from the nVidia site which has tons of options that you can use for those too.

  • The problem described in this report is still around: http://sourceforge.net/tracker/index.ph ... id=1003219

    Basically the tiling textures don't display properly. I'd like to know if there is a solution other than the ones used in my examples. Stretching the textures and in some cases doubling the memory with textures that are sized in the power of two usage this way doesn't count as a solution.

    Thing is though, video cards work better when they are, and very few of the newer ones can handle textures that aren't. You should limit your imagery to:

    1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc. (though anything bigger than 1024 is going to cause trouble on all but the newest cards, and anything above 512 is going to cause trouble on the older cards, though as construct requires DX9, you should be ok up to 1024). That can be either square or rectangle shaped. So the power of two "solution" isn't really a solution, it's a rule.

    It's not a bug with construct, or directx or anything, it's just how these things work and how they've always been done. Try changing your texture sizes to fit one of the above numbers, if it works then yay, if not, THEN it could be considered a bug.

  • It looks ok for basic stuff, but I wouldn't expect miracles with it, and it's probably crippled with what it can do simply due to the way it works.

  • Well I noticed the random explosions toward the center of the screen (to the left, usually three at once if that helps), seems to happen when asteroids are destroyed towards the bottom right.

    I did notice the ever increasing number of asteroids, but simply put that down to you being a cruel horrible person and making it insanely difficult after reading my mind when I said to myself "meh this is too easy" and thus quadrupling everything a minute later LOL!

    But I couldn't for the life of me get it to crash, and I've been playing it for a while now.

  • Hi, is it possible that someone would write a tutorial or walk through for this. It sounds really good... But it would be much easier if there was some sort of an example with explanation or tutorial how to use it in game. Many thanks if anyone will write it.

    There is an example included, which shows how it all works.

  • My graphics card drivers are up to date. I have DirectX 9, but I updated anyways. Reinstalled Construct, but to no avail. Still isn't working I don't believe it has anything to do with DirectX because when I try to make a regular app it still freezes.

    Hmm, I don't know what it could possibly be then. Isn't there a way to set windows to record crash logs somewhere? I've never used it, or XP so wouldn't know where to find it. But maybe it would have something in there that could at least give the devs or somebody, an idea why it's happening.

    You could always try testing your drive(s) and memory, see if there's a problem with those. Or maybe checking the runtime files are being installed correctly, could be a problem with those too?

    Sorry, it's really hard to say what it could be, there's nothing much to go on. :\</p>

  • > Hmm, do any of your other DirectX apps/games crash too, or is it just construct? Is it the exe it creates that crashes, or temp.exe when you do a test in the program? Can you at least run the program, create something, or does it crash during that too?

    >

    > I'm sure someone else will be able to offer more help, best I can suggest is reinstalling it and make sure DirectX is installed and updated as needed too.

    >

    I'm not sure what games I have on here that are using DirectX, but I don't recall any games crashing on me. It's both the exe and the temp.exe that freeze up. I can run and create something fine with no problems. It's only when I try to test it or run it that I have a problem. I'll try reinstalling and making sure my drivers are up to date and get back to you.

    If it asks to install DirectX (I think construct does when installing) let it. I noticed that even though I had it all installed correctly, some games (The Maw being one I remember) just plain refused to work correctly without letting it install or at least check the installation of it. So could be that?

  • Brilliant, absolutely brilliant!

  • > A wii remote controller for construct would be fun too haha.

    >

    LMAO! That is awesome! I was partially joking too, didn't think it would happen, but wow how cool is that? *runs off to download it*

  • You could put things into groups, disable them, and use variables to cue up orders or something, then re-enabling the groups to play out the orders given. If you keep the sound out of those groups, it shouldn't be effected (such as with music). Would that work?

  • > I don't get it..

    >

    3d box is extremely useful. It should never be dropped.

    Guess I just see it as something of a Pandora's box (box, geddit? ha, anyways). I suppose I don't quite see the usefulness to it right now. But I'm sure I'll change my mind once I start seeing real world examples of what it's capable of.

    Though I would be the first to jump on 2.5D build engine style support. So I'm not totally opposed to some kind of 3D.

  • Moan.

    And yeah, there's no support for standard controllers.... yet!

    The ".... yet!" makes me hopeful you're feverishly working on something?

    I wonder if things like lightguns and such would even work these days too.. do games use those anymore? lol. A wii remote controller for construct would be fun too haha.

  • > all those objects have different depth maps, which all make up one full screen depth map.

    > Which is made up of individual, static depth maps...

    [quote:24hiditd]Flat drop shadows are ok to a point, but they show up the 2Dness of things, unless they can make use of a depth map (or height map) to shape the shadow in realtime across something behind them. The option to use either would be the best bet, as there's lots of uses for drop shadows and SSAO.

    SSAO doesn't change with light direction or occlusion, as it is AMBIENT light (the A in SSAO). The occlusion term would only change if depths change, which you can fake convincingly enough with a soft drop shadow object (in case I fail to produce an effect )

    So anyways. Seems I can't convince you that 2D SSAO doesn't make any sense (just as I failed in an old DoF thread).... perhaps an example showing nice shadowing would do

    Yes an example would shut me u.. I mean convince me..