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 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.