So I'm trying to get Fable working, and after going through the various things that I had found on the 'net, it's still not working. So I am wondering what else I could do?
I installed DirectX 9, Windows Media Player, and Fable itself without much trouble. The game boots and goes through the splashscreen and opening animation, and then quits. I looked briefly through the output on the terminal, but I can't really make heads or tails of it.
So I am wondering, can anyone help me with what I'm suppost to be looking for, or how to tell what's causing the game to crash?
Help with debugging Fable
-
John Drescher
Help with debugging Fable
On Fri, Jan 23, 2009 at 12:57 PM, ShideKnight <[email protected]> wrote:
If you really did that. This is most likely the cause. Do not install
native DirectX.
John
"I installed DirectX 9"So I'm trying to get Fable working, and after going through the various things that I had found on the 'net, it's still not working. So I am wondering what else I could do?
I installed DirectX 9, Windows Media Player, and Fable itself without much trouble. The game boots and goes through the splashscreen and opening animation, and then quits. I looked briefly through the output on the terminal, but I can't really make heads or tails of it.
So I am wondering, can anyone help me with what I'm suppost to be looking for, or how to tell what's causing the game to crash?
If you really did that. This is most likely the cause. Do not install
native DirectX.
John
Help with debugging Fable
On Fri, Jan 23, 2009 at 11:57 AM, ShideKnight <[email protected]> wrote:
.
Paste the output and we'll help. If it's a lot, use pastebin.
--
-Austin
Without having done any debugging, it's hard to say, it's a learned artSo I'm trying to get Fable working, and after going through the various things that I had found on the 'net, it's still not working. So I am wondering what else I could do?
I installed DirectX 9, Windows Media Player, and Fable itself without much trouble. The game boots and goes through the splashscreen and opening animation, and then quits. I looked briefly through the output on the terminal, but I can't really make heads or tails of it.
So I am wondering, can anyone help me with what I'm suppost to be looking for, or how to tell what's causing the game to crash?
.Paste the output and we'll help. If it's a lot, use pastebin.
--
-Austin
-
ShideKnight
- Newbie
- Posts: 3
- Joined: Fri Jan 23, 2009 12:42 pm
Funny thing is, I just read that a DirectX couple minutes after posting 
Oh well. We'll see if I have to redo it.
By the way, how would I do that? I saw something about a complete reinstall of Wine. I guess that is because the install writes over the versions of the files that Wine uses?
Also, here's the pastebin: http://pastebin.com/m28f85740
I have looked through it a bit... there are a bunch of fixmes comming up and some errs also. I saw on the wiki that fixmes tend to be aimed more at developers... but I am thinking maybe the errs show more serious problems? I mean like, how can I tell what might be caused by a file or dll?
Also, thank you, you two
Oh well. We'll see if I have to redo it.
By the way, how would I do that? I saw something about a complete reinstall of Wine. I guess that is because the install writes over the versions of the files that Wine uses?
Also, here's the pastebin: http://pastebin.com/m28f85740
I have looked through it a bit... there are a bunch of fixmes comming up and some errs also. I saw on the wiki that fixmes tend to be aimed more at developers... but I am thinking maybe the errs show more serious problems? I mean like, how can I tell what might be caused by a file or dll?
Also, thank you, you two
-
John Drescher
Help with debugging Fable
On Fri, Jan 23, 2009 at 1:42 PM, ShideKnight <[email protected]> wrote:
the wine FAQ on how to clean the prefix.
John
Do not reinstall wine. This will not clean up your wine prefix. SeeFunny thing is, I just read that a DirectX couple minutes after posting [Laughing]
Oh well. We'll see if I have to redo it.
By the way, how would I do that? I saw something about a complete reinstall of Wine. I guess that is because the install writes over the versions of the files that Wine uses?
the wine FAQ on how to clean the prefix.
John
Help with debugging Fable
On Fri, Jan 23, 2009 at 12:42 PM, ShideKnight <[email protected]> wrote:
installed. The files that wine uses (unless overridden with native)
are in /usr/, and you can't overwrite them, unless you're root.
--
-Austin
No, just '$ rm -rf ~/.wine'. That'll wipe out any apps you'veFunny thing is, I just read that a DirectX couple minutes after posting [Laughing]
Oh well. We'll see if I have to redo it.
By the way, how would I do that? I saw something about a complete reinstall of Wine. I guess that is because the install writes over the versions of the files that Wine uses?
installed. The files that wine uses (unless overridden with native)
are in /usr/, and you can't overwrite them, unless you're root.
Try 'winetricks dcom98'.Also, here's the pastebin: http://pastebin.com/m28f85740
I have looked through it a bit... there are a bunch of fixmes comming up and some errs also. I saw on the wiki that fixmes tend to be aimed more at developers... but I am thinking maybe the errs show more serious problems? I mean like, how can I tell what might be caused by a file or dll?
Also, thank you, you two
--
-Austin
-
ShideKnight
- Newbie
- Posts: 3
- Joined: Fri Jan 23, 2009 12:42 pm
Okay. I'll have to do that then...
In the mean time, I have a couple questions
- Is it possible to remove just one program with a command like that so I don't have to try to reinstall anything else?
- What exactly is the native vs. builtin distinction in user.reg? I got the impression that native uses a dll from the system or system32 folder, whereas builtin uses a dll from the /usr/ directory. But if you switch a file from builtin to native, for instance, does it write over the file in the /usr/ directory, or does it just redirect the command to the other file? Also, what does it mean when it lists both native and builtin?
In the mean time, I have a couple questions
- Is it possible to remove just one program with a command like that so I don't have to try to reinstall anything else?
- What exactly is the native vs. builtin distinction in user.reg? I got the impression that native uses a dll from the system or system32 folder, whereas builtin uses a dll from the /usr/ directory. But if you switch a file from builtin to native, for instance, does it write over the file in the /usr/ directory, or does it just redirect the command to the other file? Also, what does it mean when it lists both native and builtin?
Help with debugging Fable
On Fri, Jan 23, 2009 at 4:19 PM, ShideKnight <[email protected]> wrote:
uninstallers don't work on windows. If you install each program in a
separate WINEPREFIX, you can just remove that prefix.
builtin = wine's replacement dll
If you use native, it'll try to use the native dll in the same
directory as the executable, then any in your (windows) PATH. Most of
the time, their put in system32. The confusion there is that many
'fake' wine dlls, because many programs check for dlls to be located
here (poor practice, but works on windows).
Overriding with native won't replace the file in /usr, it just tells
wine to use that file instead, when possible.
If you have native AND builtin, it will try them in the order listed.
--
-Austin
Uninstallers should work as in windows, but don't always...and someOkay. I'll have to do that then...
In the mean time, I have a couple questions
- Is it possible to remove just one program with a command like that so I don't have to try to reinstall anything else?
uninstallers don't work on windows. If you install each program in a
separate WINEPREFIX, you can just remove that prefix.
Native = windows dll- What exactly is the native vs. builtin distinction in user.reg? I got the impression that native uses a dll from the system or system32 folder, whereas builtin uses a dll from the /usr/ directory. But if you switch a file from builtin to native, for instance, does it write over the file in the /usr/ directory, or does it just redirect the command to the other file? Also, what does it mean when it lists both native and builtin?
builtin = wine's replacement dll
If you use native, it'll try to use the native dll in the same
directory as the executable, then any in your (windows) PATH. Most of
the time, their put in system32. The confusion there is that many
'fake' wine dlls, because many programs check for dlls to be located
here (poor practice, but works on windows).
Overriding with native won't replace the file in /usr, it just tells
wine to use that file instead, when possible.
If you have native AND builtin, it will try them in the order listed.
--
-Austin
-
James McKenzie
Help with debugging Fable
ShideKnight wrote:
de-install.
(preferably WindowsXP) that you place either in the execution directory
(.wine/drive_c/Program\ Files\<Path to executable>) or in the system32
directory, replacing the .dll 'stub' file that is there. It is
preferable to put the native dll in the execution directory and create
an entry with winecfg that 'overrides' the dll file settings for that
program only.
Built-in dlls are 'stub' files that redirect program activity from the
dll file that resides in the system32 directory to *NIX static object
(.so) or MacIntosh dynamic library (.dylib) files located in the /usr
directory structure. Please keep in mind that you do not and should not
remove the *NIX files nor rename them as some do provide extended
functionality not normally provided by a native dll.
Setting native, built-in will first scan the native dll (if available)
for a desired function call and then Wine's dll. This provides Windows
like performance in some cases, but is not best to test if Wine is
correctly emulating Windows functionality as the Windows dll will be
used first.
Setting built-in, native will first scan the built-in dll and then the
native dll. This may be better than using native, built-in for Wine
functionality tests, however, if you are looking for Windows performance
this may be worse than using only the built-in capabilities.
The remaining two settings should be self-explainatory.
James McKenzie
This might work, if you have an installer that supports command lineOkay. I'll have to do that then...
In the mean time, I have a couple questions
- Is it possible to remove just one program with a command like that so I don't have to try to reinstall anything else?
de-install.
Native dlls are dlls obtained from a licensed copy of Windows- What exactly is the native vs. builtin distinction in user.reg? I got the impression that native uses a dll from the system or system32 folder, whereas builtin uses a dll from the /usr/ directory. But if you switch a file from builtin to native, for instance, does it write over the file in the /usr/ directory, or does it just redirect the command to the other file? Also, what does it mean when it lists both native and builtin?
(preferably WindowsXP) that you place either in the execution directory
(.wine/drive_c/Program\ Files\<Path to executable>) or in the system32
directory, replacing the .dll 'stub' file that is there. It is
preferable to put the native dll in the execution directory and create
an entry with winecfg that 'overrides' the dll file settings for that
program only.
Built-in dlls are 'stub' files that redirect program activity from the
dll file that resides in the system32 directory to *NIX static object
(.so) or MacIntosh dynamic library (.dylib) files located in the /usr
directory structure. Please keep in mind that you do not and should not
remove the *NIX files nor rename them as some do provide extended
functionality not normally provided by a native dll.
Setting native, built-in will first scan the native dll (if available)
for a desired function call and then Wine's dll. This provides Windows
like performance in some cases, but is not best to test if Wine is
correctly emulating Windows functionality as the Windows dll will be
used first.
Setting built-in, native will first scan the built-in dll and then the
native dll. This may be better than using native, built-in for Wine
functionality tests, however, if you are looking for Windows performance
this may be worse than using only the built-in capabilities.
The remaining two settings should be self-explainatory.
James McKenzie
