OpenMW 0.11.0

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

OpenMW 0.11.0

Post by lgromanowski »

Zini wrote: While we wait for 0.10.0 to finish up, I started to build a suggested task list for 0.11.0.

From the previous list we keep the terrain tasks. The linux path problem will be most likely moved to the suggestion list again, since I haven't heard from dhardy. NPC dialogue windows and water will go straight to the 0.11.0 roadmap again. I plan to move the remaining unfinished tasks (minus NPC rendering and physics) to the "Other Tasks" list again, since there hasn't been any work on them recently and they don't have a high priority either. But if you are one of the contributors for these tasks and want to pick them up again, please feel free to do so.

Furthermore on the suggestion list we have:

- Rendering optimisations

Rendering is too slow. We need to look into batching. Smart batching strategy required that takes the different parts of the MW world model into consideration.

- Caelum

Not exactly urgent, but it is the last major graphical element, that is missing, once the water and the terrain is done. Also the current implementation is a bit problematic. It shows the sky in cells that should not have one. And in Star's last video you could see the problem with the way too fast day-night cycle.

- Inventory, Container- and trade-windows

We have a limited inventory system so we can as well create a GUI for it. We can't support trade yet, but the GUI should be written in a way, that the same code (base class) can be reused for all three window types. There are various features that are not supported yet (like dropping items). We can discuss these when someone decides to take the task.

- Ensure every member variable has an m prefix

Code maintenance. Boring. I know. But desparately needed.

- Move components from global namespace into their own namespaces

More boring code maintenance.

- Refactor engine class

Currently a lot of code that actually should have gone into the various mw*-subsystems ended up in the engine class, which resulted in a huge pile of clutter.

- Journal

Journal implementation, including script instructions (but no GUI). I reserved this task for myself. With the current workload (managing the code; helping out other people with their tasks) I can't realistically expect to tackle something larger. This is small enough to be still manageable with the time I have left for actual coding. Also, a large number of scripts currently fail because of missing journal instructions. This feature will boost the percentage of functional scripts in Morrowind.esm quite a bit.

- Rewrite cmake scripts to enforce dependency-policies

At least make sure, that components and sub-modules can't depend on apps/openmw.


As usual these are only suggestions. Feel free to pick up anything you like (but preferably ask on the forum for input on the task first).
Star-Demon wrote: haha I think I might take the enforcement task. I hear you can't trust refactor, soooo...
Zini wrote: Anyone started working on anything? I know there were quite a few new people, who wanted a new task for 0.11.0. In fact so many, that I lost track of them.

0.10.0 is dragging on a bit longer than expected, but that shouldn't stop you from starting to work on something else, while gus and I finish up 0.10.0. After all we have a modern version control system, that makes concurrent lines of development easy.

If there is something on the suggested tasks list (or the rest of the roadmap page), that you are interested in and that you think you can manage, now is the time to speak up!

btw. I am going to clean out the 0.10.0 roadmap now. Its unlikely that we will get any of the non-mandatory tasks finished in time for the upcoming release.
Star-Demon wrote: Well, coding wise I'm little off-priority with what I spend time on.

It's good to get the jump on, but from the sound of things we should probably get the issue tracker deal resolved and in place - I think it'd be way better to pick out tasks. I'm still for doing the corrections but I think it's very monotonous and very likely for me to make a mistake because of how large the project is. Refactoring might not work completely., so I'm not sure how to go about it other than one file at a time, lots of CTRL F, and lots of careful reading of a very organic project.

So I'm not sure if it's a good idea to pick anything out until we have a better grasp on issues and then main tasks, what do you think?
Zini wrote: I think I didn't express myself clear enough. The intention for the issue tracker was only to offload the list of long-standing issues, that I am currently keeping in my memory. It was not intended to replace the roadmap (which works rather well as it is).
Issues that would go into the tracker would mostly be those that are too hard or to time-consuming to tackle them immediately.
Later, when OpenMW is more complete and we have a broader user/tester base, we might also use it to track error reports from users.

