On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky (Abscissa) wrote:
> suggestion that Robert could get this going an order of magnitude faster without too terribly much trouble. Luckily, Ethan explained my stance better than I was able to.

I think you guys overestimate the importance of performance at this early stage.

The hardest problem is to create a good usability experience and also provide an easy to use API for the programmer.

On 5/26/19 9:52 PM, Manu wrote:
> 
> Unity is perhaps the worst possible comparison point. That's not an
> example of "designing computer software like a game engine", it's more
> an example of "designing a game engine like a GUI application", which
> is completely backwards. Optimising Unity games is difficult and
> tiresome, and doesn't really have much relation to high-end games.
> There's virtually no high-end games written in Unity, it's made for
> small hobby or indy stuff. They favour accessibility over efficiency
> at virtually all costs.

While I agree completely (based on direct experience), I also feel compelled to point out, just as an aside:

I've seen some games that make Unity look WAY worse than it really is. Ex: The PS4 versions of "The Golf Club 2" and "Wheel of Fortune". As much as I admit I enjoy *playing* those games, well...Unity may have its technical drawbacks, but cooome ooon!!, even at that, it's still WAY more capable than the steaming joke those games make Unity appear to be. I've seen indie games on PS3 that did much a better job with Unity.

> They do have the new HPC# ECS framework bolted on the side though,
> that's the start of something sensible in Unity.

I'm chomping at the bit for that, particularly "Project Tiny". I'm converting some old flash stuff to unity/webgl and that framework would be fantastic for it. Only problem is I'm currently relying on some things (like procedural geometry, though I suppose I could potentially change that...) that AFAICT aren't yet supported by Project Tiny. But, maybe if I'm lucky (or realllyyy slloooowwww....) it'll get there by the time I'm done with the basic flash->unity conversion and ready to re-architect it some more.

On 5/26/19 11:46 PM, Ola Fosheim Grøstad wrote:
> On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky (Abscissa) wrote:
>> suggestion that Robert could get this going an order of magnitude faster without too terribly much trouble. Luckily, Ethan explained my stance better than I was able to.
> 
> I think you guys overestimate the importance of performance at this early stage.
> 
> The hardest problem is to create a good usability experience and also provide an easy to use API for the programmer.
> 

Again, I don't think anyone actually said that it absolutely needs to be done *at this early stage*. I know I certainly didn't.

Besides, from what Robert described, it sounds like he already has it decoupled and modular enough that performance *can* likely be improved later (probably by an order of magnitude) without too much disruption to it's core design. So, on that, believe it or not, it sounds like we already agree. ;)

And I'll point out *again*, the only points I was trying to make here were to dispel the misunderstandings, misinformation, and frankly knee-jerk reactions towards game engines and, more importantly, game-engine-like approaches.

