Up early today.


Well, the new class path splitting is much more concise.


Appears my ZIP file reading is not correct somehow.


Actually it is failing because you can open a directory in a FileChannel. At least on Linux. So when running on Linux there would just be an extra exception that prints because of this.


It is undocumented and opening directories fails on other operating systems, so I am not going to duplicate it even on Linux.


I am currently away and have no internet connection and I am using another computer. However I might not have the APPNOTE.TXT file which contains the ZIP specification.


So I cannot implement ZIP files right now since I lack the details.


The good thing about fossil however is that it is a DVCS so I have all the revisions and I can commit locally. With SVN I would need the internet to do any real work.


I feel like for a demo program (a game) which uses the entire J2ME and Java ME set would be Squirrel Quarrel, which is a Starcraft clone. For simplicity and space, for graphics I would do it NES style with 256x240 because the screen sizes may be small. If the screen being used is large then it could just be scaled up. Since tiles are 32x32, that means the graphics would be 12.8x12.8. However 12 is kind of bad binary wise. So I suppose then that units and such are based on 8x8 graphics. The game internally would be using 32x32, however graphics being drawn would be scaled down so that 8x8 is normal. So a normal game would be 640x480, divided by 4 would be 160x120. That would actually work on older Palm OS PDAs which are 160x160. In today's terms for graphics it would look pixely, but this game would be made to be light as possible. Also lots of images would consume lots of memory. However the less space the graphics take up the better. I would however need a PPM/XPM to PNG converter because I would not want to have


I am going to eventually add MIDP 3.0 (JSR 271) anyway because that way I am not completely limited to line based interfaces. However that would be after the base stuff is done. For Squirrel Quarrel I could have it actually use the line based interface although it may end up beign rather horrible due to the abundance of ASCII. However it could work out despite being a bit limited.


When I get to compression algorithms I am going to have deflate and gzip be in separate packages from the ZIP code. I may put them together or I might just split them apart. I also need a CRC stream too.