The initial idea for Cascade was to make a lighweight css engine to make UIs for web.
After struggling with this idea for quite some time (and even achieving an almost-working prototype), we decided that this has been a bad idea all along. It's unnecessarily complicated. Too many standards, too many things to support. The project was intended to be lightweight, but was quickly growing into a full-on browser. At this point a more logical step would be to either go web-all-the-way, or drop the idea.
We did not want to give in to the world of web. Frankly, the project started to look too big and too niche at the same time, plus it's unlikely that we would have succeeded - existing web browsers are much better web editors, they already support the layout, styles, js scripting, God, even shaders. Even if we managed to realease a very simple editing tool, it would likely be criticised for lack of features that most chromium-based projects support out-of-the-box. We can't claim something to be 'for web', and not deliver a product, compatible with at least a large portion of web standards. Which is an insurmountable task for a 2-person team.
So we decided to change the idea. Now, Cascade is a simple, general-purpose vector editor with deep focus on procedural/parametrized/automated stuff. We could not have been happier with this decision.
This is only the beginning. I'll be posting more information soon.
I will tease the next post - the 'semi-immediate mode' UI system.
Many game developers talk about how making the right tools for their artists can greatly increase the quality of the design, because people can try out ideas, very fast. They can experiment, be creative etc.
That's waht I did for our new UI system. I made a language + engine for UI layouts. Not unlike css, but much, much simpler both syntax-wise and under the hood. (I know first hand how complex the css standard is. And I try very hard to avoid such complexity.) It's a simple format, hot loadable, checks errors on the fly. And the most important thing - the authoring of the UI can be done by the UI designer.
I will provide more datails about this system in the next post.
But that's it for now. Thank you, and I'll see you soon!
After struggling with this idea for quite some time (and even achieving an almost-working prototype), we decided that this has been a bad idea all along. It's unnecessarily complicated. Too many standards, too many things to support. The project was intended to be lightweight, but was quickly growing into a full-on browser. At this point a more logical step would be to either go web-all-the-way, or drop the idea.
We did not want to give in to the world of web. Frankly, the project started to look too big and too niche at the same time, plus it's unlikely that we would have succeeded - existing web browsers are much better web editors, they already support the layout, styles, js scripting, God, even shaders. Even if we managed to realease a very simple editing tool, it would likely be criticised for lack of features that most chromium-based projects support out-of-the-box. We can't claim something to be 'for web', and not deliver a product, compatible with at least a large portion of web standards. Which is an insurmountable task for a 2-person team.
So we decided to change the idea. Now, Cascade is a simple, general-purpose vector editor with deep focus on procedural/parametrized/automated stuff. We could not have been happier with this decision.
This is only the beginning. I'll be posting more information soon.
I will tease the next post - the 'semi-immediate mode' UI system.
Many game developers talk about how making the right tools for their artists can greatly increase the quality of the design, because people can try out ideas, very fast. They can experiment, be creative etc.
That's waht I did for our new UI system. I made a language + engine for UI layouts. Not unlike css, but much, much simpler both syntax-wise and under the hood. (I know first hand how complex the css standard is. And I try very hard to avoid such complexity.) It's a simple format, hot loadable, checks errors on the fly. And the most important thing - the authoring of the UI can be done by the UI designer.
I will provide more datails about this system in the next post.
But that's it for now. Thank you, and I'll see you soon!
Hello! This is more of a "I'm not dead post". Just a couple updates.
The engine re-write is in progress. I'm sill working just on the flex-box spec implementation. This is the first time ever that i've actually hit a capacity limit of my mind. I just cant keep all the spec in the brain-RAM or whatever it is. The spec itself is not that difficult. It's short. The implementation is less than 1000 loc. But omg, the nomenculature is making things hard. It's actually turned out to be a serious problem for me. Everything has to be triple-checked all the time. (Is it auto, is it definite, is it specified/computed/used/target value? Why. Is it set by mistake etc. etc.). I have to 100% know that sonething is a bug, a correct behaviour or incorrect behaviour (I misread the spec)
It's especially hard, because by know I already wrote 2 different layout engines for Cascade, and this one is taking way, way more time than I ever imagined, which is very demotivating.
To help with all that, I took an inspiration from one of the Jeff And Casey show episodes and made a thing that explains every single decision, that the engine took, for every single value of every tag. I called the struct for that info - muratori_node. We'll see how that helps. Right now I'm in middle of restructuring the engine to improve readability and understanding. I'm renaming a lot of stuff just to be more similar to what is said in the spec.
Oh, also we now have another programmer helping us with Cascade. Pure luck. On one of my streams a guy from Yekaterinburg, Russia got so interested in a project, that decided to join full-time. He's never heard of Casey or Handmade Hero, but his approach is very similar to the Handmade philosophy. He is much more skilled than I am, he made his own 3D engine (and a giant set of general-purpose libraries) from scratch. We're so happy and lucky to have Vladimir (@frowrik) working on Cascade with us.
And yes, I'm streaming Cascade development now on Wednesdays 1.30 pm PT / 9.30 pm UTC. Come say hi if you're interested.
https://www.twitch.tv/koschei_
Ok, hopefully we'll have better updates next time.
Bye-bye!
The engine re-write is in progress. I'm sill working just on the flex-box spec implementation. This is the first time ever that i've actually hit a capacity limit of my mind. I just cant keep all the spec in the brain-RAM or whatever it is. The spec itself is not that difficult. It's short. The implementation is less than 1000 loc. But omg, the nomenculature is making things hard. It's actually turned out to be a serious problem for me. Everything has to be triple-checked all the time. (Is it auto, is it definite, is it specified/computed/used/target value? Why. Is it set by mistake etc. etc.). I have to 100% know that sonething is a bug, a correct behaviour or incorrect behaviour (I misread the spec)
It's especially hard, because by know I already wrote 2 different layout engines for Cascade, and this one is taking way, way more time than I ever imagined, which is very demotivating.
To help with all that, I took an inspiration from one of the Jeff And Casey show episodes and made a thing that explains every single decision, that the engine took, for every single value of every tag. I called the struct for that info - muratori_node. We'll see how that helps. Right now I'm in middle of restructuring the engine to improve readability and understanding. I'm renaming a lot of stuff just to be more similar to what is said in the spec.
Oh, also we now have another programmer helping us with Cascade. Pure luck. On one of my streams a guy from Yekaterinburg, Russia got so interested in a project, that decided to join full-time. He's never heard of Casey or Handmade Hero, but his approach is very similar to the Handmade philosophy. He is much more skilled than I am, he made his own 3D engine (and a giant set of general-purpose libraries) from scratch. We're so happy and lucky to have Vladimir (@frowrik) working on Cascade with us.
And yes, I'm streaming Cascade development now on Wednesdays 1.30 pm PT / 9.30 pm UTC. Come say hi if you're interested.
https://www.twitch.tv/koschei_
Ok, hopefully we'll have better updates next time.
Bye-bye!
Hi y'all. Been working on the CSS engine and a debug system for it.
Here's a little video of that + some live UI editing.
This system is not unlike Chrome Dev Tools, but I also added zoom and UI resize to check for pixel-level errors and responsive behaviours. You can browse the html tree (not DOM!) to see how the selected element is drawn, which is very useful for debugging (helps to see how child-elements affect the parent's size, how wrapping works etc.)
I can also select the tree node and trigger a break on it inside the enigne. Super useful.
It's a lot of work to implement the CSS engine. I literally have to decipher the spec paragraph-by-paragraph using an intermediate representation.
Also, at first I wanted to use my engine for all the CSS rules. But is was bad. I had to add workarounds to make CSS's way of doing things work, which contaminated my API with unnecessary things. Also the resulting CSS behaviour was not really 100% adhering to the spec, which would have caused compatibility issues in the future. Also it was harder to debug. CSS uses its own nomenclature like "line-boxes", "block context" etc. etc. And I had to reinterpret all those things in terms of my engine API, which made the implementation and debugging much, much harder.
And thus I gave up and decided to have 2 completely independent engines. That had 2 consequences. I had to finally admit that I am making a full-on web browser. And secondly - (which is a good thing) I eliminated a bunch of complexity and got rid of the Janus problem. For example, with a single engine, if I move/resize an object with mouse I had to translate its properties each frame to the language of CSS (position became top/left coordinate etc.) and vice-versa: if I open a CSS properties editor and set a "top" value to 10px - these changes would have to be applied to my engine object.
It was not good. There were these priority and synchronization issues all the time. And now I'm just editing html/css always.
So this is where I'm at. There's a lot of work, and I'm slooooowly moving forward.
Thanks and see you next time!
Here's a little video of that + some live UI editing.
This system is not unlike Chrome Dev Tools, but I also added zoom and UI resize to check for pixel-level errors and responsive behaviours. You can browse the html tree (not DOM!) to see how the selected element is drawn, which is very useful for debugging (helps to see how child-elements affect the parent's size, how wrapping works etc.)
I can also select the tree node and trigger a break on it inside the enigne. Super useful.
It's a lot of work to implement the CSS engine. I literally have to decipher the spec paragraph-by-paragraph using an intermediate representation.
Also, at first I wanted to use my engine for all the CSS rules. But is was bad. I had to add workarounds to make CSS's way of doing things work, which contaminated my API with unnecessary things. Also the resulting CSS behaviour was not really 100% adhering to the spec, which would have caused compatibility issues in the future. Also it was harder to debug. CSS uses its own nomenclature like "line-boxes", "block context" etc. etc. And I had to reinterpret all those things in terms of my engine API, which made the implementation and debugging much, much harder.
And thus I gave up and decided to have 2 completely independent engines. That had 2 consequences. I had to finally admit that I am making a full-on web browser. And secondly - (which is a good thing) I eliminated a bunch of complexity and got rid of the Janus problem. For example, with a single engine, if I move/resize an object with mouse I had to translate its properties each frame to the language of CSS (position became top/left coordinate etc.) and vice-versa: if I open a CSS properties editor and set a "top" value to 10px - these changes would have to be applied to my engine object.
It was not good. There were these priority and synchronization issues all the time. And now I'm just editing html/css always.
So this is where I'm at. There's a lot of work, and I'm slooooowly moving forward.
Thanks and see you next time!
Ok, just a quick update.
I've been working on 2 things. First, I started to nail down the html/css parsing and the engine. This will allow us to do the next demo (we're going to show working bootstrap.css + stuff like drag-dropping html code onto the canvas to create objects etc.),
And also - I want to finally make a thing that is going to allow our designer to modify/tweak the interface. And we'll use html to do that. He's used html/css for years and we're doing parsing for that anyway, so naturally the html UI specification it going to be better than a cusom text format (maybe). Of course, we'll have to augment the html spec to describe various interactive things (like, waht should happen if this button is clicked)
And second - I've took some time to work on a debug system. Before using a dynamically-generated UI, I wrote it entirely in C++. And it was somewhat debuggable (although, it was still hard to catch a weird engine behaviour sometimes. Lots of pointer hunting was involved). A dyanmic UI system would make this debugging process almost impossible, and I wanted a better system anyway.
So I started with an introspection system, which will be a part of the debug mode. So far the only 2 things it does is showing the object hierarchy and selected object's data. Which is not much, but it's already proven to be super helpful.
I have all type information available, all parameters. all enums - everything to very easily inspect data, and print it out. (Huge thanks to Casey for the struct offset trick from his introspection streams!)
And that's that for now. I'm going to improve the debug system over the next couple weeks, add a profiler, and couple other convenience things. And then - lots and lots of UI work will follow, which is going to be interesting.
Until next time! Bye-bye!
I've been working on 2 things. First, I started to nail down the html/css parsing and the engine. This will allow us to do the next demo (we're going to show working bootstrap.css + stuff like drag-dropping html code onto the canvas to create objects etc.),
And also - I want to finally make a thing that is going to allow our designer to modify/tweak the interface. And we'll use html to do that. He's used html/css for years and we're doing parsing for that anyway, so naturally the html UI specification it going to be better than a cusom text format (maybe). Of course, we'll have to augment the html spec to describe various interactive things (like, waht should happen if this button is clicked)
And second - I've took some time to work on a debug system. Before using a dynamically-generated UI, I wrote it entirely in C++. And it was somewhat debuggable (although, it was still hard to catch a weird engine behaviour sometimes. Lots of pointer hunting was involved). A dyanmic UI system would make this debugging process almost impossible, and I wanted a better system anyway.
So I started with an introspection system, which will be a part of the debug mode. So far the only 2 things it does is showing the object hierarchy and selected object's data. Which is not much, but it's already proven to be super helpful.
I have all type information available, all parameters. all enums - everything to very easily inspect data, and print it out. (Huge thanks to Casey for the struct offset trick from his introspection streams!)
And that's that for now. I'm going to improve the debug system over the next couple weeks, add a profiler, and couple other convenience things. And then - lots and lots of UI work will follow, which is going to be interesting.
Until next time! Bye-bye!
Ok this is demo 2, where I try to create a web page or something like that.
So now you can actually create something and Cascade is starting to feel like an actual editor.
We planned for this demo to be a bit more polished, but at some point it's become a waste of time, and we decided to leave it at that and move on to working on next milestones.
So here you go: a short video, demonstrating some layer work, colors, gradients, css classes and many more little things.
(There were some file open issues - for some reason my system hangs whenever I use open/save file dialog in any program...)
Se you soon! You're all welcome to comment, btw!
So now you can actually create something and Cascade is starting to feel like an actual editor.
We planned for this demo to be a bit more polished, but at some point it's become a waste of time, and we decided to leave it at that and move on to working on next milestones.
So here you go: a short video, demonstrating some layer work, colors, gradients, css classes and many more little things.
(There were some file open issues - for some reason my system hangs whenever I use open/save file dialog in any program...)
Se you soon! You're all welcome to comment, btw!