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:
Anonymous2011-09-10 0:17
Always make custom properietary formats to tailor and optimize your data for your use cases.
Name:
Anonymous2011-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:
Anonymous2011-09-10 0:22
>>2
But you can't easily interchange proprietary formats!
Name:
Anonymous2011-09-10 0:22
>>3
It's a bad format. Sprites are far better compressed using LZW+RLE combination.
Name:
Anonymous2011-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:
Anonymous2011-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.
>>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:
Anonymous2011-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:
Anonymous2011-09-10 0:38
>>7
It's a bad idea to do anything in hardware. It makes code nonportable.
and for software, RLE is much faster than uncompressed, because sprites have big transparent regions.
Name:
Anonymous2011-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.
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.
>>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:
Anonymous2011-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:
Anonymous2011-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:
Anonymous2011-09-10 0:47
>>17
LZW is fast enough (a few bitshifts per pixel) for direct writing to frame buffer.
Name:
Anonymous2011-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:
Anonymous2011-09-10 0:49
>>20
Enjoy your 50% less battery life while playing whatever game does that for rendering.
Name:
Anonymous2011-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).
>>25
How is just straight memcpy'ing slower than a decompression algorithm?
Name:
Anonymous2011-09-10 0:55
So are there any good sprite format or I've to invent another one?
Name:
Anonymous2011-09-10 0:56
>>29
You cant memcpy 8-bit palette sprite into 32-bit frame buffer.
Name:
Anonymous2011-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:
Anonymous2011-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:
Anonymous2011-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:
Anonymous2011-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.
>>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:
Anonymous2011-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:
Anonymous2011-09-10 1:13
>>34
Thats because they don't have Unlimited Detail Technology which would makes EVERYTHING a voxel sprite.
Name:
Anonymous2011-09-10 1:14
>>36
Do you know, that OpenGL damages pixel colors with its othogonal projection?
Name:
Anonymous2011-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.
Name:
Anonymous2011-09-10 1:19
>>39
Let me guess, it's because you forgot to adjust your polygon coordinates by 0.5 for texel -> pixel accurate rendering?
Name:
Anonymous2011-09-10 1:20
>>40 Linux has hardware support...
if you reverse engineer DirectX driver and write Linux one.
Haiku supports Mesa 3D
On my OLPC XO-1 Mesa is a little slow, compared to plain frame buffer.
Name:
Anonymous2011-09-10 1:22
>>42
What GPU are you trying to use on Linux that doesn't have driver support?
Name:
Anonymous2011-09-10 1:22
>>41
Nope. DosBOX OpenGL output has noticeable difference over software one. This leads to conclusion that OpenGL is crap and should be avoided.
I take it you haven't heard that you can root it, and that a recent version of the PS3 SDK is available from pirate sites? Or if you want to go legit on the PSN Store, that the official dev-kit only costs $3000.
Name:
Anonymous2011-09-10 1:27
>>44
Or that the DosBOX developers are idiots and don't know how to use OpenGL?
Name:
Anonymous2011-09-10 1:33
>>46
There is an official Linux support for PS3. It has no 3D, but you can still play all your beloved software games on TV screen using joypad.
Name:
Anonymous2011-09-10 1:34
>>48
Same goes for PlayStation 2, which doesnt have OpenGL at all.
this could also be due to system opengl drivers, your video card drivers, etc. also, color values represented as 0 to 255 integers are going to be turned into a 0 to 1 number in opengl, and depending on your gfx card, some precision might be lost.
Name:
Anonymous2011-09-10 6:18
>>57 color values represented as 0 to 255 integers are going to be turned into a 0 to 1 number in opengl
That is why I wont use OpenGL for pixel-art drawing.
Name:
Anonymous2011-09-10 6:20
>>55 sprites are stored as actual machine code instructions
hardcore.
This thread is painful to read. This is the problem with ``Software Engineering'' and seemingly simple things: a lot of imbeciles who have no clue of what they're talking about think spouting their misinformed opinions is a good idea.
Name:
Anonymous2011-09-10 11:13
>>63
that's not funny -- my brother got his PhD that way
Name:
Anonymous2011-09-10 13:50
>png
>not animated
Are you retarded op?
>HURDUR DECOMPRSSHUIN
>not using even the most basic engines which support pre-loading sprites, SINCE EVERY FUCKING FORMAT HAS TO BE IN UNCOMPRESSED RGB OR SOME SUCH NONSENSE BEFORE BEING RENDERED
LoseThos has a format and editor. You'll have to make a renderer for operating systems besides LoseThos.
Name:
Anonymous2011-09-10 15:13
>>65 Are you retarded op?
No. GIFs are far superior to PNG. They even support frame timing.
>EVERY FUCKING FORMAT HAS TO BE IN UNCOMPRESSED RGB OR SOME SUCH NONSENSE BEFORE BEING RENDERED
RGB is slower, than 8-bit paletted RLE sprites.
Name:
Anonymous2011-09-10 15:58
GIF is also proprietary
whereas PNG is glorious open source grade
Name:
Anonymous2011-09-10 16:03
>>68 PNG is glorious open source grade
That explains why it sucks and uses primitive LZ77 (developed by two stupid jews), instead of much cooler LZW.
Name:
Anonymous2011-09-10 16:07
Sure are some fucking trolls in this thread thinking that 8-bit sprites are faster than 32-bit RGBA sprites when the backbuffer itself is 32-bit RGBA.
Name:
Anonymous2011-09-10 16:11
>>70
8-bits sprites are more cache efficient, and back in my time, all graphics cards had hardware support for colour palettes.
Name:
Anonymous2011-09-10 16:15
>>71
Only when the back buffer itself was 8-bit paletted, and you had to use a single palette for the entire scene.
Someone else mentioned using a 32-bit RGBA back buffer with 8-bit paletted sprites being faster earlier in the thread, perhaps it was you.
You don't have hardware support for that, you have to manually lookup each pixels color in the palette when rendering and that incurs an extra indirection and instruction dependencies. Even if it's all in the L1 cache, it can still be 4-5 extra cycles of latency for the indirection per pixel, and even slower than that if you can't adequately pad the instruction pipeline to spread out instruction dependencies.
What used to be the case is no longer true. You're living in the past.
Name:
Anonymous2011-09-10 16:19
>>72 4-5 extra cycles of latency for the indirection per pixel
Bullshit. Kill yourself, faggot.
Name:
Anonymous2011-09-10 16:24
>>73
It's not bullshit. You kill yourself for not knowing basic memory controller architectures or anything to do with instruction parallelism. Cycle latency on older CPUs for L1 used to be lower like around 2-3 cycles, but on modern CPUs, memory access times haven't kept pace with CPU clocks speeds and total instruction throughput and so it's around 5 cycles on Core i7 Nehalem or Sandy Bridge for L1.
>>69 That explains why it sucks and uses primitive LZ77 (developed by two stupid jews), instead of much cooler LZW.
"LZ" refers to Abraham Lempel and Jacob Ziv in LZ77 as well as in LZW. If these are your two "stupid jews", you might want to reconsider your argument.
Now, the compression part itself of PNG isn't particularly brilliant all things considered (specially for natural true-color images), but you'll be hard pressed to find sets of data where "LZ77" (in fact it's DEFLATE, which you could say is LZ77 backed by Huffman) performs worse than LZW.
I am very well aware IHBT.
Name:
Anonymous2011-09-10 16:42
Someone write a simple benchmark using libsdl and custom 8-bit and 32-bit sprite blitting routines for blitting to a 32-bit RGBA backbuffer. I want to see this settled.
>>77 you'll be hard pressed to find sets of data where "LZ77" (in fact it's DEFLATE, which you could say is LZ77 backed by Huffman) performs worse than LZW.
Any data in fact. Huffman (another jewish name) is slow, because jews want you think that you hardware is slow and you have to upgrade your PC. It's called "planned obsolescence", as electonics (without moving parts) has pretty long service time, they have to plan its demise, providing inefficient algorithms and languages like Ruby.
Name:
Anonymous2011-09-10 16:56
>>79
Doesn't matter. At or over 2/3 jewish either way.
>>80
"Performs" WRT compression algorithms usually means compression ratio. DEFLATE compresses better but is slower than LZW. There's nothing wrong with that.
DEFLATE performs sufficiently in fast in practice for most applications. Many web pages are transparently compressed using it, for example (including all HTML served by this domain).
In fact, seeing recent developments, it'd be appear there's a demand for better yet slower algorithms, a demand the Russians are filling.
Name:
Anonymous2011-09-10 17:04
>>81 Doesn't matter. At or over 2/3 jewish either way.
The basic distance-length idea was on surface. LZ were just first to write some crappy paper on it. Nothing original. Tomorrow some jews will write paper on ass wiping.
>>82 DEFLATE compresses better but is slower than LZW. There's nothing wrong with that.
It's wrong, if you want realtime speed. Compression rate isnt proportional to compression speed.
>>87 you can do a lot better than LZW.
We all would like to know how.
Name:
Anonymous2011-09-10 17:18
I think, I will use LZW compressed SEXPs for my sprite format. It will allow bignums for width and height, unlimited extensibility and instant Lisp support. Of course, I'll have to do something other than plain ASCII.
Name:
Anonymous2011-09-10 17:23
>>92
Sounds super fast. Way faster than straight 32-bit RGBA.
Name:
Anonymous2011-09-10 17:32
>>93
Loading compressed file from HDD is faster than loading uncompressed. And you can transfer it on internet without zipping.
Name:
Anonymous2011-09-10 17:38
>>92
It should also allow storing sounds and creature/projectile parameters. Hope to use it for storing resources ripped from various video games. Today sites like spriters-resource.com use crappy sprite sheets with missing frames and without palettes, sounds or any animation structure.
Name:
Anonymous2011-09-10 17:52
>>94
Yes, this is important since the best sprite renderers always load in the sprites from disk every frame and decompress pixel by pixel during rasterization.
LZW uses variable length codes. Anything that doesn't use them will trounce it in speed. Five seconds in Google: http://www.quicklz.com/
Of my personal knowledge, recent versions Windows use similar stuff for compression in the kernel (for NTFS, cache files, and the hibernation file) and for some userspace components (remote desktop protocol and a few others). Basically you have a bitmask every once in a while telling you which bytes are literals and which ones are matches.
Hint: Outside GIF, basically nobody uses LZW. What does that tell you about its compression/speed tradeoff? It has the performance disadvantages of variable length encoding without its main adaptability benefit.
Name:
Anonymous2011-09-10 18:37
>>99 LZW uses variable length codes. Anything that doesn't use them will trounce it in speed.
Anything that doesnt achieves far worse compression ratio. Still they are faster than huffman codes and bit-shifting isnt an expensive operation.
Outside GIF, basically nobody uses LZW.
Because LZW was patented and open source crowd makes a drama from this.
Name:
Anonymous2011-09-10 18:38
>>99 asically you have a bitmask every once in a while telling you which bytes are literals and which ones are matches.
I've seen it used in Stonekeep sprites. Had to disassemble .exe to get algorithm.
I created sprites in LoseThos by concocting a SVG-like scheme that can include bitmaps. LoseThos has LZW compression routines. If you save a bitmap to a file (with name ending in "Z") then it will be compressed. LZW is not good compression, normally, but since LoseThos is limited to 16 color, it's not as bad as it sounds.
That's LZW compression. Files with names ending in "Z" are automatically compressed and uncompressed when written to disk. In other words, LoseThos files look strange and corrupted because they are compressed.
God says...
Line: 61344
risen upon thee.
60:2 For, behold, the darkness shall cover the earth, and gross
darkness the people: but the LORD shall arise upon thee, and his glory
shall be seen upon thee.
60:3 And the Gentiles shall come to thy light, and kings to the
brightness of thy rising.
60:4 Lift up thine eyes round about, and see: all they gather
themselves together, they come to thee: thy sons shall come from far,
and thy daughters shall be nursed at thy side.
>>100 Anything that doesnt achieves far worse compression ratio. Still they are faster than huffman codes and bit-shifting isnt an expensive operation.
You trolled me real good, you made me actually check.
I used a LZW compressor I found somewhere which performs about 10-30% better than the classical compress, which also performs better than a textbook LZW implementation.
On the other side of the ring we have LZO (the free, old and busted version) since it's what I had at hand.
The test corpus is a bunch of files (about 45% text, 25% executables, 15% uncompressed images, 15% random crap) totaling 300MB. LZMA compresses this to less than 90MB.
Now that I think about it, an easy way to test LZW as used in GIF is to compare the resulting GIF with a raw uncompressed image, and with a PNG that does not use filters (of course all of them using indexed 8-bit color).
Benchmarking image (de)compressors is hairy though because they're too fast, so I'm not going to try.
LoseThos can handle other compression algorithms pretty easily. I don't enjoy fiddling to get better results as much as I used to. I don't give a fuck, basically. Nothing seems to matter much.
God says...
Line: 3616
36:39 And Baalhanan the son of Achbor died, and Hadar reigned in his
stead: and the name of his city was Pau; and his wife's name was
Mehetabel, the daughter of Matred, the daughter of Mezahab.
36:40 And these are the names of the dukes that came of Esau,
according to their families, after their places, by their names; duke
Timnah, duke Alvah, duke Jetheth, 36:41 Duke Aholibamah, duke Elah,
duke Pinon, 36:42 Duke Kenaz, duke Teman, duke Mibzar, 36:43 Duke
Magdiel, duke Iram: these be the dukes of Edom, according to their
habitations in the land of their possession: he is Esau the father of
the Edomites.
Name:
Anonymous2011-09-10 20:00
>>107
PNG does row subtraction and LZO compresses palette and header, which may consist of redundant data. You're biased as the whole Israel of jews.
>>109
Maybe you missed a PNG that does not use filters I disabled these specifically.
In fact, I just tested with them enabled, and the compression ratio decreased (resulting size 89130), which is not surprising since they're meant for true color data.
The palette data is 768 bytes out of 2074368. I suspect it doesn't compress very well either, since LZO has no delta filter or entropy coder, and all palette entries are different.
However your analysis makes me think you understand what's going on and are just trolling at this point (if not all along), and therefore I will refrain from posting further.