Next time you need to explain to someone just how small 4 kilobytes really is, put it this way:
360 games can fit on a single floppy disk.
That’s enough to include every 4K game produced in the last 4 years of competition, and still have nearly half the space left over. If floppy drives were still popular, I’d be tempted to produce a “Java 4K Contest Special Edition Floppy” just to drive the point home.
So remember, guys. The stuff we’re doing here really is incredible. 
…or roughly 175 000 on a single CD ;D
yeah, put all the games on one floppy… and the JRE on the other 12 =)
It’s the size of a 64X64 pixel image.
Oooo… images from 4k jars… good idea… I wonder who has the coolest looking jar converted to an image ?
Kev
I would LOVE to see these!! ;D
Your wish is my command:
import java.awt.*;
import java.awt.image.*;
import java.io.*;
import javax.imageio.*;
public class ImageMaker4K
{
public static void main(String[] args) throws Exception
{
int[] buffer = new int[4096];
BufferedImage image;
FileInputStream in;
int data;
int index;
if(args.length < 2)
{
System.out.println("Usage: java 4kImageMaker <input> <output>.png");
return;
}
in = new FileInputStream(args[0]);
index = 0;
while((data = in.read()) >= 0 && index < buffer.length)
{
buffer[index] = (data << 16) | (data << 8) | data;
index++;
}
image = new BufferedImage(64, 64, BufferedImage.TYPE_INT_RGB);
image.setRGB(0, 0, 64, 64, buffer, 0, 64);
ImageIO.write(image, "PNG", new File(args[1]+".png"));
}
}
I love Java. ;D
See the attachments for a few examples. (Sorry if your favorite game is missing, but a LOT of people need to fix or remove their JAR links.)
HAHA very cool!
Daftest - tool - ever.
Kev
PS. Way cool
What’s interesting is that you can see massive amounts of wasted space in Warpstar4K, and reasonably good sized chunks of wasted space in W4K. You see that white wave in Xero? That means that the data is nearly all binary 1’s. I’m guessing that this area could be slightly better compressed, but there is some variation in the white, which would make it more difficult for the compressor.
BTW, if you want black to represent data and white to represent the lack of data, change the loop to this:
data = 0xFF - data;
buffer[index] = (data << 16) | (data << 8) | data;
index++;
Same in argb 
import java.awt.*;
import java.awt.image.*;
import javax.imageio.*;
import java.io.*;
public class Gen4kImage{
public static void main(String[]args)throws IOException{
byte []a=new byte[4096];
File file=new File(args[0]);
DataInputStream in=new DataInputStream(new FileInputStream(file));
int read=0;
do{
int got=in.read(a,read,(int)file.length()-read);
read+=got;
if(got==-1){
System.out.println("meh");
return;
}
}while(read<file.length());
in.close();
System.out.println(read);
int []ab=new int[1024];
DataInputStream in2=new DataInputStream(new ByteArrayInputStream(a));
for(int i=0;i<1024;i++)
ab[i]=in2.readInt();
BufferedImage i=new BufferedImage(32,32,BufferedImage.TYPE_INT_ARGB);
i.setRGB(0,0,32,32,ab,0,32);
ImageIO.write(i,"png",new File("out.png"));
}
}
fuzetsu in technicolor:
Will you look at that? Here I was just about to post my wonderful color version, and oNyx beats me to it!
Oh well, mine’s better anyway. ;D
import java.awt.*;
import java.awt.image.*;
import java.io.*;
import javax.imageio.*;
public class ImageMaker4K
{
public static void main(String[] args) throws Exception
{
int[] buffer = new int[4096];
BufferedImage image;
FileInputStream in;
int data;
int index;
if(args.length < 2)
{
System.out.println("Usage: java 4kImageMaker <input> <output>.png");
return;
}
in = new FileInputStream(args[0]);
index = 0;
while((data = in.read()) >= 0 && index < buffer.length)
{
int Y = ((data & 0xE0) >> 6);
int U = ((data & 0x1C) >> 3);
int V = (data & 0x03);
double R = Math.abs(Y + 1.403 * V);
double G = Math.abs(Y - 0.344 * U - 0.714 * V);
double B = Math.abs(Y + 1.770 * U);
buffer[index] = ((int)(R * 255) << 16) | ((int)(G * 255) << 8) | (int)(B * 255);
index++;
}
image = new BufferedImage(64, 64, BufferedImage.TYPE_INT_RGB);
image.setRGB(0, 0, 64, 64, buffer, 0, 64);
ImageIO.write(image, "PNG", new File(args[1]+".png"));
}
}
This version works by treating each 8 bit value as a YUV color. While I’m not so sure about my YUV to RGB color conversion, it does produce a 64x64 image that can easily be palletized. It also retains much of the analytical ability of the previous version, allowing you to see “dead spots” in your code.
See attachments for some examples.
Speaking of analytical abilities, BTW, the new version makes several things more clear:
;DI have a theory about that space at the end, though. I’m thinking that may be the ZIP file metadata about where the files are in the archive. Since it doesn’t have to store much (a directory and two files), it’s probably got large amounts of empty space. Just a theory, anyway. I’d need to break out a hex editor to be sure.
If that were the case, wouldn’t there be similar gaps in everyones jars?
Afterall pretty much everyone has the same number of files, and file names.
[quote=“Anon666,post:14,topic:26221”]
That would be correct. So far, this seems to be holding true. (A few more game images are attached.)
So, who is going to write a 64x64 image -> jar file converter =)
A Visual Editor of sorts
Yeah, what we need is something to go back from the image to the game… Then we can trade bitmaps
that would be insanely cool! you could technically compress the games further with pngout etc
That is insanely geeky.
Well done!
This is fantastic! Awesome indeed! 
Posting Icejump4k and FreefallFour4k.
EDIT: Also, I too would love it if you could create a tool that’d reverse the process. Color wouldn’t be neccessary, just b&w
Not necessarily one that works with recompressed images using visual editors, just one that could re-jar the original from-jar image.
EDIT2: I took the liberty of creating an anti-jar (going backwards?), ehm, I mean, inverted image. Also, for your pleasure… a fake!