<commit_before>### TODO Document
## How to use this document:
Entries will be written as follows, and should be updated as work progresses. In addition the description notes should also be updated if previously unmentioned things are found to be needed to meet the goal

## Entry Title [DateAdded]
### Description of the work to be done
- Descriptions of steps that must be done
	- Additional information about each step

### Progress
- WorkerName and [Date]: notes on progress

## Physics [9.22.2012]
### Description
- Examine Box2D as a candidate for providing good physics functionality.
	- Physics class would then provide the object with capabilities for dealing with its Box2D physics component
- Physics::SetMove should instead take a vector move direction, instead of only Up/Down/Left/Right

### Progress
- Twinklebear [9.22.2012]: I'm working on becoming familiar with the library and testing it out in a minal test bench program, to see how it would work with SDL and with providing the physics functionality needed.

## Gamepad Input [9.22.2012]
### Description
- Add SDL's gamepad and force feedback support into Input
	- Should the SDL_HapticEffect be bundled into its own class and then exposed to Lua for creation of effects?

### Progress
- Twinklebear [9.22.2012]: Can read Joystick button, hat and axis input through the Input class
- Twinklebear [9.23.2012]: Can check if the Joystick supports haptic via Input::JoySupportsHaptic()
- Twinklebear [9.25.2012]: Added function to check if a Joystick is available

## Entities/EntityManager [9.22.2012]
### Description
- Wouldn't it make more sense to add UIManager into EntityManager, and simply have UI elements ignore the camera offsets?

### Progress

## Separation of Data [9.22.2012]
### Description
- Images/Animations should be described through their own json file that would be loaded as needed, instead of directly in the state's json file
	- Animations should be seperate from Image description files, see Twinklebear work note [9.22.2012]
		- Decided against this for now.
	- Remove old loading system
	- Need to be able to save/modify the image data files in the editor
- Entities should be in their own json files and loaded through file links in the state's json file
	- Idea for state specific entity data: It could be overriden by specifying the state specific data in the state file, this data will then be used to override the entity data
- With all these extra file readings I think the need arises for a generic file reader/writer to write and read JSON from desired files, eliminating the need for Image, AnimatedImage and Entity to each have their own JSON file opening function.

### Progress
- Twinklebear [9.22.2012]: Image's and AnimatedImage's now have their own associated json file, describing any clips or animation sequences
	- Note: Shouldn't animation be a seperate json file than the image file? So an image.json file would describe the image and its clips, while an animation would specify which image to load and the animation sequences.
- Twinklebear [9.27.2012]: Decided against seperating animation sequence information from clip information when loading an AnimatedImage. Thus you can still simply call "file.png" and the config file will be parsed from the image file name, instead of loading a json config file and then that would contain the image file name.
- Twinklebear [9.27.2012]: All Image & AnimatedImage config data (clips & sequences) is now loaded from  json files in the same directory as the image file, with the same name. So for tiles.png the corresponding clips data is in tiles.json. This file is automatically checked for and loaded when creating a new Image or AnimatedImage with Image("file.x") or AnimatedImage("file.x")
- Twinklebear [9.27.2012]: First test of loading an entity config through a json file successful. Will work on migrating everything over, and creating a simple file read class, as mentioned above in the description. Also must implement reading in override data for state specific entity configuration.

## Make Image Clips Array into a Vector [9.22.2012]
### Description
- Image currently uses a dynamic array to store the clip rects, it should be changed to a vector

### Progress
- Twinklebear [9.22.2012]: Tried the naive method of simplying bumping everything over and got rather unclear runtime exceptions, something more is going on that must be looked into.

## AnimatedImage Class Tweaks [9.22.2012]
### Description
- The framerate mentioned for the animations to play at doesn't actually mean framerate, it corresponds to how many program frames correspond to stepping the animation up a frame, this should be changed to be actual framerate
- Should the sequences vector be a map? The key would be the sequence name, and it'd return a vector of sequences perhaps? May improve speed?

