Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Are there any open source sprite format?

Name: Anonymous 2011-09-10 0:13

PNG just plainly sucks. I has no support for animations, timing or delta compression and sequence names. Also, PNG is slow at random access (you have to decompress image before use). Proprietary formats (like Diablo 2 DCC) are much better, but highly specialized for their games: some have no true color, other have no directions.

Name: Anonymous 2011-09-10 0:17

Always make custom properietary formats to tailor and optimize your data for your use cases.

Name: Anonymous 2011-09-10 0:19

Yeah, I know one you might use.
It's called "raw".
All you do is write pixel data uncompressed into a file.

Name: Anonymous 2011-09-10 0:22

>>2
But you can't easily interchange proprietary formats!

Name: Anonymous 2011-09-10 0:22

>>3
It's a bad format. Sprites are far better compressed using LZW+RLE combination.

Name: Anonymous 2011-09-10 0:28

>>4
You don't need to. Just use PNG/MNG for your intermediary formats during development and text files (json, s-expressions, etc.) for metadata. Before shipping your final deliverable, use your preprocessing tools to reformat and pack your data into native binary formats for the target platform in a single contiguous file and ordered for optimal sequential loading.

Name: Anonymous 2011-09-10 0:32

>>5
LZW/RLE is bad because it increases loading time because you have to decompress it in software. It's better to use raw for most pixel art, or native hardware compression formats like DXTC/S3/PVRTC which you can just copy over to VRAM straight with no software decompression.

Name: Anonymous 2011-09-10 0:35

Wesnoth uses some retarded packing scheme to put all sprites into single image.
http://wiki.wesnoth.org/GSoC_Sprite_Sheets_Shuger

Name: Anonymous 2011-09-10 0:37

>>7
Nope. You decompress part of sprite only when you need it, then cache the result. Like Diablo 2 does: it decompresses only single direction (which is delta-compressed).

Name: Anonymous 2011-09-10 0:38

>>8
It's not retarded, it's actually smart. If you intend to use 3D hardware for 2D sprite rendering, packing sprites into texture atlases is the only way to keep your draw calls and state switching down and performance at optimum. You might not think performance matters for 2D games, but better performance means less time spent per frame, and if you synch to vertical refresh rate it means less overall power consumption, which is good for games on mobile devices.

Name: Anonymous 2011-09-10 0:38

>>7
It's a bad idea to do anything in hardware. It makes code nonportable.

Name: Anonymous 2011-09-10 0:39

>>10
see >>11

and for software, RLE is much faster than uncompressed, because sprites have big transparent regions.

Name: Anonymous 2011-09-10 0:40

>>9
That only made sense when machines had 16MB or less of RAM. Last time I checked, my phone had 512MB of RAM and it costs $120 for a 16GB kit of desktop DDR3 at 1600MHz. Might as well use that RAM to increase performance and decrease power consumption, as well as simplify your source code.

Name: Anonymous 2011-09-10 0:42

>>13
1. CPU caches
2. distribution size

Name: Anonymous 2011-09-10 0:42

So many casual amateurs in here. >>7 is right. Profressional game developers favor RAW or hardware-supported texture compression formats these days. RLE is stupid.

Name: Anonymous 2011-09-10 0:43

>>13
http://www.mobygames.com/game/diablo-ii/techinfo
16MB or less of RAM.
Minimum RAM Required     64 MB

Name: Anonymous 2011-09-10 0:44

>>13
Those points don't mean jack shit because you have to decompress it to a buffer at some point anyway meaning you end up touching the amount of memory you normally would had you just used a native raw format.

Name: Anonymous 2011-09-10 0:45

>>16
It's a Windows game. The diablo.exe process itself only uses around 20-30MB of RAM, the rest is for the operating system and background processes so the computer doesn't grind to a halt.

Name: Anonymous 2011-09-10 0:46

>>15
What if I have no hardware support on my PC (Linux, Reactos or Haiku) or dont whant to bloat my software with DirectX?

