Broken Sprite Frames

[RO-Blank]

I used to work on sprites over a year ago, however, I haven't exactly touched them since then.

 

As much as it hurts my pride to admit it, I simply cannot avoid breaking the frames in the sprites I'm making. I've tried several different ones with the same results.

http://rathena.org/board/topic/61862-guide-spriting-101-creating-a-sprite-and-act-file/

^ Originally, I followed that guide when I learned how to create and modify sprites around two years ago. The only thing that has changed is that I've upgraded from Photoshop CS3 to Photoshop CS5. Thing is, I'm not sure if that's the problem.

 

I've followed all of the instructions listed in the text and screenshots, even matching my own settings to theirs. I've been and loading the color palettes, to using ACTs (I'm still unsure of how to create one manually, but I can modify them), converting from RGB to Indexed colors, saving as an 8-bit Bitmap file, and converting using SPR Conview. Regardless of what I do, for some reason, some (or all) of the frames keep breaking.

 

I'm literally at a loss here, because I cannot figure out what the issue is, neither from memory, nor from that guide. However, I do know that when I first started out, I had this issue, even with the guide. I just can't remember how I corrected it, but I'm assuming that it was something to do with a setting in Photoshop somewhere.

 

[Adel]

What do you mean by 'breaking' frames 

[RO-Blank]

What do you mean by 'breaking' frames 

 

Sorry, I should have specified. The colors are all fine, but the bottoms of some of the frames seem to want to scatter. I actually got frustrated to the point of removing half of the sprite to see if it would fix it. It solved the problem for 6 of the 7 frames. The 7th one was completely scattered regardless.

 

The 1st, 5th, 6th, and 7th frames of the sprite file are broken, but the 2nd, 3rd, and 4th are intact. It's driving me crazy.

 

I really enjoy spriting, so any help I can get; I'll be extremely grateful for it.

Edited October 10, 2014 by RO-Blank

[Tokei]

I *think* I know what your issue is. You're probably using SprConview to make your sprites, which has a bug if you use the RLE encoding. That option must be unchecked. (SprConview ends the RLE compression abruptly and ActOR keeps reading when it should stop. You get 'random' pixels at the bottom of the sprite, which usually corresponds to the beginning of the next frame, or whatever's currently in the memory.)

 

If that's not the case, please show us a screenshot and upload your act/sprite. We need more details ;]

[RO-Blank]

I *think* I know what your issue is. You're probably using SprConview to make your sprites, which has a bug if you use the RLE encoding. That option must be unchecked. (SprConview ends the RLE compression abruptly and ActOR keeps reading when it should stop. You get 'random' pixels at the bottom of the sprite, which usually corresponds to the beginning of the next frame, or whatever's currently in the memory.)

 

If that's not the case, please show us a screenshot and upload your act/sprite. We need more details ;]

 

Honestly, all I'm doing with SPR Conview is converting SPR to BMP, and BMP to SPR. From SPR to BMP, I'm editing the sprites (where necessary) and going from there.

 

I've not changed nor upgraded my ACTor nor SPR Conview programs from a year ago, so I doubt those are the issue. However, if you believe that they are the issue, I'd like to formally request that you explain your reasoning behind that issue. If I can understand why you've come to that conclusion, then I may be able to solve my problem.

 

The random pixels at the bottom of the sprites apply to frames 1-6, however, frame 7 is completely scrambled, resulting in even the top of the frame being completely re-arranged.

[Tokei]

I just downloaded SprConview. When you use "Bmp to Spr", uncheck "Encode (enabled for almost all sprites)". It should work fine. If not, upload the sprite... it's much easier to locate the issue with the actual file.

 

(... on second thought, I think I went into way too much details lol... but hey, you said you wanted the reasoning!)

The reasoning behind this... is pretty much explained in the previous post xD. What you describe fits the following issue, which is caused by a "buffer overflow".

 

RLE encoding is a compression used by the 0x201 sprite format. It... basically counts the number of the same pixels following each other and write this number instead of writing the pixel information multiple times. At the end of this encoding, you usually have transparent pixels and SprConview literally ignores them while compressing. This is unusual, but it's not an issue because the sprite decoder knows the amount of pixels beforehand. If it reaches the end of the compression data and there are still 200 pixels left to load in the image, it fills the image with transparent pixels. This allows greater compression.

 

