Community
SCI Programming => SCI Development Tools => Topic started by: Collector on September 19, 2011, 01:53:17 AM
-
In the Multiple text lines in one Print window thread (http://sciprogramming.com/community/index.php/topic,521.msg2897.html) gumby complained about having issues with running SCIV.EXE in Windows 7. I don't know if he has Win7 x64 or is having some issues with his NTVDM from Companion. Of course little 16-bit code will not run on x64 (thanks AMD) so the entire 16-bit subsystem and the NTVDM has been removed from x64 Windows. Even on 32-bit Windows, the NTVDM has some severe compatibility issues. For our games, we have been using DOSBox to solve these issues, but both Companion and Studio run the game's executable directly, so to use DOSBox requires you to leave your environment to do so.
Here is my first effort to get SCI Companion to run your project in DOSBox from its "Run" button. Run "DOSBoxRunSetup.exe" from your game's directory and Companion will use DOSBox to start your game. It should work for Studio as well. It comes with an uninstaller to cleanup your game of the utility before distributing it, so be sure you have a backup of DOSBoxRunSetup.exe before running Cleanup "Cleanup DOSBoxRun.exe".
-
Nice!
-
Yeah, I'm running Win 7 64 bit. Of course this isn't going to work, I should have known this - I haven't done any SCI development work since I got my new laptop a few months back.
So where is this installer that you've put together so I can give it a whirl? Or is it still in development?
-
It's right there attached to his post.
-
Sorry, attachments don't show when you are just looking at the 'Recent Posts' view. I will try this and report back.
-
Anybody try this yet? Any feed back or suggestions?
-
Yeah, I after finally putting the installer in the correct location (don't ask), This works perfectly. Very seamless, thank you!
I'm thinking back to another problem that we had with Companion, the game corruption issue when you run an instance of the game when it was already running. Would it be trivial to add this functionality into your executable as well?
-
The only game corruption issue I can recall is the one where you rebuild resources while the game is running. And that only happens in SCI Studio. Companion doesn't mess up the game files. Unless you're talking about another thing?
-
Actually the same thing does happen in Companion when you compile the game while it is running. The fix is easy enough for both editors though, so it's no real big deal. The problem comes from the compiler though trying to overwrite a file in use so I'm not real sure what can be done from the game end to resolve the issue... but it would be nice if something were in place.
* Wait my bad, not compiling, rebuilding... that is when the files in use are overwritten, or at least attempted to
-
I've tried compiling and rebuilding while already running the game numerous times over the past week and my game never got corrupted once.
-
Any kind of check and or fix would best be done from the editor side. I don't know what would happen if Companion or Studio encountered a locked file while trying to rebuild. Also, it seems like you would have to lock all resource files if the editors were not modified to set how to handle the first locked file.
-
Yeah, apparently I couldn't remember the exact issue, but here is Cloudee's how-to fix it, just for reference:
http://sciprogramming.com/community/index.php/topic,21.html
It is rebuilding that nukes everything, I suffer from it regularly when developing. I thought it had to do with having your game running twice, but it's the rebuild process that causes a problem when you have your game running, not having a game running twice.
Sorry for the noise.
-
Then how does it screw things up for you but not me?
-
New version. This will make the use of it more seamless. Unzip into Companion's "Template" folder, overwriting the GAME.INI file. When you create a new game from within Companion, it will copy the setup into your new game's folder and keep the original in the Template folder.
The first time that you hit the run button, the tool will run, allowing you select your DOSBox and settings, then launch the game. Every time you hit the run button thereafter, the game will start. If you want to change your DOSBox settings, run "Conf.exe" in your game's folder. When you are ready to distribute your game, run "Cleanup Game.exe" to remove the setup files.
-
Then how does it screw things up for you but not me?
I was until recently running XP Pro, and was plagued by this problem.
I just tested this (I apologize for not testing it before on my new setup!), and within Win 7 64 bit, I am unable to rebuild resources while a game is running - I get an error "An error occured (sic) while rebuilding resources: 80070020".
Well, that's a nice side-effect. But is it because of running the game through DosBox, or because I'm on a new OS? Either way, I'm pleased ;D.
-
Good question! Seems OS related.
-
Collector - are there switches for a silent install? I'm looking to install this from the command line.
-
I am not sure what you are trying to do. It is designed to be invoked by the run button from within the editor. On first run it does require some user input for DOSBox location, etc. From then on, it should simply run from the run button. An NSIS installer can be run silently, but it has to be compiled to do so. If you are looking for a solution for distribution of your game, a different tool would have to be designed.
-
I meant an unattended installation of your DosBoxRunSetup application, no GUI interaction. In my current development, I'll create a new game (via script) multiple times at a sitting; I was simply trying to eliminate a manual step.
-
There has to be some interaction. Without it, it would not be able find DOSBox. About the only thing that ends up in the registry from DOSBox is from the MRU cache or other things from usage (searches, opened in other programs, etc.) Even the official DOSBox installer does not track anything in the Registry. Without interaction the only way to automatically get the location of the user's DOSBox would be to do a file search on the whole system. Besides the time that that would take, if the user had more than one build of DOSBox on their system, the run utility would not know which one to use. A straight forward search would probably just take the first one it found and then quit.
That said, I suppose that it would be possible to do a new version that could refer to an ini or XML file or a registry entry to use some predetermined DOSBox. It could even include DOSBox in the same folder, but that would mean a separate DOSBox for each game. Perhaps just a separate script to be used in batch processing?
I wish my C++ skills were something more than nonexistant. I would love to take on Companion and/or Studio to update/modernize the interface. I would add some of the various tools and utilities, including seamlessly integrate the run utility and my other project.
-
But when I install it, I don't think I've ever have to specify the DosBox location (and certainly not recently). I just click through the 'Next' dialogs and I'm all set - that's why I was thinking that a 'silent install' would be practical.
EDIT: Yeah, you've supplied a default path to DosBox, which I adopted. I never have to use the 'override' checkbox to specify the location. Even if it needed to, I would think that the path could be a command-line option.
-
There is the mounting that has to added, too. Are you adding a GAME.INI for each game? If so the one line in it needs to be set to Executable=run.exe. The other thing would be to set the "mount c" of each dosbox.conf to the game's folder. If you can't figure out how to do this from your script, let me know and I'll see what I can come up with. I would need a little information on how you are scripting this. Are you using a Pearl Script? What all do you have the script doing? Besides the game scripts, what files does your script add to each game? Any other relevant information that I should to know to customize this for your script?
-
You are right, I can script this task out myself - I didn't mean for you to put so much more effort into this, I was just hoping that there was a really trivial way to do it with your installer.
I'll just modify the dosbox.conf, dosbox.ini, game.ini, game.bat appropriately. Shouldn't be a problem.
-
Hey Collector, why is it that when I open a game straight in dosbox vs using the dosboxrunsetup batch file, the screen resolution is different. The batch file seems to stretch the screen a little long. Any idea on a correct ratio to set in the .conf file. I've played around with it a bit, but can't seem to get it right.
-
Aspect ratio is enabled by default. This gives it the proper perspective. Remember that the shape of pixels has changed since the SCI0 days. The SCI engine stretches 400 pixels into the same aspect ratio (4:3) as later (S)VGA's 480 pixels. Aspect ratio will give you the perspective that the Sierra artists intended and should make full screen and windowed consistent. However, if you draw your VIEWs and PICs on modern hardware without taking this into account, your images will be taller than what Sierra would have drawn. If you want to squish the screen, set aspect= to false.