I am sorry, if you feel uncomfortable with the current roadmap system, but realistically you can't expect it to get any easier or clearer, especially not by just moving it to a different tracking system. Even if we were to integrate the wiki-roadmap into the tracker it would be just a copy operation.
gus wrote: Is it possible to implement already some Game Mechanics stuff?
Because it seems that most items in the roadmap require Ogre or GUI knowledge, which is pretty difficult when you are new to OpenMW, so i think it might be easier to start with some easy game mechanism.
Zini wrote: Game mechanics require knowledge of the esm format and the internal workings of the OpenMW world model (currently the least documented part of our project). I guess getting into the GUI or Ogre would actually be easier. Also, for most game mechanics related tasks, there is some more groundwork to cover first.
Zini wrote: Actually, the above statement isn't entirely accurate. We could easily implement the NPC dialogue system. But Peppe is currently working on the GUI for it and I am not sure, if he wants to do the back-end too. Technically it would be no problem to have one developer working on the front-end and another developer working on the back-end.
Star-Demon wrote:
Zini wrote:I am sorry, if you feel uncomfortable with the current roadmap system, but realistically you can't expect it to get any easier or clearer, especially not by just moving it to a different tracking system. Even if we were to integrate the wiki-roadmap into the tracker it would be just a copy operation.
I wasan't making such implications about the roadmap. Personally, I think a simple list is fine. I merely like seeing everything laid out, including the long standing issues you speak of.

I was simply fishing for an easier task. :)
Zini wrote: Well, we have two very easy tasks on the roadmap. The m-prefix actually might require fiddling around with git sub-modules, which makes it slightly less simple.

But there is absolutely nothing problematic about the namespace task, except for the risk of dying from boredom. If you want to take it, I can set up a branch with some code preparations and give you step by step instructions.
Star-Demon wrote:
Zini wrote:Well, we have two very easy tasks on the roadmap. The m-prefix actually might require fiddling around with git sub-modules, which makes it slightly less simple.

But there is absolutely nothing problematic about the namespace task, except for the risk of dying from boredom. If you want to take it, I can set up a branch with some code preparations and give you step by step instructions.
I wasn't aware of the namespace task - I might have missed it if you were talking about it before.

I was talking about the m-prefix - it doesn't seem hard, but I'm making assumptions about how I'd fix such a thing - there's probably a better way that I don't know of.

If you don't mind, since it seems more complicated than I assume, go ahead and describe the basic routine for fixing all of it. It seems it's more than simply going through each file and changing names or renaming through IDE refactor.
Zini wrote: Just to make sure: We are talking about m prefix or component namespaces now?

Or if the "all" in your post meant you want to do both, with which one do you want to start?
Star-Demon wrote: The M-prefix. That one requires less preparation.

PS: When did I become a mod? I almost accidentally edited your post for the worse. I thought I quoted you. Wow. :O Just goes to show you how often I'm editting my own posts.

My name isn't green...
Zini wrote: Okay. First the repository: I just created a new branch (next) this will serve as base and as integration end-point for 0.11.0 while 0.10.0 is still WIP (next kinda takes the role of master for now from a 0.11.0 point of view).
You need to create a new branch from your master branch (call it mprefix or something) and then merge in my next branch. Don't forget the submodule update!

