Any chance you can fix Birthright : Gorgon's alliance too? #13
Comments
|
Hi. Thanks for asking. Seems like a worthy game to fix. I'm busy with publishing my own game at the moment so no time in the near future unless I need a break. But, first, some questions. I assume you are running the Windows version so... What version of the game are you running? That is, what game patches did you install for it? Also, what version of Windows are you running on? And, why not run the DOS version in DOSBox instead? I don't know the game but people seem happy with that option. I think I know the answer to this but I would still like to hear your take on it. And, finally, does that error message show the exact same codes each time or are they different each time? |
|
Hey, thanks for replying. I had the latest patches installed, which seems to be 1.0.0.4 when i right click winbr.exe and check the details tab. I cant recall the exact reason but I think the dos version isnt as up to date or has some other drawback? I cant recall the exact code or if its the same...but the odds of that crash happening seems to be dramatically increased the longer you play. It never seems to crash if i restart the game then do an adventure right after, but is almost guaranteed to crash if i do multiple adventures without restarting the game or play multiple turns in realm mode without restarting the game. Hope your game works out OK by the way. |
|
Hey, thanks for finding your way back to 🌍. 😜 All I can tell right now is that the DOS version was up to 1.0.0.3, and the Win was up to 1.0.0.4 only because they decided to move it to DirectX 5 (fortunately). Thus, the only reason I see to fix the Win version is:
Given that it mostly runs, I will probably be able to fix it, so I'll add it to my todo list. But, given how niche this game is and the probable small number of fans of it unwilling to run it in DOSBox, I can't put a very high priority on it. I suspect it will also run fine in DxWnd, but that can be more messy than DOSBox. I already have at least two side projects besides my full-time game project, so no telling when I might get to it. In the mean time, if you play it more and are willing, start writing down the error addresses and report them here. It will help save on testing time. |
|
Doesnt the 0.4 version have more bug fixes than the 0.3 version at least? I will let you know if i can get the error message to happen again. |
|
I checked windows event viewer and it still has the error logs for the crashes : Faulting application name: WINBR.EXE, version: 1.0.0.4, time stamp: 0x348dd6ed Faulting application name: WINBR.EXE, version: 1.0.0.4, time stamp: 0x348dd6ed Faulting application name: WINBR.EXE, version: 1.0.0.4, time stamp: 0x348dd6ed The exception codes all seem to be the same but the rest differs slightly |
|
Awesome 😮 thank you! Other than the exception code, what I'm looking at most is: Fault offset: 0x0004da28 The more of those I get and the more I can see a pattern in them, the better. Thus, if you have more of those in your logs feel free to paste them all here (with or without the other text, whatever is easiest). The .4 version is most likely just Win fixes and not game fixes (a la DirectX 2 to 5). This was back in the day when serious gamers still preferred to play GPU-demanding games in DOS for performance reasons. The Win versions were mostly to drive sales. Thus, it is not likely they would have done any game fixes that weren't released for the DOS version -- and the DOS patches support that theory. Possible, yes, just not likely. |
|
FWIW, archive.org has what looks like the complete source code to the game (both Windows & DOS versions), with files dated 1997-12-19: https://archive.org/details/birthrt_source Definitely worth checking out even as a curiosity, although I haven't found any OBJ/MAP/PDB files in there that could help resolve the crashing addresses. |
|
Cool. I'll check it out. Thanks! Not the game I was hoping to find source code to but, hey, I might get tempted some day to rebuild it if enough people ask. (Still thinking about an open-source, hi-res version of Cyberstorm.) I spend most of my spare time these days writing new games hoping to find something to supplement my meager income. Currently working on Sendit Soccer on weekends, with GRITS Racing on the back burner. I would like to spend more time on classic games and platforms, but focus on income has to come first. |
|
Nice, good luck with your games! |
|
@minexew @juanitogan Im guessing that rebuilding the game even with the source code would be next to impossible? That you cant just run it through a compiler and have it work? And i dont suppose either of you knows if there is a way to open/modify the .dat files that the game uses? |
|
IMO it would mainly depend on how complete the source code leak is, especially with regards to 3rd-party libraries and middleware (even as pre-compiled binaries). Then you would just need to find the exact toolchain that they used, which I'm 99% sure was some version of Visual C++. |
|
@minexew is right on target there. Personally, I think it has a good possibility of turning out to be pretty straight forward, and I put it on my game-jam TODO list last year. That is, during game jams, I tend to work on side projects like this rather than jamming up a new game. I like to hang out with the jammers but typically see more value in advancing my own side games, or attempting hero (I mean: game-preservation) work like this. For example, next game jam I will likely add a feature to my River Raid Squadron game (which will also move it from v0.9 to v1.0 -- look it up on itch.io if you're into 80's games). After that, I may then tackle this rebuild. Depends. I remember digging into this a bit when I downloaded it and finding that it appeared complete and possibly the latest version. I believe, also, that I saw it was Watcom C/C++. Which, as far as I know, is what most games of the era were built with -- certainly the one's from Sierra and Dynamix. As far as libraries, etc, I haven't noticed much dependence on things outside the standard Watcom and Windows toolsets. Sometimes I see an MP3 dll and similar edge-tech stuff. Because Watcom saw support to the end of the 90's and then saw a few more years of support as an open-source product, I give it pretty good odds of being buildable as 32-bit Windows 7+ with a few days or a week of effort (while doing all the work in 64-bit Win10, hopefully). If that fails, I might drop down to WinXP and build it there -- which should still be good for running in Win10. But, building is one thing -- testing, packaging, and shipping is quite another. A lot of hours with little reward. For me, however, the likelihood of me actually doing this is measured against the fact that the DOS version is feature complete and runs fine in DOSBox. Thus, I have to look to other reasons such as: I like to avoid VMs and emus when possible; and maybe if I do this, and up the res, then maybe someone else will start throwing better textures into it, and maybe see continuous mods like DOOM gets. Can't help you with the DAT files but you can often find such tools and guides for the same or similar games if you dig deep enough. One is a text file and the other two appear to be a fairly simple format such as a regular C data file -- but, no idea what any of the numeric fields are for -- best bet on those fields is to dig through the code for comments on them (which is 100x better than trial-and-error that we usually have to resort to). |
|
@juanitogan : You wouldnt need to build it to get it to work on windows since the windows version runs on win10 anyway. I was thinking more along the lines of being able to modify the source code to change things like unit stats as such, it would add a ton more replayability to the game. Unless theres a better way to do that? I couldnt find any tools to unpack or modify old sierra DAT files...i found a tool to unpack DAT files for Arcanum, but it doesnt work for Birthright DAT files. Not sure how you would dig through the code. I cant even open the DAT files...they just show up as gibberish in notepad++. What are you using to open them? In regards to the original crashing issue, oddly enough, on my latest install of win10, i havent been able to get the game to crash in adventures anymore. Not sure why...i do have environment sounds turned off, not sure if that makes a difference. |
|
Turning off the env sounds could very very likely make a difference (crashes due to audio is what started this project) and useful intel to have. Same with new Windows installs and/or different machines. I can't help you with DAT files any more than what I've already said. That rabbit hole is entirely up to you. If you don't already know how to decode various data types in binary files, you should probably let it go. |
|
Lets say i wanted to try compiling the source code. What propgram/settings do i need to do that? Any ideas? Ive never used a c++ compiler before. Theres a make.log in the source code that says "WATCOM Make Version 10.6". |
|
Spoke too soon, i just got it to crash during an adventure again. Faulting application name: WINBR.EXE, version: 1.0.0.4, time stamp: 0x348dd6ed The only thing i did differently this time was to bring a second party member to help carry items. I wonder if carrying too many items in the party during an adventure might cause the crash... |
|
@juanitogan : Just wondering if any progress was made on this? Tried using the large address aware fix on WINBR.exe but sadly that didnt make a difference... |
|
A big NOPE on that one. But... I don't mind you asking either. 😁 It reminds me what is important to people. I did manage to one-up River Raid Squadron during the last game jam, so, who knows?, with that out of the way, maybe this during the next one. To be honest, I had completely forgotten about the source code release on this, and that tinkering with the source was on my todo list. My life turned extra crazy lately and, thus, I can't guess if I might actually game jam this one of these years or not (I only do 2 game jams a year). Too many todo items right now to think straight, and this one is not very high on that list. Anyhow, if you want to keep poking at WINBR.EXE from the outside, you might try what I suggested up top and give DxWnd or DxWrapper a try. My links to such tools are here: https://github.com/juanitogan/rbxit#other-things-for-beating-games-into-shape Anyhow DxWnd (and, thus, DxWrapper as well) offers better exception handling for old games and that may be the only feature you need from those tools. Just a guess though. And, hard to test it for sure if you can't predictably crash the game. |
|
@juanitogan : Im looking at the dxwrapper thing and im confused as to how it works. The documentation seems to be missing a lot of information. First of all, how do you tell that its actually working? That the game is using dxwrapper? Secondly, how do you actually tell which file .dll file you are supposed to put into the game folder? The documentation doesnt give any actual advice here. And how are you supposed to setup the config file? I have no idea what i should be using. Can you turn on more than one compatability mode? Im not even sure if this project is still being supported, because there are a lot of issues on the github with no replies at all... |
|
@juanitogan : I tried using dxwrapper and there was some improvement, while i still got the exception error in adventures, the game didnt crash straight away. But the graphics of all the character models became corrupted :
I kept getting more exception errors as i tried to keep playing, and after the 3rd such error, the game kept freezing up every few seconds and it became impossible to keep playing. The log file says :
Any suggestions on .ini settings? I have no idea what i should be using and the documentation just says what they do, but not what you should be using. `[General] [Plugins] [Compatibility] [DDrawCompat] [ddraw] [Dd7to9] [d3d9] [FullScreen] [dinput8] [dsound] |
|
Yeah, to quote myself from up top: "I suspect it will also run fine in DxWnd, but that can be more messy than DOSBox." As I recall DxWnd has one of the most unhelpful GUIs ever. Something only the creator geek could love. And, yet, I called it easier than to use than MS's similar tools for some reason. I dont' recall ever messing with DxWrapper but, if time, I might go into my old folders and poke around to see. It appears they have plenty of help in their Wiki so I doubt I would have anything to add. Thus, the fact that DxWrapper appears to use an INI file rather than a GUI, sounds easier to me than DxWnd in many ways. Regardless, don't throw too much at it at once. One thing at a time, generally. My earliest guess was that all you may need from DxWnd is You might even want to forget DxWrapper for now and just test DxWnd, even though it is old. Anyhow, if I find time or get bored, I might pull up the tools and share some screenshots/ini settings. |
It runs first except for one problem : the game will randomly crash with a "the memory could not be read from" error during adventures, and since you can't save during adventures, that can result in a lot of progress wasted.
The text was updated successfully, but these errors were encountered: