GUI Design

[kaveh808]

[Starting a new discussion on this topic from the Introductions discussion.]

I am thinking of basing the GUI on a design like the Glamorous Toolkit, which is based on Smalltalk.

Each GUI panel will be a customizable inspector window for the current selection. For this, I imagine being able to embed an editor window to represent and edit the code view of the objects. The editor would be connected to slime so that the user can directly modify and evaluate code in it and see the results in the 3D views.

In fact all the UI, including 3D views and the like, will be implemented as such inspector windows. This may mean that it would be better if all the GUI used the same compositor as the 3D scene.

I would recommend checking out the link above and watching the first video to get an idea of how their toolkit works and how it may apply to our system.

[awolven]

I have actually been looking at Pharo for my ide design, I haven't seen Glamorous Toolkit until now. Adhoc is designed with smalltalk in mind, btw.

…

On Sun, Aug 21, 2022 at 1:21 PM Kaveh Kardan ***@***.***> wrote: [Starting a new discussion on this topic from the Introductions discussion.] I am thinking of basing the GUI on a design like the Glamorous Toolkit <https://gtoolkit.com/>, which is based on Smalltalk. Each GUI panel will be a customizable inspector window for the current selection. For this, I imagine being able to embed an editor window to represent and edit the code view of the objects. The editor would be connected to slime so that the user can directly modify and evaluate code in it and see the results in the 3D views. In fact all the UI, including 3D views and the like, will be implemented as such inspector windows. This may mean that it would be better if all the GUI used the same compositor as the 3D scene. I would recommend checking out the link above and watching the first video to get an idea of how their toolkit works and how it may apply to our system. — Reply to this email directly, view it on GitHub <#29>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMIYCQC2IQ4PMKPOYGDV2JXT7ANCNFSM57FK74UA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kaveh808]

Pharo looks very slick. Like a modern version of the old Smalltalk 80 from Parc Place.

I want our system to be an IDE with an emphasis on 3D graphics.

[lukego]

GToolkit is awesome. I even switched from Lisp to Smalltalk to use it for a good long while. But I decided Lisp is an easier language for me to think in and gave up that nice environment to come back.

GToolkit implementation strategy seems to work well too. They build it on one modern cross-platform graphics framework and when a better one comes along they do a port (so far from Morphic to Moz2D to Skia.) That takes work but it avoids being stuck between incompatible native toolkits on different platforms.

I don't like the all-or-nothing aspect of GToolkit though. I don't want to use their text editor or Git client. I think it should play nicer with external tools.

[kaveh808]

Interesting. So do they use Skia as a 2D rendering engine and do their own UI classes on top of it?

I am thinking of building our GUI system in a cross platform way on top of OpenGL or possibly Vulkan.

[lukego]

So do they use Skia as a 2D rendering engine and do their own UI classes on top of it?

Yeah. According to the bottom of https://github.com/feenkcom/gtoolkit#components they have four layers:

• Brick: high-level widgets.
• Bloc: graphics.
• Sparta: canvas based on Skia.
• Glutin: native window & OpenGL access.

I'm not sure if there ideas there that could be borrowed/ported onto OpenGL/Vulkan. It seems to work well for them and to have been implemented quickly by a small team, anyway.

[JMC-design]

I'm not sure how quickly 10-20 years is. The model would have to be different since this would be 3d.

[kaveh808]

Let's keep Skia in mind. It has Google backing it, which is reassuring. I haven't looked at it in depth, not sure if it handles events and such or is only a drawing layer.

[JMC-design]

So unless you want to use some foreign toolkit it seems like pure 3d is the only way you can get cross platform.
None of the lisp bindings to windows api's seem to be in a working state. Wasted most of yesterday finding that out. Theoretically you could probably figure out stuff from Cormon cl which still works on windows, but ...
So if you want it now, pure 3d. So if you can understand the api's (i think I'm too simple for that), maybe Alloy should be considered as it already has widgets and text rendering?

[kaveh808]

My thinking is an immediate mode GUI built on top of OpenGL, along the lines of ImGui or NanoGUI.

That seems to be the simplest way to go with the fewest dependencies. I am thinking of those toolkits as inspiration, not something we want to build wrappers around. I think for what we're doing, it's important that the gui be written in CL for maximum extensibility.

Let's keep an eye on Alloy, and maybe evaluate it down the road.

Still early days. A lot to be discovered.

[awolven]

I have already written wrappers to imgui, if one needs to see how Imgui handles situations.