Now you need to go through all struct and class definitions and look for member variables, that don't follow the mSomeName scheme, .e.g. when you have "name", it should be replaced by "mName".
You can probably leave alone dumb structs with only public member variables and no functions (even if the member variables there don't have an m-prefix, it hardly matters).

Then compile! Your compiler should provide a large number of error messages, indicating where these variables are used. Fix each one by modifying the name accordingly. Repeat as often as needed.

I suggest you leave libs/openengine and libs/mangle alone for now. These involve submodule handling and require special treatment.

Also, I suggest not to use search and replace or any other kind of automated tool. These are very likely to mess up your code. Letting the compiler find the places requiring change is safer.

When you are done, commit and push to your mprefix branch on github (which will automatically create this branch in the github repository).
Star-Demon wrote:
Zini wrote:Okay. First the repository: I just created a new branch (next) this will serve as base and as integration end-point for 0.11.0 while 0.10.0 is still WIP (next kinda takes the role of master for now from a 0.11.0 point of view).
You need to create a new branch from your master branch (call it mprefix or something) and then merge in my next branch. Don't forget the submodule update!

Now you need to go through all struct and class definitions and look for member variables, that don't follow the mSomeName scheme, .e.g. when you have "name", it should be replaced by "mName".
You can probably leave alone dumb structs with only public member variables and no functions (even if the member variables there don't have an m-prefix, it hardly matters).

Then compile! Your compiler should provide a large number of error messages, indicating where these variables are used. Fix each one by modifying the name accordingly. Repeat as often as needed.

I suggest you leave libs/openengine and libs/mangle alone for now. These involve submodule handling and require special treatment.

Also, I suggest not to use search and replace or any other kind of automated tool. These are very likely to mess up your code. Letting the compiler find the places requiring change is safer.

When you are done, commit and push to your mprefix branch on github (which will automatically create this branch in the github repository).
Okay, sounds good. I'll make the preparations today and chime in as I do things in a separate thread.
Zini wrote: Forgot to mention: Ignore the extern directory too. That's not our code after all. For now it will be enough, if you can bring components and apps in line.
Zini wrote: Because of popular demand, I added two gameplay-related entries to the suggested tasks list. Sleeping/Resting and Level-up.
Please note, that the sleeping/resting is more or less a prerequisite for the level-up implementation.
Greendogo wrote: Can OpenMW already render all of the particle effects such as spells and fire and Weather effects etc? For some reason I thought that it couldn't yet render spells or snow/blight storms, so I figured that your statement, Zini, about the Sky and Water being the last graphical elements to add was premature. Am I right?
Zini wrote: We don't have any spell effects at all.

And I never talked about the last graphical element. I talked about the last major graphical element, i.e. anything that would result in a gaping hole in the visual presentation of the world. That are still quite a few minor visual elements to add (spell effects are one of them).
sir_herrbatka wrote: My fault. Sry, this shouldn't happen.
Zini wrote: 0.10.0 is out of the way now and the list of claimed tasks for 0.11.0 is still pretty short. Come on! Grab a headache inducing^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H juicy task, before they are all taken.
Zini wrote: Little update: We had quite a few people taking tasks from the suggested tasks list.

Of the remaining, I think these are the most important:

* Sort out the remaining path problems on Linux (case and "/" "\" problems for resources files)
* Review Caelum; generalise it or replace it
* Inventory, Container- and trade-windows


These:
* Replace tabs with 4 spaces (again)
* Collisions with terrain

can easily wait a bit longer (the first one should wait for Star to finish his work and the 2nd one can only be done, once corristo has made some progress).

I consider the other tasks on the list highly optional for 0.11.0.
bobtedbob wrote: Looks like Caelum has a new owner, 0.6 was released a couple of days ago and now uses cmake as the build system. Last code release was 2009 though

http://www.ogre3d.org/addonforums/viewforum.php?f=21

Other alternatives look like

skyx which could be paired with hydrax, again these were last updated in 2009 but the author is still active and releasing an engine with both these in (hes been saying he will release another version soon but hes said that a lot). Hydrax is a water plug in, does all the reflections with the sky etc. Looks nice

http://www.ogre3d.org/forums/viewtopic.php?f=11&t=52166

Might be missing some features of Caelum but I don't know what your sky requirements are.
gus wrote: SkyX is only in 0.1, and the authors hasn't updated it for ages. Also, skyX use a lot of GPU, so it's not for older hardware. It might be a post 1.0 feature.
Zini wrote: Defining the sky rendering requirements is the first step in this task. But I can give you a few pointers:

- two moons (using a predefined texture)

- sky must be easy to switch on/off (going inside/outside)

- must be configurable enough, that Morrowind sky mechanics can be emulated (changing moon colour, moon phases, duration of a year)
Locked