Jump to content
The Dark Mod Forums

Is anyone else using Vista?


Recommended Posts

After thinking about it and going through all the current dependencies, I can say this:

 

From what it looks we won't be able to define a "Directed Acyclic Graph" of modules. There are a few modules which contain calls to code of their dependants. I.e. the Radiant module contains code that calls the EventManager and vice versa. The nodes are connected in a bidirectional way, so to say. Hence, if we take all the code of a module into account, we can't resolve the dependencies.

 

However, if we consider only the code

- executed during the module's initialisation

- and code reachable through their public module interface

we might succeed.

 

An example: The BrushCreator depends on a list of 11 modules right now, but during its initialisation only the XMLRegistry, the ShaderCache and the PreferenceSystem are actually called. Of course, there is the possibility that code depending on the BrushCreator might call functions from the BrushCreator interface which in turn might call code from another module (not listed in the dependencies).

 

Looking at the BrushCreator interface, I can see three functions, that are createBrush, Brush_forEachFace and Brush_addFace. In these three functions, only the UndoSystem is called, so the total of effective dependencies is 4, instead of the currently listed 11.

 

If we cut down the list of total dependencies to a list of effective dependencies, we might achieve an acyclic graph. Of course, if the interfaces change to a large extent, we might run into troubles again.

 

The main problem is that we try to squeeze the existing code network into the context of directed dependencies, which is bound to fail as (at least the core) modules must be allowed to call themselves sometime.

 

OrbWeaver, what do you think?

Link to comment
Share on other sites

  • Replies 172
  • Created
  • Last Reply

Top Posters In This Topic

From what it looks we won't be able to define a "Directed Acyclic Graph" of modules. There are a few modules which contain calls to code of their dependants. I.e. the Radiant module contains code that calls the EventManager and vice versa. The nodes are connected in a bidirectional way, so to say. Hence, if we take all the code of a module into account, we can't resolve the dependencies.

 

Yes, I suspected this would be the case unfortunately. This speaks to a fundamental design issue, in that the functional division of modules is incorrect if modules are mutually dependent on each other. Modules should really fit into a hierarchy of "producers" and "consumers", where data travels from the producers through the DAG to the consumers.

 

I suspect that the Radiant module is the first place to address this, there is a lot of ad-hoc cruft on the module interface (which I have tried to remove, sometimes successfully but it is far from complete). It may be that mutually-dependent modules actually need to be combined into a single module, or subsumed by an existing one (e.g. maybe the EventManager is functionally part of the Radiant module, rather than a separate thing).

 

However, if we consider only the code

- executed during the module's initialisation

- and code reachable through their public module interface

we might succeed.

 

Doesn't this cover pretty much everything though? If code is not called during initialisation and not reachable through the public interface, when would it ever be executed?

 

An example: The BrushCreator depends on a list of 11 modules right now, but during its initialisation only the XMLRegistry, the ShaderCache and the PreferenceSystem are actually called. Of course, there is the possibility that code depending on the BrushCreator might call functions from the BrushCreator interface which in turn might call code from another module (not listed in the dependencies).

 

I had this thought originally too -- surely if we only look at the initialisation routine, the dependencies should be smaller. However as you rightly point out, something which depends on the module might call its public interface, so the entire module code needs to be scanned for dependencies not just the initialisation routine.

 

OrbWeaver, what do you think?

 

