| * Figure out transparency rendering glitches, and start using the | |
| transparent leaf texture for trees once that's been figured out. Right | |
| now they look better with the solid texture. In particular, all the | |
| "decorative" blocks like torches, flowers, reed, etc, look weird, as | |
| does water and portals. As it turns out, this is all to do with OpenGL | |
| alpha blending; in addition to a couple quick calls to glDepthMask (see | |
| renderSolid() in Chunk.java), we then need to make sure that all GL | |
| objects are rendered from far-away to near, which will take some doing. | |
| * Proper rendering support for redstone wire | |
| * Draw messages on signs like you'd expect. | |
| * Find a way to eliminate the stuttering when new map chunks are loading | |
| * Home/End will wipe the minimap and load chunks, even if we're already | |
| "in range" and might even have those chunks cached. Should fix that. | |
| * Minimap effective size has been cut quite a bit, would like to increase that | |
| * There are various conditions where the player position and spawn position | |
| markers won't show up properly on the minimap; should fix those. | |
| * As I've been editing the X-Ray code, I've been using underscore_variables like | |
| that, mostly, instead of the camelCase which was more prevalent. Should really | |
| reformat everything to a single style (and retab the whole thing, and clean up | |
| formatting and style in general). And really, I've been pretty lazy all around | |
| with doing things the "right way." The code could use cleanup in general. Also | |
| I think most of the files are still using DOS line-endings. | |
| * And, of course, completing the mod support - UI to select extra mod files, etc. | |
| "override" to explicitly override a previously-defined blocktype (this is | |
| technically in there already but completely untested), "version" so that people | |
| could override the builtin blockdef more efficiently, if they want, etc... | |
| * Technically the minimap colors for a few block types should vary based on the | |
| data value. | |
| * There's attributes in BlockType which use ArrayList, and I think I'd rather they | |
| just be arrays. Should look into that. | |
| * Pull the grass colorization color from a point on misc/grasscolor.png | |
| * Snow has data, as it turns out... Also, it would be nice to have grass+mycelium | |
| react to snow properly (by changing their side image). It seems fairly awkward to | |
| pull off with YAML definitions, though, so we'll just leave it for now. | |
| * Figure out why loading in nonexistant chunks seems to glitch the app so much | |
| * Update position information popup in realtime rather than after a delay | |
| * The resolution-picking dialog has some issues in Java7. One, the dropdowns | |
| seem very sluggish, whereas on previous JDKs they're quite fast. Two (and | |
| possibly relatedly), our hotkeys (enter and escape) only work so long as the | |
| dialog has NEVER actually had the mouse pointer focused on top of it, at | |
| least on my WM. This could potentially have something to do with my | |
| focus-follows-mouse type setup, but it works totally fine in both Java5 and | |
| Java6, so... | |
| * One of these days I need to just break down and start using some GUI library | |
| like TWL, rather than calling out to AWT windows. Alas. | |
| * It's entirely possible I should be calling .dispose() on Graphics2D objects | |
| I don't need anymore, and vice-versa. Possibly cut back on memory a bit? | |
| * Camera presets for bed positions | |
| * Doors should be rendered "properly" | |
| * Now that there's region data of some sort in the data files, we should | |
| look into doing some more accurate foliage highlighting. | |
| * I have never understood why our camera position seems to be the negative | |
| of what it should be. Like where we're storing the player position 'round | |
| line 132 in MinecraftLevel.java, or when we're reading out the camera | |
| position 'round line 2346 in XRay.java (in render()). It makes no sense to | |
| me, but I've been afraid to rip it apart to force it to make more sense. | |
| One of these days... For that matter, it might be a good idea to convert to | |
| using Minecraft's coordinate system, which differs from our own by .5f. In | |
| X-Ray, a block's coordinate (x, z) is found right at the very center of | |
| the block, whereas in Minecraft, it's found at one of the corners. So we're | |
| constantly doing some fudging to report the coordinates in a way that's | |
| consistent with what you get in Minecraft with F3. | |
| * Now that mobs are much more permanent than they used to be, it might make | |
| sense to have them in X-Ray. Would be nice to be able to highlight Ocelots | |
| hiding around in the jungle, for instance... |