### Progress

## Lua Embedding [9.22.2012]
### Description
- Need a better way for Lua scripts to load the modules they need through something like require or such.
	- Can also load other Lua scripts via calling dofile("filepath relative to exe")
		- How will these scripts have the right modules loaded?
- Implement Lua for scripting objects behavior
	- Need to determine what is necessary to be exposed and what should be handled internally and how the API should work and such
- How should the State class be handled?
	- If I create the ability to call state functions like SetExit from Lua, will ObjectButton no longer be needed? since Button's OnClick script would then simply call the function? I'll try this and then decide what to do with ObjectButton.
		- I think I've got a method for this setup, see the static StateManager function ChangeScene
			- This isn't quite right. The button needs to set exit on the actively running scene so that it can exit cleanly
	- Will need some way to grab the active state, perhaps from StateManager? It's a pure-static class so yes, I think that will work
	- Should states be run via script? Hmm. What to do with states..
		- States will execute their basic C++ functionality, such as making the calls to the manager, and other background stuff, but will also call a function on a state script if one is attached
	- Should tiles become entities that are managed by the Map class? This will allow tiles to have scripts attached. Or should tiles remain simple floor imagery and instead invisible entities should be created to enable area triggers. (kind of leaning to the latter, it'll be easier than reworking the Map & Tile class)
- How to save data from script?
	- Have decided to leave this up to the user, so editor created data will be handled by JsonCPP and script data will be handled by whatever is desired for Lua, and will have no interoperation between the C++ saved data and custom script data.
- Should all modules be loaded for every script? It would prevent potential missing module errors/crashes, would it slow script loading time?

### Progress
- Twinklebear [9.23.2012]: Changed LuaScript::LoadModules to load all modules, we'll see how it effects load times, if it does at all
- Twinklebear [9.23.2012]: You can now load modules via LPCLoadModule, which is passed the name of the module you want to load (with proper capitalization) and should be called at the beginning of the script as you would call require usually
- Twinklebear [9.25.2012]: Removal of the old bad system for using the enum and JSON file for storing a list of required modules is now gone. Modules are loaded with LPCLoadModule. I'm considering migrating over to exposing each class's RegisterLua function however, and then you'd do LPCLoadInput() and it would eliminate the need for the string comparisons
- Twinklebear [9.25.2012]: Module's registration functions are now stored in a std::unordered_map to enable fast lookup. Map is created in LuaScript::CreateMap and given to a static const unordered_map as only one needs to exist, and it should never be able to change what it contains during the program run.
- Twinklebear [9.26.2012]: Changed the unordered_map to a map, since we never perform insertions we don't need to worry about that, just quick access across all elements. So a map is a better choice
- Twinklebear [9.26.2012]: Correction, the name of the module loading function is changed to LPCRequireModule("modulename")
- Twinklebear [9.26.2012]: Changed the unordered_map to a map, since we never perform insertions we don't need to worry about that, just quick access across all elements. So a map is a better choice

## Change Button/ObjectButton to be managed by a Lua script
### Description
- The Button and ObjectButton should have their behaviours and OnClick function defined within a script, instead of in C++ code, allowing for more flexibility

### Progress

## Editor [9.22.2012]
### Description
- Tile map editor
- Need to be able to place Entities into the scene as well
	- Related: Need to be able to create new entities from within the editor
- Need to be able to import images to the editor and have them show up in the files list.
	- Need to be able to make folders, and so on, all editor folders will be subfolders of res/
	- How can i drag things into the editor without relying on platform specific API?
		- Should i just instead monitor folders? How does SDL's clipboard support work? If i can get the filepath i can copy the file.

### Progress
- Twinklebear [9.22.2012]: LuaScript class takes care of loading the script and its desired modules. Modules are stored in JSON as an array of ints corresponding to the MODULE enum in the LuaScript class. Then before calling dofile all the desired modules are registered.
	- Should I just load all modules for every script? It would prevent errors. Would it cause slower script loading? (Added to work notes)

## Multithreading [9.22.2012]
### Description
- Naive implementation: Split into three threads: Physics, Rendering and Input (main)

### Progress
- Twinklebear [9.22.2012]: Played around with it some, but some strange issues arise, this needs to be approached with caution. Perhaps when I have a better understanding of designing multithreaded programs.

## Migration to OpenGL [9.26.2012]
### Description
- A long term goal, will eventually outgrow SDL when the time comes to being adding support for GLSL shaders, normal/diffuse/etc maps for lighting and so on.
	- Rendering will still remain 2D
- I need to learn OpenGL and become very acquinted with it. This TODO task does not and probably will not be worked on for a long time.

### Progress

## Memory Leaks [9.22.2012]
### Description
- Memory leaks when changing states
	- How will the Lua scripts effect memory usage/leaks?

### Progress
- Twinklebear [9.22.2012]: Got some memory stuff freeing correctly I think, but for some reason, if you go Menu -> Play/Editor -> Menu it allocates ~9MB of memory, I'm not sure why. It drops a bit in mem usage from Menu -> Play, but jumps up when returning to Menu. Need to investigate further

## Resizable Window [9.22.2012]
### Description
- Need to make the window resizable and have elements reposition to fit in the new window
	- Resizing window is currently disabled as resizing the window while playing and then exiting to menu would crash the program

### Progress

## General/Random/Unrelated [9.22.2012]
### Description
- Clean up warnings
- More comments/documentation

### Progress
- Twinklebear [9.22.2012]: Sidenote: Subsystem is currently as Not Set so that I can get console output for debugging scripts and such<commit_msg>adding some todos from today's discussion<commit_after>### TODO Document
## How to use this document:
Entries will be written as follows, and should be updated as work progresses. In addition the description notes should also be updated if previously unmentioned things are found to be needed to meet the goal

## Entry Title [DateAdded]
### Description of the work to be done
- Descriptions of steps that must be done
	- Additional information about each step

### Progress
- WorkerName and [Date]: notes on progress

## Physics [9.22.2012]
### Description
- Examine Box2D as a candidate for providing good physics functionality.
	- Physics class would then provide the object with capabilities for dealing with its Box2D physics component
- Physics::SetMove should instead take a vector move direction, instead of only Up/Down/Left/Right

### Progress
- Twinklebear [9.22.2012]: I'm working on becoming familiar with the library and testing it out in a minal test bench program, to see how it would work with SDL and with providing the physics functionality needed.

## Gamepad Input [9.22.2012]
### Description
- Add SDL's gamepad and force feedback support into Input
	- Should the SDL_HapticEffect be bundled into its own class and then exposed to Lua for creation of effects?

### Progress
- Twinklebear [9.22.2012]: Can read Joystick button, hat and axis input through the Input class
- Twinklebear [9.23.2012]: Can check if the Joystick supports haptic via Input::JoySupportsHaptic()
- Twinklebear [9.25.2012]: Added function to check if a Joystick is available

## Entities/EntityManager [9.22.2012]
### Description
- Wouldn't it make more sense to add UIManager into EntityManager, and simply have UI elements ignore the camera offsets?

### Progress

## Separation of Data [9.22.2012]
### Description
- Images/Animations should be described through their own json file that would be loaded as needed, instead of directly in the state's json file
	- Animations should be seperate from Image description files, see Twinklebear work note [9.22.2012]
		- Decided against this for now.
	- Remove old loading system
	- Need to be able to save/modify the image data files in the editor
- Entities should be in their own json files and loaded through file links in the state's json file
	- Idea for state specific entity data: It could be overriden by specifying the state specific data in the state file, this data will then be used to override the entity data
- With all these extra file readings I think the need arises for a generic file reader/writer to write and read JSON from desired files, eliminating the need for Image, AnimatedImage and Entity to each have their own JSON file opening function.
- Maps should be described in their own json file
- Tilesets should have an associated json file describing additional tile properties, which image to use and which tile goes with which clip

### Progress
- Twinklebear [9.22.2012]: Image's and AnimatedImage's now have their own associated json file, describing any clips or animation sequences
	- Note: Shouldn't animation be a seperate json file than the image file? So an image.json file would describe the image and its clips, while an animation would specify which image to load and the animation sequences.
- Twinklebear [9.27.2012]: Decided against seperating animation sequence information from clip information when loading an AnimatedImage. Thus you can still simply call "file.png" and the config file will be parsed from the image file name, instead of loading a json config file and then that would contain the image file name.
- Twinklebear [9.27.2012]: All Image & AnimatedImage config data (clips & sequences) is now loaded from  json files in the same directory as the image file, with the same name. So for tiles.png the corresponding clips data is in tiles.json. This file is automatically checked for and loaded when creating a new Image or AnimatedImage with Image("file.x") or AnimatedImage("file.x")
- Twinklebear [9.27.2012]: First test of loading an entity config through a json file successful. Will work on migrating everything over, and creating a simple file read class, as mentioned above in the description. Also must implement reading in override data for state specific entity configuration.

## Make Image Clips Array into a Vector [9.22.2012]
### Description
- Image currently uses a dynamic array to store the clip rects, it should be changed to a vector
- Image clips should also be identified by a name instead of an array index

### Progress
- Twinklebear [9.22.2012]: Tried the naive method of simplying bumping everything over and got rather unclear runtime exceptions, something more is going on that must be looked into.

## AnimatedImage Class Tweaks [9.22.2012]
### Description
- The framerate mentioned for the animations to play at doesn't actually mean framerate, it corresponds to how many program frames correspond to stepping the animation up a frame, this should be changed to be actual framerate
- Should the sequences vector be a map? The key would be the sequence name, and it'd return a vector of sequences perhaps? May improve speed?

### Progress

## Lua Embedding [9.22.2012]
### Description
- Need a better way for Lua scripts to load the modules they need through something like require or such.
	- Can also load other Lua scripts via calling dofile("filepath relative to exe")
		- How will these scripts have the right modules loaded?
- Implement Lua for scripting objects behavior
	- Need to determine what is necessary to be exposed and what should be handled internally and how the API should work and such
- How should the State class be handled?
	- If I create the ability to call state functions like SetExit from Lua, will ObjectButton no longer be needed? since Button's OnClick script would then simply call the function? I'll try this and then decide what to do with ObjectButton.
		- I think I've got a method for this setup, see the static StateManager function ChangeScene
			- This isn't quite right. The button needs to set exit on the actively running scene so that it can exit cleanly
	- Will need some way to grab the active state, perhaps from StateManager? It's a pure-static class so yes, I think that will work
	- Should states be run via script? Hmm. What to do with states..
		- States will execute their basic C++ functionality, such as making the calls to the manager, and other background stuff, but will also call a function on a state script if one is attached
	- Should tiles become entities that are managed by the Map class? This will allow tiles to have scripts attached. Or should tiles remain simple floor imagery and instead invisible entities should be created to enable area triggers. (kind of leaning to the latter, it'll be easier than reworking the Map & Tile class)
- How to save data from script?
	- Have decided to leave this up to the user, so editor created data will be handled by JsonCPP and script data will be handled by whatever is desired for Lua, and will have no interoperation between the C++ saved data and custom script data.
- How much of the editor entities should be scripted?

### Progress
- Twinklebear [9.23.2012]: Changed LuaScript::LoadModules to load all modules, we'll see how it effects load times, if it does at all
- Twinklebear [9.23.2012]: You can now load modules via LPCLoadModule, which is passed the name of the module you want to load (with proper capitalization) and should be called at the beginning of the script as you would call require usually
- Twinklebear [9.25.2012]: Removal of the old bad system for using the enum and JSON file for storing a list of required modules is now gone. Modules are loaded with LPCLoadModule. I'm considering migrating over to exposing each class's RegisterLua function however, and then you'd do LPCLoadInput() and it would eliminate the need for the string comparisons
- Twinklebear [9.25.2012]: Module's registration functions are now stored in a std::unordered_map to enable fast lookup. Map is created in LuaScript::CreateMap and given to a static const unordered_map as only one needs to exist, and it should never be able to change what it contains during the program run.
- Twinklebear [9.26.2012]: Changed the unordered_map to a map, since we never perform insertions we don't need to worry about that, just quick access across all elements. So a map is a better choice
- Twinklebear [9.26.2012]: Correction, the name of the module loading function is changed to LPCRequireModule("modulename")
- Twinklebear [9.26.2012]: Changed the unordered_map to a map, since we never perform insertions we don't need to worry about that, just quick access across all elements. So a map is a better choice

## Change Button/ObjectButton to be managed by a Lua script
### Description
- The Button and ObjectButton should have their behaviours and OnClick function defined within a script, instead of in C++ code, allowing for more flexibility

### Progress

## Editor [9.22.2012]
### Description
- Tile map editor
	- Need to be able to place any sort of map down, not be limited to a pre-generated standard size map
- Need to be able to place Entities into the scene as well
	- Related: Need to be able to create new entities from within the editor
- Need to be able to import images to the editor and have them show up in the files list.
	- Need to be able to make folders, and so on, all editor folders will be subfolders of res/
	- How can i drag things into the editor without relying on platform specific API?
		- Should i just instead monitor folders? How does SDL's clipboard support work? If i can get the filepath i can copy the file.

### Progress
- Twinklebear [9.22.2012]: LuaScript class takes care of loading the script and its desired modules. Modules are stored in JSON as an array of ints corresponding to the MODULE enum in the LuaScript class. Then before calling dofile all the desired modules are registered.
	- Should I just load all modules for every script? It would prevent errors. Would it cause slower script loading? (Added to work notes)

## Multithreading [9.22.2012]
### Description
- Naive implementation: Split into three threads: Physics, Rendering and Input (main)

### Progress
- Twinklebear [9.22.2012]: Played around with it some, but some strange issues arise, this needs to be approached with caution. Perhaps when I have a better understanding of designing multithreaded programs.

## Migration to OpenGL [9.26.2012]
### Description
- A long term goal, will eventually outgrow SDL when the time comes to being adding support for GLSL shaders, normal/diffuse/etc maps for lighting and so on.
	- Rendering will still remain 2D
- I need to learn OpenGL and become very acquinted with it. This TODO task does not and probably will not be worked on for a long time.

### Progress

## Memory Leaks [9.22.2012]
### Description
- Memory leaks when changing states
	- How will the Lua scripts effect memory usage/leaks?

### Progress
- Twinklebear [9.22.2012]: Got some memory stuff freeing correctly I think, but for some reason, if you go Menu -> Play/Editor -> Menu it allocates ~9MB of memory, I'm not sure why. It drops a bit in mem usage from Menu -> Play, but jumps up when returning to Menu. Need to investigate further

## Resizable Window [9.22.2012]
### Description
- Need to make the window resizable and have elements reposition to fit in the new window
	- Resizing window is currently disabled as resizing the window while playing and then exiting to menu would crash the program

### Progress

## General/Random/Unrelated [9.22.2012]
### Description
- Clean up warnings
- More comments/documentation

### Progress
- Twinklebear [9.22.2012]: Sidenote: Subsystem is currently as Not Set so that I can get console output for debugging scripts and such
{'fraction_non_alphanumeric': 0.05144570571856929, 'fraction_numerical': 0.02073249089740844, 'mean_word_length': 4.286684782608695, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '384094', 'n_tokens_mistral': 6056, 'n_tokens_neox': 5601, 'n_words': 3593}