I think we have a long hard slog ahead of us if we want to fix this issue (and we'll need to if we want Vista compatibility and general robustness). I cannot think of any quick wins that would avoid the requirement to carefully analyse the module design and possibly conduct significant restructurings of the divisions of functionality.

Link to comment
Share on other sites

I'm both sorry and glad that I brought this up. It certainly needs to be fixed but before anything is done we need a second Vista owner (at the very least) to confirm my findings.

 

We must exclude the possibility that this is just a quirk on my machine.

I want your brain... to make his heart... beat faster.

Link to comment
Share on other sites

Yes, I suspected this would be the case unfortunately. This speaks to a fundamental design issue, in that the functional division of modules is incorrect if modules are mutually dependent on each other. Modules should really fit into a hierarchy of "producers" and "consumers", where data travels from the producers through the DAG to the consumers.

That's probably not how the current code works. The core modules (SelectionSystem, Radiant) are almost all depending on themselves.

 

I suspect that the Radiant module is the first place to address this, there is a lot of ad-hoc cruft on the module interface (which I have tried to remove, sometimes successfully but it is far from complete). It may be that mutually-dependent modules actually need to be combined into a single module, or subsumed by an existing one (e.g. maybe the EventManager is functionally part of the Radiant module, rather than a separate thing).

I just looked, the EventManager is probably a bad example. It's pretty much self-contained, but I used the GlobalRadiant() interface to set the status bar text (for the context help). Once we move this to the UIManager, the dependency on GlobalRadiant is gone.

 

At any rate, the GlobalRadiant() interface should still be cleaned up, I agree.

 

Doesn't this cover pretty much everything though? If code is not called during initialisation and not reachable through the public interface, when would it ever be executed?

Hm, yes, this is true, or at least it should be.

 

I think we have a long hard slog ahead of us if we want to fix this issue (and we'll need to if we want Vista compatibility and general robustness). I cannot think of any quick wins that would avoid the requirement to carefully analyse the module design and possibly conduct significant restructurings of the divisions of functionality.

I'll go through the modules and throw out any obvious extra dependencies using my experience. I've seen almost all the code in DarkRadiant in the meantime, so I think I can judge pretty well when the various code parts are called and which dependencies are probably unneccessary. For instance, I think it's safe to say that no actual rendering will occur until all the modules are initialised, so a GlobalOpenGL dependency is unneccessary in 99% of the cases. Even if rendering-related functions are accessible via the public interface, it often doesn't make sense for them to be called before everything is initialised. Unfortunately, this is not a clean way to define things, more like gut-feeling or resulting from special knowledge, but it might result in a better stability at start-up.

Link to comment
Share on other sites

Thanks for the advice guys and thanks for the offer Tels. I might come back to you on that, but I'll try a few things with angua's not-yet-ex-hdd first.

 

I seem also to remember that a friend of mine has a 2.5" external 20 GB hdd. Maybe he doesn't use it anymore, I'll have to ask if I can borrow it.

 

No problem, if you ever need the HD just PM me your address and I put it into a parcel.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

That's probably not how the current code works. The core modules (SelectionSystem, Radiant) are almost all depending on themselves.

 

I know, the current system is far from ideal, which is why it would probably be a lot of work to fix properly.

 

I'm not sure what you mean by "depending on themselves", do you mean that there is a cycle in place, or does a module specifically list itself as a dependency (I don't think this could work in any case)?

 

Unfortunately, this is not a clean way to define things, more like gut-feeling or resulting from special knowledge, but it might result in a better stability at start-up.

 

Well if it works, it's better than nothing. It won't be stable or maintainable in the long run of course, because the special knowledge will almost certainly get lost at some point (e.g. those "don't initialise the module until this method is called twice" hacks that exist(ed) in some of the module initialisers, which depend on magic knowledge about which other modules will be calling this one).

Link to comment
Share on other sites

I guess if you run it over an external HDD you may need a LOOOT of patience though. ;)

 

Windows 98 SE wasn't even able to install on the secondary HD (you could swap the HDs, install it on the "first", then swap them back and boot it from the second one, just not install).

 

Dunno about XP or Vista, but I guess it won't be much better.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I know, the current system is far from ideal, which is why it would probably be a lot of work to fix properly.

That's for sure.

I'm not sure what you mean by "depending on themselves", do you mean that there is a cycle in place, or does a module specifically list itself as a dependency (I don't think this could work in any case)?

Poor expression on my behalf. I didn't mean that they list themselves as dependency (this would be truly nonsensical), but that two modules depend on each other, for instance.

Link to comment
Share on other sites

I've traversed the modules (we have 52 by the way) and cleaned up all the dependencies, I hope I got it right.

 

@Subjective Effect: Can you test this snapshot, maybe this changes things. There is no debug output in this package, I haven't ported these changes into the Vista_Debug branch yet.

 

http://208.49.149.118/TheDarkMod/DarkRadia...ta_Debug_10.zip

Link to comment
Share on other sites

Is the Radiant editor that DR is based on the problem? Maybe some other people have got it working properly on Vista and have some answers on some other Radiant forums.

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

