Zini wrote: Nico, have you given any thought on how the GUI implementation within the openmw directory should look? My thought was to have a separate MWGUI directory (analogous to MWInput, MWRender, MWScript and MWSound). This directory would then contain a GUIManager class, which would forward all GUI calls to the actual, game-independent GUI implementation (probably another component).
If that is agreeable to you, I could start writing the GUIManager class and connect it to the script system (for now all member-functions would only print a simple message to std::cout).
nicolay wrote: That sounds like a good plan. I was going to start working in the other end, with compiling MyGUI and making the basic classes for loading templates. If you make a GUIManager with skeleton functions for the functionality you want, then I could fill in the blanks when I'm done.
Zini wrote: I pushed the GUI manager changes to my repository. No script integration yet, but you better pull it in, so you know with what you are working on the top level.
Zini wrote: Oops. Sorry. Please wait. I can come up with a better design.
Zini wrote: Okay, done. You can pull.
nicolay wrote: Great. I've started a private dev branch with MyGUI. Since I'm including the entire lib (30Mb+) I won't push it until I've cut it down a bit. Using MyGUI 3.0.1.
nicolay wrote: I've included a cut down version of MyGUI now, at about 2.3 Mb. I removed all the demos, install scripts, tools and unused backends (DirectX and OpenGL, only OGRE left.) The entire library itself is still included. Since it's so small I've moved it over to the main branch now.
I've also made a small test in apps/mygui_dev which successfully compiles, links and runs. This is what I'll be working on for the time being.
First goal is to get the Morrowind windows up and running! I'll return with screenshots.
nicolay wrote: Here it is!
Everything is still done in the stand-alone app in apps/mygui_dev/, that's why all the backgrounds are black and why the mouse is in the upper left corner (it's not connected to any input yet.)
Next up: moving the files over to the components and then I'll start working on the console. After the console is done I'll hook everything into the main executable.
raevol wrote:... *swoon*nicolay wrote:Here it is!
nicolay wrote: Back from a nice vacation I've started working on the GUI code again.
First stop was to revamp and generalize the input system a bit. I've refactored and moved bits and pieces into mangle/. I've also moved all the parts in components/engine/ into its own project, called OpenEngine (at http://github.com/korslund/OpenEngine) and which is now located in libs/openengine/. The rationale is that these parts are now truly independent of OpenMW, and they aren't likely to change all that often. It will also make it easier for people to use reusable parts from OpenMW in other projects if they want to.
Next up: hooking the mouse and keyboard into MyGUI!
EDIT: forgot to add: to get the latest commit to work you will most likely need to doto download the libs/openengine/ contents.
Code: Select all
git submodule update --init
Zini wrote: Just noticed, that you are adding stuff to mwscript/guiextensions. All interfacing with GUI should go into mwgui/guimanager instead. guiextensions is merely the compiler configuration and the binding.
Zini wrote: And the same applies to interpretercontext. The context is not supposed to interact directly with low level components (except for the interpreter component).
Edit: And apps/openmw/engine too. We can reach a much looser coupling, if all usage of the gui component is limited to apps/openmw/mwgui.
Edit2: Okay, now I get it. You made openmw/mwgui into a component. Looks wrong too me. openmw/mwgui contains Morrowind specific stuff (e.g. window and dialogue types). That doesn't belong into components, which is supposed to be Morrowind-agnostic.
nicolay wrote: Yes, finally the Gui system is done. Everything compiles together, the input is hooked up and is flowing correctly, and switching in and out of gui mode (use the 'I' key) works. The script hooks that Zini made are also hooked up. Just one minor mouse pointer bug to fix and I'm ready to mark GUI as done
Anyway, enough babbling, here's a couple of shots!
nicolay wrote:That's true, but strictly speaking most of the components contain Morrowind-specific stuff (scripts and ESMs are certainly MW-specific.) The separation between stuff in components and apps/openmw, isn't that well defined, but maybe you're right about this one. In any case lets just leave it there, we can move it later.Zini wrote:Edit2: Okay, now I get it. You made openmw/mwgui into a component. Looks wrong too me. openmw/mwgui contains Morrowind specific stuff (e.g. window and dialogue types). That doesn't belong into components, which is supposed to be Morrowind-agnostic.
(My thinking was that it was completely independent on anything else in apps/openmw, and while maybe not usable for much other than a game implementation, it could easily be reused by several and very different implementations in the future.)
Zini wrote:The world model (ESM) is MW-specific. That is true. But apart from that we already have a very good separation. Compiler and interpreter are not MW-specific at all. They only define the general structure of the language and some features, that can be assumed to be present in every game (like having a GUI, passing of time, 3-dimensional space). All MW-specific script functionality is defined in openmw/mwscript.That's true, but strictly speaking most of the components contain Morrowind-specific stuff (scripts and ESMs are certainly MW-specific.) The separation between stuff in components and apps/openmw, isn't that well defined
I think you are wrong here. Where do you want to place the business logic for the GUI? Various stats will need to be bound to information in the status window, the inventory window and the magic window. These will need access to some of the openmw/mw* stuff. And don't get me started on all the GUI stuff for the character creation process.My thinking was that it was completely independent on anything else in apps/openmw
If you insist, we can leave the GUI component in components (I still think it is a bad idea), but we will need a place in openmw/mw* for this kind of stuff.
Well, we could create a openmw/mwgamemechanics component instead (probably needs a shorter name ), but it sounds a bit sub-optimal to me.
btw. the windows are opened/closed by pressing the right mouse button. I don't know if there is a I-shortcut at all.
nicolay wrote: Alright, you've convinced me I'll move it back.
As for the key bindings, I haven't completely fixed mouse button binding yet but I'll fix that soon. All key bindings at this point are temporary in any case though as they will be user defined later.
sir_herrbatka wrote: Screens are great! But what about fonts? Again problems with mygui?
Zini wrote: @Nico: Just noticed, that console implementation has shown up as a roadmap entry and that you have assigned it to yourself. I suggest, that you leave the actual script execution implementation to me, because this is tricky business (some parts of the script system work differently in the console; a bit of subclassing, picking the right parser variant and loads of configuring is required). For now it would be good enough, if you simply echo all input back to the console output.
nicolay wrote:Hmm, seems so still. I tried the Magic Cards font (the real Morrowind font) but still no dice. The MyGUI guys can't reproduce it so I guess we have to fix this ourselves.sir_herrbatka wrote:Screens are great! But what about fonts? Again problems with mygui?
No prob, that's what I've done. In apps/openmw/mwgui/console.hpp you'll find a note about where the commands should be executed. How we pass the commands over to the scripting engine should be up to you I think. I've marked the Roadmap item as 'in progress' and leave it to you to finish it.Zini wrote:@Nico: Just noticed, that console implementation has shown up as a roadmap entry and that you have assigned it to yourself. I suggest, that you leave the actual script execution implementation to me, because this is tricky business (some parts of the script system work differently in the console; a bit of subclassing, picking the right parser variant and loads of configuring is required). For now it would be good enough, if you simply echo all input back to the console output.
Zini wrote: Working on it now.
Zini wrote: Update: Script compiling and execution in the console is working now. But I overlooked a special case. The console can handle naked expressions, which my parser originally could not handle. I am working on it, but its a bit tricky (will not push until this problem has been sorted out).
Should we kill the external console and the standalone compiler and interpreter at this point?
The console was a nice idea and it could have been really useful, but it never worked for me and we have a working in-game console now.
The standalone compiler and interpreter can't evolve further at this point and it takes additional work to maintain them.
Zini wrote: Done. Nico, you can pull.
I just noticed that I missed out one global variable (month) when implementing the passing of time. But I can fix that later.
nicolay wrote: Will do. Unless you need the external programs for further testing, I say we should kill them. Same goes for the external console.
Zini wrote: All testing can be done with the in-game console now. So go ahead and kill them all.
nicolay wrote: They're all dead
I killed the command server as well - as I really think it was a bit overkill. If we change our mind and need it for later it's always possible to recover it from the repos.
Btw Zini, do you have any examples of commands we could test in the console? Something that changes the sky would be very nice But I'll take anything.
Zini wrote: Well, we have a list of working script instructions and functions: http://openmw.org/wiki/index.php?title= ... g_(Status)
Anything but structural instructions (If, Begin, While) should work in the console.
To start with you can try to use the console as an extravagant calculator. Input like
should work. You can also query the state of global variables by simply entering their name (Hour, DaysPassed, CharGenState, ...).
Code: Select all
5+5 Player -> GetDistance Player GetSquareRoot 4
As I wrote somewhere else, the sky related commands (e.g. ToggleSky) don't work yet, because the sky manager functions are not implemented.
Edit: some spelling and fixed a link