freenode/#shirakumo - IRC Chatlog
Search
6:14:07
|3b|
Shinmera: normalize just the .xy part? i think i also had some problem with calculating normal using eye ray vs screen normal, don't remember details though
6:15:05
Colleen
github.com/Shirakumo/trial/... Website (HTML), Title: trial/workbench.lisp at master · Shirakumo/trial · GitHub
6:45:01
Shinmera
|3b|: doing that multiplication makes the lines crazy huge. Doing a divide makes them crazy thin.
6:48:40
Shinmera
The page I've been semi-following also doesn't seem to do any more than what I'm doing. https://mattdesl.svbtle.com/drawing-lines-is-hard
6:50:13
Shinmera
It /does/ add 1 to w but I think that's wrong, and also adding that doesn't fix anything.
8:05:11
Shinmera
multiplying by w and dividing by (about) the screen width seems to work, but I don't understand why.
8:08:01
|3b|
ACTION ended up just storing other point instead of point1-point2 or whatever in attribute, save some math on CPU and closer to what you want on GPU anyway
8:09:16
Shinmera
Well, point1-point2 can also be point2-point1, which will encode whether the point is "up" or "down"
8:12:23
Shinmera
Depends on which call it is. Rects and circles are cached, but polygons are immediate.
8:13:12
Shinmera
By the by, I also looked at implementing https://gamedev.stackexchange.com/questions/100614/gpu-friendly-bezier-storage-evaluation but couldn't seem to get it to work (didn't spend much time on that)
8:13:12
Colleen
gamedev.stackexchange.com/q... Website (HTML), Title: GPU friendly bezier storage/evaluation? - Game Development Stack Exchange
11:36:43
Shinmera
I'm very unhappy about how components, their extent, and their focus is strewn about and how hard it is to connect everything together satisfactorily.
11:37:20
Shinmera
Especially right now the component contains state that's required to manage its interactivity, but that doesn't mesh well with a component appearing in multiple layouts at once.
11:38:00
Shinmera
Right now I'm thinking I need a much lower level of abstraction for the "content" that should be displayed (text, editable text, boolean, choice, etc.)
11:38:40
Shinmera
And a representative component that acts as both a focus-element and a layout-element, and is responsible for managing the interactivity state, as well as the display state.
11:39:24
Shinmera
Since then each "component" is completely self-contained and you'd just create multiples of that fora particular "content" the management of the state would be much cleaner.
11:40:50
Shinmera
Usually if I can't explain something well enough it means I don't understand it well enough yet either.
15:20:24
Shinmera
1. data containers. This can be practically anything, though there will be convenient "standard containers" in case the data is only in the UI and not already represented somewhere else.
15:21:06
Shinmera
2. layout trees. These trees define the extent of elements that are displayed as well as the way they are rendered
15:21:26
Shinmera
3. focus trees. These trees define the way most events are routed and handled in the system.
15:21:58
Shinmera
4. components. These are representations of data containers that sit in a layout tree and possibly a focus tree.
15:22:57
Shinmera
5. data protocol. This protocol is a set of generic functions that allow the exchange of necessary information between a component and the data container that it represents. The protocol will need to be different for each type of data to represent.
15:24:01
Shinmera
Since components are now "shallow" they only manage display and interaction state, and there can be many components representing the same data container.
15:26:04
Shinmera
And since a component is now both a layout-element and a focus-element there's no more need to juggle the state between the two trees. The component will simply live directly in both, rather than having a container in both trees to hold the state for the component.
15:31:02
Shinmera
I'm also not sure if this is "just" MVC, as I'm never could quite understand what MVC was supposed to be exactly.