Congrats! Looks like a lot of updates to Gloss (CHANGELOG.md > 2024, 2026).
I confirm that Tetris ran on an arm mac, macos tahoe 26.2. (How-to: download, try to run it once, go to mac’s Settings > Privacy & Security, scroll to the bottom, allow brillo-tetris, run again, confirm dialogs.)
Looks good! I’m not sure about the “placement” though. Is this a full replacement for gloss? Is gloss somehow less maintained nowadays? In other words, why fork?
Yes, gloss is unfortunately less maintained, and depending on it is becoming more and more of a pain. As a maintainer with several libraries depending on gloss I’m very happy about this development.
I wanted to try out things, remove code, refactor stuff, etc without having to think of legacy users. That’s why I thought proper fork with a different name would be more suitable. The gloss team is more than welcome to adopt/copy any changes they’d like to see in Gloss!
Hello, I’m glad to see gloss being given some love!
I’m wondering about the motivation behind this change: to me the philosophy of gloss is that Picture is an abstract datatype. I shouldn’t need to care about how it’s represented and what its constructors are. Exposing these constructors means that clients of the library may start deconstructing pictures, hindering possible future refactorings.
Or did you maybe come across situations in which deconstructing pictures was useful?
Deconstructing / pattern matching was already supported as the constructor was already exposed. So they were not even true smart constructors. Given that, I don’t really see a point in wrapping it with a useless polygon = Polygon.
Also, I think graphic programming is one of the few areas where you actually want to know what’s going on under the hood so you don’t accidentally introduce performance bottlenecks.
Picture data constructor → Directly handled by Brillo
Function → Some code will be executed to create the Picture. You might be able to implement it in another way that better suits your use-case (lower resolution polygon, shader, bitmap, …)
No, unfortunately the entire rendering pipeline is still immediate mode. But yeah, making this more efficient would be a great addition for the next release. Any help would be highly appreciated!
I’m not very good with GL2/3 (I stopped doing graphics sometime when openGL1 was OK and restarted now in vulkan times ) but from what I understand there’s no good way to do actual command buffers in GL3, just some (very fat) prepared-command-buffers that the shaders can expand?
Last time I looked into that, it should be relatively easy to introduce opengl display lists (an immediate mode feature! deprecated in 3.1, yay!). Looks like the whole Picture can be compiled into it. Then a new primitive DisplayList can be added to call them (even as a part of other pictures. Not sure if they can be nested though).
Hi all, my first post/comment here. I’m learning Haskell, and for other reasons than graphics, but I have, in an earlier life, written an immediate mode OGL renderer, before converting it to OpenGL 3.2 or so.
The main idea is the number of draw calls must be minimized, and that there is a prioritized order of state updates. Data (vertices, colors, other data that can be used by shaders) stored in Vertex Buffer Objects is the cheapest to deal with, these are streamed across the other state (in the GPU). If you can rewrite stuff to instancing, even better.
Then matrices, textures and at last shaders. Absolutely sort drawables by shader. An effect of this is that it is common to make shaders of maximum code size, such that they cover as many use cases as possible.
The basic premise for instancing is that if there are shapes that can be generated (by geometry/tesselation shaders) given just a few datapoints (e.g. position and orientation, texture coordinates, …), you can put out millions of things in a single draw call. I used this for map elements (lines for example).
) but from what I understand there’s no good way to do actual command buffers in GL3, just some (very fat) prepared-command-buffers that the shaders can expand?