Hi you all around the world!
Thanks to the amazing contribution of gsky916, today is born a multilingual version of DxWnd.
This release is (almost fully) translated in chinese, but what is even more important than this, the changes needed to translate it to any other (at least left-to-right writing) language are concentrated into a single file that is dynamically loaded, so that anyone willing to get a localized version of DxWnd just has to translate a single resource script file and compile a single and very simple project.
So far, things are maybe not so simple and ready for anyone to do so, but I will keep providing support and here in attach is the (useless) english version of the resource script that you can browse and judge by yourself if you think you're tough enough for the job.
And, considering that DxWnd was born in japan, it would be a great honor for me to bring it back home and much enriched .....
Oh, I almost forgot: to show the chinese interface, DxWnd must be run with the /lang=cn argument. Future languages will utilize different codes, like /lang=jp for japanese. For each xx language identifier, DxWnd will load the corresponding resouces from Resources_XX.dll
I retrieved my copy of the Battle Realms CD (it's an italian version, I hope that doesn't make any difference) and tried to wander a little in the game. Finished the first mission, I switched to the second and tried something else, but I got no problems or whatsoever.
So, to shorten my intervention time, and to avoid playing the game entirely from beginning to end, I wish to ask you a savegame file to start close to the problem and some directions to replicate it. Can you share the file and infos (sequence of keys, screenshots, dxwnd log files, ...)?
I'm looking for your reply.
Uhm .... I saw the screenshot you posted: I have no problems to overtake that point, where the game is delayed for several seconds waiting for the text / speech termination, and then the arrow cursor appears and let you chose next mission (see screenshots taken from my PC).
I can't download your configuration right now, but the only thing I changed in my PC starting from default configuration was setting Surface Emulation to "None", and in any case I couldn't replicate a configuration that causes a problem right there.
I wonder if the problem is caused by the delay in the response, that in Win7 is not so OS friendly, or whatever else on your configuration.
Later I will try on a different PC, maybe there I'll be more lucky (or unlucky!) and I will replicate the problem.
One desperate attempt: could you try to Alt-tab or shorten the pause pressing the escape key to check whether this maneuver works?
See the attached screenshots that show the screen overtake.
It is quite strange that the EndScene log doesn't get preceded by a previous BeginScene: I checked the code, and both logs are present and under the same logging flag, so it seems that for some strange reason the rendering loop is not cycling correctly....
On a working scenario, the log is filled with repetitions of this sequence:
SetViewport(7): d3d=347000 d3dvp=18fd88
Flip: lpdds=345ae8(PRIM), src=0, flags=1(DDFLIP_WAIT)
Flip: dest=345ae8(PRIM) src=345b28 dwFlags=1000000(DDBLT_WAIT) destrect=(NULL) srcrect=(NULL)
BeginScene and EndScene should always work in couple.
Can you tell whether the loop continues forever while the game is frozen? This is not easy to tell without a timestamped trace, but you could notice the growing size of the logfile in the meanwhile....
The best thing to do, if you can, would be installing OllyDBG, run the game from OllyDBG while DxWnd is activated and notice whether the problem happens again, possibly noticing the exception fault (if happens). I'm posting here the debug version of the DxWnd.dll, that in case of exception should point to the bogus DxWnd line of code, provided that the problem is there....
The task is becoming tougher and tougher....
The game started on my second PC and with your EXACT configuration still works as a charm!
Chances are that when you took the OllyDBG snapshot, you were on the wrong thread (it happens to me most of the times): the picture shows a thread normally and safely waiting for events. You should try again and, when you stop OllyDBG, open the thread window (the azure button with a T inside, see picture) and select the main thread (the first one in the list, usually the one most likely to get into troubles) and see the new situation. Alternatively, look for a thread that shows an ERROR condition. I wish you a better luck....
The first shot (run.png) shows some interesting "insufficient buffer" errors that I neve saw on my pc, and the stack window shows traces of nested dxwnd calls, even if while running OllyDBG may show data not up to date.
The second screenshot (pause.png) unfortunately doesn't replicate the problem, and also if it did, the addressing is relative to your environment and would make little sense for me.
You should (using the debug dxwnd.dll I sent you) try to pause the game while the buffer errors are present and point to the highest dxwnd address in the stack (what would be in this case dxwnd.100CFA90), click on it, right click on the "Follow in disassembler" command and take note of the source filename and line that should appear just below the disassembler window.
This way, hopefully, we could get an idea of where the hell is the problem.
Even if dxwnd doesn't show, it could be interesting to see what are the topmost API called.
Another way to get even a better result is to use the wonderful apimonitor tool ( www.rohitab.com/apimonitor ) that is a little complicated to use (too complicated to write a full detailed instruction here) but should provide an accurate report of what's going wrong and who calls who! apimonitor traces can be exported, compressed and shared, so consider this option as well.
It's sort of frustrating.....
1) OllyDBG screenshot shows a kernel32 RaiseException call, called by who it's not clear. One possible track is the presence of a WCDToMBEx, that could come from a widechar to string conversion.... I'll check for anything may call this feature in DxWnd
2) apimonitor trace is a relatively small file, and when I try to display it I see no API traces. It almost seems that you activated the trace without specifying any of the API categories. You should set them all. Can you see the API traces on your pc? This tool also requires that I have a local copy of the very same exe file you used to do the trace capture.
3) apitrace trace is a very big file, and contains d3d7 methods only, so likely nothing related with this problem.
Can you add just a couple of simple and quick tests?
a) does the problem occour if the "Run in window" flag is unchecked?
b) does the problem occour if the "Hook enabled" flag is unchecked?
That is curious .... you say none of the tests passed the scene, but when the "hook enabled" flag is unchecked DxWnd is supposed to just skip all processing and leave the task untouched. But if you turn DxWnd off, the game works (isn't it?).
There must be something really weird: I'll try to find that out.
Thank you for your patience and all the information you're providing. I'll keep an eye on it later on when at home...
The post says that turning the second monitor off doesn't help. Did you check whether your video card is supporting a double monitor configuration, with the second one unplugged? Or if you have an integrated video chipset on the motherboard that wasn't disabled at BIOS? I suppose you did, but you never know...
DxWnd can provide sort of a synthetic video modes configuration, useful to run in window games at a very low resolution (sometimes unsupported), or at emulated color depths (like palettized 8BPP).
If you want to double-check this theory, you can try to change the "Screen resolution" field in the DxWnd "Video" configuration tab: by default, it provides synthetic SVGA resolution and colors, but if you pick "Monitor native modes" maybe Battle Realms could work no longer!
I'm happy we at last managed it.
I have NumSFXChannels set to 16 (!!), but when I tried to set it to 0 the game was no longer working, and the configuration was automatically set back to the original value. But I don't think I'm going to understand how or why....
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.