…

On Mon, Aug 22, 2022 at 1:53 PM Kaveh Kardan ***@***.***> wrote: My thinking is an immediate mode GUI built on top of OpenGL, along the lines of ImGui <https://github.com/ocornut/imgui> or NanoGUI <https://github.com/ocornut/imgui>. That seems to be the simplest way to go with the fewest dependencies. I am thinking of those toolkits as inspiration, not something we want to build wrappers around. I think for what we're doing, it's important that the gui be written in CL for maximum extensibility. Let's keep an eye on Alloy <https://github.com/Shirakumo/alloy>, and maybe evaluate it down the road. Still early days. A lot to be discovered. — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMMC2EGE3VTHH23STT3V2PEDBANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[awolven]

One thing I would like to point out about immediate mode guis is that they are designed to be run in the render thread or a support render thread (if using vulkan) and if the events they trigger also run in the render thread (which is the typical way to use them), then any unhandled errors that happen while developing crash the whole program. I think fatal errors like that while developing the gui are unacceptable, so you need to build the app in such a way that events are handled in other threads and the render thread is basically "fixed function" (to borrow the term) so it will never crash on erroneous input.

…

On Mon, Aug 22, 2022 at 4:07 PM Andrew Wolven ***@***.***> wrote: I have already written wrappers to imgui, if one needs to see how Imgui handles situations. On Mon, Aug 22, 2022 at 1:53 PM Kaveh Kardan ***@***.***> wrote: > My thinking is an immediate mode GUI built on top of OpenGL, along the > lines of ImGui <https://github.com/ocornut/imgui> or NanoGUI > <https://github.com/ocornut/imgui>. > > That seems to be the simplest way to go with the fewest dependencies. I > am thinking of those toolkits as inspiration, not something we want to > build wrappers around. I think for what we're doing, it's important that > the gui be written in CL for maximum extensibility. > > Let's keep an eye on Alloy <https://github.com/Shirakumo/alloy>, and > maybe evaluate it down the road. > > Still early days. A lot to be discovered. > > — > Reply to this email directly, view it on GitHub > <#29 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABGMMMC2EGE3VTHH23STT3V2PEDBANCNFSM57FK74UA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[kiran-kp]

I am working on a ui lib for a personal project and solved this by separating out rendering, widget layout and state updates into three separate functions. This loosely follows the Elm Architecture.

The rendering is the only part that needs to happen on the render thread and state updates/widget layout can happen on any thread. I'm currently running single threaded but eventually, the layout code would build up vertex buffers/index buffers just like Dear ImGUI does and the render thread would just be binding resources and issuing draw calls.

This system composes well IMO and it's easy to switch out the underlying implementation of how layout and rendering is done.

Example user layer code

(defclass ui-state ()
  ((player-speed
    :initform 10)))

