dev-notes.log.txt

8/25/19
Currently not sure where we are in terms of progress. Check trello.

Current Goals:
    - Make the game in ../shapegame-examples/main.cpp run without running into
      errors.
      Current error is a heap-user-after-free main.cpp.
      Now that I see that actually it looks like it might
      be an error in the game code...

        - Upon further inspection it seems as though the code that causes issue
          lies in calling object->kill() in the main.cpp file of example.
          - This is undoubtly a logical error in the example file.
            The object that kill is attempting to be called on was likely removed
            from the list, and thus freed. Double check logic.
          - It seems then that calling

7/20/2020:
    No idea where we are at


7/21/2020:
    Currently trying to get circles to work in the Circle.hpp/cpp, and main.test.cpp files
        The current issue is... well not sure. Tried to add all the triangles that the circle needs to be created, but its clearly not working.
        Next steps for breakdown might be just draw the first triangle of the circle and see if we can get that to go right?

7/21/2020:
   Still working on trying to get circle drawing working, and just reached a
   breakthrough. The is a circle-esque thing that I have gotten to draw, but it
   is objectivly wrong. Could be an issue with Ben's algorithm, but could
   also be an issue with the way I'm drawing triangles. To get to the bottom
   of this I recommend that you draw the triangles generated on paper to try to get
   to the bottom of this. A deeper underlying issue is that you don't know the order
   in which triangles are drawn by your own game engine!!!!! You should get to the
   bottom of that one too

7/22/2020:
    Got Circles working!!!! Just needed to convert degrees to radians and do a
    couple other things with the algorithm

7/22/2020:
	Got the algorithm issues sorted out and everything is looking good with circles! Still to do with circles,
	- optimize using opengls traingle fan function
	- automatically deduce the fidelity based on circle size

7/22/2020:
	everything is working well, started working on recreating my snake game. Thinking about anti-aliasing, and trying to
	match the snake game. Its clear that the engine needs an option for settings the anti-aliasing properties along with
	potentially other engine properties


7/28/2020:
  Got the library working with windows as a compiled static library along with headers and opengl

7/28/2020:
  Added the boilerplate for rotation. Now just need to call the
  rotation method on each point before converting them to a vertex.
  Also need to implement the rotation method

  See: VertexHandler.cpp::triangleVerts
    Object.hpp/cpp


7/30/2020:
  Trying to get rotation working. Running into issues algorithmically clearly. Should try to reach out to Ben to see if he can help me.

7/30/2020:
  Got rotation working BETTER using algorithm from stack overflow, but still having issues. Plugging in a single degree rotates it WAYY more than 1 degree.
  Its weird. Theories are: 1) It could have something to do with radians. 2) It could have something to do with the translation before the rotation?
  Maybe that does something weird to the angle formula?

8/3/2020:
  Got rotation working for a single triangle with Bens help. Next step, get rotaion working for entire MultiShapes.
    The steps to get this working are:
      - Get the highest parent in the heirarchy, and use it as the origin for all rotations INCLUDING the 'pos' rotation of the triangle.
      - A potential optimization to this is to add a check to see if the origin == the rotation point, and don't rotate it if so


8/5/2020:
  Working on getting rotation working in multishapes (circle). Its not working out well. It seems that the issue is that when the vertexGenerator goes to rotate shapes,
  the parent object in the multishpae isn't properly considered. I think the issue may be that the parent object isn't considered 'dirty' when it is roatated. Regardless
  things are left in a very messy state right now and should be addressed. ASAP

8/6/2020:
  Got rotation working well!

8/10/2020:
  Working on other rotation methods such as setRotation, and rotateAround.
    - setRotation is giving me some issues with, but I think I have an idea what I need to do.

8/10/2020:
  Got setRotation working well, as well as rotateAround working well.
  All is well up to this point, want to work on scaling next, and then have a 'code-freeze' (with the exception of cleanup)
  and try to get ready to release v1.0.0


9/10/2020:
    Begining to work on scaling

9/13/2020:
	Just got scaling to 'work' but its certainly not working correctly. Look into whats going on
