ID:267125
 
I was just woundering if it is possible to change your view. Say u had an isometric view so its slightly angled at the side. Could u rotate that view so its 90 degrees to that first view. Like you were looking at the front side of a house. Then you would rotate and it would move to the side back of the house.

Maybe you could make a variable engine so you could only see in that view while others still see in the other view. or maybe you could use the map and change it with every rotation some how.

Reason why I am asking is because I wanted to make a sim and in some sims this rotating is possible. Thank you if you can help. If not I don't blame you.
client.dir allows you to rotate the screen. However, to do what you describe could be kind of tricky. Here are some thoughts:

* client.dir keeps the icons' appearance the same when the screen rotates, so you'd end up with a garbled mess unless you reset the icon states after rotating. And of course this could cause big problems if it's a multiplayer game -- you'd probably need a separate map for each player. But that actually wouldn't be too tricky to do -- just create a datum that represents the "real" map, and whenever it's updated by any player, it automatically skims through all the player maps and makes the corresponding update.

* Come to think of it, isometric views typically expand the X axis of the graphics, so a normal square tile on the floor looks like a wide, flat diamond. So when you rotate this, everything is going to look tall and thin, and just plain goofy, unless you recalculate the display. So you might actually want to maintain two maps for each player! One would be the map for looking north or south, and the other would be for looking east and west.

Boy, you've got me thinking now... this might be a fun BYONDscape library to work on... :)
In response to Gughunter
Gughunter wrote:
client.dir allows you to rotate the screen. However, to do what you describe could be kind of tricky. Here are some thoughts:

* client.dir keeps the icons' appearance the same when the screen rotates, so you'd end up with a garbled mess unless you reset the icon states after rotating. And of course this could cause big problems if it's a multiplayer game -- you'd probably need a separate map for each player. But that actually wouldn't be too tricky to do -- just create a datum that represents the "real" map, and whenever it's updated by any player, it automatically skims through all the player maps and makes the corresponding update.
Hmmmm iv'e never used a datum before. How would I make a datum represent the real map?
* Come to think of it, isometric views typically expand the X axis of the graphics, so a normal square tile on the floor looks like a wide, flat diamond. So when you rotate this, everything is going to look tall and thin, and just plain goofy, unless you recalculate the display. So you might actually want to maintain two maps for each player! One would be the map for looking north or south, and the other would be for looking east and west.
Hmm it has come to my attention this might be out of my league :).
Boy, you've got me thinking now... this might be a fun BYONDscape library to work on... :)
In response to Green Lime
Hmmmm iv'e never used a datum before. How would I make a datum represent the real map?

Something like this would do the trick:

mapObject
var/turfs[100][100]

proc/SetTurf(myX, myY, turfType)
turfs[myX][myY] = turfType

Though it occurs to me that you'd probably be better off, all in all, just reserving a map level... that way you can just keep track of actual turfs.


Hmm it has come to my attention this might be out of my league :).

Heh... yeah, it's a little involved. Wish I could think of an easier way, but isometric graphics are just plain tricky. (DDT -- Deadron, Gazoot, and I -- have made an isometric game called Living and Dead, which you can play from the Hub, but we don't try rotating the screen. It's tough enough just getting it from one angle!)
In response to Gughunter
Another question how do you recalculate the map icons when you have changed your client.dir = SOUTH?

I was thinking somthing along the lines of
for(var/atom/A in world)
and then use A but I dont know what to do next am I close?
In response to Green Lime
I was thinking somthing along the lines of
for(var/atom/A in world)
and then use A but I dont know what to do next am I close?

That sounds right to me. I haven't played with client.dir in a long, long time, so I don't remember exactly how it works. I imagine you'd want to find every atom, as you noted above, and change its .dir value. It's possible that client.dir already uses directional icons wherever they're defined -- I just don't know. And it's too late at night for me to experiment. :)

In response to Gughunter
I tryed the for(var/atom/A in world)
and then A.dir = turn(A.dir, 90) but it doesn't move.
Only thing I can come up with without testing it is I dont have the diffrent dir's for the icons so they just don't change. So I tryed this A.icon = turn(A.icon, 90) and WOW lag city!

I was just woundering of what u think? Which do you think would be better to use I mean?
In response to Green Lime
Green Lime wrote:
I tryed the for(var/atom/A in world)
and then A.dir = turn(A.dir, 90) but it doesn't move.
Only thing I can come up with without testing it is I dont have the diffrent dir's for the icons so they just don't change. So I tryed this A.icon = turn(A.icon, 90) and WOW lag city!

I was just woundering of what u think? Which do you think would be better to use I mean?

Probably your best bet would be to create directional icon states for the icons (the icon editor makes it easy to rotate the base graphic). Otherwise, you could create a list of pre-turned graphics for each type, like so:

var/list/eastTurns = list()

world
New()
for(var/MT in typesof(/mob))
var/mob/tempMob = new MT()
eastTurns[MT] = turn(tempMob.icon, -90)
//(Of course you could add other directions here!)
del tempMob

Then when you want to turn the icon during the game, instead of calling turn(), you could just set the icon to eastTurns[someMob.type]. That would probably be lots faster.