ID:11180
 
I've been experimenting with an isometric engine for a while, and this is the final fruit of my creation:

http://developer.byond.com/hub/Jp/IsoEngine

I might use it in Arena's battle system at some point....

(And thanks to Jon88 for some assistance he rendered in Wizchat when I was having problems)

(Oh, and I'm aware that it isn't, strictly speaking, an isometric projection, as one axis is 'squished' compared to the other. Just using the common term rather then the technically correct one)

EDIT: The isometric engine has gone through several changes, to make it more library-worthy. Now it's an actual library you can include and use properly. It should also be a little faster, as I've incorporated several of OFD's suggestions into the little guy. There isn't a helpfile yet, but I'll be writing one.

This seems like BYONDscape material to me... Hmmm...
That is very neat- perhaps I'll use it sometime. Good work!
Really good engine. But I have 1 problem. This isn't true isometric, rather it's semi-isometric. But anyway, im probaly going to use it for my game sometime in the near future.
"(Oh, and I'm aware that it isn't, strictly speaking, an isometric projection, as one axis is 'squished' compared to the other. Just using the common term rather then the technically correct one)"
Looks really nice! I'd definately like to see that engine used in a game.
why are north and south inverted?

it looks nicer if you make k = 16 and j = 8, then modify the icons accordingly. things just line up nicer that way.

some things you might want to try to improve its speed:

using a list of existing screen objects and modifying them, or swapping between two lists to buffer it (as opposed to creating a whole new set of objects each iteration).

using a separate list of screen objects for mobs and split the screen updates into two functions, UpdateTurfs and UpdateMobs. you need to frequently update nearby mobs in case they've moved while the player hasn't, but you probably don't need to update all turfs until the player moves.
lol Pawned by OFD the IsoMaster :P
Yeah, this is just a first attempt. OFD's probably better at this then I am. :P

why are north and south inverted?

Because I liked the controls better that way. Now that I've got the basic thing running, I'm properly libraryising it into something you could just include into a game - you can pick your own control scheme then.

it looks nicer if you make k = 16 and j = 8, then modify the icons accordingly. things just line up nicer that way.

The library will allow for changing k and j (Well, xsize and ysize in the actual library) in a dynamic way. Plus, I can't draw, so it wouldn't look too good either way.

using a list of existing screen objects and modifying them, or swapping between two lists to buffer it (as opposed to creating a whole new set of objects each iteration).

Hmmm.... That's a good idea. I'll try that one.

using a separate list of screen objects for mobs and split the screen updates into two functions, UpdateTurfs and UpdateMobs. you need to frequently update nearby mobs in case they've moved while the player hasn't, but you probably don't need to update all turfs until the player moves.

That's also a good idea. Thanks for the help, OFD!

One question, though - Am I remotely close to how The Royal Nonesuch was done? Just for curiosities sake.
One question, though - Am I remotely close to how The Royal Nonesuch was done? Just for curiosities sake.

yes and no...

there were a couple of different incarnations of that project. the first one, you're not very close to, but you don't want to be close to that one. it wasn't very good. (it calculated the angle and distance to each object and placed it on the screen accordingly. none of those calculations are particularly quick, and it resulted in decimals being rounded so things would appear to "shake" when you moved. one time the decimal would round down and the turfs would line up nicely, then you move and some round off differently and are a pixel off.)

later versions, you're kinda close to. basically, instead of having a constant for j and a constant for k, it used lists. j and k varied based on the direction the camera was facing.

using lists of values for j and k ensures that the gaps between tiles is standard, so there's no rounding of decimals and no problem like earlier versions had because of that rounding. also, its a lot easier to multiply some integer j by another integer to find the position on screen than it is to find the angle and distance to the object.

http://members.byond.com/OneFishDown/files/trn.gif

the top part in that picture shows a view similiar to yours. to increase the x coordinate by one you must move 16 pixels to the right and up 8 pixels. to increase the y coordinate by one you must move 16 pixels to the left and up 8 pixels. those numbers, 16 and 8, (ignoring the sign of the numbers) are the same for both the x and y axes. that makes things seem simpler than they are. so, it can be hard to make the jump to a rotating view because you might not think of what you have as being so complex (but it is!).

the bottom part of that picture shows what the tile might look like when you rotate it. well, it looks like it shrunk a bit, so maybe 18x5 and 7x7 weren't the best numbers. but, essentially that's all you have to do, tweak those numbers until it looks nice and make all the icons fit with those numbers. then, based on the angle the camera is facing, you use a particular set of those numbers and the appropriate icon.
So how did you change the icons as the view was rotated? Did you just have a different state for various angles? 'Cause I can't see any other way of doing that in BYOND. :P

Incidentally, if I have a a list of references, Copy()ing it just provides another list with those references instead of cloning every entry, correct? I've got the modify-screen-objects going for turfs, and it uses a buffer, so now I'm wondering if that's possible at all for movable objects. I'm thinking no. So I'll just do that one the same way as I used to do turfs - keep making new ones.
the mobs list is slightly different because you won't always use the same number of objs. you can just keep track of how many are used and after you've drawn all mobs if there are used ones left just make them blank.

So how did you change the icons as the view was rotated? Did you just have a different state for various angles?

yes. but a lot of tiles could be done with only 4 icon states (and have a total of 16 directions).
Very nice.
Okay, this is weird. The engine appears to fail in multiplayer - anyone that isn't the host gets a wide variety of graphical errors. Any ideas why?
I think I've figured it out, and now I'm really ashamed. I believe it may have been usr abuse - I was using range, and for some reason I'd left off the 'this is the centre' argument.

Just goes to show how insidious and destructive usr abuse is.
usr abuse gave me some serious form problems heh, but I really like the system. I plan on making a walk through forest with it. Just something to do in my free time or when I'm somewhere boring without internet access. I'll post screenshots soon.