So, my artist changed a 32x32 turf icon into a 64x64 icon and now my map is all wonky. The map has many irregular shapes and diagonals making it a pain in the butt to manually add this 64x64 grass. I was hoping to find some sort of variable to where the turf could have knowledge of its dimension and not overlap itself every 32 px but every 64. Can anyone think of a good shortcut to solve this tedious and probably inevitable task.
| |
I don't exactly recommend this, but I guess it would work if you are determined to use a 64x64 grass icon with a world.icon_size of 32.
Take your 64x64 icon and split it up into a 32x32 icon with 4 icon_states named like so:  Then add something like this: world/New() That creates all manner of nightmares if you are trying to do any autotiling, and probably lots of other things, but it would work for something basic. | |
Flick's got a great idea of what he's talking about here. Only question is why world/New()?
turf/grass/New() | |
I've had startup issues when putting stuff in turf/New() with large maps. Just a habit I got into and never tested again. Started many versions and a number of computers ago, so it might not be an issue anymore. Hell, it might never have been the real issue and was something else in my code that got fixed accidentally... :P
EDIT: Might have been when I was messing with autotiling, and I think I was having timing issues with turfs not being created when other turfs were trying to check them. That was probably a 1000x1000 perlin generated map running on a toaster though... | |
I've had startup issues when putting stuff in turf/New() with large maps. That can happen depending on what you are doing inside of turf/New(). Also, the whole map isn't always initialized when turf/New() is called, so a lot of people have a habit of putting a sleep() or spawn() in there. This is usually what causes the catastrophic load times in turf/New(). http://www.byond.com/forum/?post=2012623 Scope out Snippet Sunday #10 for an explanation of what's going on during world setup. | |
Yeah, that sounds about right. And since I usually am doing a lot of autotiling and stuff in turfs, I just have world/New() call a turf/init() proc after loading. Sounds like it wouldn't be necessary here. Good to know, thanks for the info.
| |
Scope out the new StdLib for PostInit() flagging. You might find that interesting.
Also, AutotileLib might be of interest to you now that it's fixed. | |
That and MoveLib are currently open while I try and work out a sidescroller method. :P
| |
I love you guys :D
| |
What is "x&1" I know x is the x coordinate but &1
| |
& is a binary operator. When given two integers, it results in the bit-wise AND of them.
In this case, the operation happens to match what you want, because it results in 0 for even numbers and 1 for odd numbers. | |
That's a test to see whether the x/y coordinate of the turf is odd or even. x&1 evaluates to TRUE or 1 if x is odd, and to FALSE or 0 if x is even. I'm pretty sure there is a post about bitwise operators around somewhere...
| |
id:39760
Also a ton of info in this one. id:2078491 There is a pretty good explanation of how & (and others) works at the bottom of that post. | |
Actually, wouldn't you want it the other way around? For the bottom-left of the turf to be correct at the bottom-left of the map, you would need the bottom-left to have the state "0,0" at coordinates (1, 1).
| |
Yeah, I guess you'd want to swap the names for the bottom-left and top-right corners and also for the top-left and bottom-right.
That's what I get for testing with a solid green icon in the middle of a map. | |
Yeah a solid green icon certainly isn't a good test object. So, neither icon_state = "[x&1],[y&1]" nor icon_state = "[x&0],[y&0]" worked.
| |
You want to flip the 1 to 0 and vice versa. Here are a couple ways to do that:
// Subtract from 1: | |
Yeah this method doesn't work. It produces weird layering glitches when walking.
| |
Here you go: