please don't take the effect out of context.

I posted it for this thread, where I am asking for angles and correct hotspot information within an effect.

http://www.scirra.com/forum/viewtopic.php?f=7&t=5210

Please continue discussion in that thread.

yeah this has nothing to do with hotspots tho

but whatever, i just want to know if its intentional or a bug, i dont care about getting credit for its discovery so lock this thread if you want lol.

I didn't notice this until trying Madster's clip disc effect.

Download here

Use the arrow keys to move around, note how the effect matches the objects size and shape correctly ONLY when going up/down/left/right, but when going diaganoly it morphs into a square. Surely that's not right?

I know it's not a huge deal or anything, and unlikely to come up in actual real world usage. But I'm curious if it's a bug or just a limitation of DirectX.

lol that's funky. I see what you mean.

Could it use image points instead?

What I meant was that this is basically just a raw engine... it handles rendering, input, collision detection, and not much else. Someone using this would pretty much just be limited by their programming skill... it's not like you couldn't make whatever kind of 2D game you wanted.

So I guess I don't see how one would be stuck making "basic" or "crippled" things unless they were to cripple their own project with their own basic Javascript skills.

Don't get me wrong, you have a lot of good points and I agree with you on most of them. But this tool seems jim-dandy for someone with Javascript knowledge who wants to make browser games, and it's not like they're advertising that their engine does anything but... so... yeah.

Kind of like hating on toasters simply because you don't want to make toast, I guess.

Well yeah that's true, it's probably fine for someone with enough javascript knowledge or the time/willingness to learn it.

I couldn't find any examples or people's creations beyond the ones included on the first page though. I would have liked to have seen more of what it could do.

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

>

I don't see any reason why you might think that . It looks pretty capable of making whatever kind of 2D game you want. I mean, it's Javascript so yeah... real programming language and all.

Yeah, never been a fan of the Javascript scripting language (I wont call it a programming language). To do anything more than the basics though you need to understand how to use javascript as it looks like it's integrated with just about every aspect of the application. And if you know enough javascript to make something decent, you may as well just write it from scratch and not be tied to the site at all.

I see make your own type applications like this, construct etc. as being aimed at the casual user, or the artist, or the guy in the bedroom who just wants to have a bit of fun. To give those with no or very little programming knowledge a chance to express their idea's that they might otherwise not have the chance to. It's not much fun if 90% of that time is spent learning some other scripting language just to do more than bounce on a platform and shoot a bad guy. When it becomes more about the underlying scripting language than creativity, you may as well just learn C++ and start from the beginning, it would be more beneficial to you in the long run.

It's why I like construct, well one of the reasons. Sure, the event system is basically a scripting language, but the way it's presented and used, is entirely visual and very appealing to a none-programmer. You can jump in and with very little effort, setup a complex working event without having to understand some confusing language or worrying about where to put a curly bracket or a semi colon. If the events were replaced with XML, LUA, Javascript, Python etc. etc. that would be a whole different story.

An example

http://www.effectgames.com/effect/#Arti ... sion_Guide

Not very newcomer friendly to someone with no experience in those kinds of things.

And before anyone says "But X language is eeeaaasssyy", yeah, course it is. So is working in Machine Code if you've been doing it long enough, but you wouldn't have a clue if you'd just come along and it would take months of solid learning to even understand the basics of it. The biggest userbase for programs like these are casual creatives, not coders. A proper coder could do more, in less time, by simply working from scratch, grabbing the libaries they need and doing it themselves. So when they start including complex scripting for more than the basic stuff, it sort of defeats the point and pushes a lot of people away.

Scripting languages - A programmer doesn't need them, an artist doesn't want them.

Besides, you're games on there are only allowed to be 100mb or less, at least that's how much storage space you get, unless you request more (for a fee? I don't know). 100mb doesn't go a long way these days.

Also being javascript, it looks like all your code is open for anyone to look at, take, change, it's not like PHP where it's compiled server side and only the output is shown to the client, or true programming languages that are compiled.

You're also relying on the site themselves, and problems they have, become your problems.

I don't like how their ident appears on your game as it loads either (I'm gonna guess "for a small fee" you can remove that, heh). Construct however doesn't force any of that on you, you can even change the icon and hide the fact you used construct completely, go sell your game and do whatever the hell you want. Because of that, I'm quite willing to say I used construct, but when it's forced on me, I'm looking for a way to remove all signs of it. To me it would be the equivalent of Adobe putting a "Made with Photoshop!" watermark on anything saved in PS. Or ads on sites, if I think your site is worth it, I'll donate, purchase your product or advertise you myself to others. Force ads on me and I'll keep ad-block and no-script on.

So yeah, that's just my personal opinion, I don't expect others to agree. But if I spend more time wrestling with a program rather than doing something productive with it, it's not for me.

This was originally just going to be a simple "yeah not a fan of javascript" reply, but I guess I felt the need to explain a little more, ya'll can wake up now

As soon as you hit save in the picture editor, the image is converted to PNG and stored inside the .cap. They're also exported to the runtime as PNG. So what you use before importing it doesn't matter, although I'd recommend something lossless obviously.

Awesome, that's good to know! Thanks!

>

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

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.