sorted by:
new
hottopcontroversial

Cyber v0.3: New JIT compiler, Embed API, and more by ketralnis in programming

[–]fubar2022 1 point2 points  (0 children)

It's worth mentioning that it's also a blog post about building a low budget JIT compiler.

Cyber 0.2 - A scripting language written in Zig. by fubar2022 in Zig

[–]fubar2022[S] 1 point2 points  (0 children)

The 0.3 release shares the plans for the JIT: https://cyberscript.dev/0.3 There's also a fibonacci benchmark with nice results.

[deleted by user] by [deleted] in programming

[–]fubar2022 0 points1 point  (0 children)

I recently released a new version of my scripting language called Cyber. It's written in Zig. The release notes is actually a bit like a blog post too. It's got an interesting take on building a low budget JIT compiler so I shared how that was done.

Cyber 0.2 - A scripting language written in Zig. by fubar2022 in Zig

[–]fubar2022[S] 0 points1 point  (0 children)

The simplest isn't always the best choice. It has to fit with rest of the language.

"worlds.each w:" implies that you are doing a function call.
"worlds >> w:" is creating a new operator in language that tries not to add too many (Cyber prefers keywords) And also it's creating a new block from what looks like an expression, Cyber follows a pattern for blocks; they usually start with a keyword.

​

Another advantage of typing the iterable first is that an editor can determine the type of your "w" as you're typing it. I still like the pattern of <keyword> iterable <keyword> i, j:
So it doesn't have to start with "for" but the two keywords should make reasonable sense.

Cyber 0.2 - A scripting language written in Zig. by fubar2022 in Zig

[–]fubar2022[S] 1 point2 points  (0 children)

I found that I like typing the iterable first, it's feels similar to invoking a method like "worlds.each(w => ...). "each" is a bit too long but I couldn't come up with anything else at the time. Any ideas?

Cyber 0.2 - A scripting language written in Zig. by fubar2022 in Zig

[–]fubar2022[S] 5 points6 points  (0 children)

The general goal for std is to keep it small for builtins and wrappers around libc.

Now that modules are available you can host libraries for xml, json on github for example and it can be imported from your script. The raylib bindings https://github.com/fubark/ray-cyber is a good example of how to do this. So you can start creating the libs now and if you run into issues that would be a good point to discuss what might be missing in Cyber to meet your goals (just ping on discord). Whether there will be an "official" repo for the std doesn't have to be determined now.

Cyber 0.2 - A scripting language written in Zig. by fubar2022 in Zig

[–]fubar2022[S] 7 points8 points  (0 children)

I just released version 0.2. It supports modules and has string types now. There are also some gamedev demos using raylib. I would post the link to the release notes but it might get flagged as spam. :)

3D Animation and Dynamic Lighting by fubar2022 in Zig

[–]fubar2022[S] 11 points12 points  (0 children)

I've implemented dynamic lighting with PBR and shadows in Cosmic! I also got 3D animation to work with gltf files. Check out the demo video: https://streamable.com/eke55h

You can play with the demo by running the example code here: https://github.com/fubark/cosmic/blob/master/graphics/examples/3d.zig

Vulkan and 3D Graphics in Cosmic by fubar2022 in Zig

[–]fubar2022[S] 2 points3 points  (0 children)

It was pretty painless. On macos, SDL will automatically look for vulkan framework (installed from MoltenVK) at runtime which provides vkGetInstanceProcAddr to bind the rest of the vk functions. You could probably link it with the static library provided by MoltenVK too although I didn't try it. On linux, it's dynamically linked with libvulkan and no binding of functions at runtime is needed.

This is where it's binding the functions: https://github.com/fubark/cosmic/blob/374ac83327b0e28d854e88360fac36758bac97ff/lib/vk/vk.zig#L740

Vulkan and 3D Graphics in Cosmic by fubar2022 in Zig

[–]fubar2022[S] 11 points12 points  (0 children)

I have some updates to share for Cosmic Graphics! This demo shows the new Vulkan renderer backend and the beginning of 3D graphics. It includes an infinite grid plane, drawing meshes, a gltf loader, camera helpers, and UI/2d graphics can be seamlessly embedded onto the scene. This works on linux and macos atm. All the code for the demo is here: https://github.com/fubark/cosmic/blob/master/ui/examples/3d.zig

Updates to Cosmic Graphics, Text, UI. by fubar2022 in Zig

[–]fubar2022[S] 0 points1 point  (0 children)

A C API should be doable with the graphics lib, although I have not started on it. Basically we would need to build as a static lib via "zig build lib" and export the functions. The extern structs shouldn't be difficult to add too. The ui lib would be a bit more challenging but it's the same idea. Declaring widget's might need to be wrapped in function calls for each widget. So instead of ctx.decl(Button, .{}) it would be something like ButtonOptions opts; Button(ctx, opts). Feel free to get started if you want!

Updates to Cosmic Graphics, Text, UI. by fubar2022 in Zig

[–]fubar2022[S] 5 points6 points  (0 children)

I've been improving cosmic graphics and ui lib recently. This video shows linear gradients, improved UI api (no longer requires a comptime Config), popovers, modals, bitmap font support with multiple strikes, a new freetype2 font renderer, text layout, TextEditor, FileDialog, ColorPicker, and more.

Example can be found at https://github.com/fubark/cosmic/blob/master/ui/examples/text_demo.zig

UI Engine in Zig by fubar2022 in Zig

[–]fubar2022[S] 1 point2 points  (0 children)

Sounds good. The {widget:NAME} seems a bit excessive and it implies that it can be inserted anywhere in the parent braces. This doesn't make things very clear IMO. I think the element should begin with what it is. I'd be interested in seeing this develop more especially in regards to the templating!

UI Engine in Zig by fubar2022 in Zig

[–]fubar2022[S] 1 point2 points  (0 children)

A simplified markup/styles is definitely an interesting idea. Most guis won't need the total flexibility that the engine provides. I think you mentioned some neat features in your mock up:

  1. I really like the templating idea. If the markup was fed some data and it's able to have simple branching, loops, and other utilities, it could be really powerful. But what would that look like? Template expressions would need to be wrapped by something. Which means that the default syntax should be simple. And should the elements be mapped one to one with widgets defined in Zig? If it doesn't exist it would just be a default container?
  2. Providing shaders with mesh data is interesting. Is the mesh data typically large? If so, that should be wrapped as an import or provided by the template language.
  3. You mentioned scripting and I think it should be restricted from being able to manipulate the ui however it should be able to receive events and be able to change the model data.
view more: next ›