NOTES

BUGS
====

* cfg-all builds shared Win32 only, and won't work if MXE is installed without
  that! Detect? Try both?

* Variable logic rates seem to work now, but audio message delay is bumped up
  hundreds of ms whenever the slow motion resume is activated!
	* Order of bump/advance doesn't seem to matter.
	* Bump and advance deltas always match.
	* ???

* The whole UI is affected by the game logic frame rate - even when the game is
  paused! They should be completely unrelated.
	* Split kobo_gfxengine_t::frame() non-game stuff out into pre_render() or a
	  new function.
	* Non-game sfx need to use a "channel" of their own, with "ASAP"
	  timestamping. (Hack this using the new timestamping API, until we have
	  a proper API for that.)

* How do we create the scores dir with correct permissions with CMake?
	* Are we even supposed to bother with this? Non-portable...


FEATURES
========

* Maybe a bit of blur as well, when downscaling spinplanet textures...? (The
  original texture is scaled up at load time specifically to serve as a very
  low resolution "interpolation.")
	* NOTE: RAW and NONE textures should not be blurred unconditionally,
	        as that would add extra colors! (RAW ones aren't even scaled,
	        so no problem there.)

* Skewed dithering without breaking the 50% checkerboard pattern...?

* 90/180/270° sprite rotation!

* Implement color and alpha modulation for all window draw calls!



GAMEPLAY
========

* Not sure about this whole idea of balancing the skill levels through shields
  and damage... It just makes the harder skill levels slow and boring, as you
  have to play defensive and attack over and over!
	* Might not be as much of an issue with Charged Firing. Tougher enemies
	  just call for more effective use of this new weapon!

* Bosses with complex collision zones, so they need to be shot from particular
  directions to take damage - a bit like mobile bases.

* Enemy/core/... indicator subsystem:
	* Since all objects are updated every game logic frame, it's probably
	  most efficient if the relevant ones report to the indicators
	  themselves.
	* We need something to report to. Shouldn't mess directly with the LED
	  bars from game logic code.


ARTWORK
=======

* More contrast and/or detail in the backgrounds? More traditional hand drawn
  pixel art style?


REFACTORING
===========

* Why are we using world pixels in the sound API, and not 24:8 coordinates?

* Maybe we should have a fixed target delay for sound effects, so we don't
  have sounds playing before animations when running on lowlatency JACK setups
  and the like? 'tsdelay' would be the minimum allowed delay.

* We need to deal with timestamps when the game engine isn't running too!
	* Maybe UI sound effects and the like shouldn't be timestamped anyway?
		* Can we create a thin API state for that...?

* Implement a wrapping scroll offset in stream_window_t, so we can use it for
  the radar! Or maybe we can just use the current offscreen window like that?

* Should window_t manage SDL renderer state? Probably, because the window_t
  rendering API gives the impression of keeping state per window.
	* Well, it pretty much does already - and there isn't much state in an
	  SDL renderer anyway.

* Remove all load time image filters?
	* ...or just turn them into a stand-alone library operating on raw
	  32bpp buffers or something? It's just too messy to use as it is.
		* If we go for EEL, we just implement each theme as a script
		  that performs all loading and processing.
	* Actually, we're using some of them again, to preprocess the spinning
	  planet texture, instead of storing a huge, blurry texture on disk.


OPTIMIZATIONS
=============

* Don't lock the entire spinplanet buffer unless we need to!
	* Resize the window? Calls for clearing the border around it.

* Double buffered stream window! (For reduced spinplanet frame rate on very
  low end hardware.)

* Do we really need z coordinates for the rotating starfield? They're all
  fixed anyway.

* Double buffered stream window! (For reduced spinplanet frame rate on very
  low end hardware.)

* Do we really need z coordinates for the rotating starfield? They're all
  fixed anyway.

* Double buffered stream window! (For reduced spinplanet frame rate on very
  low end hardware.)

* Do we really need z coordinates for the rotating starfield? They're all
  fixed anyway.

* Problem with offscreen windows: They can only share textures with the screen
  when using render targets! The software fallback renderers need their own
  textures.
	* Can't remember why I felt the need to comment on this, but these are
	  the main problems:
		* Engine managed sprites/textures won't work as is, as they all
		  belong to the display render target.
		* Even if the engine would support this, it would have to make
		  copies of the textures used with each offscreen window.


NOTES
=====

* Some handy command lines for audio engine testing:
./kobord -audiodriver sdl -maxfps 0 -audiobuffer 8192
./kobord -audiodriver sdl -maxfps 0 -audiobuffer 1024
./kobord -audiodriver sdl -maxfps 0 -audiobuffer 128
./kobord -audiodriver sdl -maxfps 60 -audiobuffer 8192
./kobord -audiodriver sdl -maxfps 60 -audiobuffer 1024
./kobord -audiodriver sdl -maxfps 60 -audiobuffer 128
./kobord -audiodriver sdl -maxfps 30 -audiobuffer 8192
./kobord -audiodriver sdl -maxfps 30 -audiobuffer 1024
./kobord -audiodriver sdl -maxfps 30 -audiobuffer 128
./kobord -audiodriver sdl -maxfps 20 -audiobuffer 8192
./kobord -audiodriver sdl -maxfps 20 -audiobuffer 1024
./kobord -audiodriver sdl -maxfps 20 -audiobuffer 128

* Original XKobo speeds:
				shift	rnd	max
	cannon:
		greenbullet	6	32	0
		redbullet	6	32	0
		bluebullet	4	32	0
		others		5	32	0
	core:
		greenbullet	6	0	0
		redbullet	6	0	0
		bluebullet	4	0	0
		others		5	0	0
	enemy2:
		bluebullet	4	0	0
		was: redbullet	5	0	0
	enemy5:
		greenbullet	6	0	0
	enemy6:
		redbullet	6	0	0
	enemy7:
		bluebullet	6	0	0
	enemy_m1:
		enemy1		4	0	0
	enemy_m2:
		enemy2		4	128	192

* File locations of a Kobo DL install on Ubuntu:
	/usr/share/kobo-deluxe/
		gfx/
		sfx/
	/var/games/kobo-deluxe/scores/

* MetaRetroScreenFX:
	"Retro display effects implemented on virtual retro hardware."
	* Opaque 8 bpp monochrome "surface" object
		* Size determined on creation
	* Border value or "wrapped" flag.
	* FX modes:
		* 3x3 blur
		* 3x3 glow (like blur, but non-linear?)
		* 3x3 raster horizontal
		* 3x3 raster horizontal
		* IIR left raster
		* IIR down raster
		* IIR left raster + 3x3 blur
		* IIR down raster + 3x3 blur
	* Output translation:
		* Palette with 32 bpp entries
			* 2..256 entries, assumed to map index to intensity.
		* Byte index of target channel. (32, 24 and 8 bpp only.)
	* Methods for rendering all or part of the surface into memory
		* Target pixel formats:
			* 32, 24(?), 16 and 8 bpp
			* Bit level pixel format irrelevant; we just grab
			  values from the palette!
			* If no palette is specified, directly output raw bytes
			  into the specified index of output pixels.
		* Parameters:
			* Bytes per pixel
			* Source position (x, y)
			* Destination (pointer to top-left pixel)
			* Destination pitch (bytes per row)