Turbo Badger implementation

Share your helpful Urho3D code snippets, samples and tutorials here.

Re: Turbo Badger implementation

PostPosted by Dave82 » 22 Sep 2016, 14:46

I think this is great and a really good implementation however i would rather see a version that is more urho compatible.Instead of implementing it as an external subsystem why not wrap it like the other libraries ? So the default Urho3D::UI should use TurboBadger ? Im not familiar with TurboBadger but i think it would be even possible to add some CMake configuration to build Urho3d with the default UI or with TurboBadger.
So this way :
1 will work out of box (at some point)
2 the Urho3D Editor would work with TurboBadger widgets without any major code modifications
3 Without code modifications it is automatically exposed to Scripts too.
Infested : An old school puzzle solving survival horror game :
topic1430.html

Infested Facebook page
https://www.facebook.com/infestedgame
User avatar
Dave82
Active user
Active user
 
Posts: 136
Joined: 11 May 2015, 18:08

Re: Turbo Badger implementation

PostPosted by cadaver » 22 Sep 2016, 15:10

I don't think you can reasonably expect to code to the same API if you switch the underlying UI library, except by simplifying a lot, and that wouldn't benefit the good parts of either UI library.

This has been discussed before and I do think the ideal would be for the UI library to be wrapped so that you use e.g. Urho events and Urho resources instead of the UI library's native ones. However in practice it's a very difficult ideal, since either you have a lot of wrapping/adaptation work to do, or lose features. Compare to Bullet: Urho's physics components don't expose Bullet nearly completely so for a physics power user using Bullet directly could actually make more sense.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Turbo Badger implementation

PostPosted by Dave82 » 22 Sep 2016, 20:03

I don't think you can reasonably expect to code to the same API if you switch the underlying UI library, except by simplifying a lot, and that wouldn't benefit the good parts of either UI library.


Yes , these are the modifications i mention , but yes this would require a lot lot work ,when probably after TurboBadger integration the default UI would be obsolete anyway.So maybe it would be better just switching to TurboBadger as the UI (by using the existing UI unterface and expanding it).Maybe it worth a new branch for testing this.


This has been discussed before and I do think the ideal would be for the UI library to be wrapped so that you use e.g. Urho events and Urho resources instead of the UI library's native ones. However in practice it's a very difficult ideal, since either you have a lot of wrapping/adaptation work to do, or lose features. Compare to Bullet: Urho's physics components don't expose Bullet nearly completely so for a physics power user using Bullet directly could actually make more sense.


Well i would rather lose features than using api's directly.Thats the main reason i like Urho3d.It's clear and easily understandable interface.Once you learned the coding workflow you don't need extra tutorials to get into other features.By using apis directly you always have to learn the new library first...Which isn't really attractive for new users

here's a screen shot of my modified gui skin.I added some shadows , highlights to buttons and switched to monochrome style.I think it is more pleasant for the eyes than the deafult blue style.
Image
Infested : An old school puzzle solving survival horror game :
topic1430.html

Infested Facebook page
https://www.facebook.com/infestedgame
User avatar
Dave82
Active user
Active user
 
Posts: 136
Joined: 11 May 2015, 18:08

Previous

Return to Code Exchange

Who is online

Users browsing this forum: No registered users and 0 guests

cron