But please understand, (and I strongly suspect this also speaks to the reason for Ethan's arguably abrasive tone): It gets REALLY, *REALLY* tiring when you spend the majority of your life studying a particular discipline (videogame code) and, as far as you've EVER been able to tell, pretty much the ENTIRE so-called-professional community outside of that specific discipline has absolutely 100% verifiably WRONG ideas about your field, and then they go and defend those falsehoods and prejudices with more misinformation and dismissal.

And @Robert: FWIW, I *am* definitely curious to see where this project goes. Also: While it *looks* in the video like a simple grid being resized, you've commented that under-the-hood it's really more of a flexbox-like design. This suggests that the computations you're doing are (or will be) capable of far more flexibility than what is apparent in the video. I'm curious what sorts of CSS flex-like features are currently being accommodated for in the computations, and are projected in the (hopefully?) near future?

On Sun, May 26, 2019 at 8:50 PM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky
> (Abscissa) wrote:
> > suggestion that Robert could get this going an order of magnitude faster without too terribly much trouble. Luckily, Ethan explained my stance better than I was able to.
>
> I think you guys overestimate the importance of performance at this early stage.

Performance is a symptom of architecture, and architecture *is* the early stage.

> The hardest problem is to create a good usability experience and also provide an easy to use API for the programmer.

They're somewhat parallel problems, although the architecture will
inform the API design substantially.
If you don't understand your architecture up front, then you'll likely
just write a typical ordinary thing, and then it doesn't matter what
the API looks like; someone will always feel compelled to re-write a
mediocre library.
I think it's possible to check both boxes, but it begins with
architectural concerns. That doesn't work as an afterthought... (or
you get Unity, or [insert library that you're not satisfied with])

On Monday, 27 May 2019 at 04:46:42 UTC, Nick Sabalausky (Abscissa) wrote:
> without too much disruption to it's core design. So, on that, believe it or not, it sounds like we already agree. ;)

Alright! :-)

> And I'll point out *again*, the only points I was trying to make here were to dispel the misunderstandings, misinformation, and frankly knee-jerk reactions towards game engines and, more importantly, game-engine-like approaches.

Well, I don't think I knee-jerk. Sitting on my bookshelf: Graphic Gems I-V,  Computer Graphics by Hughes et al, Advanced Animation and Rendering Techniques by Watt&Watt,  Real-Time Rendering by Akenine-Moller et al, a bunch of MMO design books etc.

On Monday, 27 May 2019 at 05:01:36 UTC, Manu wrote:
> Performance is a symptom of architecture, and architecture *is* the early stage.

I expected that answer, but the renderer itself can just be a placeholder.

So yes, you need to think about where accelerating datastructures/processes fit in. That is clear. But you don't need to have them implemented.

On Sun, May 26, 2019 at 10:25 PM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 27 May 2019 at 05:01:36 UTC, Manu wrote:
> > Performance is a symptom of architecture, and architecture *is* the early stage.
>
> I expected that answer, but the renderer itself can just be a placeholder.

Actually, I'm not really interested in rendering much. From the original posts, the rendering time is most uninteresting cus it's the end of the pipeline, the time that I was commenting on at the start is the non-rendering time, which was substantial.

> So yes, you need to think about where accelerating datastructures/processes fit in. That is clear. But you don't need to have them implemented.

How does the API's threadsafety mechanisms work? How does it scale to my 64-core PC? How does it schedule the work? etc...

On 2019-05-27 04:46:42 +0000, Nick Sabalausky (Abscissa) said:

> Besides, from what Robert described, it sounds like he already has it decoupled and modular enough that performance *can* likely be improved later (probably by an order of magnitude) without too much disruption to it's core design. So, on that, believe it or not, it sounds like we already agree. ;)

That's the case. The 2D layer could be replaced. It's not yet perfectly isolated and minified, because we are still learning & experimenting to see how things fit together. Refactoring for isolation comes after this.

> And @Robert: FWIW, I *am* definitely curious to see where this project goes.

We too :-)

> Also: While it *looks* in the video like a simple grid being resized, you've commented that under-the-hood it's really more of a flexbox-like design.

Correct.

The grid is structured like this: root-> 1..X columns -> 1..Y cells per column and the only property given is to use the available vertical and horizontal space evenly.

> This suggests that the computations you're doing are (or will be) capable of far more flexibility than what is apparent in the video.

Yes, the idea is that you get a responsive app GUI, which resizes in a smart way which fits your app layout. So, you have control over this. Getting browsers to do what you want can be pretty tedious. We want to avoid this.

> I'm curious what sorts of CSS flex-like features are currently being accommodated for in the computations, and are projected in the (hopefully?) near future?

The stuff that one really needs, so no frills. We want to create a node structure with layout rules/hints per node and as a result you get a perfect responsive layout for your app.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote:
> How does the API's threadsafety mechanisms work? How does it scale to my 64-core PC? How does it schedule the work? etc...

Ah yes, if you don't run the GUI on a single thread then you have a lot to take into account.

On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote:
> Actually, I'm not really interested in rendering much. From the original posts, the rendering time is most uninteresting cus it's the end of the pipeline, the time that I was commenting on at the start is the non-rendering time, which was substantial.

Btw, I agree that spatial constraint solvers are tricky… it is a rather specialized field with very specialized algorithms…

…but as Robert said CSS Flex then we know that there are free implementations out there that perform very well (Chromium, Firefox, etc).

I don't know how useful Flex is for UI layout though, based on my experience with browser layout. But I guess that is something one will have to experiment with.