9/14/2020:
	Scaling on the Y axis still doesn't seem to be working. Decided to rewrite the scaling in a simpler way
	first by writing and implementing a setScale method first. That way we know we don't need to keep track
	of as much. So far all I've done is write the boilerplate to the Object class, still needs implementation
	in object to be thought out, and needs to be implemented in the vertexGenerator. Things won't compile now

9/17/2020:
	Realzing that there are issues with my scaling algorithm. I'm scaling based on posiiton of points, thinking through
	it now, the scale should be considering the height and the width of the object its self right? Because scaling a point
	on the y axsis at 1 * 2 will only move the point 1 pixel even if the object is 100 pixels tall. So the scaling algorithm
	should be:
		y += (scaleFactor * height)
		x += (scaleFactor * width)


	NOTE* Godot scaling moves everything AWAY from the origin (which makes sense).

	So in order to implement this feature we need to first implement a few other features, which may be non-trivial

	- Width
	- Height
	- Calculate Direction between points (e.g. Up, Down, Left, Right) (should be pretty easy)

		e.g. y = 1, height = 100, scaleFactor = 2;
		scale(y, scaleFactor) == 2 * 100 == 200


	Width, Height:
		These numbers will have to be calculated, and here is a suggested algorithm,

			For height: difference between heighest and lowest y value
			For width: difference between left most and right most x value
				We can keep track of these numbers as shapes are added to multi shapes,
				we need to figure out how to handle it cleanly between MultiShapes and Triangles and MultiMultiShapes. Maybe
				what we should do is keep track of it in every triangle and multishpae, then when a shape is added to a multishape
				we ask for most exreme poitns, if any of them are father (more extreme) than the multishape being added to, they
				become the new value.

				With this implementation something else we'll have to do is update these values when any scaling, adding, or removing
				happens.
				Another place where this might get hairy is in rotations. If any object is rotated 90 degrees, does its width
				and height values change? What if an object is added while an object is rotated, do we need to roatate that object
				first and then calculate? This actually brings forth a deeper question about how do we handle objects being added
				to rotated objects in the first place. We need to figure that one out.
9/17/2020:
    Just created a branch to work on height-width as per above comments
9/21/2020:
	Apparently there was already an implementation for width and height, it just wasn't finished. I went ahead and finished
	it, but it needs more work for mulitshapes
9/23/2020:
    Going to try to implement width and height for multishapes

    UPDATE:
        - Implemented the algorithm and it seems to almost be working. Looks like we need to account for position somewhere?
        The main file shows that an objects width is 110 when it should just be 100. Look into this

9/24/2020:
	Tried to finish implementing height and width, but running into issues recalulating the height and width after
	 the size has changed when a triangle is scaled. Also the implementation of the calculation of the triangle size is
	 very convoluted and should be reworked.
	 TLDR: Need to recalulate height and width when scaled
	
9/27/2020:
	Realized that the scaling does work, but the height and width are mixed up. Lets try to sort that out
	UPDATE:
		- Turns out I was just setting the variables opposite in the calulation code
	UPDATE:
		- While trying to write some test code, i realized that using the MutliShape::addShape method doesn't work
		outside of the constructor. I think the reason is that shapes aren't actually added to the scene in multishapes
		when they are added, so we need to figure that one out.
	UPDATE:
		- Was finally able to get the feature working where you can add an object to a multishape after Its
		already been added to the scene, BUT WITH A BIG CAVIAT! It seg faults when the game is closed. This seems
		to be due to a double free or something. Figure this out next
	UPDATE:
		- Fixed the seg fault issue. Everything seems to be working properly with adding objects to multishape after
		its been added to the scene
9/29/2020:
		While testing out scaling, realized that although the results of the getSize()
		method is acurate, its not actually acturate until the vertexes are updated for
		the given object, which is needless to say not right away. So a good idea would
		be to calculate what the new size is going to be before the vertexes are updated
