I don't know if anyone noticed, but Trolltech (www.trolltech.com) released their C++ framework verion 4 as GPL for windows (uses mingw). Why might this be important?
1. QT has established itself as a complete, cross platform framework to build off. It now comes broken into smaller libraries that allows one to build server, guis, or even more complex code.
2. QT offers a complimenertary product , QSA which is gpl (although support for QT 4 wont be until third quarter 2005). This is a Javascript inteerperator.
3. The potential is there to significantly upgrade/streamline an emu, with a well established and proven framework, simplifhying a lot of the current code. It also would support the fundemental mechansisms (communication, signal/slot, event processing) for future use.
4. Estalblishs a framework for gui tools that can utilze the same classes as the emu, and work cross platform.
5. Provides for the user who wants to build the emu the potential of a far easiter time (try building spidermonkey, which almost seems abandoned for standalong use) with mingw, etc. One can do it, but not easily out of the box).
The possibilities
Moderator: punt
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
UOX4 already existed, died, existed again (by other planners/developers) and died again.
Moreover, someone long ago registered all the UOX4-ish names.
Were there ever to be another versioning of UOX3, it would be named something quite different. Though honestly I don't see room for more/new emulators. I wonder, at times, about there being enough room for those already in existence.
Moreover, someone long ago registered all the UOX4-ish names.
Were there ever to be another versioning of UOX3, it would be named something quite different. Though honestly I don't see room for more/new emulators. I wonder, at times, about there being enough room for those already in existence.
Scott
Well, I started this as a "possibiliites" thread, that given the release of a rather complete framework (one that was robust for a emu as WELL as for tool development), and provided an integrated scripting option, the possibility for a rather clean emu seem feasible. Ir also provides the ability to easily expand outside the emu, to tools, clients, and other avenues, yet keeping the same common framework to build off.
It would seem to be able to address many of the shortcomings of other emus in terms of builds (especially crossplatform), support classes, sharing of classes between tools and emu, etc.
As for UOX (be it 3 or 4), I don't think it matters in a name (or even if UOX).
As for room for emulators, there are always room, for they are just hobbies by the developer. If one went by user use, then UOX itself would have be gone by now. So even if no users outside the develolper base, there is room as long as one is interested in working on it.
Now in particular, yes, I think it would be a feasible thing to migrate, evolve, replace UOX3 with one based on this framework, but that is my own personal view, not the thrust of this ramble, which is just one for possiblities.
It would seem to be able to address many of the shortcomings of other emus in terms of builds (especially crossplatform), support classes, sharing of classes between tools and emu, etc.
As for UOX (be it 3 or 4), I don't think it matters in a name (or even if UOX).
As for room for emulators, there are always room, for they are just hobbies by the developer. If one went by user use, then UOX itself would have be gone by now. So even if no users outside the develolper base, there is room as long as one is interested in working on it.
Now in particular, yes, I think it would be a feasible thing to migrate, evolve, replace UOX3 with one based on this framework, but that is my own personal view, not the thrust of this ramble, which is just one for possiblities.
Or start a fresh project to learn QT. There is no reason not to go QT now - there is just the learning curve...Sydius wrote:I think we should all learn QT inside out, then take what we all know about UO and UOX, and apply it towards a fresh project. Just for the fun of it. I agree, though… it is not really about popularity or the number of emulators already in existence, it is about enjoying what you do.
I started messing around with QT4 and some network code a few days ago. Development speed is quick. I currently have the basic server setup done which includes listener, clients, a networkmanager that maintains all connections, packet/buffer deserialisation/parsing/queuing and a packet handler. The network layer is basically done except just to create abstraction for all the UO packets (which may take some time.) To test it out I am creating a standalone loginserver for UO. Also created classes to handle logging, console and an XML configuration file to read in the serverlist. I just need to finish off the Login Packets + logic and I should be done. Not sure if I would have time to create a real emu but just wanted to say that starting with basically no knowledge of QT4 I have all this working in a few days with little hassle (and of course hopefully it is portable tooSydius wrote:As in, have a project to learn QT, then a “real” project that uses it?
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
While this is an old topic, it's still one of great relevance to UOX3.
After quite a while working with the Spidermonkey engine, I feel like I'm constantly hitting walls. Now it's possible that these walls are just my lack of understanding, but it could also be bad documentation or even implementation. I do know that compiling the Spidermonkey source seems to be a constant battle.
Anyhow, with that said, the only downside I see to using QT4 is that we would no longer be able to use MSVC as a compiler. But the benefits may well outweight that one detriment.
After quite a while working with the Spidermonkey engine, I feel like I'm constantly hitting walls. Now it's possible that these walls are just my lack of understanding, but it could also be bad documentation or even implementation. I do know that compiling the Spidermonkey source seems to be a constant battle.
Anyhow, with that said, the only downside I see to using QT4 is that we would no longer be able to use MSVC as a compiler. But the benefits may well outweight that one detriment.
Scott