Next Generation Emulation banner

Status
Not open for further replies.
1 - 20 of 28 Posts

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #1 (Edited)
Thread for things of interest

I tested mystIII once and i was able to get to the loading screen with the progress bar going all the way across before the emulation froze; I decided to try it again but now all i get is a black screen. The same problem happened with Turok:Evolution. Any ideas guys?

edit: decided to use this thread to post things i find strange or inconsistent or interesting :p
 

·
Registered
Joined
·
907 Posts
is this within 1 run.
or do you close the application.

so running.. stop and run again ?
and what does it do when you run it after closing dxbx...

prehaps we do not cleanup something.
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #3
I ran and then closed the application
after opening dxbx again to try the game
i get the black screen
 

·
Registered
Joined
·
423 Posts
Before, you probably used a version that used our old symbol detection engine. The new one is better in many ways, but worse in other cases. MystIII and Blade2 are examples of games that worked better before, but are now less compatible.

Another thing Joao Hadouken discovered a while ago, is that in some cases Dxbx works better if configured to use the software rasterizer instead of the hardware acceleration; In the case of MystIII this gives me the complete intro movie (Blade2 doesn't do much different though, so it's only a partial 'solution').

I understand your enquiry (and I hope to have answered satisfactory), but I would like to stress that right now it's still *way* to soon for any form of support requests. Perhaps when our compatibility improves we could start investigating specific cases, but at this moment I'm already glad that some things actually work on my machine! ;-)
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #5
I dont have any other version of dxbx on my test setup other than the latest one. Thats why I found it so surprising. If it were a matter of different versions i promise you I wouldnt have wasted your time :)
I'll get to the bottom of this and post what caused this when i do
 

·
Registered
Joined
·
423 Posts
Ok, thanks. Let us know that you find, and if you do, please also note which version (mentioned as a revision number in Help|About) you're using, as that's needed for any regression search I might need to do.
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #7 (Edited)
playing around with the video settings seems to have helped
im not getting the loading screen but parts of the intro are playing
i think if i play around with the settings so more i'll get a good result
heres a screen

edit: dammit i JUST noticed i mispelled dxbx at the thread title :p

edit2: when i max out the resolution everything looks better and i get double screens
 

