LÖVE

Well my visual element is non-existent at the moment. Obviously I have a temporary display until the game is sorted, so I can write the classes to work in whatever way is optimal.

So if I am to use this technique, it would be best to use 'traditional' orthogonal tiles and not isometric tiles? That would actually make some parts of content creation much easier. Most interesting.

osa1 wrote:Can you explain what does `axono` function do ?

yes, i will try : it convert cartesian plane (X, Y) into isometric draw
(Z values are offset-ed later in -y axis)

imagine this is the logical map where 10 for example is (x=1, y=0) axono function will give you the coordinates to draw something like this

Version 0.085 : what's next to come ? (free-move-version ?)

keep up the good work !

That is just getting better, and better, Saegor.
By the way, maybe you might want to take a look at this game, seen in LudumDare 25 ? Awesome isometrics inside, too.

I don't know if it would benefit you to look at some of my code, as it is probably hard to read. The main difference I see between this and my engine are that this is based off simplicity, which makes it lightning fast. Mine has regular 3D and perspective with Rectangular prisms, but is rather... slow.

Your lighting inspires me to make complicated lag systems of realism

hello guys. i lost all my hdd in a format + wrong backup so i also lost all versions of isömap + ton of Lua/Löve notes

i got a netbook to write Löve code but isömap run on it at 15fps so i will light the code to run on even the oldest computer

darky : yes, free moves will come, i promise it to you

roland : thanks, i will throw an eye. maybe the author and me can exchange some isometric tips

xxx...xxx: my goal is to make a very light engine so maybe you can find some inspiration in my code (but i'm not an experienced programmer, so maybe not)

i also plan to write games for kids (~3 years) so if somebody is interested to make that with me please send me a PM or use telepathic contact but not after 21:00

I've been working on some stuff related to this project. The attached LOVE file features a cube that can rotate, and which has "skins" attached to its sides. I'll should be able to apply it to whatever new Isomap you eventually come up with.

@sanjiv I see you got some gimbal lock goin' on there. Nice notes too.

Based on the constraints I've put in, the vertical lines in the cube (hopefully there's a pic up) will always be vertical. I initially put this constraint in to simplify the math, the code, and the controls, but now I wonder if I'll regret not including rotation about the z axis (see diagram below?).

-y
|
|___ x
/
/
z

I think the rotation I've put in is enough, because if you want to rotate across the Z axis, just rotate the screen. Yay, nay?

on a related note, the way I've measured the various axis lines is by skewing a diagonal line along the x and y axis. All lines start off as that thick, diagonal black one, and then by applying skews to it (sx or sy), you can get horizontal or vertical lines, or anything in between as needed.



There are three lines (X, Y, Z), and they are skewed differently, to represent different dimensions in 3D space. So you'd have variables like
xsx and xsy
zsx and zxy
ysy -- note that the vertical lines are always vertical, according the limits I've put on rotation here. So no xsx

So I'd reuse those values when drawing a grid full of these cubes, or whatever. Have any of you run into unusual problems following this strategy?

sanjiv wrote:Have any of you run into unusual problems following this strategy?

i'm sorry but i don't understand the way you draw your cube, so i will take time to read your code and try to make some light on that
take care of using very simple logic when you want to put everything together for a larger code

my code is limited in rotation cause it's the scale of the cube's faces that change (there is no true rotation) and i can't rotate in Z axis cause the axono/isometric calcul is failry simple