freenode/#shirakumo - IRC Chatlog
Search
6:55:19
Shinmera
I feel like I might to revise the Simple API to be changed such that the draw functions first return an object representing the shape to be drawn, and then you can call render on those.
6:55:35
Shinmera
Would still allow immediate stuff be just rendering and discarding, but it would also allow caching things.
7:13:01
Shinmera
Currently they look like this (animated, too!) which is, uh, very interesting. https://filebox.tymoon.eu//file/TVRnd05nPT0=
7:46:09
Shinmera
The current transform matrix I pass along to the shaders is the full MVP matrix (there's no distinction in Alloy)
7:46:43
Shinmera
So the only choice I have is to pass in a projection scaling vector to scale the normal by
8:54:25
Shinmera
anyone know a fast way of determining the minimal delta to push an AABB inside another
13:21:29
scymtym
Shinmera: i worked on the traits idea a bit: https://techfak.de/~jmoringe/traits-idea.html . i think what is shown would work without runtime overhead compared to regular generic function dispatch but i suspect an SBCL bug causes additional COMPUTE-APPLICABLE-METHOD calls
13:21:29
Colleen
www.uni-bielefeld.de/techni... Website (HTML), Title: Universität Bielefeld: Technischen Fakultät
13:42:55
Shinmera
scymtym: Though I have to wonder if there's a (maybe implementation-dependatn) solution that would allow attaching actual type information to instances.
13:47:27
Shinmera
I'm mostly thinking of the Scala traits, where you decide what traits to combine at instantiation
16:55:46
Shinmera
|3b|: Do you have any thoughts on how to implement the caching logic for an immediate UI? I'm struggling to think of a good way to manage GL resources-- making sure they don't just get allocated out the wazoo and/or never deallocated.
16:58:32
|3b|
not thought that far, aside from having some sort of scoped resource manager thing that can automatically deallocate a bunch of things at once by name or scope (and with a wrapper with validity tracking for the resources, so they can error if used after deallocation)
16:59:51
Shinmera
I'm asking because I don't see the situation being much better in a retained mode UI
17:00:26
|3b|
yeah, seems like retained-mode just makes it easier to tell what can be cached / for how long
17:01:33
Shinmera
Even then it's hard to keep track of stuff. Like, if lots of things are drawing line strips... should I allocate fixed VBOs for everything, and hope there's not too many to blow me up, or should I just stream it every time?
17:02:49
|3b|
ACTION has some vague thoughts about having a fairly big VBO with 'automatic' memory management/GC inside it, but probably will start with just a bunch of small VBOs
17:04:41
|3b|
though wouldn't have the liveness tracking of a real GC, mostly just compacting it to avoid fragmentation
17:05:07
Shinmera
Yeah, but even then I shudder to think of this blowing up in someone's face and trying to debug it.
17:05:13
|3b|
GPU have lots of bandwidth, so that should be reasonable fast, leaving only tracking/updating offsets on host side to deal with
17:07:06
|3b|
i'm just talking about moving parts of a buffer around inside that buffer (or from 1 buffer to another), all on GPU
17:10:12
|3b|
ACTION would probably lean towards just rendering windows to an FBO, and caching that, ideally with incremental updates
17:11:11
Shinmera
Caching circles and rectangles is easy enough, but text, line strips, beziers, gradients (?) etc would be more tricky.
17:11:34
Shinmera
Not even sure what I'd do for gradients. stencil the shape then use a rect or something?