deadeye's Forum Posts

  • And looks like a lokijki game. If it weren't for the fact that I can actually see the sprites

    And those gravity changing arrows kind of remind me of something else...

    ... hmm, nope can't think what it might be

    Anyway, nice job so far . I'm assuming there's only one level? I get to the llama and it just stops.

  • When previewing games in fullscreen, you come back to the desktop and the Contruct IDE window has been shrunk down to whatever resolution your game was running at.

    Happens to me every time. I thought it was common knowledge.

  • Loading frame by frame just like sprite animation, so we basically need to split the mesh animation into single frames.

    Don't game model files generally have their animation stored in them already? Why would you need to import frames?

    Anyway, just to clarify, I didn't mean that there should be a modeling/animation window like the Image Editor for sprites. Importing completed models would be all that's necessary, there are plenty of 3D packages out there for modeling and animation.

    Again, if someone were to ever make a plugin

  • You're missing my point a bit - it's not just about collisions, that was an example of one of many areas that 3D in Construct would become a headache.

    As I said before, 3D-graphics-with-2D-gameplay is easy enough, and would be a good direction to move in. Construct as a full 3D game creator is what I'm arguing against. That means you need to start thinking about 3D angles, 3D trigonometry, 3D layout editors, 3D behaviors etc. etc. which IMO would be hard work to pull off.

    I'm not missing the point, I fully agree with you

    I'm arguing for 3D-graphics-with-2D-gameplay and against 3D-gameplay/editing. 3D behaviors aren't necessary for 2D gameplay.

    For the layout editor, placing models could be done similar to placing the 3D box. That would suffice, I think. No need for rotating the layout around or anything like that.

    But yes, I can see how it would be a big undertaking, it wasn't my intention to make light of that fact.

  • I'm not saying the devs should make a plugin, but I do agree with Arima... If a a 3D model plugin were ever to be made, it wouldn't need to have collision capabilities. Construct already does collisions just fine with other objects.

    A model could be used in lieu of a sprite to make games like Tomba or the new Bionic Commando, where the gameplay is purely 2D. The current method that people use to check collisions - with collision detector sprites - could be used in exactly the same way, but instead of an animated sprite, you set a model on top of your detector. You wouldn't need to have collision capabilities for the model at all.

    The only things that would really be needed would be the ability to rotate, scale, and translate the model (like you can with the 3D Box), and to change animations. The rest of it, collisions and whatnot, can be done in Construct in whatever way the designer chooses.

    Anyway, it would be a nice perk... perhaps some clever plugin maker will make a clever plugin for it someday. That's what open source is about

  • [quote:233ybvmz]Superfluous

    It's not superfluous if it's necessary.

  • Well, you could do it by getting the difference in angle from the torso to the mouse and the angle of motion for your player, but that's a lot of math that I wouldn't want to bother with so I'd just do something like this:

    Make four detector objects that follow the player, but do not rotate. Next, set up a series of image points for your torso, one in each direction. When the image overlap the detector objects, they tell that object what animation should play when the player moves.

    <img src="http://i42.tinypic.com/qracyc.jpg">

    Then, when the player presses a movement key, pick the proper detector that matches the key, get the direction that's stored in the private variable, and play that animation.

    It's low-tech, but it should do the trick.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • I voted! Good luck, guys

  • Heh, who needs floating points? "Ooh look at me, I have ten decimal places." Pff.

    Glad to hear everything is back on track

  • Oh my god, round() did the trick. Everything works perfectly now!

    Hehe, you're welcome

    It seems to me that scrolling should automatically respect point filtering as well, though. There's not much reason to scroll at sub-pixel increments if your filter is set to point. Don't know how hard that would be to implement as a feature, though.

    Except for my friend is still experiencing some weird rendering issues, like pictured below:

    http://img190.imageshack.us/img190/7717 ... eringw.png

    Any idea what could cause it? Surely float X/Y position of the sprite shouldn't be an issue?

    Not sure what the issue is there because I'm not sure what the sprite is supposed to look like normally. It could be something like your friend may need to update his graphics card drivers.

    But if it's a matter of it going funny at the edges, and you want total compatibility with different kinds of graphics cards, then you should try leaving a 1px blank space around the outer edge of your sprite animation frames. I know, that's probably a lot of hassle at this point, but from here on out you can do this automatically when importing your sprite frames by holding Shift and clicking Crop in the image editor. Of course, there has to be a larger-than-1px space around your sprite already for the Shift+Crop trick to work

  • It's a misnomer that 2D requires less power than 3D. Textures for 3D games are relatively small, and the images you see onscreen with huge landscapes and such are just the same textures repeated over and over again. You need to adopt the same mentality for your 2D games. That's why games over the years have used tiles... not because they want to, but because they have to.

    Graphics cards are optimized for 3D geometry. If you take the geometry out of the equation, you still have to abide by the 2D texture processing limits. And things like shaders require just as much memory for 2D as they do for 3D, so that's why Braid takes up just "as much memory as Oblivion."

    As for your other question... Instances of a sprite will always be faster than two sprites with the same image. Your graphics card isn't smart enough to see that the texture for one object is the same as the texture for another object, so it's going to store two textures in memory. If you're using instances, then you only need to store one texture. You can spam as many instances of one sprite as much as you like, and it's not going to affect performance, but if you have 10 different sprites with the exact same image then you're wasting VRAM.

  • Try rounding the scrolling x and y to a whole number and see if that does anything to fix it.

  • Compression algorithms like .jpg or .png only apply to the size of the file on disk. Once they're in memory, regardless of if they are .jpg, .png, .gif, whatever, they all take up the same amount of space.

    It's a computer thing, not a Construct thing. You just can't get away with making enormous sprites or backgrounds without bumping up the system requirements, and that's that, period, end of story.

    If you want to squeeze performance out of your sprites, then look into bone animation. If you want big backgrounds, then you will need to make a small set of tiles that you can snap instances of together to form larger images. That's just how it works.

    Yes, it means more work, and more planning, but them's the breaks.

  • Object: Set Width to global('variable')[/code:1vbb3qyv]

That should be it.

Things to double-check:
[ul]
[li]Make sure your variable is a number and not text[/li]
[li]Make sure you're using the proper single quotes[/li]
[li]Make sure you're not setting the width again after your event (this will override it)[/li]
[li]Make sure your event is triggering properly (all conditions are met)[/li][/ul]

If it's still not working then post your .cap.