ID:151954
 Aug 17 2008, 10:09 am
|
|
Just a thought, but it could potentionally look nicer, I guess.
| |
Here is a tutorial on what your talking about.
http://www.byond.com/members/PixelArt/forum?id=4333 | |
Actually I think things like this are a somewhat good idea to keep it slightly more varied and less 'tiled'.
DarkCampainger wrote: Not to mention players would have to download all the turned states... But this isn't really relevant, since this is exactly the same whatever you do, random pre-made states or anything. | |
One option you could use would be to use multiple icons and present them in a "turned tile" format. Incursion's water uses 5 tiles arranged like so:
12345 45123 23451 51234 34512 The key arrangement to this pattern is: 1 1 1 1 Within a 5×5 space the tiles contain 5 squares that are slightly turned. If you draw a tileset like this yourself, you just have to respect that pattern with any pixels you lay down (a big brush setup to use this pattern would work). In Incursion's case, I had the water generated by a small Java program. Alternatively, you can draw the rotated square as a sort of template on a 96×96-pixel grid, and then stamp it into the correct positions on a full 160×160 image. Lummox JR | |
I like to create 4-5 icon states, usually 4 because I can just rotate the one grass tile. I used to use icon.Turn(), but that is far too slow on maps with a lot of grass icons. On Grass.New(), I just pick an icon_state at random.
turf/Grass | |
CaptFalcon33035 wrote:
I used to use icon.Turn(), but that is far too slow on maps with a lot of grass icons. Not if you do it properly, of course: 1) use turn() instead of creating an /icon object if you don't need to run other operations on it 2) cache the results so you only call turn() 4 times instead of hundreds of times. =P But yes, the Icon Editor supports turning easily, so you can do it there and save the tiny delay on startup only, I suppose. | |
Another problem with turn except for it potentially causing a ton of lag if used incorrectly is that the grass might not tile together properly if rotated. And you basically end up with a field of grass where you can clearly see each tile (because of where they cut off and do not "join" with other tiles visually).
But yeah, make use of a few different (but tileable) grass icons, and randomly pick one under New(). You can basically do this for most any surface that has some randomness to it. I've used it for all kinds of terrain, grass (long and short), dirt, sand, snow, rock, cliff faces, man made surfaces such as pot holes in roads (randomly with a small chance of there being a pot hole). It can even be used to add things like cracks in walls. I even do this for objects like trees, flowers and other small details that can be randomized. Only downside is how the world will in effect be different everytime it is started up, but since these are only very small details most players wont notice it doesn't matter too much. | |
Kaioken wrote:
Not if you do it properly, of course: 1) use turn() instead of creating an /icon object if you don't need to run other operations on it 2) cache the results so you only call turn() 4 times instead of hundreds of times. =P turn() returns a direction, not a rotated icon. typecasting adds minimal delay. And why cache those results when they give you the same output as rotating the icons themselves in the icon editor, but with more work? I'll take the way that doesn't include unnecessary delay and work. | |
CaptFalcon33035 wrote:
turn() returns a direction, not a rotated icon. Nope, it does when used with an icon instead of a direction. Use the DM Ref. :P typecasting adds minimal delay. Defining the type for the initial var causes no delay and makes a difference only at compile-time, and you shouldn't use re-typecasting for this anyway. So no, I wasn't talking about this and you made up/confuzzled that I was. There is a proc version for using on normal icon files, so you can simply use it instead of converting the icon file to an /icon DM object first. And why cache those results So you don't re-create the same result again for each grass tile as per your apparent initial implementation, why of course, as I said previously. when they give you the same output as rotating the icons themselves in the icon editor, but with more work? I'll take the way that doesn't include unnecessary delay and work. Actually, I don't have anything specific against that method, but I take it typing 3-6 code lines is faster and easier than opening up the DM Icon Editor and manually editing and saving multiple new icon states, so that would be the extra delay, not the code method (unless you're a slow typer). It's not difficult at all, even with the caching, and you're able to do it. Of course there is slight startup delay, but no one's there to feel it at that time, provided it's even noticeable to begin with. ;) | |
Kaioken wrote:
Nope, it does when used with an icon instead of a direction. Use the DM Ref. :P So I fail once again! Defining the type for the initial var causes no delay and makes a difference only at compile-time, and you shouldn't use re-typecasting for this anyway. So no, I wasn't talking about this and you made up/confuzzled that I was. There is a proc version for using on normal icon files, so you can simply use it instead of converting the icon file to an /icon DM object first. I was talking about this. I was saying that using icon.Turn() makes no difference since turn() does the exact same thing. I don't think there is any conversion involved, either--just typecasting. So you don't re-create the same result again for each grass tile as per your apparent initial implementation, why of course, as I said previously. I take it that's a joke? Why would you split up a sentence to take it out of context? Actually, I don't have anything specific against that method, but I take it typing 3-6 code lines is faster and easier than opening up the DM Icon Editor and manually editing and saving multiple new icon states, so that would be the extra delay, not the code method (unless you're a slow typer). It's not difficult at all, even with the caching, and you're able to do it. You make it sound like the icon editor is a chore. We're talking about copy/paste/rotate. It's not very difficult. I can, in fact, do the same exact thing for what you've suggested. Observe: Actually, I don't have anything specific against that method, but I take it that using the icon editor is faster and easier than writing a procedure to rotate, cache, record, and pick the icon state used by every single grass tile. So that would be the delay, not the icon editor. But, I think you should take into account not just specific systems, but entire systems. He may have other things working in world.New(), datum.New(), and atom.New(), and maybe such a system adds too much delay to the collective delay that is already there. Of course there is slight startup delay, but no one's there to feel it at that time, provided it's even noticeable to begin with. ;) It is likely they will notice on world.Reboot() when all of the other New() procedures are being called as well. | |
CaptFalcon33035 wrote:
I was talking about this. I was saying that using icon.Turn() makes no difference since turn() does the exact same thing. I don't think there is any conversion involved, either--just typecasting. Well, obviously there is object creation involved in icon() or new /icon, and there is 'conversion' of the DMI file to an /icon object, which is basically an "opened"/loaded version available in memory to be manipulated, and it is automatically converted back internally when you say, set an atom's icon to an /icon object. This is also in the DM Reference. >__> I take it that's a joke? Ya, it kind was. ^_^ You make it sound like the icon editor is a chore. We're talking about copy/paste/rotate. It's not very difficult. I can, in fact, do the same exact thing for what you've suggested. Observe: Yes, but I don't mean either is a chore, I simply meant opening various DMI file(s) and states and working manually on each of them and duplicating them to create new states is most likely more time consuming than quickly typing up a few lines o' code. But, I think you should take into account not just specific systems, but entire systems. He may have other things working in world.New(), datum.New(), and atom.New(), and maybe such a system adds too much delay to the collective delay that is already there. Ah, but that is beyond the scope of my example. =P I can do the same thing. Observe: But, I think you should take into account a possible existing game, where the icon_states limit per file may have been reached, and the user can't add any more icon_states like you suggest as it will go over the top of the amount of states already there! Bla bla. <_< >_> It is likely they will notice on world.Reboot() when all of the other New() procedures are being called as well. Because you're doing caching, they're really not likely to notice, and as I said probably the 4 calls to new /icon will be over before they get a chance to relogin (don't quote me on this I suppose?). Well yeah. Pretty silly argument since I support your point too, just that it's faster for me to type up this rather than start messing with icons: world/New() It will also avoid icon_states clutter of identical (but rotated) states inside your physical DMI file when editing it, although when running the game the extra icons will still be loaded up to the RSC as with the other method. But you don't SEE the clutter then! >_> | |
The Magic Man wrote:
Only downside is how the world will in effect be different everytime it is started up, but since these are only very small details most players wont notice it doesn't matter too much. This problem can be eliminated with the rand_seed() proc. Basically just set the seed to a value based on the tile's x,y,z before calling any of the rand() functions and the world will still be created at random, but remain the same each time it is created. | |
Kaioken wrote:
Well, obviously there is object creation involved in icon() or new /icon, and there is 'conversion' of the DMI file to an /icon object, which is basically an "opened"/loaded version available in memory to be manipulated, and it is automatically converted back internally when you say, set an atom's icon to an /icon object. This is also in the DM Reference. >__> Fair enough, but the DM Reference also states "an /icon object is created by loading an icon file into memory for direct access and manipulation", so the same exact thing must be happening in the shortcut turn() procedure. Ya, it kind was. ^_^ You're a funny man. :P But seriously, we have limits to icon_states per file? That is news to me. I have never hit that limit and I don't organize icons very well, i.e. all exterior turfs in "Exterior Turfs.dmi", all interior turfs in "Interior Turfs.dmi". I must not have enough. And the solution to that is to just put grass in its own icon file. | |
CaptFalcon33035 wrote:
so the same exact thing must be happening in the shortcut turn() procedure. Indeed, but it all happens internally so it's that that much a little faster. But it also makes your code more compact, so might as well eliminate the /icon object creation and all and just use it instead. The same with the icon_states() proc, by the way. I think it's nice there are more options like this, yeah, it'd be bad if we had turn() but not icon.Turn(). You're a funny man. :P Yas, but I'd prefer "guy", "man" makes me feel old. But seriously, we have limits to icon_states per file? That is news to me. It's nothing I'm specifically aware of, but I'm working based on the true premise that everything has a limit, always. If not an actual limit, then you would, eventually, be able to hit a "limit" by running out of memory to store all the icon_states. Of course, I was talking hypothetically, but the above is still true. =P I have never hit that limit and I don't organize icons very well, i.e. all exterior turfs in "Exterior Turfs.dmi", all interior turfs in "Interior Turfs.dmi". I must not have enough. Note that organizing icons properly actually has some differences other than tidiness. For example, icon files are always sent (uploaded/downloaded) as a whole and not state by state, and you can't flick() an atom with an icon_state that is not in its file or is the blank state in a DMI file, and more, etc. And the solution to that is to just put grass in its own icon file. Ho, but that is less efficient and takes more disk space (which could potentially cause the server computer to run out of free space!) because of the extra PNG header and comments needed in the new file. Or, it might hit the limit of files in one RSC archive. Joking again. =P | |
Not to mention players would have to download all the turned states...