I took the time to make a draft of how I thought this could play out. (I don't use windows so it's not as planned out as it could be).
ID:260599
 Jul 31 2008, 8:08 am
|
|
Less guess work for programmers, it's now the artists job; Gives artists the confidence to make things that are more challenging and pleasing to the audience while giving them more control of their own icons. You can't go wrong with stronger graphical quality.
I took the time to make a draft of how I thought this could play out. (I don't use windows so it's not as planned out as it could be). | |
Kaioken wrote:
No. Instead of ending this post here, I'll provide a tiny bit of additional food for thought: For some reason even though I haven't spoken to you much I don't like the way you post or atleast it irritates me. I'll give you credit and pray to God you knew better to then to have ended the post there because that would have just caused you trouble. On to the bulk of your response... But there is no thought in that post. Only fear of change, you didn't even provide a reason why it should only be handled by objects. You simply told me "This is how things should be done because thats how things are done". Which is insane, if you love how things are so much then why do you even post in this section? (This is a place where you suggest newer features that will make byond better and easier for developers.) Then you give me a suggestion that I already knew, why do you think I'm making this post? To avoid that.  And if I were to present to you a scenario like the above? The programmer needs to move the players character 16 pixels in the direction they are facing and the swords need to match. So the icons need to be spilt between the center tile and the direction tiles. It's not the most enjoyable task. However taking the more direct approach (through the icon itself) the artist would be able to easily pick through the icon states. | |
Aye, I don't like some of your posts, either.
Hulio-G wrote: ended the post there because that would have just caused you trouble. No. But there is no thought in that post. Only fear of change, you didn't even provide a reason why it should only be handled by objects. I can't help it if you don't decide to digest what I've given. I told you why it should be as is, handled by objects only, and involving the icon file will just make it messy. However, you've given no actual reason for your suggestion other than "this is more convenient because I'm too lazy to change the existing object vars accordingly". Pixel artists don't make your game. They just make your graphics, the rest is up to the programmer. Putting such a setting in an icon is insane in itself; it should not have an actual impact on the game, an icon is there to simply 'be there'. If you tell your code to ultimately put an icon on tile X, it should most definitely be on that tile, and not on another. It wouldn't make sense otherwise, and would be messy. And if I were to present to you a scenario like the above? Oh boo hoo. It doesn't appeal to you to do something you can already do? It doesn't excite you? Let's make it built-in more conveniently instead of spending time on new features and bugfixes! Really. Also, if programming is troublesome or unenjoyable for you, perhaps you shouldn't do it. | |
A great man once said, "If its not broken, don't fix it."
But that doesn't mean it cant be made better. Hulio-G wrote: (This is a place where you suggest newer features that will make byond better and easier for developers.) My Ignorance aside, What you said is exactly true. However it is also true about this section of the forums is that plenty of ideas have been rejected because they could be done easily by the programmer, and if not completely easily but still at a mid level, a snippet would be given or a link directed to a lib(rary) and yet someone still asks "But can you make this built in so that i dont have to use that." Now that, my friend, IS insane. | |
You're crossing the line between separation of code and resource there. Resources to a game should not dictate how something is displayed on the screen, only what something would look like.
| |
Kaioken is right on the money here. This really is about equivalent to adding something to the GIF or PNG specs that allowed the author to say "Make sure you display this 100 pixels to the left of where the program actually wants to put it", or "Always show this at the bottom of the user's screen no matter what". Positioning the image should be decided by the program; the image itself should be decided by the file.
I really do understand what you're trying to accomplish here, but applying pixel offsets to the image itself just doesn't really fit well into BYOND's design, just as it doesn't fit into pretty much any image format. If you were making this game on a handheld system like the Nintendo DS, you'd be facing the exact same issue of having to use pixel offsets on the object itself. Lummox JR | |
I can understand the official stance, but on the other hand, BYOND has no applicable means of synching a graphic based on pixel offsets, short of creating each frame as its own pixmap and handling the switch between frames in the code itself. Given BYOND's widely variable transmission rate, this can look "jumpy" when rendered on a client's end.
For future consideration, maybe it would be possible to define some sort of /animation datum within the code itself that defines a specific sequence of /images, which the client could understand and display when it is shown to the client. This could be used as a replacement for the venerable (and feature-limited) flick() proc... | |
Obviously, they still need to implement editing icons larger than 32x32. (It has been said before that they will implement that eventually.) Then I'm sure you wouldn't have any problems anymore.
Of course, you can currently do that in another icon editing program. (However annoying and tedious that may be...) | |
No, you didn't get what he said, he said pixel offsets, not different sizes. And if difffernet sizes where made. You(Well Ljr) would have to make all byond differently in its movement(If you wanted it to fit right). The tile system would be screwed, and nothing would be going right, unless it was made with built-in pixel movement. Hulio was talking about moving the actual image on the screen with pixel offsets, your in a whole different zone right now...
| |
No, if you paid attention to the other posters in this thread, that whole pixel offset thing within the icon editor is not going to be implemented, and from the example he showed for what he needed, he simply needs to use multi-tiled icons.
It's the job of the programmer to implement pixel offsets so that it appears correctly in-game. In fact, this might as well be better off in the How-To forum. | |
Naokohiro wrote:
It's the job of the programmer to implement pixel offsets so that it appears correctly in-game. Hulio-G wrote: "Then you give me a suggestion that I already knew, why do you think I'm making this post? To avoid that. " My goodness, anyway... I don't know why this thread needs 7 different people just to say it's not being put in. A programmer was complaining about this task (Vermolius). So I offer a suggestion he tells me yeah go ahead and post it. Then when Kaioken and Gohan reply he goes "I don't see any point in your suggestion". -_- | |
Implementing pixel offsets is pretty easy if you know what you're doing... Given the graphics artist creates the icon correctly as well.
| |
Hulio-G wrote:
"Then you give me a suggestion that I already knew, why do you think I'm making this post? To avoid that. " Kaioken wrote: Oh boo hoo. My goodness, and I thought I was lazy. Anyway, it's your problem if you insist on not doing this [properly]. But it's not anyone else's and we don't need this feature, which is just unsuitable, and this should remain primarily up to the programmer. Too bad. | |
Kaioken wrote:
Hulio-G wrote: I couldn't help but chuckle here. Anyway, it's your problem if you insist on not doing this [properly]. You can't not do it properly, there's one option and no ones insisting. But it's not anyone else's and we don't need this feature, which is just unsuitable, and this should remain primarily up to the programmer. Too bad. Thank you Kaioken, I think if you didn't convince me the 6 other people did certainly without this post which had nothing to deliver to me except "Too bad" this issue would have never been settled. (Seriously, the point was proved, sometimes I think you just talk for the sake of talking, go play a Dbz game or something.) | |
No, he's in the right ballpark. What he's suggesting is increasing the size of the image so that the artist just moves the sprite within the same static rectangle. In other words, you see the animation that Hulio-G posted earlier? You can notice how the GIF does not move at all, only the pixels within it: if a large icon like that were supported in BYOND, the actual pixels inside the icon move, but the icon itself does not. Thus, by supporting icons bigger than 32x32 in the icon editor, it would totally obviate the need to support pixel offsets in animations because the animator could do all of the sprite movement inside the animation, which would not otherwise move on the map.
All that said, however, BYOND does use a fairly simple PNG format for its DMIs; if someone extracted all of the frames from that GIF and set them side-by-side horizontally in a PNG image, they could then use TweakPNG to add the appropriate comments to the PNG file, then rename the .png to .dmi. It'd be easier than splitting it up within the DMI Editor itself, anyway. | |
Instead of ending this post here, I'll provide a tiny bit of additional food for thought: There is a reason this is handled by an object variable, and not an icon parameter. It is because, this should be handled by and potentially vary between objects, and should not be dictated by the icon itself, really.
If you wanted this for convenience/cleanliness/featurefulness or making it simpler to implement what artists make (or whatever), you could always handle this through DM code. You can check an atom's icon_state, and you can check icon_states() of DMI files. So you could name the state accordingly if you really wanted this, eg instead of "Punch", you could have "Punch (0,0)", "Punch (0,1)"... Then have your code check for that.