Name: Anonymous 2011-09-10 0:47

>>17
LZW is fast enough (a few bitshifts per pixel) for direct writing to frame buffer.

Name: Anonymous 2011-09-10 0:48

>>19
Then you just use raw uncompressed images. Storage space and RAM capacity are no longer an issue. RLE is slower because you have to convert to a RAW format to display it anyway.

For distribution over the internet, using bz2 or lzma for your entire distributable is as good as PNG compression.

Name: Anonymous 2011-09-10 0:49

>>20
Enjoy your 50% less battery life while playing whatever game does that for rendering.

Name: Anonymous 2011-09-10 0:51

>>17
Cache memory consists only of on-screen sprites, which is much smaller than total compressed sprite memory (all mobs and dodads used on map).

Name: Anonymous 2011-09-10 0:52

>>23
It's not 1999 anymore.

Name: Anonymous 2011-09-10 0:52

>>21
But raw is slower than compressed!

Name: Anonymous 2011-09-10 0:54

>>25
No it is not.

Name: Anonymous 2011-09-10 0:54

>>24
Which means you can write lame Java code, that requires 6GHz CPU + 16 Gb RAM to run Mario?

Name: Anonymous 2011-09-10 0:54

>>26
It's.

Name: Anonymous 2011-09-10 0:55

>>25
How is just straight memcpy'ing slower than a decompression algorithm?

Name: Anonymous 2011-09-10 0:55

So are there any good sprite format or I've to invent another one?

Name: Anonymous 2011-09-10 0:56

>>29
You cant memcpy 8-bit palette sprite into 32-bit frame buffer.

Name: Anonymous 2011-09-10 0:57

>>31
Why would you want to use an 8-bit palette sprite with a 32-bit frame buffer when a 32-bit RGBA native raw sprite is faster to just memcpy around?

Name: Anonymous 2011-09-10 1:04

>>32
Because it allows color cycling and recoloring? Because it original was drawn as 8-bit? Because 8-bit pixelart looks better than blurred 24-bit continuous tones?

Name: Anonymous 2011-09-10 1:06

Just admit it, Crysis, with all its antialiasing and texture filtering, looks like amateur crap compared to good old 8-bit Street Fighter sprites.

Name: Anonymous 2011-09-10 1:09

>>33
You can always convert 8-bit paletted images to 32-bit RGBA during preprocessing when packing your data for your final build, while using 8-bit for development and you get the exact same result as you would had to tried to manually do a pallete lookup per pixel in code.

As for color cycling/recoloring, I suppose those are valid reasons if your an amateur and your head is still stuck in 1990s development techniques, but on modern hardware, even a 2002-2003 era SM 2.0 pixel shader from DX8/GL2 could easily handle that and allow you to do so much more when it came to implementing special effects while letting you work with 32-bit RGBA sprites.

Name: Anonymous 2011-09-10 1:12

>>35
Hell, what am I saying, you don't even need pixel shaders for coloring, you can just use the fixed function pipeline and set up some colored lighting parameters in the texture stage.

Name: Anonymous 2011-09-10 1:12

>>35
You can always convert 8-bit paletted images to 32-bit RGBA during preprocessing when packing your data for your final build,
Why should I?

on modern hardware,
What if I have no hardware support on my PC (Linux, Reactos or Haiku) or dont want to bloat my software with DirectX?

Name: Anonymous 2011-09-10 1:13

>>34
Thats because they don't have Unlimited Detail Technology which would makes EVERYTHING a voxel sprite.

Name: Anonymous 2011-09-10 1:14

>>36
Do you know, that OpenGL damages pixel colors with its othogonal projection?

Name: Anonymous 2011-09-10 1:16

>>37
Linux has hardware support unless you're a complete moron. Haiku supports Mesa 3D and has a Linux driver emulation layer which works quite nicely. Reactos has mostly working Windows XP driver support and is known to be able to run 3D games such as half-life, half-life 2, etc.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List