Return To Castle Wolfenstein Mac Os X
2021年10月30日Download here: http://gg.gg/wdetb
Return to Castle Wolfenstein, often abbreviated RtCW, is an entry in the Wolfenstein series released November 19, 2001. The game was published by Activision, developed by Gray Matter Studios and Nerve Software. Id Software oversaw the game’s development and was credited as the game’s executive producers.
*Return To Castle Wolfenstein Cnet
*Return To Castle Wolfenstein Mac Os X 10 11 Download Free
*Return To Castle Wolfenstein Mac Os X 10.7
*Return To Castle Wolfenstein Mac Os X El Capitan
As a side quest from my Quake III: Arena port using the id Tech 3 engine, I have ported Return to Castle Wolfenstein to iOS and tvOS for Apple TV.Return to Castle Wolfenstein for iOS and tvOS for Apple TV
https://github.com/tomkidd/RTCW-iOS
Back when I first looked into the possibility of doing an id Tech 3 port, I at first thought that I would need to do some sort of single player game using id Tech 3, like RTCW. When I was poking around on the Internet, I discovered that there’s a project called iortcw which is more or less a feature-parity copy of ioquake3 that’s designed to run RTCW. At some point after working with the Quake III port and getting the latest ioquake3 code in there I got the idea to basically make a copy of it, copy over the iortcw files to it, re-graft in the dwindling number of iOS-specific changes, and have it up and running in no time. And as usual, this was both easier and harder than I thought it would be. Of course it was.
*System requirements were not listed when MacCentral posted this article, but requirements for the original Return to Castle Wolfenstein called for a G3/500MHz or faster, Mac OS X v10.2.8 or later.
*Return to Castle Wolfenstein is 19 years old. RtCW developed by ID Software, published by Activision, was released to the North American market on November 19th, 2001. Release date(s): Microsoft Windows: NA - November 19, 2001 / EU: November 30, 2001 Linux: March 16, 2002 Mac: OS X April, 2002. Enjoy remaining RtCW time! Return to Castle.
*Warning: to let the game load successfully, you should patch the game to v1.40, then apply the unofficial v1.42d made by Knightmare in 2015.
*Wolfenstein: Enemy Territory is a free and open source multiplayer first-person shooter video game set during World War II. It was originally planned to be released as a commercial expansion pack to Return to Castle Wolfenstein and later as a standalone game.
There’s this concept of an “id Game” and up until a certain point it was straightforward: a game that id Software developed. At some point it got a little squishier. They briefly got into the publishing game, with the games Heretic, Hexen: Beyond Heretic and Hexen II being published by id Software (through GT Interactive), so those games had the id Software logo on them but they weren’t explicitly “id Games”, both because the label “a game by id Software” hadn’t been coined yet and also because id didn’t own the Heretic/Hexen IP. Return to Castle Wolfenstein was, as near as I can tell, the first “id Game” that they did not develop directly but was based on their IP. It was at this point that id and Activision had decided they had enough franchises that they could farm out some of them and have games released more often. By this point Carmack had revealed that they were working on a new DOOM game (which would go on to be DOOM 3) so having just come off a Quake game it made sense to do something with their other tentpole franchise.
Return to Castle Wolfenstein was titled like a sequel to either Wolfenstein 3-D or Castle Wolfenstein/Beyond Castle Wolfenstein (the Apple II games the IP was based on) but in reality it was essentially a remake/reboot of the original games. The single player portion was done by Gray Matter Interactive (later absorbed into Treyarch) and the multiplayer was done by Nerve Software. It came out in 2001 for Windows with a Mac OS X and Linux port releasing the following year. There were also ports to the (original) Xbox and PlayStation 2 with slightly different names and content. An expansion pack was planned but that’s a whole different story.
I believe the mod source code (so, the game rules code interpreted by the engine) was released but I’m not sure when. Probably shortly after the game’s release. The source code for the full game was released under the GPL in 2010, five years after Quake III‘s source.
Like I said I had discovered the iortcw project, which appeared to be a more or less feature parity copy of ioquake3 but with the differences required to run RTCW. The first thing that darts out is that there are two different copies of the code, one in a SP directory for single player and a second in a directory called MP for multiplayer. This is how id chose to distribute the original source, and the final game consists of two separate executables. To this day when you launch the game from Steam, you’re prompted with a choice as to whether or not you want to run single player or multiplayer, and when you’re in one executable, if you choose to play the other way (so, you launched the single player executable but you want to switch to multiplayer), the executable launches the other one and then exits.
There’s some logistical reasons for this – for one thing, separate teams did the single player and multiplayer portions of this game. Another advantage this has is that if the multiplayer game needs to have security and anti-cheating concerns that wouldn’t apply to the single player game, you can avoid needing to have that in the single player executable. But on top of all of that, RTCW posed a somewhat unique challenge: the use of nazi imagery.
In the game you’re fighting nazis and so it only makes sense that there be nazi imagery on the walls of, say, the prison/castle you’re escaping from initially. However, something that’s always plagued the series is when they want to sell the game in countries that outlaw nazi imagery – namely Germany. The original Wolfenstein 3-D game was banned for sale in Germany and actually caused certain laws regarding nazi imagery in video games to be created.
For RTCW, Activision wanted to sell the game internationally, including Germany, so they created a version of the game that omitted references to nazis directly and doesn’t feature the swastika, but rather a “double iron eagle” symbol which is reminiscent of Third Reich imagery without actually being Third Reich imagery. So American audiences got the nazi version and German audiences got the “wolves” version (their substitute name).
However one of the anti-cheating maneuvers the id Tech 3 engine had in place for Quake III was to institute the concept of a “pure” server. Namely: everyone has the same game files. They had run into issues with previous Quake games whereby people would replace models and textures within the game to make enemies easier to see and hit. Quake III‘s pure server concept ensured everyone was running the same files. However, this wasn’t compatible with the concept of a separate non-nazi version for Germany.
So the compromise was: the multiplayer executable loaded up its own, separate set of pak files, and everyone saw the “double iron eagle”/”wolves” version of the bad guys, and only the single player version would feature the nazi imagery in the regions that allowed it.
That’s a handy reasoning for why RTCW in particular used separate executables, but other id Software games since then have also done the same thing, including 2016’s DOOM. That game also had the multiplayer farmed out to a different developer so perhaps there was similar reasoning but I wonder if part of it is that id believes there are tech advantages to having the two split out. Even when you switch modes in DOOM on the Xbox One or the Switch, it’s really launching a separate executable, causing the whole screen to freeze up briefly.
So my plan was to make a copy of the Quake3-iOS structure, rename directories within it to reflect RTCW, and then start grafting. I made a directory called RTCW-SP and one called RTCW-SP-iOS, since this whole separation of concerns meant that my port, too, would need separate apps. I copied over all the files, then went through and did a diff of the base ioquake3 code with the Quake3-iOS code, and re-making those changes to the RTCW-SP-iOS code as well. This was actually pretty simple. And almost nothing else about this project was even remotely close to being as straightforward.
When I tried running it for the first time, it didn’t get far because it couldn’t load the .qvm files from the PAK files. Something I mentioned briefly in my Quake article was the “rules” code for these games gets compiled into it own separate file. This allows the game to load in the rules and game logic dynamically, the practical upshot of which is it allows for mods – they can release the mod source code and people can make their own mods to load in the game.
With the original Quake, since its original shipping platform was MS-DOS, they had to roll their own dynamic library concept. The result was the QuakeC programming language (sort of a syntactical subset of C) and the compiler that could turn it into a file called progs.dat. A big advantage to this approach is that whenever Quake would get official ports to the Macintosh, Linux and, of all things, the Amiga, the progs.dat file could come along for the ride because it wasn’t compiled for any specific architecture. When Quake II was being developed, since the initial platform was Windows, id just used .dll files, since Windows already had its own official dynamic library concept. The problem with this though was that it limited cross platform functionality. Since by this time the thought process was to concentrate on Windows this wasn’t seen as a huge deal but it did mean that the Macintosh port of Quake II wouldn’t come out until 1999, the same year as Quake III, and it wouldn’t be compatible with .dll-based mods.
For Quake III: Arena they decided to try a hybrid approach – it shipped more or less simultaneously for Windows, Macintosh and Linux and you could compile your mod into either a platform-specific dynamic library concept (so, .dll for Windows, .dylib for Macintosh, .so for Linux) or you could compile it into a .qvm file, which was a virtual machine concept similar to the progs.dat file on the original Quake. I seem to recall the logic at the time was that if your mod had some sort of need for an operating system hook (like maybe a server-side mod writing out live results to a database or webpage) then go with the appropriate platform-specific library, otherwise go with a .qvm file. Also for Quake III, they split the data into three different libraries – one for the server-side game, one for the client-side game, and one for the user interface. Conceivably an ambitious mod might need all three.
And it case it’s not obvious yet, this is one of the big reasons why I’ve done Quake and Quake III but not Quake II yet since the progs.dat and .qvm files come along for the ride on iOS just like progs.dat came along for the ride for the Amiga, so this is one less thing to worry about. I assume once I get back to Quake II for iOS I’ll need to investigate what the deal is with iOS and .dylibs.
So the first thing I did was look in the pk3 files for RTCW (which are really just zip files) and see what the name of the .qvm file is why it’s not finding it. And as it turns out it’s not finding it because it’s not there. The pk3 file had .dll files for Windows since I got them out of a Windows-based installation (since Windows is the only platform with digital releases of RTCW – the Macintosh version has the same issue as all pre-Intel games and the Linux version is out of Bethesda/Zenimax’s wheelhouse) but no .qvm files. Curious, I went and looked at the pk3 files for Quake III and sure enough they had .qvm files and no platform-specific anything.
OK, so I just need to make .qvm files. No big deal, right? After some Makefile tweaking with the scripts the iortcw project includes, I had the Mac compiling the LCC compiler from source and then using it to compile the .qvm files. Once I did this, at the end of just one day of working with it, I had RTCW up and running on the iPad. The menu showed up and the opening cinematics played and everything.
However I couldn’t start a game yet because the kludgey, never quite worked right menu pointer logic from my Quake 3 port didn’t let me get the mouse cursor to where it needed to be. With some tweaking I was able to at least get it to go down there (recall that the gig was that the code is designed for relative mouse movements, not absolute positioning), I started a game. Whereupon it crashed.
When you get an error message in a game or application, the first thing to do naturally is to figure out what’s causing the error message by searching for it. The error message was about failing to find a model file, so I searched for the message and found a few different contenders, so I modified the messages by prepending “e1!”, “e2!”, etc. so I could see where it was coming from. But when I saw the error next time, I didn’t see my prepended characters. It was at this point I realized some of the error messages I was modifying were in source code associated with .qvm files, so not files that would be compiled by Xcode and pushed to the phone. I had to go in and re-build the .qvm files. And I had to change the prepended messages to things like “g1!”, “c2!” so that I’d know what library is dying.
It was the client-side .qvm file. I drilled in to see where the issue was coming from and found that it was from some code that existed in the RTCW code but not in Quake III code, so the easy angle to see why it worked in one but not the other was gone. The method that was failing was being passed in a string, whereby every other method was being passed in integers. I could trace it to the very instant a string would disappear.
On a whim I searched for the enum case that was associated with it and I came across this page from a project called Spearmint, a project from an ioquake3 and iortcw contributor named Zack Middleton (zturtleman). It describes the code as “not QVM friendly”, which would explain why it’s not working.
So then I tried to investigate .dylib files again. I had started to look into this with Quake II before I caught wind of the Beben III project and started going down the id Tech 3 rabbit hole instead. When you fire off the Makefile for iortcw on a Mac, it makes Mac-specific .dylib files of the three libraries and that’s how you’re able to run it on the Mac.
The problem with .dylib files on iOS is that up until a certain point they weren’t supported at all only Static libraries, and while I’m seeing reports that they’ve been supported as of iOS 8, I can’t seem to find any concrete evidence that apps using them can be used or sold on the iOS App Store, a concern supported by the idea that Xcode doesn’t list them as an option when you want to create a new target for iOS. The big concern has always been that they want to avoid the situation where you could conceivably deliver different or updated .dylib files over the Internet to your app, meaning some of the app’s executable code has changed but you didn’t go through the App Store approval process. Static libraries have to be set at compile time so they don’t have this problem, in theory. But if the .dylib files are loaded through the Resources directory (which is read-only as far as the app is concerned) then it shouldn’t be a problem but I can’t seem to get a definitive answer for it online. Not that I’m looking to put these ports on the App Store – I don’t have the rights to the games themselves so that’s a no-go – but I also would like to not have an issue that could impede someone else in the future. Like if I ported Quake II and Brendon Chung wanted to use it to put Gravity Bone on the App Store, stuff like that.
I stewed on this for a while not sure what would be the best course of action – to either dig in and fix the issue with the .qvm file, or to use .dylib. The thing that gave me pause about the .dylib I mentioned above but the thing that gave me pause on the .qvm thing, besides just having very little knowledge on the nature of the issue, was the thought that: the RTCW source code has been out since 2010, eight years ago. A bunch of people have fooled with it since then, including a very well done ioquake3 port/merge. If this was a simple problem to fix, wouldn’t it have been done so by now?
So I went down the road of the .dylib file. I knew there might be an issue with using them in potential future App Store projects, but I figured that was a “cross that bridge” sort of situation for later. You can’t make an iOS .dylib in Xcode, but you can make a macOS one and then change its target architectures to the standard ones for iOS, so I did that. After going down the road of figuring out what the process was for naming the files to be picked up by the engine was, I had the three .dylibs going, and the UI one worked well enough because otherwise I woudn’t even get to the menu.
And then I launched the game and it died. Again. It actually worked fine in the simulator, where I could very slowly load up the cutscene level at the beginning of the game, but on an actual iOS device it died. I did some tracing of values and it looks like the values were being passed in incorrectly on an actual device but correctly in the simulator. Since the Simulator was effectively an x86_64 processor situation and iOS devices are arm64 processors, I figured something about architectures had something to do with it.
So I started to brace for the process of having to go in and figure that out but on a lark I emailed zturtleman and asked if he had any ideas since it was his project’s wiki that I found the information previously. I re-stated my premise that I figured if this was simple someone would have done it by now, so really I figured if I got a response at all it would be to explain why it was impossible to fix the QVM issue.Return To Castle Wolfenstein Cnet
And then he not only responded to my email but he fixed it, too.
He didn’t fix the underlying issue itself because it turns out there is a fundamental reason it doesn’t work, but he was aware of what this and a few other methods were trying to do and added fallbacks for them. The gist is that these VMs talking to each other can’t actually send data like strings, they can only send integers, either in the form of numbers themselves or in the form of memory offsets (basically the number represents the offset) which act as pointers. Passing strings can be fixed by copying it into the qvm VM’s memory. However in the particular method that was failing the cgame VM was trying to get the memory address of a data structure in the game VM which seems to work OK on a native library like the .dlls Windows uses but fails with qvm VMs because of how they use memory differently. The apparent reason this was happening was to save memory –
https://diarynote-jp.indered.space
Return to Castle Wolfenstein, often abbreviated RtCW, is an entry in the Wolfenstein series released November 19, 2001. The game was published by Activision, developed by Gray Matter Studios and Nerve Software. Id Software oversaw the game’s development and was credited as the game’s executive producers.
*Return To Castle Wolfenstein Cnet
*Return To Castle Wolfenstein Mac Os X 10 11 Download Free
*Return To Castle Wolfenstein Mac Os X 10.7
*Return To Castle Wolfenstein Mac Os X El Capitan
As a side quest from my Quake III: Arena port using the id Tech 3 engine, I have ported Return to Castle Wolfenstein to iOS and tvOS for Apple TV.Return to Castle Wolfenstein for iOS and tvOS for Apple TV
https://github.com/tomkidd/RTCW-iOS
Back when I first looked into the possibility of doing an id Tech 3 port, I at first thought that I would need to do some sort of single player game using id Tech 3, like RTCW. When I was poking around on the Internet, I discovered that there’s a project called iortcw which is more or less a feature-parity copy of ioquake3 that’s designed to run RTCW. At some point after working with the Quake III port and getting the latest ioquake3 code in there I got the idea to basically make a copy of it, copy over the iortcw files to it, re-graft in the dwindling number of iOS-specific changes, and have it up and running in no time. And as usual, this was both easier and harder than I thought it would be. Of course it was.
*System requirements were not listed when MacCentral posted this article, but requirements for the original Return to Castle Wolfenstein called for a G3/500MHz or faster, Mac OS X v10.2.8 or later.
*Return to Castle Wolfenstein is 19 years old. RtCW developed by ID Software, published by Activision, was released to the North American market on November 19th, 2001. Release date(s): Microsoft Windows: NA - November 19, 2001 / EU: November 30, 2001 Linux: March 16, 2002 Mac: OS X April, 2002. Enjoy remaining RtCW time! Return to Castle.
*Warning: to let the game load successfully, you should patch the game to v1.40, then apply the unofficial v1.42d made by Knightmare in 2015.
*Wolfenstein: Enemy Territory is a free and open source multiplayer first-person shooter video game set during World War II. It was originally planned to be released as a commercial expansion pack to Return to Castle Wolfenstein and later as a standalone game.
There’s this concept of an “id Game” and up until a certain point it was straightforward: a game that id Software developed. At some point it got a little squishier. They briefly got into the publishing game, with the games Heretic, Hexen: Beyond Heretic and Hexen II being published by id Software (through GT Interactive), so those games had the id Software logo on them but they weren’t explicitly “id Games”, both because the label “a game by id Software” hadn’t been coined yet and also because id didn’t own the Heretic/Hexen IP. Return to Castle Wolfenstein was, as near as I can tell, the first “id Game” that they did not develop directly but was based on their IP. It was at this point that id and Activision had decided they had enough franchises that they could farm out some of them and have games released more often. By this point Carmack had revealed that they were working on a new DOOM game (which would go on to be DOOM 3) so having just come off a Quake game it made sense to do something with their other tentpole franchise.
Return to Castle Wolfenstein was titled like a sequel to either Wolfenstein 3-D or Castle Wolfenstein/Beyond Castle Wolfenstein (the Apple II games the IP was based on) but in reality it was essentially a remake/reboot of the original games. The single player portion was done by Gray Matter Interactive (later absorbed into Treyarch) and the multiplayer was done by Nerve Software. It came out in 2001 for Windows with a Mac OS X and Linux port releasing the following year. There were also ports to the (original) Xbox and PlayStation 2 with slightly different names and content. An expansion pack was planned but that’s a whole different story.
I believe the mod source code (so, the game rules code interpreted by the engine) was released but I’m not sure when. Probably shortly after the game’s release. The source code for the full game was released under the GPL in 2010, five years after Quake III‘s source.
Like I said I had discovered the iortcw project, which appeared to be a more or less feature parity copy of ioquake3 but with the differences required to run RTCW. The first thing that darts out is that there are two different copies of the code, one in a SP directory for single player and a second in a directory called MP for multiplayer. This is how id chose to distribute the original source, and the final game consists of two separate executables. To this day when you launch the game from Steam, you’re prompted with a choice as to whether or not you want to run single player or multiplayer, and when you’re in one executable, if you choose to play the other way (so, you launched the single player executable but you want to switch to multiplayer), the executable launches the other one and then exits.
There’s some logistical reasons for this – for one thing, separate teams did the single player and multiplayer portions of this game. Another advantage this has is that if the multiplayer game needs to have security and anti-cheating concerns that wouldn’t apply to the single player game, you can avoid needing to have that in the single player executable. But on top of all of that, RTCW posed a somewhat unique challenge: the use of nazi imagery.
In the game you’re fighting nazis and so it only makes sense that there be nazi imagery on the walls of, say, the prison/castle you’re escaping from initially. However, something that’s always plagued the series is when they want to sell the game in countries that outlaw nazi imagery – namely Germany. The original Wolfenstein 3-D game was banned for sale in Germany and actually caused certain laws regarding nazi imagery in video games to be created.
For RTCW, Activision wanted to sell the game internationally, including Germany, so they created a version of the game that omitted references to nazis directly and doesn’t feature the swastika, but rather a “double iron eagle” symbol which is reminiscent of Third Reich imagery without actually being Third Reich imagery. So American audiences got the nazi version and German audiences got the “wolves” version (their substitute name).
However one of the anti-cheating maneuvers the id Tech 3 engine had in place for Quake III was to institute the concept of a “pure” server. Namely: everyone has the same game files. They had run into issues with previous Quake games whereby people would replace models and textures within the game to make enemies easier to see and hit. Quake III‘s pure server concept ensured everyone was running the same files. However, this wasn’t compatible with the concept of a separate non-nazi version for Germany.
So the compromise was: the multiplayer executable loaded up its own, separate set of pak files, and everyone saw the “double iron eagle”/”wolves” version of the bad guys, and only the single player version would feature the nazi imagery in the regions that allowed it.
That’s a handy reasoning for why RTCW in particular used separate executables, but other id Software games since then have also done the same thing, including 2016’s DOOM. That game also had the multiplayer farmed out to a different developer so perhaps there was similar reasoning but I wonder if part of it is that id believes there are tech advantages to having the two split out. Even when you switch modes in DOOM on the Xbox One or the Switch, it’s really launching a separate executable, causing the whole screen to freeze up briefly.
So my plan was to make a copy of the Quake3-iOS structure, rename directories within it to reflect RTCW, and then start grafting. I made a directory called RTCW-SP and one called RTCW-SP-iOS, since this whole separation of concerns meant that my port, too, would need separate apps. I copied over all the files, then went through and did a diff of the base ioquake3 code with the Quake3-iOS code, and re-making those changes to the RTCW-SP-iOS code as well. This was actually pretty simple. And almost nothing else about this project was even remotely close to being as straightforward.
When I tried running it for the first time, it didn’t get far because it couldn’t load the .qvm files from the PAK files. Something I mentioned briefly in my Quake article was the “rules” code for these games gets compiled into it own separate file. This allows the game to load in the rules and game logic dynamically, the practical upshot of which is it allows for mods – they can release the mod source code and people can make their own mods to load in the game.
With the original Quake, since its original shipping platform was MS-DOS, they had to roll their own dynamic library concept. The result was the QuakeC programming language (sort of a syntactical subset of C) and the compiler that could turn it into a file called progs.dat. A big advantage to this approach is that whenever Quake would get official ports to the Macintosh, Linux and, of all things, the Amiga, the progs.dat file could come along for the ride because it wasn’t compiled for any specific architecture. When Quake II was being developed, since the initial platform was Windows, id just used .dll files, since Windows already had its own official dynamic library concept. The problem with this though was that it limited cross platform functionality. Since by this time the thought process was to concentrate on Windows this wasn’t seen as a huge deal but it did mean that the Macintosh port of Quake II wouldn’t come out until 1999, the same year as Quake III, and it wouldn’t be compatible with .dll-based mods.
For Quake III: Arena they decided to try a hybrid approach – it shipped more or less simultaneously for Windows, Macintosh and Linux and you could compile your mod into either a platform-specific dynamic library concept (so, .dll for Windows, .dylib for Macintosh, .so for Linux) or you could compile it into a .qvm file, which was a virtual machine concept similar to the progs.dat file on the original Quake. I seem to recall the logic at the time was that if your mod had some sort of need for an operating system hook (like maybe a server-side mod writing out live results to a database or webpage) then go with the appropriate platform-specific library, otherwise go with a .qvm file. Also for Quake III, they split the data into three different libraries – one for the server-side game, one for the client-side game, and one for the user interface. Conceivably an ambitious mod might need all three.
And it case it’s not obvious yet, this is one of the big reasons why I’ve done Quake and Quake III but not Quake II yet since the progs.dat and .qvm files come along for the ride on iOS just like progs.dat came along for the ride for the Amiga, so this is one less thing to worry about. I assume once I get back to Quake II for iOS I’ll need to investigate what the deal is with iOS and .dylibs.
So the first thing I did was look in the pk3 files for RTCW (which are really just zip files) and see what the name of the .qvm file is why it’s not finding it. And as it turns out it’s not finding it because it’s not there. The pk3 file had .dll files for Windows since I got them out of a Windows-based installation (since Windows is the only platform with digital releases of RTCW – the Macintosh version has the same issue as all pre-Intel games and the Linux version is out of Bethesda/Zenimax’s wheelhouse) but no .qvm files. Curious, I went and looked at the pk3 files for Quake III and sure enough they had .qvm files and no platform-specific anything.
OK, so I just need to make .qvm files. No big deal, right? After some Makefile tweaking with the scripts the iortcw project includes, I had the Mac compiling the LCC compiler from source and then using it to compile the .qvm files. Once I did this, at the end of just one day of working with it, I had RTCW up and running on the iPad. The menu showed up and the opening cinematics played and everything.
However I couldn’t start a game yet because the kludgey, never quite worked right menu pointer logic from my Quake 3 port didn’t let me get the mouse cursor to where it needed to be. With some tweaking I was able to at least get it to go down there (recall that the gig was that the code is designed for relative mouse movements, not absolute positioning), I started a game. Whereupon it crashed.
When you get an error message in a game or application, the first thing to do naturally is to figure out what’s causing the error message by searching for it. The error message was about failing to find a model file, so I searched for the message and found a few different contenders, so I modified the messages by prepending “e1!”, “e2!”, etc. so I could see where it was coming from. But when I saw the error next time, I didn’t see my prepended characters. It was at this point I realized some of the error messages I was modifying were in source code associated with .qvm files, so not files that would be compiled by Xcode and pushed to the phone. I had to go in and re-build the .qvm files. And I had to change the prepended messages to things like “g1!”, “c2!” so that I’d know what library is dying.
It was the client-side .qvm file. I drilled in to see where the issue was coming from and found that it was from some code that existed in the RTCW code but not in Quake III code, so the easy angle to see why it worked in one but not the other was gone. The method that was failing was being passed in a string, whereby every other method was being passed in integers. I could trace it to the very instant a string would disappear.
On a whim I searched for the enum case that was associated with it and I came across this page from a project called Spearmint, a project from an ioquake3 and iortcw contributor named Zack Middleton (zturtleman). It describes the code as “not QVM friendly”, which would explain why it’s not working.
So then I tried to investigate .dylib files again. I had started to look into this with Quake II before I caught wind of the Beben III project and started going down the id Tech 3 rabbit hole instead. When you fire off the Makefile for iortcw on a Mac, it makes Mac-specific .dylib files of the three libraries and that’s how you’re able to run it on the Mac.
The problem with .dylib files on iOS is that up until a certain point they weren’t supported at all only Static libraries, and while I’m seeing reports that they’ve been supported as of iOS 8, I can’t seem to find any concrete evidence that apps using them can be used or sold on the iOS App Store, a concern supported by the idea that Xcode doesn’t list them as an option when you want to create a new target for iOS. The big concern has always been that they want to avoid the situation where you could conceivably deliver different or updated .dylib files over the Internet to your app, meaning some of the app’s executable code has changed but you didn’t go through the App Store approval process. Static libraries have to be set at compile time so they don’t have this problem, in theory. But if the .dylib files are loaded through the Resources directory (which is read-only as far as the app is concerned) then it shouldn’t be a problem but I can’t seem to get a definitive answer for it online. Not that I’m looking to put these ports on the App Store – I don’t have the rights to the games themselves so that’s a no-go – but I also would like to not have an issue that could impede someone else in the future. Like if I ported Quake II and Brendon Chung wanted to use it to put Gravity Bone on the App Store, stuff like that.
I stewed on this for a while not sure what would be the best course of action – to either dig in and fix the issue with the .qvm file, or to use .dylib. The thing that gave me pause about the .dylib I mentioned above but the thing that gave me pause on the .qvm thing, besides just having very little knowledge on the nature of the issue, was the thought that: the RTCW source code has been out since 2010, eight years ago. A bunch of people have fooled with it since then, including a very well done ioquake3 port/merge. If this was a simple problem to fix, wouldn’t it have been done so by now?
So I went down the road of the .dylib file. I knew there might be an issue with using them in potential future App Store projects, but I figured that was a “cross that bridge” sort of situation for later. You can’t make an iOS .dylib in Xcode, but you can make a macOS one and then change its target architectures to the standard ones for iOS, so I did that. After going down the road of figuring out what the process was for naming the files to be picked up by the engine was, I had the three .dylibs going, and the UI one worked well enough because otherwise I woudn’t even get to the menu.
And then I launched the game and it died. Again. It actually worked fine in the simulator, where I could very slowly load up the cutscene level at the beginning of the game, but on an actual iOS device it died. I did some tracing of values and it looks like the values were being passed in incorrectly on an actual device but correctly in the simulator. Since the Simulator was effectively an x86_64 processor situation and iOS devices are arm64 processors, I figured something about architectures had something to do with it.
So I started to brace for the process of having to go in and figure that out but on a lark I emailed zturtleman and asked if he had any ideas since it was his project’s wiki that I found the information previously. I re-stated my premise that I figured if this was simple someone would have done it by now, so really I figured if I got a response at all it would be to explain why it was impossible to fix the QVM issue.Return To Castle Wolfenstein Cnet
And then he not only responded to my email but he fixed it, too.
He didn’t fix the underlying issue itself because it turns out there is a fundamental reason it doesn’t work, but he was aware of what this and a few other methods were trying to do and added fallbacks for them. The gist is that these VMs talking to each other can’t actually send data like strings, they can only send integers, either in the form of numbers themselves or in the form of memory offsets (basically the number represents the offset) which act as pointers. Passing strings can be fixed by copying it into the qvm VM’s memory. However in the particular method that was failing the cgame VM was trying to get the memory address of a data structure in the game VM which seems to work OK on a native library like the .dlls Windows uses but fails with qvm VMs because of how they use memory differently. The apparent reason this was happening was to save memory –
https://diarynote-jp.indered.space
コメント