·
Registered
Joined
·
423 Posts
I fixed the title of this thread (did you know you could've done that yourself?).

Anyway, I believe you got a beta build? If it's SourceForge.net Repository - [dxbx] Revision 1434 or higher, could you send us a dump of your logfiles? That way, we can take a peek at your graphics adapter and it's capabilities, which could indicate why you're getting this strange pitch-related render-bug in your output.
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #10 (Edited)
sure thing! i'll edit this post and add a link to a dump along with the video settings I used to reproduce the bug

Direct3D HAL
512 x 384

it becomes quite large when unzipped :innocent:
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #11
Blade 2

Since Blade 2 was a 4627 game I was optimistic about testing it
(unfortunately it didnt work but thats not the point)
when i looked at the logs this jumped at me:

DxbxHLE : Library "XBOXKRNL" is version 4627
... No patterns registered for this library!
DxbxHLE : Library "WMVDEC" is version 4627
... No patterns registered for this library!
DxbxHLE : Library "LIBCMT" is version 4627
... No patterns registered for this library!
DxbxHLE : Library "LIBCPMT" is version 4627
... No patterns registered for this library!

I was under the assumption the devs had everything they needed for the 4627 xdk...
 

·
Registered
Joined
·
423 Posts
@Bill_gates : You probably started Dxbx from another folder or did something else that resulted in Dxbx not being able to load the 'StoredTrie.dpt' resource file, as your previous log (of Myst) showed no problems scanning for 4627 patterns...

But in any case, both MystIII and Blade2 don't get very far. With our previous symbol scanning code, blade did show the intro movie, but since I rewrote that, the results are worse now for this specific title. Right now I'm concentrating on other things, but I have these two titles on my radar for later, when I pick up the symbol scanning code again.

To be honest : I'm putting that work off, even though improved symbol scanning will result in a higher number of runnable games. The reason is, that symbol scanning is not really a subject that I like working on.. I much rather fix some obscure graphics problem, as that's much more rewarding right now. (That, and I'm not really looking forward to getting loads and loads of bug-reports from people, once we start running more titles.)

Just yesterday I fixed vertex shaders that contain backside lighting operations... these cannot be recompiled, so I now remove those instructions, which fixes an render-bug I was experiencing in an XDK samples (TwoSidedLighing). My focus right now is on removing all problems that I know of right now (which are many). Once most of these things are sorted out, we'll also have less problems on other titles later, once we do improve the symbol scanning code.
 

·
Registered
Joined
·
75 Posts
Patrick (oh, and Blueshogun, too!), you're very lucky that Microsoft will extend the singular lifespan of the Xbox 360 console before launching their next console, thanks to their introduction of the Kinect motion controller device, which should automatically stretch the console's lifespan by 2 years from 6 years to 8 years. So that means that the next Xbox should come in 2013, thus giving you 3 years of pressure-cooker-free time to code away in your DXBX emulator at your own pace. It's so that there would be no potential for you, or any other emu author to feel like halting gasping/choking or something when there are 2 distinct consoles from the same manufacturer that would be already out at the same time. I think that this sort of thing has the capability to affect the laser-like focus of any given emu programmer to work on just one program, and then trying to finish it as quickly as possible before the next one would begin, if he's so inclined.

When Microsoft probably releases their new console in 2013 (8 years after 2005's X360), and Sony's one in 2014 (8 years after 2006's PS3) THOSE consoles, I really hope, should last for 10, I repeat, TEN, years before the next iterations comes out!!! I'm so sick of people complaining about wanting the newest and latest graphics (and physics) in a console, when they should just as well buy a new PC! The hopeless wankers!!! :rant: They just DON'T understand the expense of developing an AAA+, or B budget blockbuster game, coz both the devs, and publishers just wanna extend the lifespan of their lovingly polished, and refined engines for as long as possible.

Oh well, at least there is one good thing on the horizon - we're living in an ageing society, where even now so many of us are already over the full-time working age of 18 years. So this means that the money power of us adults will already defeat the complaints of many school-age users on the Internet forums, and comments section in the eyes of the big-time publishers! :D:spit::x3::yippee:

Secondly, in using this 'extended-lifespan' model the emulators only has less of the new consoles to emulate at any given time, therefore they can get many more game releases to work on the same emulator with which they've already known and created for years.
 

·
Registered
Joined
·
423 Posts
I'll let this little rant slide right past me ;-)

Seriously, there's no competition, no honour, no pressure, nothing. I'm just interested in how far I can get this; I use this project to improve my skills, gain knowledge and prove to myself that I got what it takes to be an emu-author. That's all, and that's it. (I can't speak for the other Dxbx members, but I believe them to have the same kind of attitude as me.)

Actually, to be completely honest, I know already that once we got the majority of games working, I'll loose interest. But that's nowhere near right now, and I see plenty of challenges lying ahead of us, so I'll just go on my merry own way - cheers!
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #15
@Bill_gates : You probably started Dxbx from another folder or did something else that resulted in Dxbx not being able to load the 'StoredTrie.dpt' resource file, as your previous log (of Myst) showed no problems scanning for 4627 patterns...

But in any case, both MystIII and Blade2 don't get very far. With our previous symbol scanning code, blade did show the intro movie, but since I rewrote that, the results are worse now for this specific title. Right now I'm concentrating on other things, but I have these two titles on my radar for later, when I pick up the symbol scanning code again.

To be honest : I'm putting that work off, even though improved symbol scanning will result in a higher number of runnable games. The reason is, that symbol scanning is not really a subject that I like working on.. I much rather fix some obscure graphics problem, as that's much more rewarding right now. (That, and I'm not really looking forward to getting loads and loads of bug-reports from people, once we start running more titles.)

Just yesterday I fixed vertex shaders that contain backside lighting operations... these cannot be recompiled, so I now remove those instructions, which fixes an render-bug I was experiencing in an XDK samples (TwoSidedLighing). My focus right now is on removing all problems that I know of right now (which are many). Once most of these things are sorted out, we'll also have less problems on other titles later, once we do improve the symbol scanning code.
Im sure i didnt do anything silly like run it from another folder. Besides all the other 4627 patterns besides the 3 in my post loaded just fine.

But like you said you dont want to focus as much on symbol detection right now so itd be silly for me to keep going on and on about it :p
Fixing graphics issues will pay its own dividends im sure. :)
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #17
ill let the screenshot do the talking :D
 

·
Registered
Joined
·
907 Posts
Bill_gates .. is the movie also working again ?
this logo is fading in.. then out. then it will start a movie file .. can you see that one also again. ?
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Discussion Starter #19
Bill_gates .. is the movie also working again ?
this logo is fading in.. then out. then it will start a movie file .. can you see that one also again. ?
Yeah the movie works too
the logo fades in then out then the movie plays then black screen

when the blade logo comes up i get a crash message but everything continues like normal. Same story with gauntlet. but thats probably an issue on my end.
 

·
Registered
Joined
·
423 Posts
Yeah, those darn exception dialogs...

I don't know how exactly they arise - In Gauntlet I traced it to a call to a native DirectSound API that somehow clears the FS page selector register. I don't know how that could ever happen, and I haven't found a way to fix it either. (It could be caused by some form of stack corruption, but I'm not sure about that.)

For now, I just move these dialogs aside - as somehow the game stays alive.
 
1 - 20 of 28 Posts
Status
Not open for further replies.
Top