Search options (Page 108 of 137)

ui: These guys are mathematical researchers. Their job is not to showcase pixel artists, but to showcase their algorithm. And for that reason I think it's actually the right choice for them to choose game sprites. The game sprites are neutral. Game sprites should be well polished, but don't really mean anything outside of the game context, which means the average reader will focus on what the algorithm does. More artistic artwork will likely beg the questions, where is this from, what does it mean? and take away the attention of the thing on display (the algorithm.)

And to continue the neutrality argument, game sprites are pixelated because they needed to be, and were actually usually not even perceived as being pixelated because of the TV screen's blur. It was never part of the aesthetic. Pixel art on the other hand, especially in recent years, is focusing on the pixelation as an aesthetic. It might even be seen as a light insult to the artist to depixelate their art. All of a sudden you have two conscious aesthetic choices that are competing, pixelated or depixelated, and the reader will perhaps not be judging the algorithm just on its technical merits because he may have a bias towards the pixelated aesthetic, if they were using "modern" pixel art as examples.

Seems like he got slashdotted. His page barely responds...
Shame, I would've wanted to read the paper...

Edit: Found a link in the cmments to the article. http://www.mediafire.com/?1yagc72uz7lx8u2

I'll steal both of your new versions and submit them again, which means I win the competition.

http://www.robwebb1.plus.com/copiers/copiers.htm

There's always Rob Webb, who's located in the UK. However, with the low dollar exchange rate, you will probably actually save a few pounds if you buy from Kitsch, even including shipping costs. On the other hand, UK shipping will probably be faster than overseas shipping.

In hindsight, a checksum of the data would've been nice too. And better compression, like Huffman, or even LZO... On the other hand I personally really like LSDj's compression because it's relatively easy to recover data from it.

I don't really have any good suggestions, but since I've written my own file manager, I can help you a little with hints about hings you can error cherk when loading files.

All of this can be summarized as, check that the file length is correct. You should get $e0, $ff when you have output exactly 32768 bytes, not more, not less. What's below are just methods to detect errors as early as possible.

1) Check that block switches ($e0) are valid. The parameter must be > (the current block) and < $1f. Or constants $f0/$f1 for default instr/wave, or $ff for EOF.
2) Check that there's actually a block switch within the 512 bytes of a block. If not, the file is corrupted somehow.
3) Check each block against the values in FAT. If you don't have a 1:1 match, either the FAT or the contents of the file are corrupted.
4) Another thing you can check, which is the only thing in this list that I don't check in LittleFM, is that the default instrument/wave commands are at output positions that are actually possible. I.e. the instrument command can only output data at positions $3080, $3090 and following aligned addresses. Likewise, waves must be written to $6000, $6010 and so on.

At the very least, check 1 and 2.