freenode/#shirakumo - IRC Chatlog
Search
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?
17:13:26
Shinmera
Yeah, gone are the days of only being able to afford memory for one screen at a time.