no, you can do it with events. its 3d rotation. why do you even need anything relating to a 3d box object. just get the yaw pitch roll, and theres no reason to even use a 3d box, since yaw pitch and roll are all just numbers.

why does a camera relating to a 3d world need to refer to a 3d box object at all???

its essentially the same thing to rotate the world. theres no such entity as a "camera", you'll always be rotating and translating the vertex cloud around a fixed point. that point is the "camera". in anycase, you wont be able to actually manage the 3d programming in a game if you can't make a simple camera using events. theres no EASY way to do 3d programming in construct, and i'm skeptical there ever will be in the near future. The quality of the graphics have nothing to do with it.

you can only rotate the world. there is no other way around that fact.

a camera facing towards you is the same from top left right bottom back front. the only thing you need to alter is your graphics. to be viewed from that angle. saying you have a problem with the camera facing top when you want a side view, is like complaining the 2d plane in construct is only letting you make top down games.

As for a camera thats not oriented on an axis, thats more of a "should you be using construct for 3d games" kind of question.

EDIT: misread your post a bit sorry. any way you look at it, making a true 3d game where you move around in 3d is not the best idea in construct, and its never going to be easy, because 3d isn't. construct isn't made for fully fledged 3d games, it just has some 3d functionality. if you really wanna do it, learn the rotation math yourself, its not "easy", but its not all that difficult either.

the wolfenstein 3D demo and my mode7 example do exactly what your asking for with events. and in not at all that many.

you need to focus on testing what each object does for yourself, its not that difficult. look at the actions conditions parameters etc of each one, and try to do little tests based on little hypothesis you have as to what each might do.

As for expressions, theres not all that much too them besides math and a very basic syntax.

whenever you see an object name followed by a dot, it means its returning whatever parameter after the dot as a number, or *rarely* a string for that specific object.

so sprite.x, is returning the x position as a number for the object "sprite", so if the object is at x=24, sprite.x=24. etc, this goes for all "after dot" parameters, like .angle, .y, .width, etc. theres too many to list. if the condition that expression is running for picks an instance of sprite with its logic, then sprite.x will refer to the sprites which have been picked.

if you see ONLY a .x .y .angle etc. that means that it is choosing the object type specified in that specific action.

so lets say we have the action... set sprite's x position to: sprite.x+other.y+5

you could :

also write it as the action......... set sprite's x position to: .x+other.y+5

you don't need to write "sprite".x, because sprite is already the object being referred to in the action.

both do the exact same thing, except one is cleaner and quicker to write.

brackets, multiplication, division, etc. all follow the basic BEDMAS you'd expect to use in any math. think of expressions as any other mathematical equation, where the result of the expression is your answer.

http://sourceforge.net/apps/mediawiki/c ... xpressions

basic expression stuff and what each is...

private variable are the next BIG thing you need to know, basically, anything encompassed in single quotes like 'your variable' is a private variable of an object.

now remember how you can have sprite.x and .x mean the same thing based on what the action is blablabla.

the same goes for PV's, except its a tad different. you can have...

Sprite.Value('Variable name'): which nobody really uses, since its long compared to:

Sprite('Variable name') : this does the same thing in EVERY situation at the above.

'Variable name' : without brackets or sprite, works the same as the ".x, .y, .angle"

these are the MAIN and i'm pretty sure ONLY things you really need to know, because i get along fine with just this knowledge, and I write some of the most complicated expressions around.

of course theres also the oh so important

http://sourceforge.net/apps/mediawiki/c ... xpressions

system expressions work as described in this well written wiki page. look over it, because it gives you those "simpler" ways of doing things.

of course just knowing HOW expressions look and work doesn't mean you can write them, but at least now you can apply your mathematical knowledge to expressions.

math is the only way. i can't make that any less true, and i wont explain math either, theres enough of that EVERYWHERE to help you. Google is your friend.

if youre comparing actual individual objects' variables its a better idea to use "compare private variable" on said sprite/object instead of a system compare. system compares DONT evaluate for each instance, they evaluate only once.

can i hug you all.

yea they're made of distort maps

its 3d shapes sorted in with the sprites, and the way i set it up, it makes iso sorting a lot simpler, you wouldn't have to fiddle with all the stuff you normally would doing iso sorting with odd shapes

its just way easier to use the z buffer than to use the old send to back send to front stuff.

you can implement your own A* algo using events

http://www.policyalmanac.org/games/aStarTutorial.htm

or play around with rts, but i never got rts to work

nice one

im pretty sure what your experiencing is not due to the high object count, but probably due to the code that controls them not being built for so many instances, and perhaps framerate, and the z ordering.

i never saw any bugs when i had a ton of objects. although it would be nice to see this cap file, instead of having to recreate it ourself

i think these rumors are fake at this point.