The Mana World Forums

I honestly think the server should not use Qt...

Kage wrote:I honestly think the server should not use Qt...

Not even a server version that doesn't have the gui elements?

Hi,

I personally agree with Kage upon that, even if it's an obscure and technical point of view.

In fact, I wouldn't oppose to implement it in QT, but I'd prefer to keep what's working using Enet for now.

Best regards.

Bertram wrote:Hi,

I personally agree with Kage upon that, even if it's an obscure and technical point of view.

In fact, I wouldn't oppose to implement it in QT, but I'd prefer to keep what's working using Enet for now.

Best regards.

I don't think we should use enet either. When the client starts using QtNetworking, we will most likely be forced to go to TCP.

What do we need QtNetworking for? We already built a networking framework around enet which is as comfortable and extensible as it can get. I doubt that we would really benefit from writing a new one around Qt.


By the way: I think forums.themanaworld.org is the wrong place to talk about technical development. We should set up a forum on manasource.org for such discussions.

Crush wrote:What do we need QtNetworking for? We already built a networking framework around enet which is as comfortable and extensible as it can get. I doubt that we would really benefit from writing a new one around Qt.


By the way: I think forums.themanaworld.org is the wrong place to talk about technical development. We should set up a forum on manasource.org for such discussions.

but ManaSource doesn't have a forum.... also... I hate mailing lists....

Hi,

Crush wrote:By the way: I think forums.themanaworld.org is the wrong place to talk about technical development. We should set up a forum on manasource.org for such discussions.

Yes, we could set up a forum for technical discussion, but to keep the administration charge low, maybe it shouldn't be public as the one here is.

Crush wrote:What do we need QtNetworking for? We already built a networking framework around enet which is as comfortable and extensible as it can get. I doubt that we would really benefit from writing a new one around Qt.

Yes, Enet is indeed working and we do not have so much dev time to spend about rebuilding it all. And I kinda feel QT could be an help and a disease at the same time for some odd reason.

For now, it's been agreed to aim at a generic client binary and do bug fixing and low new features to get a first working ManaServ version.
The best roadmap I've seen so far for this is your TODO list.

What is less clear is the feature target of the next eAthena client, 0.0.30. I guess we could do an half-way release, mostly bug fixing the current GIT client?

Best regards.

I've kept my opinion to myself since I read the discussion on IRC a while back.

...Although Qt could reduce dependencies and save time, I think it would put the code base at the mercy of Nokia. and also would cost speed (?).

TMW, Mana, whatever, it is a game. QT has been used for the big desktop environment KDE and desktop applications. I think TMW should use minimal libraries optimized and simplified for game creation and speed. So it would be better to have lots of smaller, specialized libraries than one big fat generalized enterprise library.

I'm not a coder, so I'm speculating.

bcs86 wrote:QT has been used for the big desktop environment KDE and desktop applications.

That is very bad reasoning. Qt is also used for smaller projects. Mana is a desktop application. Several of our dependencies are used for very large projects.

bcs86 wrote:I think it would put the code base at the mercy of Nokia. and also would cost speed

Not really... because the code is GPL, if Nokia drops it, as many people that uses it... the community would surely take over development of it.

Hi Jaxad,

I'm reviving this subject because I've seen you created a branch about SFML.

Could you tell me a bit more about it?
Do you wish to replace the video opengl part with sfml?
Do you wish to replace the audio part, too?
The networking part?

What about QT?

Thanks for your answers.

Best regards.

If SFML does positional audio, I'm willing to accept it as the final audio solution.

SFML seems to handle most graphical things better than SDL, so that'd be a sensible place to start from.

On a design point of view, I thought SFML could replace the sound part, and and the opengl part while keeping an SDL layer at least for video, since some people have problems with OpenGL.

But what about the efforts put on QT in that case?

I'm looking to replace all of SDL with SFML.

As for Qt, http://gitorious.org/mana/manamobile.

I'm looking to replace all of SDL with SFML.

Hmm, isn't sfml based on OpenGL only, or I'm wrong?
What for the users having problems with OpenGL?

Are we officially tending to a non-SDL support?

Thanks for the answer.