I think we're on the same page, Ashley - I also don't think construct as a full 3D game creator is the right way to go. I was also arguing for construct to stay the same as it is with a mesh object that behaves the same as the 3D box. No 3D rotations of the layout, etc, or even 3D behaviors. Just a 3D box that loads a mesh.

I also did not intend to make light of the difficulty of making construct full 3D. I merely thought that it would be much, much easier to make a mesh object instead, since it seems like most of the work had already been done.

I would be happy even if it didn't have animation capabilities!

3D collision detection is probably more than necessary, and 2D collisions can already be done via pasting a 3D box to a canvas and using the canvas for collisions. Then you could do a simple compare of the z position of the object and a collision check with the canvas.

While it would be lacking stuff like 3D collision detection, Construct IS primarily 2D. If people want stuff like that, as has been said, there's other engines made for it.

I'm not trying to be stubborn either, just trying to understand why the 3D box couldn't be modified to basically load a model with no other modifications.

Edit: clarifiying - the reasons that you've said for it being difficult (aside from new features) already seem to have been done in the 3D box object, which is why it's confusing.

> Plus rotating objects for things like huge battleships in shoot em up games are a bitch to animate. You hardly ever see objects rotate around their x-axis (roll axis) in 2D because it's such a pain to animate correctly. In 3D, however it's easy as simply rotating the model around.

>

well, this is a pretty specialized use. You would have a heck of a lot more trouble coding 3d models than 2d sprties.

I don't think this is a good reason. The 3D box is very easy to work with, and a mesh object would theoretically have the same commands.

Also, you can make objects roll with animations, as i'm sure you know. Even though it uses a lot of vram it's possible, and it's super easy to do with rendered sprites.

I disagree, it's not really a specialized use at all - it's quite common. There's a lot that can be done easily with 3D models that is unrealistic with sprites - like rolling an object that takes up the whole screen, or an environment that's a 3D model with 2D sprites moving in it. Even if you limit it to 512s, that's a LOT of texture memory. Not to mention if you want to roll at any other angles.

I don't understand why everyone seems so against 3D here when people are at the same time talking about how awesome the attempts are to bend the sprite distortion into 3D models.

It's not about making crysis in construct - all that's really needed is a 3D box object that loads models to make up for what sprites aren't good at. A 3D box is already in construct, why is everyone so against a 3D mesh object?

I don't think construct should go full 3D, but I really really think that a mesh object should be made that acts the exact same as the 3D box but displays a fully textured custom model. The 3D object is easy to use and versatile enough that a lot could be done with it, and no modifications would be needed to be made to the editor to do it. This way it retains the ease of use of construct and has more power.

For example, I'm making a gradius style shooter. With it, I could have massive starships that can move and rotate about easily - without, I have to use massive amounts of VRAM.

While I would like some basic features like basic lights, 3D 'hotspots' placement (to make it rotate at the correct location and to make objects that have multiple parts), camera controls to move about in 3D space, and maybe something like a 3D bullet behavior would be nice, but none of those are really necessary. A 3D object version of the box object alone would be awesome.

I was playing with motion blur and found that even my new 9800GT stutters occasionally with it. I was reading up on it on the web, and found another technique that involves using a velocity buffer to determine how to blur the scene - which means the screen doesn't need to be rendered multiple times per frame, and doesn't leave gaps on fast moving objects.

Theoretically, it seems like this technique would be both faster and provide better image quality, though I'm certainly no expert on it. Would this be a possibility in construct 2?

Update - It turns out it wasn't enough. Not because of the wattage - because of the amps. Apparently, adding up the amps across all the 12v rails for the total is not true - each rail is limited to what it says, so even with a 500 watt power supply, the graphics card was still asking for almost double the amps that the power supply was rated for!

Solution - when shopping for power supplies, make sure to check the amps needed for the card, and get a power supply with ONE 12v rail.

Here's the reading for anyone who wants to understand everything about power supplies - and really, it's important: http://www.techjamaica.com/forums/showt ... hp?t=52054

Upon using "play animation" construct sets the animation frame to 1. I have a scenario where I want a bunch of particles to start on different animation frames. I can set the frame to random, but that pauses the animation. Using play to unpause it puts them all on the same frame again.

I suggest that using play animation should play from the current frame.

Awesome! One feature that's really needed - accurate word wrap. The current text object will write a sentence, and if a period gets wrapped, it doesn't wrap the word with it - like this

.

Ashley said it's an issue with direct x that they can't do anything about, so it would be really nice if your plugin wraps correctly.

I doubt this would be a possibility for 1.0, but perhaps for the 2.0 rewrite? I was watching videos of hardware accelerated physics demos pushing like 50,000 or more objects around, which would be awesome for fluid simulations or such. Thoughts?

Wow, awesome!

I'm making a prototype where I want to have a lot, lot of objects on screen. A lot of those objects are unnecessary after a certain point, because they're obscured by objects in front of them. Is there any way to tell if an object is obscured?

Edit: Alternatively, I might be able to check if two of the same sprites are on the same x/y and have the same angle and perform an action on one, but I'm not sure how to do that.

You'll want to set the zoom based on the distance between the two. Try:

Always

Set zoom to dist(player1.x, player1.y, player2.x, player2.y)

You're going to have to tweak the equation to get it to zoom the right amount, like multiplying it by some amount, but that's the expression you'll use.

I can't remember, is zoom 50 smaller or larger than 100%? The value might be backwards.