ActOR decodes the sprites differently though. It keeps reading the compression data until the amount of pixels decoded is greater or equal than the amount of pixels expected. It shouldn't though. If it reaches the end of the buffer and there are still 200 pixels left to load in the image, ActOR will keep decoding, and that is the buffer overflow. It starts reading outside the data buffer (usually on the next image). You can imagine how badly this will affect the next sprites to read (hence why the more you go, the more disturbed the images are). For the last image, there is nothing at the end of the buffer. So... it starts reading outside the file buffer (whatever's currently in the memory).

 

Depending of the usage of the sprite ingame, this might work fine, but it's not guaranteed. The client version might change the behavior as well. It's a lot simpler to just uncheck the encoding option ;].

 

I said this was a bug from SprConview in the previous post though, and that is because the encoder shouldn't stop if all the remaining pixels in the image are transparent. It should instead write "there are 200 transparent pixels following", and that will work properly all the time.

 

Then again, people don't need to know this while making sprites lol xD! I just happen to have made libraries to read/write spr and act files.

Edited October 11, 2014 by Tokei

[RO-Blank]

I just downloaded SprConview. When you use "Bmp to Spr", uncheck "Encode (enabled for almost all sprites)". It should work fine. If not, upload the sprite... it's much easier to locate the issue with the actual file.

 

(... on second thought, I think I went into way too much details lol... but hey, you said you wanted the reasoning!)

The reasoning behind this... is pretty much explained in the previous post xD. What you describe fits the following issue, which is caused by a "buffer overflow".

 

RLE encoding is a compression used by the 0x201 sprite format. It... basically counts the number of the same pixels following each other and write this number instead of writing the pixel information multiple times. At the end of this encoding, you usually have transparent pixels and SprConview literally ignores them while compressing. This is unusual, but it's not an issue because the sprite decoder knows the amount of pixels beforehand. If it reaches the end of the compression data and there are still 200 pixels left to load in the image, it fills the image with transparent pixels. This allows greater compression.

 

ActOR decodes the sprites differently though. It keeps reading the compression data until the amount of pixels decoded is greater or equal than the amount of pixels expected. It shouldn't though. If it reaches the end of the buffer and there are still 200 pixels left to load in the image, ActOR will keep decoding, and that is the buffer overflow. It starts reading outside the data buffer (usually on the next image). You can imagine how badly this will affect the next sprites to read (hence why the more you go, the more disturbed the images are). For the last image, there is nothing at the end of the buffer. So... it starts reading outside the file buffer (whatever's currently in the memory).

 

Depending of the usage of the sprite ingame, this might work fine, but it's not guaranteed. The client version might change the behavior as well. It's a lot simpler to just uncheck the encoding option ;].

 

I said this was a bug from SprConview in the previous post though, and that is because the encoder shouldn't stop if all the remaining pixels in the image are transparent. It should instead write "there are 200 transparent pixels following", and that will work properly all the time.

 

Then again, people don't need to know this while making sprites lol xD! I just happen to have made libraries to read/write spr and act files.

 

The reason I had used the encoding to begin with was because of the fact that it was used in the guide I linked. I know I've used it in the past and things worked fine, but I'm willing to give it a try, and I'll let you know the results. However, I don't think ACTor decoding the sprites are the issue, though. Even in SPR Conview, the images are broken, though they're just showing white where they're broken instead of showing the scrambled sprites like ACTor is. I'm not sure if that makes a difference on your answer or not.    Anyway, I'm going to give it a try sometime this morning. Even if I've always used it in the past, it can't hurt to change it if it'll fix the issue. Thanks for the detailed explanation.

Edit: Well, if fixed the issue, as well as resulted in smaller SPR files, which is odd, since you said that the encoding part was for compression. Seems like it was doing the opposite, because my SPR is 24.1KB instead of 60.3 now.

The only thing that bugs me now is that the files on some of the sprites I tested stretch beyond the preview window on the bottom of ACTor, which they didn't before. I can resize it, though, so it's not too big a deal, but I'm not sure why it's doing that.

Anyway, I'd like to leave this topic open for a little while longer before being considered "solved." It may just be me being stubborn, but I know for a fact that I didn't have to turn the encoding off in the past. I still think it might be something to do with my Photoshop settings somewhere, because I've been working with other things, I upgraded from CS3 to CS5, and I've changed a lot of the defaults. I guess I could just restore to default settings, but that wouldn't exactly teach me anything, which would result in further problems in the future. I'm not saying I'm not grateful for your help or anything, but I'm worried that this fix may be nothing more than a "Band-Aid fix," and that I may just run into more problems in the future due to some setting in Photoshop.

Edited October 11, 2014 by RO-Blank