(defun ui-init ()
  (make-instance 'ui-state))

(defun ui-update (msg model)
  (case msg
    (increase-speed
     (with-slots (player-speed) model
       (incf player-speed)))
    (decrease-speed
     (with-slots (player-speed) model
       (when (> player-speed 0)
         (decf player-speed))))))

(defun ui-draw (model)
  (gooey:push-window "Player Inspector")
  (gooey:button "Increase Speed" 'increase-speed)
  (with-slots (player-speed) model
    (gooey:label (format nil "Speed: ~a" player-speed)))
  (gooey:button "Decrease Speed" 'decrease-speed)
  (gooey:pop-window)

  (gooey:push-window "Test Window")
  (gooey:label "This is just a sample window")
  (gooey:pop-window))

gooey_recording.webm

[kaveh808]

That is good to know. Also annoying. :)

I am not an expert on threading, and my only experience with it in CL has been that UI interactions have to be on the main thread on MacOS. I imagine that our system should be doing a lot of multithreading to take advantage of all those CPU cores. And offload whatever is possible onto the GPU for computations.

If we were willing to put in the work, what is the conceptually simplest and most minimal layer we can build a cross-platform gui on top of? Something like GLFW for handling events and device input, and bare OpenGL for display? In such a case, I imagine we would be reproducing some or most of the work done by ImGui in CL?

[awolven]

I was planning on piecemeal replacing ImGui until it's all Lisp. ImGui is actually a pretty substantial facility with it's docking and multiple OS window support. GLFW is fine for now but could potentially be replaced by "glop" if you desire a pure-lisp solution. There is also the issue of compute shaders. I personally wouldn't be interested in any graphical lisp software that did not include support for compute shaders. The GPU is capable of solving certain types of problems like Nurbs evaluation and meshing in 1/100th the time of the CPU. I think Baggers even wrote a little lisp compiler which compiles Lisp to GLSL. I'm not for certain, but I think compute shaders were not introduced in OpenGL until OpenGL v3 or v4. You will find that OpenGL 4 is as alien compared to OpenGL 1.1/1.2 as Vulkan is to OpenGL 1.1/1.2. So if you decide you want to include developers that use compute shaders, I would recommend Vulkan and Metal as the graphics languages. For a decade now, game developers have been complaining about threading issues/bugs with OpenGL and that's why Khronos adopted Vulkan as it's new flagship standard for the decades to come. So when you decide you have had enough with the limitations of OpenGL 1.1/1.2 (if indeed that is what you are using) then I would seriously consider switching to a Vulkan/Metal combination. I have been planning on writing Metal bindings for some time now, because I have a mac, and ultimately want people with Macs to be able to use Regen.

…

On Mon, Aug 22, 2022 at 4:38 PM Kaveh Kardan ***@***.***> wrote: That is good to know. Also annoying. :) I am not an expert on threading, and my only experience with it in CL has been that UI interactions have to be on the main thread on MacOS. I imagine that our system should be doing a lot of multithreading to take advantage of all those CPU cores. And offload whatever is possible onto the GPU for computations. If we were willing to put in the work, what is the conceptually simplest and most minimal layer we can build a cross-platform gui on top of? Something like GLFW for handling events and device input, and bare OpenGL for display? In such a case, I imagine we would be reproducing some or most of the work done by ImGui in CL? — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMI4HEU52DACKUMKAO3V2PXM7ANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[JMC-design]

glop is not pure lisp. Pretty sure mfiano, 3b, and some others also have lisp dsls for shaders.

[awolven]

you can't get rid of win32, cocoa or X to manage the window system, but what can be lisp is lisp in glop, or at least could be.

…

On Mon, Aug 22, 2022 at 5:21 PM Johannes Martinez Calzada < ***@***.***> wrote: glop is not pure lisp. Pretty sure mfiano, 3b, and some others also have lisp dsls for shaders. — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMPSYOZ3CPTPN7GBFJLV2P4QBANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[kaveh808]

Yes, compute shaders are exactly what I meant by running CL code on the GPU. I'm all for that. I don't want people complaining that our system is slow because it's written in Lisp. :)

I don't know much about Vulkan except a couple of videos I have watched. Never used it, but by all accounts it is more complicated to use than OpenGL.

Here's what I'm thinking:

Once we have an SBCL version of the code running on MacOS and Linux (the Windows version can be done later once somebody volunteers) using OpenGL, then if someone wants to work on a Vulkan version of our rendering code, I say go for it. If it goes well, maybe at some point we abandon OpenGL and go completely Vulkan.

[JMC-design]

So I'm really starting to like GLOP. Totally unlike GLFW where the window and context are melded never to be separated.
You can create multiple contexts and attach them to different windows. I can also make an x11 surface from the glop window and manipulate it through CLX. Which means there is also the possibility of not being restrained by the eventing system and use an os specific event loop, or multiple event loops.

If you don't mind I can take a look at moving stuff to glop, probably over an abstraction layer, and then see if it works on windows after it works on linux.
edit: which branch should I base off, or wait till they're merged?

[kaveh808]

Sounds good. I'd wait a couple of days while we clean things up and merge. Then have at it.

[JMC-design]

will do. Meanwhile I've almost got glop working as a backend for my stuff and can use that to check out how stuff works on windows.

[kaveh808]

The main branch is good to go for your glop work.

[awolven]

that sounds excellent

…

On Tue, Aug 23, 2022 at 10:55 AM Johannes Martinez Calzada < ***@***.***> wrote: So I'm really starting to like GLOP. Totally unlike GLFW where the window and context are melded never to be separated. You can create multiple contexts and attach them to different windows. I can also make an x11 surface from the glop window and manipulate it through CLX. Which means there is also the possibility of not being restrained by the eventing system and use an os specific event loop, or multiple event loops. If you don't mind I can take a look at moving stuff to glop, probably over an abstraction layer, and then see if it works on windows after it works on linux. — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMMBWLNMOC63MYNRJX3V2TX7RANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[awolven]

you might want to touch base with |3b|

…

On Tue, Aug 23, 2022 at 12:11 PM Andrew Wolven ***@***.***> wrote: that sounds excellent On Tue, Aug 23, 2022 at 10:55 AM Johannes Martinez Calzada < ***@***.***> wrote: > So I'm really starting to like GLOP. Totally unlike GLFW where the window > and context are melded never to be separated. > You can create multiple contexts and attach them to different windows. I > can also make an x11 surface from the glop window and manipulate it through > CLX. Which means there is also the possibility of not being restrained by > the eventing system and use an os specific event loop, or multiple event > loops. > > If you don't mind I can take a look at moving stuff to glop, probably > over an abstraction layer, and then see if it works on windows after it > works on linux. > > — > Reply to this email directly, view it on GitHub > <#29 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABGMMMBWLNMOC63MYNRJX3V2TX7RANCNFSM57FK74UA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[JMC-design]

That was my thought when I read his thoughts for glop2. Lots of overlapping stuff with what I'm doing already.
I really need to finish that irc client. Too many projects, not enough time.

[kaveh808]

Who or what is |3b|?

[JMC-design]

he's the guy to thank for cl-opengl and glop, as well as many other ffis to graphic related stuff.
Think he's currently working on (m)sdf generation of glyphs for font atlases as used by Shinmera and trial/alloy.
https://github.com/3b

[kaveh808]

Very cool. Holy cow, 115 repositories!

[JMC-design]

I wish there was a way to keep your own repositories separate from ones you've forked. I keep forking stuff I think will disappear and now I can barely find my own stuff.

[JMC-design]

Is anybody here experienced with windows dev? God I hate that POS.
It seems ~ doesn't work in strings/format because of stupid windows line endings. is there a way to not get those added? Or windows needs them?
git at the command line doesn't seem to work properly, clones some repositories, and it creates folders neither emacs or explorer can view. finally used the stupid git gui and then it didn't download my newest commits for who knows what reasons.
Seems like windows might require you to handle certain events, crashed on resizing, something which is kind of optional on linux because of how window managers work. Does anybody know if there are required events to handle on Windows and MacOS?

[awolven]

im just looking at the code -- why it would give that message.

…

On Fri, Sep 9, 2022 at 3:42 PM Johannes Martinez Calzada < ***@***.***> wrote: if it has multiple cmap tables for different languages or multiple fonts within one file I don't think 3b has pushed that yet. But it's recent stuff he's working on. — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMML4U5R4BKZDDPVVFETV5OONFANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JMC-design]

Some fonts, either because of bad conversions, or some stupid thing apple does using 16bit indices, will create a font without a character map table.

[JMC-design]

huh, works for me with the monaco font I found at font mirror.

[ghost]

I came across this while looking for lispm's comments on S-expressions:

https://news.ycombinator.com/item?id=15119836

If I won the lottery, I'd hire some smart friends to make a new SK8 with an updated version of the old Dylan and a 3D game engine designed for building immersive environments by modifying them as they ran.

I don't think I could find this person, never mind winning the lottery or finding any smart friends. Oh well, "missed opportunities"...back to imitating Blender.

[ghost]

So let's see...kons-9 has:

• Lotto winners
• Smart friends (adjective elided in my case, but true in general for kons-9)
• Updated version of old Dylan
• 3D game engine
• Building immersive environments by modifying them as they run
• Need for GUI
• People who have worked on projects canceled by pointy haired bosses, including technology ahead of its time, now liberated from their corporate overlords

No, I'm still not seeing it. CL != Dylan, darn. (I wish GH markdown had "-" indeterminate markers.)

[mikelevins]

I've written before about what I liked better about circa 1992 Dylan than Common Lisp, but I don't propose to insert a screed here on that subject. It boils down to all the advantages of Common Lisp with a simpler surface language that is easier to learn and extend.

But I like Common Lisp better than any other programming language that actually exists (the current versions of Dylan don't count; they lost too much of what was good about the language in 1992). If we can build it all in Common Lisp, that's good enough for me.

The lottery winnings are not a philosophical requirement; I just assumed they were a financial one. If the kons-9 project manages to do what I hoped for without a pile of money, that, too, is good enough for me.

The requirement you are omitting is SK8, but I don't fault you for that. The number of people who know what SK8 was and what it offered is very small.

[ghost]

The requirement you are omitting is SK8

I know I was being oblique, but SK8 isn't a requirement, it is the project. Note that you also said on HN:

my favorite development environment ever was SK8, Apple's HyperCard-on-steroids-with-a-built-in-knowledge-representation-system

what I liked better about circa 1992 Dylan than Common Lisp

Again, obliquely, I meant that Common Lisp is closer to Dylan than C++ which even today is the funnel for projects. I'd like to rebuild prefix Dylan--but that's a lonely position. Common Lisp has a few warts--it isn't brain dead by any means.

The number of people who know what SK8 was and what it offered is very small.

Probably true, but also true of Lisp Machines, prefix Dylan for Newton, Open Inventor, and who knows what else. Why not build what we want and what we know is good?

So what the hell point am I trying to make, directly? I'm down for a new SK8.

[mikelevins]

I know I was being oblique, but SK8 isn't a requirement, it is the project.

Hey, you're referencing my requirements. I get to say what's in and what's out.

If you want to recapitulate SK8, I'm all for it. Allow me to suggest the following as a place to get started:

https://dspace.mit.edu/bitstream/handle/1721.1/6089/AIM-306.pdf?%2520sequence%3D2

I'm probably being too oblique here, too, so I'll just explain: SK8 was a Hypercard-on-steroids built on top of a frame language (https://en.wikipedia.org/wiki/Frame_(artificial_intelligence)) used to represent all of its components in a persistent knowledge graph.

If you want to rebuild that, as I said, I'm all for it. It's a larger project than anything we've discussed here so far, and I imagine the folks who actually want to get a 3D authoring environment done in a reasonable amount of time would not appreciate a side expedition into the grand history of symbolic knowledge representation.

[JMC-design]

lots of dead KR and expert systems to be resurrected in the AI repository.
I'm not particularly happy with the direction the semantic web has taken, but have been too busy getting pixels to the screen to really think about it.
I do think symbols are under utilized. I see all these lisp markups for documentation and such with funny syntax around words to denote things that are represented by symbols and always wonder why not just use symbols?
I'm sure i'll find out how bad an idea this will be when my text analyzer converts every word string into a symbol. sigh, reminds me I need to publish my dictionary stuff sometime.

[ghost]

Hey, you're referencing my requirements.

Both needing to remember we're on Kaveh's turf--his repo his rules.

[ghost]

No, I'm still not seeing it. CL != Dylan, darn

For the record, this running joke was totally about me and my stubborn inability to see the forest through the trees (graphs?) about the potential of kons-9 and its contributors. I'm sure mikelevins knows the similarities/differences between Dylan vs. Common Lisp and why he is here! I wasn't being that oblique, I would say jokingly abtuse.

Somewhere in there is also, related to this thread. the thought that looking back to what we liked in the past in GUI design--including SK8 and Ray Dream Studio and [insert your favorite here]. I liked RDS so much I probably would just run it in Wine if it weren't so buggy--it's main weakness (and now of course the antiquated rendering). I still have the user manual for RDS on my bookshelf for inspiration. The undersea tutorial is really rewarding--something to keep in mind for attracting users to kons-9 would be similarly engaging tutorials.

[ghost]

[JMC-design] but have been too busy getting pixels to the screen to really think about it

I too wish I could check the "get pixels to screen" box checked off. If I could go back 25 years, I probably would just tell myself to write the whole pipeline in Common Lisp in the style of Ray Dream Studio and Open Inventor, add F-rep techniques 20 years later and be done--sipping mint juleps on the porch with my wife instead of doing this.

[mikelevins] If you want to recapitulate SK8, I'm all for it.

@mikelevins OK, if you want to be the boss, please create a SK8-Revival repo and I'll start contributing. I can create one, but keep in mind I've been described as "not management material" by more than one Fortune 500 company. I've gathered a couple of relevant repos.

Allow me to suggest the following as a place to get started:
https://dspace.mit.edu/bitstream/handle/1721.1/6089/AIM-306.pdf?%2520sequence%3D2

I would really like to take 5 years off and read all the AIM memos--I've made it through the "Lambda Papers" and a number of others. I haven't read 306 but I have read one of his better student's books, Winston's AI which covers frames in Ch. 9-10. Using frames as a store is an intriguing idea I haven't explored, but would be interested in. I did see your comments on the "Prefix Dylan Newton" store and even Dr. Strandh's LispOS seems to hint at this technique. Maybe we can do it as an add-on to kons-9 to make something like your win-the-lottery scenario.

[mikelevins]

OK, if you want to be the boss, please create a SK8-Revival repo and I'll start contributing.

Not right now, I think. It would be one too many projects. I already have another Lisp project besides kons-9 that needs my attention, plus some work on a product of mine that is overdue for a new version, plus my day job. It would be imprudent to add another one right now.

Ironically, I actually started just such a project twenty years ago, and even got three of the original SK8 team to agree to contribute. We called it "Skate".

Unfortunately, that was just before I came down with a serious chronic illness that took me out of the workforce entirely for several years.

[ghost]

One of the many things Dr. Winston showed us, from https://people.csail.mit.edu/phw/

Who.i.am.not

I do not use social media. For a time, there was a fraudulent Facebook page with my picture and other material that attempted to deceive. Now I have a defensive Facebook page saying that I do not use Facebook or other social media.
Why do imposters do what they do? Some may be psychotic. Many are criminals attempting to extract personal information from “friends” via a form of so-called spear phishing.

We should learn from smart people that get things done.

[mikelevins]

Hmm...you haven't seen a Facebook page pretending to be me, have you? I don't use Facebook, either.

I did have a Facebook page briefly, because it was required for some work I did. I followed what instructions I could find to delete it, though, so if there is one that purports to be me, it's a faker.

(I'm not sure why anyone would pretend to be me, but I know of at least one website that uses copies of some of my homepage content for no reason that I understand.)

[awolven]

@JMC-design glyph:raster is reporting sizes larger than the size of the bounding box. I'm investigating, but maybe you could shed some light on it?

…

On Sun, Sep 11, 2022 at 6:49 AM mikel evins ***@***.***> wrote: Hmm...you haven't seen a Facebook page pretending to be me, have you? I don't use Facebook, either. I did have a Facebook page briefly, because it was required for some work I did. I followed what instructions I could find tio delete it, though, so if there is one that purports to be me, it's a faker. (I'm not sure why anyone would pretend to be me, but I know of at least one website that uses copies of some of my homepage content for no reason that I understand.) — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMMWGIGCAVNW73726C3V5XBK3ANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JMC-design]

Do you have a specific example? Or it's like that for every font, every glyph. I'll look into it tomorrow, I know there's probably some problems with glyphs that extend below the baseline. Even ones that extend slightly like 0's are going to get 1 pixel below baseline (floor) even if it's too small that the render doesn't go past the baseline.

[awolven]

It was actually a width I had a problem with, not a height. But I just used the greater of the two numbers. It was for the width of a "cell" for a glyph on a texture for the whole font, so extra blank space doesn't do anything but use more memory. So I have it working. A text engine commit is on its way, where everything supporting the text engine is lisp, except for opengl itself. How are things going with glop?

…

On Mon, Sep 12, 2022 at 10:10 PM Johannes Martinez Calzada < ***@***.***> wrote: Do you have a specific example? Or it's like that for every font, every glyph. I'll look into it tomorrow, I know there's probably some problems with glyphs that extend below the baseline. Even ones that extend slightly like 0's are going to get 1 pixel below baseline (floor) even if it's too small that the render doesn't go past the baseline. — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMNGYWFQTMXE76UFS2TV57WB5ANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JMC-design]

oh wait, you said width. I didn't change the generic function for glyph width which doesn't use ceiling/round. I'll have to think about that since it would mess up drawing from paths where you want the precision.

[JMC-design]

i'm really tired.

[kaveh808]

I really appreciate you guys working on this project. I hope it can be of benefit to the larger CL community. :)

[aykaramba]

In terms of general audience benefits, this project forum is the best cs 1xx course ever. More pls. Very fun to follow.

[kaveh808]

@JMC-design The text is fuzzy when rendered, even if I make sure it is at integer pixel locations (it's fuzzier if not). Can you think of a reason why that might be? My ad-hoc testing seems to indicate each glyph is approx 7.3 pixels wide, if that could have something to do with it.

[awolven]

You can test whether it is the rasterization process or the texturing process by rendering the whole font atlas with glDrawPixels. If the atlas bitmap is blurry then it's the rasterization, if not then it's the texturization. The texture coordinates are floats and may have precision problems if the boundaries of the glyphs are at ratios which cannot be represented exactly by a floating point number. Whether or not this is the case, I think we should abandon that code and use the 3b-bmfont atlas.

…

On Tue, Sep 27, 2022 at 6:48 PM Kaveh Kardan ***@***.***> wrote: @JMC-design <https://github.com/JMC-design> The text is fuzzy when rendered, even if I make sure it is at integer pixel locations (it's fuzzier if not). Can you think of a reason why that might be? My ad-hoc testing seems to indicate each glyph is approx 7.3 pixels wide, if that could have something to do with it. [image: Screen Shot 2022-09-27 at 1 47 30 PM] <https://user-images.githubusercontent.com/103860793/192656927-559f66cd-20c3-49b9-866e-5c932933a7a4.png> — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMLBR67MFMVPCRNIJ2TWAOBVTANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kaveh808]

I agree with moving to 3b-bmfont. Is your plan still to:

1. port the existing OpenGL code to 3.3 so we are more up to date and at parity between Linux/Win and MacOS
2. move to 3b-bmfont (which requires 3.3)
3. work on moving over to Vulkan/Metal

[awolven]

I have been working on the graphics language independent portion of a graphics engine the past week. Basically, I'm working on all the functions necessary to build and maintain draw lists for various primitives. After I get the draw-lists system working, I need to test it. This requires pipeline classes and their respective shader programs. As it is, I have lots of pipeline and shader code written for Vulkan, only a little smidgen of pipeline and shader code written for OpenGL 3.3 (from the text engine) and none for Metal. So the short of it is that this graphics engine will support Vulkan first. In my last few years of graphics development, I have been moving away from the "code-compile-start-test-crash-recode-recompile-restart-retest-crash" cycle of development which C++ developers consider to be the norm, hence the popularity of immediate mode guis, and I am moving to a more stable-running-lisp-image based development. To do this it is important to not crash the render loop, which forces a warm or cold restart of the program to debug. So the next thing I need to do after getting draw-lists and pipelines implemented is to implement a rendering architecture where draw list changes can be injected into the render loop and are perfectly safe, while the application logic runs in another thread, and can fall into the slime debugger without stopping the program. I have an implementation of this sort of thing for my Hemlock port. Choice of graphics languages affects the architecture since OpenGL has double buffering and Vulkan can have two, three or more framebuffers going at once, hence requiring the work partitioning to be different. My initial version will be for the least common denominator: double buffering, but in the future I want to partition the work of maintaining the scene to allow for the performance enhancements of Vulkan/Metal, so I am putting a little bit of thought into that as I do this. It's likely to be several weeks before I have an initial version of the engine running, and then it's going to take some time and work to port kons-9 to it.

…

-AKW

On Wed, Sep 28, 2022 at 3:33 PM Kaveh Kardan ***@***.***> wrote: I agree with moving to 3b-bmfont. Is your plan still to: 1. port the existing OpenGL code to 3.3 so we are more up to date and at parity between Linux/Win and MacOS 2. move to 3b-bmfont (which requires 3.3) 3. work on moving over to Vulkan/Metal — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMP3IMOPB2HSE6MTZHLWASTRPANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lukego]

I have lots of pipeline and shader code written for Vulkan

Just out of curiosity, may I ask what this code generally look like?

I'm wondering if it's e.g. written in GLSL, or S-exp GLSL, or S-exp-compiled-to-SPIRV, or...?

[awolven]

Basically it's lisp code to drive the vulkan api and set up pipeline objects, build and manage draw lists, and execute pipelines. The shaders are written in GLSL 450.

…

On Sun, Oct 9, 2022 at 3:27 AM Luke Gorrie ***@***.***> wrote: I have lots of pipeline and shader code written for Vulkan Just out of curiosity, may I ask what this code generally look like? I'm wondering if it's e.g. written in GLSL, or S-exp GLSL, or S-exp-compiled-to-SPIRV, or...? — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMML6H6TEQOZVKE2FNWTWCJ6YDANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[awolven]

put this in your .sbclrc (setf *read-default-float-format* 'double-float)

…

On Fri, Sep 2, 2022 at 3:19 PM Kaveh Kardan ***@***.***> wrote: Sounds good. How can I change my default to double-float? — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMPSDGALWK2O65AXDFDV4JONFANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[awolven]

font:code-points calls font:glyphs which calls font:code-points

…

On Fri, Sep 9, 2022 at 3:46 PM Andrew Wolven ***@***.***> wrote: im just looking at the code -- why it would give that message. On Fri, Sep 9, 2022 at 3:42 PM Johannes Martinez Calzada < ***@***.***> wrote: > if it has multiple cmap tables for different languages or multiple fonts > within one file I don't think 3b has pushed that yet. But it's recent stuff > he's working on. > > — > Reply to this email directly, view it on GitHub > <#29 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABGMML4U5R4BKZDDPVVFETV5OONFANCNFSM57FK74UA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[awolven]

My version of hemlock could probably be ported to Alloy fairly easily. The only thing that I would worry about is that the current version uses a pseudo-windowing system (internally called viewports) which allows a "window" to be dragged out of the main window onto the desktop. It also has docking, which is cool too. (That is, if anyone is interested in using hemlock in the future.) For those who might want to know why to use hemlock, hemlock has a rich set of text editing features compatible with gnu emacs, and could not only be used with file editing, but text widgets as well. Currently it uses emacs keys, but I'm working on a Windows key mode as well. It also has a Lisp Listener and a CMD mode on windows, and the unix shell mode could be fixed up to work as well. There are emacs style Ctrl-s, and Ctrl-r search features, a directory editor, and other emacs-like features. One of the things I like most about it is the command and key binding system which can be used as an intelligent way to add functionality to the app, but is not so imposing as to prevent direct callbacks from working to zoom or rotate the graphics view. I have put an MIT license on it, so there should be no issues there.

…

On Mon, Aug 22, 2022 at 9:45 AM Johannes Martinez Calzada < ***@***.***> wrote: So unless you want to use some foreign toolkit it seems like pure 3d is the only way you can get cross platform. None of the lisp bindings to windows api's seem to be in a working state. Wasted most of yesterday finding that out. Theoretically you could probably figure out stuff from Cormon cl which still works on windows, but ... So if you want it now, pure 3d. So if you can understand the api's (i think I'm too simple for that), maybe Alloy should be considered as it already has widgets and text rendering? — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMJUAWQLL4A35OVLMOTV2OHAFANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[awolven]

the rendering of the glyph is already completely separated from the rasterization

…

On Thu, Sep 1, 2022 at 8:34 PM Kaveh Kardan ***@***.***> wrote: I have text on the screen now. There were conflicts in the OpenGL state. Will continue investigating. — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMLHABUUN62N7MEYRITV4FKSRANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[awolven]

I develop in windows as my main platform. I also port to MacOS and and Linux. I have no problems developing in Windows, including using Git, or dealing with Linefeeds in text files, or with crashing on resizing. I actually think Windows is a great OS to develop for, sans Genera. It's certainly not got any problems worse than MacOS's need to update the window from the initial thread.

…

On Tue, Aug 23, 2022 at 10:25 PM Johannes Martinez Calzada < ***@***.***> wrote: Is anybody here experienced with windows dev? God I hate that POS. It seems ~ doesn't work in strings/format because of stupid windows line endings. is there a way to not get those added? Or windows needs them? git at the command line doesn't seem to work properly, clones some repositories, and it creates folders neither emacs or explorer can view. finally used the stupid git gui and then it didn't download my newest commits for who knows what reasons. Seems like windows might require you to handle certain events, crashed on resizing, something which is kind of optional on linux because of how window managers work. Does anybody know if there are required events to handle on Windows and MacOS? — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMIONGS5VSRCTI7C56LV2WI3JANCNFSM57FK74UA> . You are receiving this because you commented.Message ID: ***@***.***>

[awolven]

I'll look into these bugs.

…

On Fri, Sep 2, 2022 at 8:01 AM Sorin Cătălin Păștiță < ***@***.***> wrote: However, when I make the window fullscreen the text disappears. When I make it small again the text reappears. And also, I have a n00b question. When I run (render-text) the *draw-list* variable does not seem to update and I am stuck with the same initial text on the screen. Do I have to update somehow the scene to display the new text? Or (render-text) is not the correct function to call when I want to add text to the screen? — Reply to this email directly, view it on GitHub <#29 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGMMPK6FJ7QHWV2QFHIG3V4H3DHANCNFSM57FK74UA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[awolven]

oh, yeah, and i forgot, i need the glyph metrics.

…

On Sat, Sep 3, 2022 at 6:54 PM Andrew Wolven ***@***.***> wrote: If Johannes has a text rasterizer then it could be used to replace freetype. All my code needs is at minimum a grayscale bitmap of the font at a particular size, preferably, the entire visible character set in one bitmap. On Fri, Sep 2, 2022 at 6:17 PM Kaveh Kardan ***@***.***> wrote: > I agree. We need test branches for big changes. > > Also, I proposed a workflow where people would send me pull requests: #37 > <#37> > > I want to make life easy for our potential users. Limiting dependencies > is a part of that. > > — > Reply to this email directly, view it on GitHub > <#29 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABGMMJ3UFKRPSMG4IICOSDV4KDIBANCNFSM57FK74UA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >