Sinae
Topic Author
Posts: 11
Joined: 25 Dec 2013, 09:11

New to noesis

05 May 2017, 05:41

It's not clear exactly how to load and debug neosis application while using normal wpf ressources or app.xaml

i recommend that you really work on this because it's a pain at the moment..

i don't know how to test the samples you have on github inside noesis engine..
or how it work with unity and visual studio 2017..

would'nt it be better just to load normal wpf apps with app.xaml on neosis without any changes whatsoever in the code? you could use fody AOP instead of preprocessor directives

i've seen the tutorials but it's still unclear to me..

also I wonder about speed and most importantly about text rendering quality.. is it on par or better than other alternatives?
 
User avatar
ai_enabled
Posts: 231
Joined: 18 Jul 2013, 05:28
Contact:

Re: New to noesis

05 May 2017, 07:41

I agree - the workflow setup is quite complicated. There is no "WPF-to-NoesisGUI" converter. But NoesisGUI was initially designed as UI middleware for the game engines so it's understandable.

You can find your own perfect workflow. For example, in our new game we use exactly the same WPF project (including C# code) with NoesisGUI - the game itself has Roslyn compiler and preprocess WPF C# code to make it 100% compatible with NoesisGUI (it also wires actual game API instead of "fake" API). XAML files don't need any preprocessing and used as-is. Our game engine also allow hot-swapping of C# and XAML code and any assets - this dramatically simplifies the development workflow and modding.

In my opinion, MonoGame integration https://github.com/aienabled/NoesisGUI.MonoGameWrapper is much easier to understand and setup the workflow (if you don't need right now the crossplatform support and don't need all the Unity engine features - especially if you prefer the code-first approach instead of bothering with clumsy Unity Editor). Thought there is no separate WPF project in this repository it's quite easy to setup one. If you're looking for the already setup WPF project, I've done something close to this in Ammy integration sample https://github.com/aienabled/NoesisGUI.AmmyIntegration (based on SharpDX, but I've not updated it for a few months so it will require some API fixes to properly work with latest versions of NoesisGUI and Ammy) - it contains a separate WPF project from which the Ammy files are automatically used by the application - SharpDX app automatically convert Ammy to XAML; the app is listening to the file system changes to reload Ammy files. But SharpDX app is using separate C# classes for each Ammy/XAML file, it doesn't reuse the same C# code files from WPF project.

The reason why you can't simply take a WPF project and run it in "Noesis engine" is that NoesisGUI uses different namespaces (everything is in Noesis, not in System.Windows.Controls, System.Windows.Media, etc) and in some cases it has a little bit different API - the most bothering one is that NoesisGUI C# SDK uses in its API float instead of double, so sometimes you simply cannot compile WPF code for NoesisGUI API because of this and few other issues. We're using a fork of their C# SDK (and merging it with the latest versions) to workaround all the WPF difference issues (there are really not much, less than 1000 LOC) until they provide a proper fix. But good news is that almost everything different from WPF is already reported to their bugtracker and they're working on it.
Also NoesisGUI doesn't have a concept of WPF Application and doesn't understand App.xaml file. But it's easy to use the same XAML files and it's possible (with some Roslyn preprocessing and C# SDK fork) to reuse C# code. If you're curious about the Roslyn preprocessing code see this gist https://gist.github.com/aienabled/d20c5 ... be8b76bd09


Ideally, I would like to have NoesisGUI C# SDK to have exactly the same namespaces as WPF and exactly the same API - so we will not need to use Roslyn for preprocessing of C# code and no need to fork C# SDK API. I'm completely sure it's possible (the changes are related to how they generate SWIG wrappers over C++) so perhaps some day we will receive a separate NoesisGUI C# SDK package which is done this way or the same C# SDK package but with different CONDITIONAL_COMPILATION_SYMBOL (propose one - WPF_API_COMPATIBILITY). I would like to hear the NoesisGUI team comment on this.


Regarding the text rendering quality - in NoesisGUI 2.0 they've redone it and dropped colored subpixel rendering for many reasons (but implemented perfect grayscale subpixel rendering when I've complained about it - they're really listening to the user feedback!). Microsoft UWP also dropped colored subpixel rendering (one of the reasons - it's not useful when you rotate your device to landscape mode as the RGB rows layout change to RRR, GGG, BBB rows) and use grayscale subpixel rendering - but NoesisGUI 2.0 render text with much better quality than UWP, in my opinion. And with colored subpixel rendering at 1.2 it was just a little bit better on very small fonts.

Regarding the performance - NoesisGUI was designed to be fast and reliable, to provide great user experience even on low-powered mobile devices. It's much faster than WPF/UWP in terms of controls loading speed and rendering speed (and memory utilization is also comparable to WPF/UWP). Previously (with our Unity-based game) we've used a workflow where we had a separate WPF application project and reused XAML files (but no C#) from it in the Unity-based game. There are more than hundred of user controls and thousands of XAML resources (such as styles, templates and brushes). WPF project has a complete "demo" logic so we could test whole UI separately from the game (it was easy to prototype the UI and ensure everything works as expected in WPF). And close to the game release, this WPF project literally crawled - more than 5 seconds to launch, framerate dropping dramatically sometimes (and usually not stable 60 FPS). There is only UI and very light logic. While in the game the controls loaded just in a second and the game maintained 500 FPS easily on mid-tier GPU while rendering exactly the same UI as WPF (but with the 3D game behind the UI! So if we disable the game rendering it will be much more). I didn't measured exact numbers but NoesisGUI is obviously faster. I need to mention that this game still uses NoesisGUI 1.2. In 2.0 they've improved performance even more and get rid of XAML precompiler (so NoesisGUI load XAML files directly - and do this much quicker so no preprocessing is required).

Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com
 
User avatar
jsantos
Site Admin
Posts: 3906
Joined: 20 Jan 2012, 17:18
Contact:

Re: New to noesis

08 May 2017, 06:47

Hi and welcome to our forum!
It's not clear exactly how to load and debug neosis application while using normal wpf ressources or app.xaml

i recommend that you really work on this because it's a pain at the moment..

i don't know how to test the samples you have on github inside noesis engine..
or how it work with unity and visual studio 2017..

would'nt it be better just to load normal wpf apps with app.xaml on neosis without any changes whatsoever in the code? you could use fody AOP instead of preprocessor directives

i've seen the tutorials but it's still unclear to me..
I am really sorry about all the confusion with the documentation. We are working really hard to update all the documentation to 2.0 and also preparing more samples. Anyway, as you are mentioning Unity3D I assume you already installed the unity package. Inside it you will find several complete samples. You can also find more samples in our Download section. The samples in Github also include the Visual Studio project to allow modifications using Blend. For now, the C++ SDK and C# SDK only include basic integration samples and tons of XAMLs ready to be played in the XamlPlayer. We have plans to port all the samples in Download to all our platforms.

There is an important difference between WPF that you must understand though. NoesisGUI is not an application framework (we are not a new Xamarin). We are a lightweight UI middleware providing just the framework classes for displaying and interacting with the UI in your game or application. It is client responsibility to host the application, manage the windows, initialize the renderer, etc. We think this is an important advantage among bloated monolithic approach like Qt. We also avoid including virtual machines that would increase the complexity of the library.
also I wonder about speed and most importantly about text rendering quality.. is it on par or better than other alternatives?
The rendering algorithm of NoesisGUI has been meticulously optimized to run fast in all our platforms, including low-end mobile devices and consoles. We struggle to send the minimum number of batches to the GPU and to steal the minimum numbers of milliseconds from the client frame. Our team is highly experienced in videogames and realtime performance techniques.

I think we already had a good quality text rendering algorithm in 1.X. We dedicated a lot of man hours to improve it in 2.X. The performance in 2.X is vastly superior and the quality under animations is better. We dropped the support for LCD (rgba channels) antialiasing because it didn't escalate properly to all the scenarios. We are really happy with the results. We dedicated great efforts to investigate different techniques (like distance field rendering) and we think that we have for now one of the more complete approaches. I think our algorithm is superior to WPF. In WPF if you scroll the text of a listbox for example, it gets blurry momentarily and then stabilize. I think that's an horrible effect that you won't find in Noesis.

Anyway, you can test this yourself because the free version of NoesisGUI (for indies) can also be used for evaluation.

I hope this helped!
 
User avatar
jsantos
Site Admin
Posts: 3906
Joined: 20 Jan 2012, 17:18
Contact:

Re: New to noesis

08 May 2017, 06:59

THANKS for the time writing your testimony here to help new users. You guys are helping us a lot to shape NoesisGUI! We are really excited about your new CryoFall game :)
Ideally, I would like to have NoesisGUI C# SDK to have exactly the same namespaces as WPF and exactly the same API - so we will not need to use Roslyn for preprocessing of C# code and no need to fork C# SDK API. I'm completely sure it's possible (the changes are related to how they generate SWIG wrappers over C++) so perhaps some day we will receive a separate NoesisGUI C# SDK package which is done this way or the same C# SDK package but with different CONDITIONAL_COMPILATION_SYMBOL (propose one - WPF_API_COMPATIBILITY). I would like to hear the NoesisGUI team comment on this.
Yes, we have this in the roadmap. Although I am not sure if we are going to be able to 100% solve it, because I assume we cannot use exactly the same namespaces as WPF or UWP. So our idea was replicating all the WPF namespaces but under a global root one named "Noesis". What do you think about it?
 
User avatar
ai_enabled
Posts: 231
Joined: 18 Jul 2013, 05:28
Contact:

Re: New to noesis

10 May 2017, 15:42

I'm glad to help! I think NoesisGUI deserves much more attention from developers than it currently has.
Yes, we have this in the roadmap. Although I am not sure if we are going to be able to 100% solve it, because I assume we cannot use exactly the same namespaces as WPF or UWP. So our idea was replicating all the WPF namespaces but under a global root one named "Noesis". What do you think about it?
If there are no exactly the same namespaces, it will not be possible to simply reuse C# code from WPF/UWP projects, and that's the whole point.
I see no reason why you could not use exactly the same namespaces as WPF or UWP (just don't make it by-default as some users might not need or don't want such API compatibility). And I'm quite sure that's not a much work for you to done this (there are still a few API differences but they're all manageable).
It will allow to create an application framework based on Mono (or CoreCLR) and NoesisGUI (+OpenGL C# wrapper) which will allow developers to use exactly the same XAML and (in most cases) exactly the same C# code as for WPF and UWP application (so it will be possible to link the same files from WPF/UWP projects and (re)use them completely - not just XAML files as it's (usually) done currently). This application framework could be done as an opensource project. It will be superior to Xamarin in many aspects. It will make porting of already existing WPF/UWP applications an approachable task. And it will make NoesisGUI much more favorable to developers with XAML/WPF/UWP experience looking for porting or developing apps.
Also we have one application in mind - our game launcher (WPF). It should not be hard to completely port it to NoesisGUI and make crossplatform. So we're very interested in this NoesisGUI application framework based on 100% compatible XAML/C# code.

Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com
 
User avatar
jsantos
Site Admin
Posts: 3906
Joined: 20 Jan 2012, 17:18
Contact:

Re: New to noesis

11 May 2017, 23:07

Also we have one application in mind - our game launcher (WPF). It should not be hard to completely port it to NoesisGUI and make crossplatform. So we're very interested in this NoesisGUI application framework based on 100% compatible XAML/C# code.
We have support for App.xaml (and the corresponding platform dependent Application and Window classes) already implemented but it is not part of the redistributed library of Noesis (was part of 1.X but we eliminated it from 2.0). We are planning to open source this. The implementation is C++ but I think this is good because that way, we can create a very simple C# layer on top of it. So, this framework would basically have an entry point accepting an application XAML and it will setup a window and a root in a platform independent way. A different approach would be doing the window loop abstraction in C#...

Could you please create a ticket for the namespace WPF compatibility issue? thanks!
 
User avatar
ai_enabled
Posts: 231
Joined: 18 Jul 2013, 05:28
Contact:

Re: New to noesis

12 May 2017, 07:32

@jsantos,
I'm glad to hear you've already added support for App.xaml. It will simplify things a lot!
I've created two tickets
http://bugs.noesisengine.com/view.php?id=1078 - C# SDK with namespaces compatible with WPF/UWP
http://bugs.noesisengine.com/view.php?id=1079 - Noesis Application Framework (my proposal of how I see it)
As we talked before, ideally these tickets (feature requests) should be public so everyone (even without the account) could see them and (with account) comment on them.

Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com
 
Sinae
Topic Author
Posts: 11
Joined: 25 Dec 2013, 09:11

Re: New to noesis

13 May 2017, 20:40

thx for your quick reply and help, i'm looking into the sample you gave me.. i'll let you know

but it's a pain to start just saying it should be a generic APP model with and same app configuration, it should be the same for all platforms and language , with some specific configurations to each platform(if needed)

in my opinion it should be lot simpler than now or at least we should have a clear full example on how a C# wpf templates and xaml can work directly into noesis and how one can map customcontrol and user control, behaviors, converters made for wpf into noesis..

-
also like i said, you should really look into an AOP option like Fody and create a plugin that would just fix namespaces or anything at compile time so you could easily just take a wpf customcontrol made by a user as a noesis custom control without any change in code or even preprocessor directive
-

you have everything to create a new fast UI SDK alternative for wpf coders who might not necessarely want to stick to Microsoft ui sdks and go xamarin/wpf/uwp mess..
 
Sinae
Topic Author
Posts: 11
Joined: 25 Dec 2013, 09:11

Re: New to noesis

13 May 2017, 20:46

if you are looking to hire a wpf coder to handle this let me know, i'll analyse your framework and create a mostly transparent bridge ..

i would have to work remotly from my home office of course =)

a custom control / user control wpf to noesis converter could also be nice as another option.

do you support everything of wpf xaml into noesis xaml?

I understand you are just a middle layer working over 3d engines but i wonder how different both framework are at their core.

If you can work in blend it means you pretty much support all of wpf xaml i'm i right?
 
Sinae
Topic Author
Posts: 11
Joined: 25 Dec 2013, 09:11

Re: New to noesis

13 May 2017, 21:02

as for font rendering quality.. it need to be the best rendering possible for both small & bigger fonts.. i also understand that when animated some renderer are better than others.
i would use the best renderer specific to the dpi, the font size and ongoing font animation.. best would be perfect transparent application of the right font renderer
with wpf you have to specify with some hacks and you need to use different font rendering config for smaller font, bigger font, animated fonts for acceptable quality.

also do you offer something similar to snaptopixels & layout rounding of wpf (if needed) and is it applied automatically where needed or we need to set it ourselves like in wpf?

--
you should consider bringing back the app.xaml , window.xaml into noesis for easy integration etc..

and yes, you should open source all custom controls and skins of noesis in my opinion

Who is online

Users browsing this forum: Semrush [Bot] and 37 guests