DSLua Community

Hey all,

After several sad attempts at spriting for myself, I've decided to screw that. And I got an idea.

Just as we can bruteforce passwords by trying every possible combination with a bruteforcing app, I'm gonna try making a bruteforcer that bruteforces COLORS!

I'll use raw files, due to ease of use. It'll take a looong time to get every combination figured out, but EVERY possible sprite? That would contain EVERY sprite you'd EVER need!  ;D

So, more to the point... anyone know a program that can write raw hex? I can't find anything like that in any of the languages I know, besides DSLua, but I refuse to bruteforce on 4MB of RAM.

If I figure this out, I'll release the finished result onto the net. Then maybe I'll try bruteforcing palettes, too ;)

64-pixel sprites (8x8) with 256 different colours = 13,407,807,900,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 different images... I think...

Yes, but if my bruteforcing calculations are correct for my 15ghz (literally) processor, that will only take a matter of a month or two.

Although... I was planning on doing 16*16 images... hehehe...

Yeah, but do you really want to sit through 1.3 x 10^153 images to see which ones are  pleasing or not? ???

With MY spriting skills, yes. At least this way, nobody in the world will ever have to sprite again  ;D

Are you sure you have the 2,728,306,970,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 yottabytes of disk space for all this?

W-whoa...

OK, there MUST be something wrong with your calculations. I thought your first one MAY have been a little off, but there's no way I'd need THAT much storage.

Let's do a little maths here.

16*16 = 256. 256 pixels per image, and in raw 256 color format, with its 1:1 ratio, only 256 bytes per image.

100000 images of this size are approximately 23GB.

With 256 pixels and 256 colors to work with, the maximum number of images is logically only 65536.

And I am buying a new 160GB hard drive tomorrow.

I think I can handle it.  ;D

EDIT: And I'm starting to think even 23GB is a huge overshoot. 65536 images * 256 bytes each ends up being only around 11 MEGABYTES.

EDIT 2: Oh, that's what I did. It wasn't 23GB, it was 23MB. Megabytes. For 100000. Hehehe. So, still. 11MB for the bruteforcing. Not bad.

EDIT 3: Too many edits, eh? I forgot a part of the formula, FAT32 has a minimum hard disk limit of 4KB per file. So the total count for the bruteforcing becomes ~234MB. Still nothing comapred to Jeremysr's math...

Nope there's nothing wrong with my calculations. You don't multiply 256*256, you do 256²⁵⁶. Then multiply that by 256 and you get the amount of space they'll take up (in bytes). I can't figure it out though because my computer can't handle large numbers like that (which is why I only figured it out with 8*8 sprites, in the posts above.)

Yep, seems google calculator's limit was 256^127 = 7.02223881 × 10³⁰⁵ (http://www.google.com/search?hl=en&safe=off&q=256%5E127)
So, square that number and times 65k, something like 4x10⁶¹⁵ possible 256 color 16x16 sprites

...

...

...

Maybe I'll start with 16 colors...

Assumption is the mother of all fuckups... ;) Be happy you didn't start it a week before posting this to realize you ran out of disk space. ;D