Niotso - Current tasks

TODO
Because there are too many long-term things to list that we still have "to do" to reach the next development phase (e.g. alpha to beta), this file contains only the things that are worked on currently or that will be in the very near future.

While anybody is free to work on _anything_ at any point during Niotso's time, this list shall ONLY contain those relevant to complete the criteria for the next development phase, which can be found here: 

//--//

Development Phase: Planning

Technical Preview 1 Schedule: (Not very subject to change) 1. Implement cst, uis, ini, and xml parsers with support for UTF-8 [20%] 2. Replicate functionality up until the login dialog [90%] 3. Implement the audio engine 4. Implement the OpenGL-based windowing system 5. Replicate character selection and creation features and the city selection dialog 6. Implement debug logging and support for configuration files 7. Implement the code needed to allow the game to read all necessary files from the TSOClient folder 8. Port the client to Linux

1. Implement cst, uis, ini, and xml parsers with support for UTF-8 [20%]

 * Add a UTF-8 reader&mdash;that's the easy part. But there are a ton of issues. What string format do we want to use everywhere? Do we want to "decompress" to UTF-32 first and make each character worth 4 bytes? (uint32_t) Experiments by others say, because the area of memory is larger, that it's slower than decoding UTF-8 characters on the fly. But if we also plan to support Shift-JIS and the likes in the Niotso Protocol (to preserve bandwidth), then we will need a File::ReadChar function. The other consideration is to convert strings to UTF-8 right when we receive them.
 * We can't use strcpy/strcmp/etc. functions on any data that is not 8-bit ASCII; and the wcs versions are not portable (on Windows it works with 16-bit ASCII, on Linux, 32-bit). Thus, we need to implement our own, e.g. File::strcpy, File::strcmp, etc.

2. Replicate functionality up until the login dialog [90%]

 * Fading out the audio and showing the cursor are the only two things left for this task

3. Implement the audio engine

 * Audio logic will occur just before or after (doesn't matter all that much which we pick) scene logic, and in the same manner: catching up to the current time after having slept for v-blank
 * Supply contexts for sounds with an upper barrier of say 16 playable sounds at a time, with some reserved for background music, stinger music, and UI. Each catch-up, the volumes of all sounds are updated, and if a sound has finished fading out, it will be destroyed and have its handle distributed back into the pool.

4. Implement the OpenGL-based windowing system

 * Power-of-2 textures should be created by piecing together related sprites into spritesheets, at runtime (how we will do this *and* support custom-resolution (svg) replacements, I have no effing idea), so that we can support OpenGL ES to cater to smartphones and generally increase performance at the same time (less calls to glBindTexture meaning less state switches)
 * We will use a texture for the cursor, not a cursor function provided by the OS. Remember, game consoles don't have cursors. ;) Besides, do we really want the Wall Tool cursor stretching past the borders of the game window?

5. Replicate character selection and creation features and the city selection dialog

 * Currently, most character rendering functions occur in Renderer.cpp. They need to be moved into libvitaboy. Also, we need to add bounds-checking so we don't read out of memory (this is the only code in the codebase without bounds checking), and add multiply guards for the malloc(count * sizeof(type))s we're using.
 * Use VBOs and vertex shaders for character animation.

6. Implement debug logging and support for configuration files

 * Maybe /etc/niotsod/vanilla/network.conf (et cetera) for the server, and /etc/niotso/vanilla/network.conf (et cetera) for the client

7. Implement the code needed to allow the game to read all necessary files from the TSOClient folder

 * The far library needs to be rewritten to keep a file descriptor to the far file, and only read entries that are requested over time. (This is not an issue for iff because the largest iff file is 12MB, and we typically^Walways want to read everything from a given iff file anyway; not so for the 50MB far files where we may just be interested in reading one iff file from it.) The linked list also needs to be replaced with a vector using realloc, as done in the iff library.
 * When reading an entry, read the compressed data into temporary memory, decompress it, and then free the temporary memory. This is comparable in performance (faster if the file is big) to reading the compressed data from the file bytes at a time with fread, consumes the memory of only one extra object, and is easier to program.
 * Stop using dynamic allocation everywhere and for the tiniest things (descriptors like Image_t, Sound_t, ...); often we will want to keep track of hundreds of sounds, so it makes sense to allocate the descriptors together once rather than hundreds of times into hundreds of little pieces with bad locality.
 * So far this change has been made into the iff library and xa and utk readers, but the higher level interfaces still need to be updated.

8. Port the client to Linux

 * Audio: ALSA? PulseAudio? OSS? JACK? libao? Pick your poison: http://harmful.cat-v.org/software/operating-systems/linux/audio-mess.png
 * Kernel-specific functions, such as epoll, are desired to increase performance