Is the Radiant editor that DR is based on the problem? Maybe some other people have got it working properly on Vista and have some answers on some other Radiant forums.

 

GtkRadiant development is pretty much dead AFAIK, and besides we left them in the dust a long time ago. Our module system is completely new (introduced in 0.9.3 or thereabouts), so any changes to the GtkRadiant codebase would not be of any value.

Link to comment
Share on other sites

Is the Radiant editor that DR is based on the problem? Maybe some other people have got it working properly on Vista and have some answers on some other Radiant forums.

 

I was corresponding with the guys from the xreal revamp for the Quake 3 engine, and they can't even help me get their version working on Windows Server 2003...or XP. They say it works fine on Linux though. Heh. That's all well and good, but it just looks like they're making another mess of that one. Are the zero radiant guys the same ones who worked on GTK?

 

I agree Orb. You guys definitely left them choking on dust and fumes ages ago.

Link to comment
Share on other sites

Are the zero radiant guys the same ones who worked on GTK?

ZeroRadiant is handled by iD software people themselves. The commits are made by TTimo on a very irregular basis (I assume the project has been on the backburner right from the start).

Link to comment
Share on other sites

Well, there are several options.

  • Fix it yourself (prefered)
  • Find somebody who can fix it (also good one)
  • One of the developers has got time and patience to install Vista just for that and can fix it.
  • Install a different OS.

At the moment I don't see any other options as greebo tried it already.

Gerhard

Link to comment
Share on other sites

Lol, 'time and patience' to install vista. Download the bloody thing and stick it on another HD, It hardly requires time or patience.

I thought it was common practice for developers to have several OSes to test on, like web designers having several different browsers to test on.

Vista is soon going to be the most widely used OS.

Civillisation will not attain perfection until the last stone, from the last church, falls on the last priest.

- Emil Zola

 

character models site

Link to comment
Share on other sites

I'm not sure what you're really saying here spar?

 

Are you saying that if people want to use Dark Radiant and they have Vista that they should either install XP or fix it themselves?

 

I think Spar was simply covering all the options. Essentially, it will be fixed when one of our developers has the time/resources to install Vista. Greebo was looking into it, but it's likely to take some time. GTK Radiant, from what Orb and Greeb have said...a nightmare of spaghetti code. They've spent a good amount of time just cleaning the thing up and rewriting it. It will take some time, but it will work on Vista eventually.

Link to comment
Share on other sites

Are you saying that if people want to use Dark Radiant and they have Vista that they should either install XP or fix it themselves?

 

Well, that's a pretty good summary if you insist on playing offended. But of course, not everybody has to fix it himselve. One would be quite sufficient, assuming he doesn't keep it to himself. ;)

 

Getting it Vista ready is not the primary objective, and if you want to use DR and it doesn't work on Vista, then I don't see much options than either waiting until somebody fixes it, or trying to find the problem yourself, one way or the other.

 

But you should see it the positive way. You can at least run the mod on Vista so you can play mods. Mac users are also a big userbase, and they can't even run the mod.

Gerhard

Link to comment
Share on other sites

Someone certainly could join to take on the task, or handle it even without joining. Didn't Thelvyn do that as a side project for the Linux build of TDM? (My apologies if I've forgotten the true person to have done that!) I for one would hate to see our DR devs' talents go to waste (yep waste) on adding support (right now) for another OS, whatever it is. The core functionality (of which there is a boatload, and more to come) far outweighs that task in importance.

 

We learn and relearn this at work all the time: we build the product for the target audience first, and add support for other OSs only if there's time, or later, so say the bosses. My current project even supports Mac OS from 10.3 all the way up to Leopard, before worrying about Vista. The latter was tacked on later because they figured, well, someday a few customers might use it. It's that low on the totem pole, and that's in a business model (since the point was made to diminish "just gamers" as being unimportant, earlier).

 

Anyway, it's just an opinion. Everyone's entitled to work on whatever-the-hell they want, really.

 

Edit: PC World seems to agree that it's not the second coming. Funny how they conclude it; sure, Vista will catch on eventually, because people will be forced to accept it. Actually, that's not very funny at all.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...