-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdev-notes.log
248 lines (196 loc) · 12.1 KB
/
dev-notes.log
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
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