Trimming Sprites Discussion

vision

vision

Member
O Ilusionista said:
...
Click to expand...

very useful  ;D, now if only it don't crop every frame . i don't like using tons of different offsets for a single action. but i can work around it. thanks for the tool

*Edit By DC:* Topic split, added quote link referring to original.
 
in OpenBOR different offsets on every frame is very bad idea especially cause bbox have to be adjusted on every frame as well, big mess.
Only reason for cropping was filesize but come on it was like 10 years ago, we have more ram today.
 
bWWd said:
Only reason for cropping was filesize but come on it was like 10 years ago, we have more ram today.
Click to expand...

Even then you only save storage space - not RAM, as OpenBOR optimizes images itself anyway. Either way it's useless micro optimizing.

Incidentally, Adobe Image Ready CS2 can be used to easily automate creation of uniform sprite sets from a group of images; uniform palette, size offset, the works. Use of it in concert with this tool would be a marvelous time saver. Unfortunately Image Ready was dropped with CS3+, and though most of its functionality is in Photoshop it is a PITA to use. You can still do it though, and the overall time saved is well worth it. Google search and you should find a tutorial or two.

DC
 
Damon Caskey said:
bWWd said:
Only reason for cropping was filesize but come on it was like 10 years ago, we have more ram today.
Click to expand...

Even then you only save storage space - not RAM, as OpenBOR optimizes images itself anyway. Either way it's useless micro optimizing.
Click to expand...

And if you're using PNG, you don't really even save storage space, because the compression in the PNG format makes large blocks of transparency (the part that would be cropped out) take up virtually no space.
 
sorry, but that is not true.

This is true when you really use transparency (ie. no data on it), not just a transparent pixel. If you use a mask to hide content, the data is still there, it just have an alpha 0.

Specially when you use Photoshop to make transparent PNG. By default, Ps just hide the pixels, but the data is STILL there, increasing the file size. There are many tools to get ride of that non used data.

You can see more info here: http://www.websiteoptimization.com/speed/tweak/png-optimization/
 
That is for 32bit png.

8bit png is pretty well optimized in photoshop.
 
+1. Even .gif is extremely efficient about dealing with large areas of one color in an image; that's what it was designed to do. Obviously .png is even better. Anyone who says otherwise is either saving the wrong way (in Photoshop use the save for web dialog and watch your settings), using the wrong mode (only 8-bit uses color tables) or they just plain don't know what they're talking about.

DC
 
Anyone who says otherwise is either saving the wrong way
Click to expand...
I am talking about 32bits PNG.

And about wrong way, you should take a look at the article. Photoshop is something I use 90% of time in my day since I am Art Director, so its something I can say I know how to use,  but Fireworks works better with it than Photoshop.

And aren't we derailing the topic?
 
I too am quite experienced with Photoshop, but I'm not interested in a pissing contest or trying to offend anyone - I wasn't referring to you in that statement, I was talking about blanket statements people tend to make without doing their homework. One of the most idiotic and common examples being ".png files are bigger than .gif".

I'm not sure why you are talking about 32-bit .pngs as they pretty much have 0 to do with the subject at hand. OpenBOR does not even support them, and they are patently useless for most sprite work. 8-bit mode files are what matters here.

The reason this matters is that clipping sprites with an even offset saves work and resources; we are trying to debunk a serious and detrimental misconception among many module authors that they have something to gain from trimming individual sprites to the last pixel, when that couldn't be further from the truth.

You are right though, things are getting a bit off the rails. Topic split.

DC
 
but I'm not interested in a pissing contest or trying to offend anyone
Click to expand...
Neither I.

I wasn't referring to you in that statement, I was talking about blanket statements people tend to make without doing their homework.
Click to expand...

My apologies. Yeah, people tend to say that kind of things.

I'm not sure why you are talking about 32-bit .pngs
Click to expand...

Thanks to the statement "because the compression in the PNG format makes large blocks of transparency (the part that would be cropped out) take up virtually no space.", which is not true. People often mix alpha transparency with no-data transparency.

we are trying to debunk a serious and detrimental misconception among many module authors that they have something to gain from trimming individual sprites to the last pixel, when that couldn't be further from the truth.
Click to expand...

Keep in mind that my original topic was on Mugen section, were this kind works on the opposite way. Its not we have more RAM that we need to use all of it. Remember of the KISS principle.

PS: some people doesn't like the way I reply, by sentence. Its just my style, no offense.
 
Back to the subject, I made some tests and the result is: to trim the sprites, for OpenBOR, doesn't worth the trouble.

I got a char from Pierwolf's FinalFightCE, which use sprites in 420x272pixels. Then I cropped the sprite to something saller (200x200 I think) and the result is, for the whole char, 20kb less.

20kb is way too small to bother with. So the uncropped sprites are better, because they made things quicker.

My only concern is about the memory, since bigger images consumes more memory on graphic programs.
 
You think guys it will be possible to use alpha transparency of png files in sprites? so even bacgrounds would have smooth fadeout between layers ?
 
So the uncropped sprites are better, because they made things quicker.
Click to expand...

It depends on how you get the sprites though. If your sprites are already in big images but with properly aligned sprites, then don't bother trimming.

However, for me, I usually get sprites either from ripping or spritesheet which are hardly aligned. So what I do is crop the sprites one by one and paste them on a photoshop document, one sprite one layer.
With layer function, I could move each sprite for proper alignment
 
@BB - That was always my method too, but I've found 'Fighter Factory 3' is better for this.

It has great onion skinning that's easy to use, you can preview animations while your working.

Once you're done you can export all the sprites with axis alignment.

Fighter Factory - http://www.virtualltek.com/lang/en_us

Also to speed things up you can use alfred sprite sheet unpacker to crop all the sprites from the sprite sheet for you first.
 
Beastie, the most (public) updated version is here (this is the official release topic):
http://mugenguild.com/forum/topics/fighter-factory-3-rc6-reup-mirror-137126.0.html

There are a more updated version, but its still private for the beta testers. I have it, but for what you will use, the public version works fine (the updates are more mugen targeted).

Also to speed things up you can use alfred sprite sheet unpacker to crop all the sprites from the sprite sheet for you first.
Click to expand...

As DC told, this will defeat the propouse, since you will need to put an offset for each frame. To do this on mugen is easy, but on BOR is tedious and won't help at all.
 
Cool I will check it out, I think that's what version I'm using thou. I am making some chars too thou.

I just meant using sprite sheet unpacker to save time instead of cropping them manually, before onion skinning and making them openbor ready.
 
You must log in or register to reply here.
Back
Top Bottom