Let me start by saying this: I love the isometric worlds that you allow us to build. I absolutely -hate- the way that client.view is handled.
We have never been able to directly set the resolution of the game. Instead, we have always used client.view to determine resolution. When 4.0 was released, we could use the interface to determine the scale of the map. Once big icons were introduced, we could use icon_size and client.view to manually set the client's screen to an even larger array of resolutions.
But, when moving into the realm of isometric projection, all of that is thrown to the wind. We are given a method, an obtuse formula for finding the resolution of the screen, but no method for actually setting it.
Will we ever be given a way to set the native resolution of our games? Can we at least be given a decent method of setting the resolution in isometric games?
ID:1067133
 Nov 26 2012, 8:13 pm
|
|||||
| |||||
Well, it's bad enough that there's no easy way of getting the native resolution of the client, without using interface hacks, or the JavaScript method you came up with.
What we really need is for client.view to work pixel-perfectly. If it did, then we could just determine the resolution, and calculate the client.view based on that. We already have built-in pixel movement, so now we need to be able to adjust the client's view accordingly. This would also allow for cool effects, like smoothly transitioning the view "inward" or "outward" as the land's elevation changes. Anyway, I'm not sure why isometric view in particular, would make the tile-based view size any worse, unless it has something to do with the icon_size not being square. The engine seems to handle client.view in isometric as I would want it to; counting the tiles vertically and horizontally, instead of along the diagonals. What exactly is bothering you with client.view in isometric format in particular? | |
There's also an issue with how laggy client.view makes the game at larger sizes. On a 64 world.icon_size an 11x7 client.view causes horrible visual lag. This is on a 1.8Ghz Dual core CPU with a built in Radeon HD graphics chipset. Increasing the view just a bit more renders my Desktop with 3.2ghz dual and a Nvidia Geforce GT440 has issues.
It's like, I can run Skyrim with maxed out graphic settings at 60fps, but I can't play byond properly if it has less than half of that resolution in pixels on-screen. What's up with that? | |
Bumpity.
| |
I was talking to a few people today about exactly this and we were all scratching our heads. So bump.
| |
I was also recently wondering how to change resolution without changing view, since variable sight distance can lead to unfair advantage in some games. I came up with an idea of handling it on my own using screen objects and some winget() foo, but ultimately an easy, native way to change resolution without changing view would be spectacular. The HUD could be constrained to the resolution and/or view. The HUD objects could be anchored like skin controls, and/or scaled uniformly (ideally) and/or non-uniformly to fit the screen. Just tossing ideas out there. Dream Seeker might need a better rendering method, though.
| |
Bump again.
| |
I'm actually confused on what this request is even asking.
| |
It would be nice to have a built-in function to control resolution. It is a complete headache in isometric mode to determine the appropriate math and interface foo, and even then, most resolutions will result in black barring.
If a setter method is out of the question, it would be excellent to see an example given in the documentation on how one might set the size of an isometric viewport. | |
Letterboxing will happen any time the map control uses auto-zoom and is not the exact aspect ratio of the visible map. (Alternatively, letterboxing can be disabled and then the map crops out excess pixels.) That's a function of the interface, not something that would make any sense to try addressing at a proc level, so this goes back to why I'm confused about what's actually being asked for here.
The calculations themselves are really not difficult. In isometric, the logical view (by tiles) is always square; the physical view (what's on the screen) is rectangular, extensions from the HUD notwithstanding. For a logical view of NxN, and an icon width W, the physical view is W*(2*N+1) by W*(2*N+1)/2, although the physical height is then rounded up to a multiple of the icon height H. If you want to fit a given width or height for the map control, then you just have to invert the formula. From map width Mx, the formula is N = ceil((Mx/W - 1) / 2) From map height My, the formula is N = ceil((floor(My*2/W) - 1) / 2) | |
One thing worth noting is that some of Ter13's recommendations for improving HUD positioning stuff are going in to 512.
| |
Regards.