git-svn-id: svn://svn.ijw.co.nz/svn/OpenRa@1320 993157c7-ee19-0410-b2c4-bb4e9862e678
This commit is contained in:
104
todo.todo
104
todo.todo
@@ -1,64 +1,70 @@
|
|||||||
OpenRA
|
OpenRA
|
||||||
------------------------------------------------------
|
------------------------------------------------------
|
||||||
|
|
||||||
[ ] Automagically work out unit rendering offsets based on SHP size
|
|
||||||
[ ] Ore
|
|
||||||
[ ] Better harvester logic - seek out more ore when harvesting, until full
|
|
||||||
[ ] Fix weird delegate names - Provider<T>, Comparison<T>, Converter<T>, Action<T>
|
|
||||||
should be used where appropriate. `Func` says nothing, and is damned misleading
|
|
||||||
when the delegate isnt referentially transparent... IE, not a `function`.
|
|
||||||
|
|
||||||
Note that the lack of referential transparency for Provider<T> cannot be helped,
|
|
||||||
it's in the nature of an object that converts () -> T.
|
|
||||||
|
|
||||||
[ ] Palette hax for selection outlines. Basically, just hijack a palette entry that's not
|
|
||||||
getting used, and draw the selection borders into the SHP images using that color.
|
|
||||||
Then we double up the hardware palettes, and we can draw selection with no extra cost.
|
|
||||||
|
|
||||||
(Except maybe losing any alpha=0 optimization the backend of the shader hardware does)
|
|
||||||
|
|
||||||
[ ] Weapons
|
|
||||||
[ ] Consume more caffeine!
|
|
||||||
[ ] Multiplayer!
|
[ ] Multiplayer!
|
||||||
|
|
||||||
[ ] Unit turn rate as specified in rules.ini
|
[ ] Rules.ini
|
||||||
[ ] Infantry squishing logic (tracked vehicles do this)
|
[ ] Unit turn rate as specified in rules.ini
|
||||||
|
|
||||||
[ ] Time-to-build overlay on sidebar
|
[ ] Ore
|
||||||
[ ] Mod support
|
[ ] Better harvester logic - seek out more ore when harvesting, until full
|
||||||
|
|
||||||
[ ] Get rid of all the damned static classes! Makes it REALLY HARD to reuse code,
|
[ ] Weapons
|
||||||
dependencies aren't easily visible (or even substitutable, which matters more)
|
|
||||||
|
|
||||||
[ ] Group pathfinding logic
|
[ ] Infantry
|
||||||
[ ] Special-case pathing for floating units, flying units...
|
[ ] Infantry squishing logic (tracked vehicles do this)
|
||||||
Does existing pathing work for boats? float=?? speeds should tell us everything required..
|
|
||||||
|
|
||||||
[ ] Shroud rendering. This is going to be ugly, and it's going to hurt perf, unless we can optimize
|
[ ] pathing
|
||||||
the hell out of the other rendering based on where shroud blocks happen to be..
|
[ ] Group pathfinding logic
|
||||||
|
[ ] Special-case pathing for floating units...
|
||||||
|
Does existing pathing work for boats? float=?? speeds should tell us everything required..
|
||||||
|
- No pathing for air, just fly towards a spot
|
||||||
|
[ ] Solid buildings, units
|
||||||
|
|
||||||
|
[ ] Rendering
|
||||||
|
[ ] Automagically work out unit rendering offsets based on SHP size
|
||||||
|
|
||||||
|
[ ] Shroud rendering. This is going to be ugly, and it's going to hurt perf, unless we can optimize
|
||||||
|
the hell out of the other rendering based on where shroud blocks happen to be..
|
||||||
|
|
||||||
[ ] Optimize ground renderer, so we only submit visible chunks, not whole rows.
|
[ ] Optimize ground renderer, so we only submit visible chunks, not whole rows.
|
||||||
For machines with severe vertex-rate issues, use 2x2 chunks or larger for some things.
|
For machines with severe vertex-rate issues, use 2x2 chunks or larger for some things.
|
||||||
|
|
||||||
[ ] Configuration option for choosing which tuned solution to use:
|
|
||||||
- Cope with lack of HW VP
|
|
||||||
- Cope with lack of fast texture memory (although UMA makes this almost a non-issue)
|
|
||||||
- Cope with REALLY WINFUL FAST HEAVENLY HARDWARE (The boss might want to play this :P )
|
|
||||||
|
|
||||||
|
[ ] Configuration option for choosing which tuned solution to use:
|
||||||
|
- Cope with lack of HW VP
|
||||||
|
- Cope with lack of fast texture memory (although UMA makes this almost a non-issue)
|
||||||
|
- Cope with REALLY WINFUL FAST HEAVENLY HARDWARE (The boss might want to play this :P )
|
||||||
|
[ ] Palette hax for selection outlines. Basically, just hijack a palette entry that's not
|
||||||
|
getting used, and draw the selection borders into the SHP images using that color.
|
||||||
|
Then we double up the hardware palettes, and we can draw selection with no extra cost.
|
||||||
|
|
||||||
|
(Except maybe losing any alpha=0 optimization the backend of the shader hardware does)
|
||||||
|
[ ] Time-to-build overlay on sidebar
|
||||||
|
|
||||||
[ ] Console
|
[ ] Console
|
||||||
[ ] Ditch special unit classes, use templates extracted from rules.ini instead.
|
|
||||||
Push the special-case logic into code that can be named.
|
|
||||||
|
|
||||||
[ ] Remove all remaining `../../../` bullshit from the code. We should be able to set our datapaths
|
|
||||||
externally, then `just go`. The FileSystem class is there to facilitate this.
|
|
||||||
|
|
||||||
[ ] Read/write distinction on IFolder implementors. I think Package should be read-only,
|
|
||||||
FS folders can be mounted read-only or read-write, (or even write-only, but that's odd...)
|
|
||||||
Use FileSystem.Create() to automatically place output files on sensible mounts.
|
|
||||||
|
|
||||||
[ ] Factor duplication out of Sheet, HardwarePalette. Both contain logic for converting bitmaps to
|
|
||||||
hardware textures on demand.
|
|
||||||
[ ] Refresh hardware image of a Sheet if its bitmap content changes. This will kill the prefetch
|
[ ] Refresh hardware image of a Sheet if its bitmap content changes. This will kill the prefetch
|
||||||
bugs permanently!
|
bugs permanently!
|
||||||
[ ] Solid buildings, units
|
|
||||||
|
[ ] Code concerns
|
||||||
|
[ ] Read/write distinction on IFolder implementors. I think Package should be read-only,
|
||||||
|
FS folders can be mounted read-only or read-write, (or even write-only, but that's odd...)
|
||||||
|
Use FileSystem.Create() to automatically place output files on sensible mounts.
|
||||||
|
[ ] Fix weird delegate names - Provider<T>, Comparison<T>, Converter<T>, Action<T>
|
||||||
|
should be used where appropriate. `Func` says nothing, and is damned misleading
|
||||||
|
when the delegate isnt referentially transparent... IE, not a `function`.
|
||||||
|
|
||||||
|
Note that the lack of referential transparency for Provider<T> cannot be helped,
|
||||||
|
it's in the nature of an object that converts () -> T.
|
||||||
|
[ ] Ditch special unit classes, use templates extracted from rules.ini instead.
|
||||||
|
Push the special-case logic into code that can be named.
|
||||||
|
[ ] Remove all remaining `../../../` bullshit from the code. We should be able to set our datapaths
|
||||||
|
externally, then `just go`. The FileSystem class is there to facilitate this.
|
||||||
|
[ ] Factor duplication out of Sheet, HardwarePalette. Both contain logic for converting bitmaps to
|
||||||
|
hardware textures on demand.
|
||||||
|
[ ] Get rid of all the damned static classes! Makes it REALLY HARD to reuse code,
|
||||||
|
dependencies aren't easily visible (or even substitutable, which matters more)
|
||||||
|
|
||||||
|
[ ] Mod support
|
||||||
|
[ ] Consume more caffeine!
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user