9/30/2020:
	Now calculate the size of the object before and after scaling. The after scaling is probably overkill,
	but kind of a fail safe because the calculation method seems more accurate? Maybe rethink this in the future
	TODO:
		Scale relative to original. setScale method should be relative to the objects original size. E.g. psudo code
			print(obj.size) // (10, 10)
			obj.setScale(5, 5);
			print(obj.size) (50, 50);
			obj.setScale(1, 1);
			print(obj.size) (10, 10);
10/1/2020:
	- Working on reimplemneting setScale method to scale relative to original scale as described in yesterdays notes
	UPDATE:
		- Gave up on trying to scale object correctly for now. Haven't figured out the algorithm yet other than 
		two do it in 2 steps, scale back to 1, then scale up from there and that would be waste as well as annoying and dirty to implement. Think on it more



10/4/2020:
    - Trying to figure out how to get the scaling how I want it.
    - Can't figure out how to get scaling the way I want it to be. I'm going to do it in 2 steps
        and maybe optimize later if needed

10/7/2020:
    - Can't figure out how to get scaling the way I want it to be. I'm going to do it in 2 steps
        and maybe optimize later if needed
		UPDATE:
			- Copied the current implementation of the setScale method into the scale method because that is the behavior we want
			for scale I believe. We could possibly call it scaleBy

			UPDATE:
				- The setScale method has code in it, but it is not correct. We are going to need some other control variables
				to determine how much we need to scale down by and what not

			UPDATE:
				- Trying to update the scaling algorithm in the vertex generator, but I'm just taking shots in the dark. Need to think this throught
10/8/2020:
	Think I may have gotten the setScale method to work the way I want it to. I'll have to run more tests tomorrow


10/13/2020:
	- Testing out scaling. Have found some issues so far:
		- When scaling and rotating at the same time things don't go right


10/14/2020:
	- The scaling algorithm clearly has issues, scaling doesn't work correctly when the object is
	at different positions on the screen. I think it has something to do with the way that the
	origin point is being scaled. Check it out.

	UPDATE:
		- New revalation, scaling algorithm is incorrect. The scale depends on location of the point,
		which doesn't make any sense. Thats where the wonky scaling is coming from (at least some of it)
		What we actually need to do, not multiply the x or y location times the scale factor, but ADD 
		the scale factor times the width, to the x or y location
	UPDATE:
		- That ^ doesn't actually work. Rethink algorithm


10/18/2020:
	- Updated the scaling algorithm, it seems to be ALMOST working, but doesn't scale back
		down properly

10/19/2020:
	- Trying to figure out scaling issues. It seems to be scaling up okay, but scaling down, sill scales up


6/5/2026:
- Just gave up trying to get clion to debug my project
- Found out lldb has a 'gui' feature that is pretty nifty
- Finally got shader pulled in from its own file rather than inline.
- Next step...?
	- It would be a good idea to continue trying to implement all transforms
		- rotate
		- scale
		- translate

- It would be fun to make more games and implement features as needed to the engine

6/26/2026

- Debugging can now happen in vscode with F5 from 'main.test.cpp'
- Updated 'sani' paths for new homebrew location so that address sanitizer builds should work
	- Might be nice to have this enabled by default since this laptop has a bit more power
- Working a little bit more on implementing scaling:

	Added a Transform object top-level then also added it to Object.

	The idea is to implement all transform actions based on that object.

	I think that the implementation will be like:

	We'll have a global 'Position point(x,y)'
	- Then we'll apply transforms on a per-frame basis?
	- Could we apply the transform in openGL?


6/27/26
- Going to try to remove all other scaling logic
- Removed all existing scaling logic and the snake game seems to be working more correctly now!

6/28/26
- Realized that shape's 'update' methods weren't working properly, but entity update methods
were. Brute force removed 'dirtyable' logic from re-draw pipeline and now application stupidly
recalculates everything all the time.

This worked!

Going to strip out the rest of the 'dirtyable' logic and see if we can come up with a cleaner
solution if/when it is needed

--
Removed 'dirtyable' logic and 'Position.hpp' and replaced it with a Point everywhere.

'Position' was exactly the same as 'point' except it captured dirty logic and that was pretty
gross.

For now we're just going to be dumb and update everything in the scene all the time.

Optimize when needed.