Community
General and Everything Else => The Games and other Sierra Adventure stuff => Topic started by: gumby on May 13, 2011, 06:59:38 PM
-
I think I've found a simple solution on how this can be accomplished. Today I discovered the JPC project over at SourceForge. It is capable of launching a pre-configured VM (FreeDos) and then one of our games - delivered through a java applet to a browser. The only prerequisite is the client machine needs to have a JRE installed. If I can grab some time I'll see if I can get this tested out this weekend.
Here is the project page if anyone is interested taking a look. They've got a version of Doom you can play in your browser - exactly the configuration that I've described above. Doom was laggy for me, but the requirements for our games are much lower.
http://jpc.sourceforge.net/home_home.html
-
RGB Classic Games (http://www.classicdosgames.com/about.html) was using JPC, but it was too slow and had other issues. They have since replaced it with a Java port of DOSBox "to make DOS games playable in your browser! Speed and compatibility are almost perfect in every game." No lag in Doom. You still need the Java runtime installed, but who does not already have it installed, these days?
-
I just tried out jDosBox. Works much better. Thanks - you just saved me a few hours of tinkering, no doubt.
-
Some fanmade AGI games have memory issues with the original interpreter, and got to be run through Nagi. Nagi doesn't run in Dosbox, though. So... will this allow us AGI folks to play those games?
Also, how do savegames work with that setup?
-
Some fanmade AGI games have memory issues with the original interpreter, and got to be run through Nagi. Nagi doesn't run in Dosbox, though. So... will this allow us AGI folks to play those games?
I don't have any experience with Nagi. What are it's requirements to run? I looks like it runs in a windowed environment - probably requires the MFC classes or something. I guess we'd have to dream up another solution for the games that won't run under the original interpreter.
Also, how do savegames work with that setup?
Right off the top of my head, this may or may not be an issue. I was thinking in terms of 'immediate accessibility' or the 'try-then-buy' sort of approach, like what you had posed in the 'agigames.com' thread. If they like playing the game, they'll download it?
That said, we could attempt to create a complete packaged solution where the games could be played online (hosted in a browser) & offline (downloaded jar and run in console). I'm sure there are some security issues to address when it comes to writing to local disk from a browser and I'm not sure if an applet can do that or not (perhaps if it's signed?). For that matter, we'd be saving games to a VM, which would have to be saved to the local disk. Lot's of questions here.
I've got some research to do.
-
Nagi does run under Windows, but uses SDL. I don't even know if it's usable in Java (although Dosbox does use it as well). In the worst-case scenario, we'd have to ask Nick to port it.
The question 'bout the savegames is exactly for that reason: Can we use it for try-before-you-download idea, or would it fit the in the cloud idea? Either one's useful, but it'd be good to know which one's possible.
-
There is a Java AGI interpreter project, but it seems to be abandoned. http://sourceforge.net/projects/agi/ Whether these flawed games would run in it or not is another matter.
Save games can be written with the Java DOSBox, but are not stored locally, so are not available when you reload the page. I don't know if there is someway to alter this behavior or not. The Java DOSBox project can be found here: https://sourceforge.net/projects/jdosbox/ and the development thread on VOGONS is here: http://vogons.zetafleet.com/viewtopic.php?t=27467
You could also contact RGB Classic Games to ask about their browser implementation.
-
I spent a good amount of today playing with jDosBox. I've got it working within a website in both ways that we have been discussing. The on-line play simply launches the JVM & mounts the disk image from the hosting site in-memory. The off-line play downloads the disk image to the client computer, extracts it & launches it locally. The major distinction between these two methods is that the offline play allows for save games & you can restore (even after blowing out all of your cookies, etc) because the disk image is stored within the user's profile. I'd propose that this is the way to go. The only downside (and it's pretty small) is that the jDosBox jar file needs to be signed - not a big deal at all.
I've figured out how to create disk images for each game (that was fun - haven't played with VM's or emulation in a while). Setting up an applet for a webpage was really easy. I'm ready to go to town & convert all the fan games into disk images.
Raf - do you know of a couple of games that don't work with the original interpreter so we can test them against other implementations?
-
This is all very fascinating, you mean theoretically all we need is an applet that loads jdosbox, and our games and we're good to go online as is minus saved games, at least as far as sci goes
-
Yeah, it's super-easy. The applet consists of nothing but a couple of lines of html.
I should clarify. Save games are a go. Our implementation of the applet just needs to use the code that sends the game image file down to the client. It's all 'online' from the point of view of the user.
EDIT: I shouldn't have used the 'on-line' and 'off-line' phrases in any of this. It's confusing, and a subtle distinction. Everything is run through the browser, it's all a matter of where the resources are when you run the game.
-
Probably need more bandwidth than what this site often has. RGB Classic Games usually has fairly decent bandwidth and there can still be a bit of a lag loading.
I linked to the Java AGI interpreter project above, but I have not explored it. It may not be in a usable state. If Lance could take a look at it, he could determine how close it is to be usable. NAGI seems to be about the best of the AGI interpreters. I don't know how much work it would be to port it to Java.
Just found out that Sarien.net is open source. It could be one solution for the AGI games. http://sarien.net/source
-
Raf - do you know of a couple of games that don't work with the original interpreter so we can test them against other implementations?
Enclosure (if I'm not mistaken), Klownstein's Hobbits (100% sure) and Ninja Forever (100%, but it's not released yet)
-
Probably need more bandwidth than what this site often has. RGB Classic Games usually has fairly decent bandwidth and there can still be a bit of a lag loading.
I linked to the Java AGI interpreter project above, but I have not explored it. It may not be in a usable state. If Lance could take a look at it, he could determine how close it is to be usable. NAGI seems to be about the best of the AGI interpreters. I don't know how much work it would be to port it to Java.
Just found out that Sarien.net is open source. It could be one solution for the AGI games. http://sarien.net/source
If you recall from a few months ago, we were discussing what the best fan made AGI games were in case Martin Kool was unable to continue sarien.net with Sierra's games. But then he sorted things out with Activision and was able to continue with some of the originals. So I think that it would be left to us now to attempt to convert the games into the sarien.net format.
A Java DOSBOX applet would obviously work with the original formats and would in theory require less work. On the other hand, sarien.net does not require a Java plugin. It works with what a browser has by default. So sarien.net does seem nice from that point of view, but I've got no idea how much work it would take to convert the games. I'm guessing it might not be straight forward. I would be keen to hear back on anyone who has tried converting a fanmade game and what issues they encountered. I recall that Martin didn't just launch all the games at once. I seem to recall that he kept advertising games that were in the pipeline, which suggests to me that there was a conversion process that wasn't 100%. I can ask him and see what he says about that.
The Java DOSBOX approach sounds very interesting though.
Anyone keen to write a Flash AGI interpreter?
-
Enclosure (if I'm not mistaken), Klownstein's Hobbits (100% sure) and Ninja Forever (100%, but it's not released yet)
Yep, Hobbits bombs nicely with the original interpreter - memory problem immediately.
If you recall from a few months ago, we were discussing what the best fan made AGI games were in case Martin Kool was unable to continue sarien.net with Sierra's games. But then he sorted things out with Activision and was able to continue with some of the originals. So I think that it would be left to us now to attempt to convert the games into the sarien.net format.
A Java DOSBOX applet would obviously work with the original formats and would in theory require less work. On the other hand, sarien.net does not require a Java plugin. It works with what a browser has by default. So sarien.net does seem nice from that point of view, but I've got no idea how much work it would take to convert the games. I'm guessing it might not be straight forward. I would be keen to hear back on anyone who has tried converting a fanmade game and what issues they encountered. I recall that Martin didn't just launch all the games at once. I seem to recall that he kept advertising games that were in the pipeline, which suggests to me that there was a conversion process that wasn't 100%. I can ask him and see what he says about that.
I agree with you Lance - further investigation of the sarien.net code is needed & hopefully it's a more complete solution than the jDosBox solution from the AGI standpoint. I doubt that the process is trivial to convert the games, but maybe it was the multi-player aspect that required additional work.
Unless anyone has any objections, I think I'll plow ahead with the jDosBox approach, create disk images of all the games (shouldn't take too long), figure out which AGI games don't work & then dive into the sarien.net solution.
-
Anyone keen to write a Flash AGI interpreter?
Could this be done to use existing unmodified game logic?
-
You know, it just struck me, scummvm wanted in on the agi/ sci development this is right up their alley, what kind of in browser options might they be capable of. Or could be compelled to explore.
-
Okay, SCI games are done & tested. I've downloaded the AGI archive & am working through those now.
I have noticed that (at least on my machine) after trying to run about 5 games or so, jDosBox stops working completely - all you get is a black screen, no indication of anything going on. Requires closing the browser completely in order for games to start working again. Not a big deal, but annoying while testing. Happened both on Firefox & Chrome - haven't tried IE yet.
-
You know, it just struck me, scummvm wanted in on the agi/ sci development this is right up their alley, what kind of in browser options might they be capable of. Or could be compelled to explore.
I see two reasons to not count on this. First, they are so paranoid of being associated with piracy that they would not like to develop anything that could be used for pirated games, even though there are plenty of shareware, freeware, demos and fan games that the project supports. Second, there have been threads on the ScummVM site about Java ports of ScummVM and in browser play with Sarien, the engine that was incorporate to add AGI support. The general consensus of the ScummVM devs is that they have no interest in a Java port nor in browser compatibility. Of course they also add the usual dismissive line of "if you want it, do it yourself, the code is open source." If someone were to work on a Java port from scratch to play AGI, I would say start with NAGI or pick up the afore mentioned Java AGI interpreter.
I have noticed that (at least on my machine) after trying to run about 5 games or so, jDosBox stops working completely - all you get is a black screen, no indication of anything going on. Requires closing the browser completely in order for games to start working again. Not a big deal, but annoying while testing. Happened both on Firefox & Chrome - haven't tried IE yet.
Have you checked if the problem exists on RGB Classic Games, too? Perhaps their code has something to unload the Java VM on close so that each new instance "respawns" it as if for the first time. You can also see if killing the FF "Plugin Container" process works. I don't know if there is a script that could be embedded into the page to close the container before launching the jDOSBox. Of course the drawback with this is that it would only work with Firefox and it would kill any other plugin that might be running at the same time, such as if someone had another browser open, streaming media with flash in the background. The real solution needs to be cross browser compatible and not have collateral consequences.
-
Yeah collector I know, that was my passive aggressive jab at them. While Raf and Patrick are working away at agi world, I plan for now to leave that implementation up to them. The sci games however I'm going to look into. Gumby could you pm me the sample code you used. Haven't had a chance online to check it out myself.
-
Have you checked if the problem exists on RGB Classic Games, too? Perhaps their code has something to unload the Java VM on close so that each new instance "respawns" it as if for the first time. You can also see if killing the FF "Plugin Container" process works. I don't know if there is a script that could be embedded into the page to close the container before launching the jDOSBox. Of course the drawback with this is that it would only work with Firefox and it would kill any other plugin that might be running at the same time, such as if someone had another browser open, streaming media with flash in the background. The real solution needs to be cross browser compatible and not have collateral consequences.
I sure didn't see anything in the source of the pages on RGB's that killed the plugin. During my testing, I was using the browser back button, which I'm sure aggravated things (without ever setting focus on the game, keep reading). Quite frequently, I couldn't get the games to close 'normally' - probably because I was impatient & wanted to move on to the next one. However, even when they did close, DosBox did not. So the user was left with a dos prompt and no way to kill the plugin from there either (the 'exit' command does not appear to be implemented). Oh, and you can't switch focus out of the dosbox environment - the mouse cursor is stuck within the dosbox window so you can't even navigate away from the page. You have to do it within the OS - switch applications entirely.
Anyone have ideas on how to kill off the plugin?
-
Don't forget that part of the script could be server side, meaning that you would never see the script on the client side. Are their pages either PHP or ASP of just straight HTML?
Another thought. Have you tried the DOSBox exit command? I always add it at the end of my autoexec section so that DOSBox closes after the game exits, i.e.:
[autoexec]
cls
@ECHO OFF
mount c "C:\Sierra\Conquests of Camelot"
c:
cd \
SCIV.EXE
exit
-
Their pages appear to be straight HTML. Interestingly enough, I played a mouse based game and was able to freely scroll from within the game to other elements in the page. Doesn't look like they are doing anything special, so I've probably bungled something somewhere.
I did try executing an 'exit', but it didn't work. Just checked RGB - they suffer from the same problem on game exit, which at least is comforting. Now just have to figure out the mouse piece...
-
Dosbox, by default, keeps the mouse inside the window (offline Dosbox, that is). I believe it's a parameter in the config file somewhere. Maybe for jDosbox, you can change that parameter so it doesn't lock the mouse?
The exit part's tricky, even from a theoretical point of view. In offline Dosbox, exit closes the entire program, so window and all. Since jDosbox is embedded in a page, what's concidered as "closed"? That the plugin's stopped? Or that the embedded object's removed from the page entirely? Or that jDosbox gives a black screen with "Switched off" on? I don't really see how, from jDosbox's view, they could define what "exit" should do.
As said before, killing off the plugin itself's not an option either, since you'd kill any Smileycentral noisy banner as well. Those people pay good money so it shouts through your webpages, so you better not turn that off along with jDosbox!
-
The jDOSBox default for autolock is not the same as DOSBox. DOSBox's is on and jDOSBox is off. The dosbox.conf setting to turn it off is
[sdl]
autolock=false
Autolock is necessary for some games, usually VESA, else there can be problems ranging from mouse acceleration issues to restrictive movement. Forcing full screen can usually fix these after the fact. For SCI0 games autolock is not an issue, so that can be ignored for here.
Exit does seem to have some effect in jDOSBox. It does not close the plugin, but the prompt stops flashing and becomes unresponsive. I would have expected that the jDOSBox.jar would have been closed/released on the exit command without closing the the Java VM. Some of these issues could be asked of the jDOSBox developer on VOGONS.
-
Ah, I overlooked that when using the jar file in our proposed configuration we do get to download a dosbox conf file from the server (or maybe it should be included within the zip file with the image). That & the autolock switch should take care of it.
You guys are right - my expectations of what should happen with 'exit' were all wrong. It does exit, it just can no longer update the display, so you get what appears to be a stalled dosbox.
-
Okay, SCI games are done & tested. I've downloaded the AGI archive & am working through those now.
I have noticed that (at least on my machine) after trying to run about 5 games or so, jDosBox stops working completely - all you get is a black screen, no indication of anything going on. Requires closing the browser completely in order for games to start working again. Not a big deal, but annoying while testing. Happened both on Firefox & Chrome - haven't tried IE yet.
I was just thinking about Java vs. the sarien.net approach and remembered one big plus on the sarien.net side of things. It will work on then iphone and ipad and various other smart phones and tablets. Usually for iphone apps you need to go through the whole Apple appstore process, but since sarien.net is simply Javascript, images, DHTML and all those things you expect in a browser, it just works. Cross browser shouldn't be an issue either. I doubt that it will freeze or require browser restarts or anything like that.
-
Anyone keen to write a Flash AGI interpreter?
Could this be done to use existing unmodified game logic?
No idea. I've never written a Flash app. From what I've read, ActionScript is a lot like JavaScript, so I'm guessing the answer to your question is no. About the middle of last year I was thinking about writing an AGI interpreter in Javascript (which I do know and have written a bit of). This was before I realised it had already been done... twice... before (in case you didn't know, sarien.net was not the first AGI interpreter in Javascript, and this year I've heard of yet another one in the pipeline). So I decided against reinventing the wheel. But the thinking I did at the time made it clear to me that Javascript would not allow the unmodified game logic to run. AGI code does look a lot like Javascript, but the gotos are one of the big things missing from Javascript. Both of the AGI Javascript interpreters written so far have had to deal with that issue, and from what I've read, they solved the problem in different ways, the end result being fairly strange (e.g. a big switch statement with the switch cases being the line numbers!). - I'm guessing that ActionScript would therefore have similar restrictions.
-
I agree with you Lance - further investigation of the sarien.net code is needed & hopefully it's a more complete solution than the jDosBox solution from the AGI standpoint. I doubt that the process is trivial to convert the games, but maybe it was the multi-player aspect that required additional work.
Unless anyone has any objections, I think I'll plow ahead with the jDosBox approach, create disk images of all the games (shouldn't take too long), figure out which AGI games don't work & then dive into the sarien.net solution.
You are probably right about the multi-player bit being the extra work. I think Martin also put his own interface on top of it for making it easier to do things, which I imagine would change a bit for each game. It would actually be quite cool to see some of these AGI fan made games supporting multi-player though wouldn't it?
-
You know, it just struck me, scummvm wanted in on the agi/ sci development this is right up their alley, what kind of in browser options might they be capable of. Or could be compelled to explore.
Anyone know what this web page below is referring to?
http://www.cuppadev.co.uk/scumm-in-javascript/
It mentions both a Javascript and Flash interpreter for SCUMMVM. Is this for real? I don't have a chance right now to give it a go.
-
Anyone keen to write a Flash AGI interpreter?
Could this be done to use existing unmodified game logic?
No idea. I've never written a Flash app. From what I've read, ActionScript is a lot like JavaScript, so I'm guessing the answer to your question is no. About the middle of last year I was thinking about writing an AGI interpreter in Javascript (which I do know and have written a bit of). This was before I realised it had already been done... twice... before (in case you didn't know, sarien.net was not the first AGI interpreter in Javascript, and this year I've heard of yet another one in the pipeline). So I decided against reinventing the wheel. But the thinking I did at the time made it clear to me that Javascript would not allow the unmodified game logic to run. AGI code does look a lot like Javascript, but the gotos are one of the big things missing from Javascript. Both of the AGI Javascript interpreters written so far have had to deal with that issue, and from what I've read, they solved the problem in different ways, the end result being fairly strange (e.g. a big switch statement with the switch cases being the line numbers!). - I'm guessing that ActionScript would therefore have similar restrictions.
Another idea related to this: Anyone keen to write a SCI interpreter in Javascript? Martin Kool was thinking about it at one point in time, but I think it is a long way down his list at the moment. If you were to right such an interpreter, I'm sure you'd end up being the first.
-
I agree with you Lance - further investigation of the sarien.net code is needed & hopefully it's a more complete solution than the jDosBox solution from the AGI standpoint. I doubt that the process is trivial to convert the games, but maybe it was the multi-player aspect that required additional work.
Unless anyone has any objections, I think I'll plow ahead with the jDosBox approach, create disk images of all the games (shouldn't take too long), figure out which AGI games don't work & then dive into the sarien.net solution.
You are probably right about the multi-player bit being the extra work. I think Martin also put his own interface on top of it for making it easier to do things, which I imagine would change a bit for each game. It would actually be quite cool to see some of these AGI fan made games supporting multi-player though wouldn't it?
Looking at the readme included in the source, the process doesn't look terribly difficult, just time consuming. All resources for the game need to exported using WinAGI. A few files typically fail to export & agistudio is needed to extract the rest. Then the files are run through AgiConvert.
Not too bad - I think from running through the AGI games last night there were only a small handful that use NAGI (maybe 8-10). I'd be willing to at least attempt it for a smaller game.
-
Ah, I overlooked that when using the jar file in our proposed configuration we do get to download a dosbox conf file from the server (or maybe it should be included within the zip file with the image). That & the autolock switch should take care of it.
You guys are right - my expectations of what should happen with 'exit' were all wrong. It does exit, it just can no longer update the display, so you get what appears to be a stalled dosbox.
Yep, that was it. I included a dosbox config file with the autolock=false, and it works just fine.
-
autolock=false seems to be the default. You do not need to add it. According to the jDOSBox author the parameter to use a conf file is
<param name="param1" value="-conf jar://dosbox.conf">
This assumes that the dosbox.conf is in the jdos folder in the jdosbox.jar file. Keep in mind that if you use the dosbox.conf for more than global settings, you will need a different jdosbox.jar file for each game. I did not try to add it to the game's jar to see if you could get a game specific conf. Some commands can simply be added to the autorun.bat file in the game's image file, but not all of the DOSBox commands will work with jDOSBox. Many seem to cause it to crash. If included in the dosbox.conf it will accept aspect=true, but if done from the command line, jDOSBox will crash. BTW, if you kill java.exe with the task manager you do not need to restart the browser to get it to run again.
-
OK, I just tried adding the dosbox.conf to the game's jar and used
<param name="param1" value="-conf jar://dosbox.conf">
and jDOSBox used it. The aspect correction is a little wonky in jDOSBox. It blurs the graphics, unlike DOSBox and seems to make the graphics unstable. It does not use SDL, so some things might not ever be added and other things will not work as well as with DOSBox. Still it does work surprisingly well. It will take a little experimenting to see what supported command don't work that well.
-
Are you using a self-signed jar, or are you using one of the other methods? I've had no problem with any of the games & mouse focus with the changes to the dosbox config.
Here's my configuration:
- I'm using the self-signed jar approach where the image file is downloaded to the client
- The game zip file consists of the game image file & a dosbox.conf file. This gives us the flexibility to have different config settings for each game. Currently, it only consists of:
[sdl]
autolock=false
- The applet code looks very similar to this (from the 3rd example in the jDosBox applet howto) - my disk image size is different though
<APPLET CODE="jdos.gui.MainApplet" archive='jdosbox.jar' WIDTH=640 HEIGHT=400>
<param name="download1" value="http://191.168.0.13/ap2.zip">
<param name="param1" value="imgmount e ~/.jdosbox/ap2/ap2.img -size 512,16,2,512">
<param name="param2" value="e:">
<param name="param3" value="sciv">
<param name="param4" value="-conf ~/.jdosbox/ap2/dosbox.conf">
</APPLET>
This works just fine (in my opinion). The only thing I was thinking about modifying was to have the applet launch in it's own frame, so navigating away wouldn't be an option, and the frame size would be the same size and the game screen resolution.
I've updated all the SCI games to use the dosbox config file, and I'm still working through the AGI games.
-
If there is no dosbox.conf it defaults to autolock=false. I was just using something similar to RGB Classics's code
<applet code="jdos.gui.MainApplet" archive="jdosbox.jar,freddy.jar" width="640" height="480" style="z-index: -100;">
<param name="param2" value="imgmount c jar://freddy.img -size 512,16,2,512">
<param name="param3" value="c:">
<param name="param4" value="autorun">
</applet>
with autorun.bat in the base of the game's image file, giving whatever additional commands needed. This has worked well for me unless I try to use "codebase=", so the jars have to be in the same folder as the page.
Just curious, why are mounting the image as e:? It probably won't matter with the SCI games, but some DOS games don't like not being on C: (with D: for the CD-ROM dive for CD games).
By opening jDOSBox in a frame, do you mean a true frame or an iframe? I'm not sure how possible a true frame would be to do on this site. Would a popup window work, too? An iframe would be a nice touch, but a popup would allow you to navigate away without losing the game, but might encounter problems with popup blockers.
-
That's interesting, because I never got the behavior of 'autolock=false' until I set it explicitly. That's why I asked about which implementation method you were using - perhaps it makes a difference, dunno.
I just used E: because it was the default (and it happened to work).
Sorry, I was envisioning a popup window containing the applet, sized to it contents - frame is the wrong term.
-
Looking at the readme included in the source, the process doesn't look terribly difficult, just time consuming. All resources for the game need to exported using WinAGI. A few files typically fail to export & agistudio is needed to extract the rest. Then the files are run through AgiConvert.
Not too bad - I think from running through the AGI games last night there were only a small handful that use NAGI (maybe 8-10). I'd be willing to at least attempt it for a smaller game.
I asked the question of Martin this morning and he told me it was fairly straight forward, so I think it might be easier than I was expecting.
A small game? Hmmm... I might be biased but you could try The Ruby Cast. It is around 15 rooms I think.
-
Looking at the readme included in the source, the process doesn't look terribly difficult, just time consuming. All resources for the game need to exported using WinAGI. A few files typically fail to export & agistudio is needed to extract the rest. Then the files are run through AgiConvert.
Not too bad - I think from running through the AGI games last night there were only a small handful that use NAGI (maybe 8-10). I'd be willing to at least attempt it for a smaller game.
I asked the question of Martin this morning and he told me it was fairly straight forward, so I think it might be easier than I was expecting.
A small game? Hmmm... I might be biased but you could try The Ruby Cast. It is around 15 rooms I think.
Hey, that sounds fine to me - for sure I'd like to use someone's who still active so we can get feedback whether it's correct or not (from a playability standpoint).
-
So I obviously missed something, where are those how tos you mentioned gumby. got my iso, where did you get the size settings, maybe that's my issue. dosbox loads in the applet, but my image fails to mount.
-
So I obviously missed something, where are those how tos you mentioned gumby. got my iso, where did you get the size settings, maybe that's my issue. dosbox loads in the applet, but my image fails to mount.
DOSBox can be a little fussy with mounting HDD images. Bochs bximage is the HDD image creation tool that the DOSBox devs has usually recommended. I believe there is also one of the unsupported, and by now outdated, 3rd party SVN builds of DOSBox that has some kind image creation tool build in. You have to first create the image, mount it in DOSBox and then format it. I forget if you have to fdisk it before formatting it or if bximage does that for you. After you have done that you can use a tool such as WinImage to inject files and folders. You can find more on this on the DOSBox Wiki if you want, but I find it easier and faster just to modify an existing image.
This is a ZIP with the jar that contains an image that includes your Black Cauldron game. I had to upload it to my site because the board keeps flaking out when I try to attach it.
http://sierrahelp.com/download.php?file=Temp/black.zip
You can use WinRAR to open the jar and inside the jdos folder is the image file. You can modify it for other games by using a tool like WinImage to delete and inject folders and files as needed. I have also included a simple page with the basic HTML needed to add the applet. If you drop the jdosbox.jar file in the same folder, it will work as is.
-
Yeah, there's a learning curve there for sure. Here's what I did, hopefully I can get this right:
1. Download Bochs & use the Disk Image Creation Tool - I created 10 meg images, don't worry - they compress to zilch later.
2. Crank up the image in Bochs and fdisk then format it
3. I then used DiskExplorer found referenced in the IMGMOUNT page in the DosBox pages http://www.dosbox.com/wiki/TOOLS:Disk_Explorer - use the 'Manual HD image' option & then the 'ATFormat' to open the image. Drag'n'drop your files into your image & you are done.
I could just zip up the SCI ones & my sample HTML pages that I've done so far, upload them here, and you can take over from there (at least that was my original intent). I'm pretty much done with them at this point.
DOSBox can be a little fussy with mounting HDD images. Bochs bximage is the HDD image creation tool that the DOSBox devs has usually recommended. I believe there is also one of the unsupported, and by now outdated, 3rd party SVN builds of DOSBox that has some kind image creation tool build in. You have to first create the image, mount it in DOSBox and then format it. I forget if you have to fdisk it before formatting it or if bximage does that for you. After you have done that you can use a tool such as WinImage to inject files and folders. You can find more on this on the DOSBox Wiki if you want, but I find it easier and faster just to modify an existing image.
Agreed. For sure it's easier to keep a 'pristine' empty disk image so you don't have to mess around with creating a new one each time for each game. Oh, and that DiskExplorer tool is fussy, it doesn't allow you to delete files or it corrupts the image (at least for DosBox usability).
-
WinImage is not fussy, but it is not free, either. It does work as shareware until it is registered, but I don't remember what limitations it has in shareware mode.
-
I looked up which SVN build of DOSBox has image making abilities.
H-A-L-9000's Megabuild (http://home.arcor.de/h-a-l-9000/)
I have not tried it myself.
-
I really hate not having the internet at home. Thought I had everything I needed but I didn't grab a boot disk, freedos. Made an img but now I can't do nothing to it. I did play some black cauldron over my local server, that was cool. It's definately slow but I'm assuming I can play with all the usual numbers and adjust some of that. Pretty cool though. As soon as I can make a couple of my own images, there's gonna be a new link button up there. anybody know of real good hosting, lol
-
Okay, I've imaged & zipped up all the AGI games w/dosbox config. I removed older versions/demos of the same title and came up with a total of 152. Now I just need to create webpages for each & run through them, make sure they all work.
-
anybody know of real good hosting, lol
I use Arvixe (http://www.arvixe.com/). It's been a good service. The package I have gives unlimited space and shy of 3000 gb bandwidth a month. All for about $40 a year plus $10 domain registration. SHP averages over 25,000 unique visitors a month and last month used over 170 gb bandwidth.
We were moved to another server because of some SQL errors that we were having that kept reoccurring. Bandwidth is not quite as good as on the old server. It is a shared server and I suspect that they put us on one that has another very busy site.
Even so, usually speed is reasonable, even with the occasional slowdown. It has only been down only once that I am aware of. It easily handles the jDOSBox code. Freddy Pharkas demo (http://sierrahelp.com/jDOSBox/FreddyDemo.html)
-
I haven't had time to monkey around with this anymore, but I did turn Collector's image of the Black Cauldron into an disk image of one of my in progress games. This is currently available for a little bit of online play testing.
I make the big formal speech later in the news section, but for now if you want to give a little sci-online a little try.
Might I suggest Shoot em up (http://sciprogramming.com/desktop.php). A word of warning, it plays slow... But it plays.
-
First level runs just fine I think... level 2, a bit laggy but still playable. I recognize the rope from level 4 ;D
-
Amusing little shooter. Gumby's right, level 2 is a bit slow. Danoon just released a new version of jDOSBox that is faster.
New Beta Version build 19c
The new caching core is almost done. It runs all my standard test games, including, Death Rally, Doom, Tomb Raider and Dungeon Keeper. Currently the only problem is Windows 3.11.
On average this version should be about 2x faster than my previous official release.
Please test this version and report back any problems.
http://jdosbox.sourceforge.net/beta/jdosbox.jar
I think the load time is mostly due to the size of the jdosbox.jar. I could setup a sub domain for you to put some of the larger and more bandwidth things, say sciprogramming.sierrahelp.com, at least until you can get a better service.
I've been using WinImage to handle the disk images. I haven't tried Disk Explorer, so I am not sure about it, but at least in WinImage you can delete and rename files and folders inside the image. I find it good practice to use unique names for the folders, images and jars/zips for each game. By the time you get all of the games uploaded it will make it hard to keep track of them all.
I've been busy, too. I have been setting up my large collection of Sierra demos. I have made templates of empty disk images (of varying sizes in 5 MB increments) an empty JAR, batch file and an HTML page to speed things up. All I have to do is copy and rename the templates, edit the batch file, open the image in WinImage and drop the game's folder in with the edited batch file. I can then add the image into the jdos folder in the jar. All that is left at that point is to change names in the HTML file.
http://sierrahelp.com/jDOSBox/jDOSBox.html
-
I actually used disk explorer to copy the new resource files I didn't bother trying to change the names at all. I'm going to a slightly diffrent direction to start off with, but I'll try to explain it when the link pops up. For now though I wanted to get something up and rolling. New jdosbox, twice as fast... sounds perfect. I pity anyone who makes it into the bank.
-
Okay, AGI games are coming along nicely. I've got them all except for the NAGI games:
- Al Pond 1
- Apocalyptic quest
- Bob the Farmboy
- Enclosure
- Gennadi
- Hobbits
- Journey of Chef
- Open Mic Night
- Save Santa
- Space Quest 0
- Tales of the Tiki
- The Long Haired Dude
- V - The Graphical Adventure
I'm also having some problems with a handful of other games, sound/video issues crashing dosbox.
I'm changing the scope of this project. I'm thinking I'll create an installation package that allows all games to be played both for web-hosted play and local pc play. So I'll put together some nice webpages for displaying the games, etc. Maybe some sorting by category (author, genre, PG rating).
I have to say that I was impressed with of the vast majority games (AGI & SCI) from what I saw. Very nice.
-
So are you just running the agi games through dosbox or have you looked into sarien at all. I suppose since I'm using a popup there's no reason that adding in agi support shouldn't go rather smoothly. And from what I've seen of sarien.net, it doesn't seem to suffer the lag that dosbox does. I've went from a full blown conf file to not using one at all without much change. Makes me wonder just how much is controllable.
-
I've went from a full blown conf file to not using one at all without much change. Makes me wonder just how much is controllable.
I have wondered, too. Some things it will accept, like aspect correction, but not machine=tandy. It also seems to ignore cycle and frame settings. I had to resort to the old GOSiERRA patcher for SB initialization errors because it ignored cycle settings.
I could see that he might not have Tandy support built in, but cycles is so basic that it is hard to believe he has ignored that.
-
Just today I created a generic applet html file for launching games. Wish I'd done that from the beginning; I had put together a separate html file for each AGI & SCI game and now they are useless.
The good news is that that a webserver is not longer necessary, just a browser (and java) - I've eliminated all absolute urls. So I've met my requirement of a package that can be downloadable & fully stand-alone, as well as a package that can be easily integrated into a website.
I'll be moving along to testing the sarien solution once I finish up the jDosBox stuff.
-
Hey gumby, did you register your JDK after installing? I wanted to experiment with the signed approach for some of the larger and more demanding demos. I followed the instructions to sign the jar and it seems to work, but it complains that it cannot verify it when launching it.
-
Hey gumby, did you register your JDK after installing? I wanted to experiment with the signed approach for some of the larger and more demanding demos. I followed the instructions to sign the jar and it seems to work, but it complains that it cannot verify it when launching it.
No, despite the fact that the jar is signed, the JVM cannot verify the signature. You can check the box 'Always allow content from this provider' or whatever it says and it won't bother you again. I think this is the same issue as a self-signed SSL certificate - unless you use a public on-line providers' signing method (e.g. Thawte) it will always be 'unverified'.
-
Okay, I'm finished. All the games (except the NAGI ones) are playable either on-line or off-line (both from within a browser). The archive consists of:
- An index page of all the games in a sortable html table, nothing fancy.
- A generic, parameterized page to launch jDosBox
- jDosBox itself, current stable version
- All games in 10 meg images, zipped up
The NAGI games are listed in the index, but are not playable.
The file is 30 meg, couldn't upload it. Cloudee & Raf, PM me so I can get this to you guys - assuming you'd like to host it. I guess I don't see a problem releasing the package for the community to download as well.
On to testing the sarien.net solution.
-
Lol. The Ruby Cast took me less than an hour (newbie fumbling & bumbling included) to get working in Sarien.net. Let's see if it works with the NAGI games...
-
Okay. I've found out that the sarien.net solution needs some work when it comes to the fan made games. For sure, NAGI games just plain don't work - probably because sarien is a port of the original AGI interpreter, I'm guessing. Anyway, here are my results:
AGI games
- The Ruby Cast: Works, but when you attempt to go 'out-of-bounds' toward the river, the warning dialog loops.
- Boring Man 1: Doesn't work, all you get is the parser input '>' and a black screen (perhaps mouse support not available?)
- Car Driver: Works, but car view doesn't change to the 'vertical' orientation.
NAGI games
- AGI Combat: Does nothing
- Hobbits: Can get through the initial cutscene, but upon any keyboard input 'You are dead' & the game restarts
- Save Santa: Get intro splash screen, then javascript error
I can say that The Ruby Cast runs blazing fast compared to jDosBox.
-
"I can say that The Ruby Cast runs blazing fast compared to jDosBox."
jDosbox/Dosbox will default to a slow speed for 16-bit apps. You can set the cycles to max in the dosbox.conf file to speed things up if this is the case, or call "z:\config -set cpu cycles max"
As for mouse captures issues mentioned earlier in this thread, it will default to capturing the mouse if the applet is signed, otherwise for unsigned applets jdosbox will not have permission to control the mouse like that.
-
"I can say that The Ruby Cast runs blazing fast compared to jDosBox."
jDosbox/Dosbox will default to a slow speed for 16-bit apps. You can set the cycles to max in the dosbox.conf file to speed things up if this is the case, or call "z:\config -set cpu cycles max".
I actually find the default speed of jDosBox to work just fine for the AGI games. Upon changing the speed within the game, I can easily outdo the default speed of sarien.net.
However, for SCI games I may want to tweak the default cycles a bit depending upon what kind of feedback we get.
Thanks for the info - nice to see you taking an interest in what we are doing with your software :).
-
I think that you can easily get by with a generic dosbox.conf for the fan games here, perhaps just one embedded in the jdosbox.jar. I doubt that there are any timer bugs in the fan SCI games, but I default to 10000 cycles (official DOSBox) for the SCI games for my installers. For most games this is slow enough to avoid most unpatched speed bugs and fast enough to not notice any lag. Only the SCI32 games seem to want more. LSL7DEMO, an SCI32 game, does not run quite right in jDOSBox, even when cycles are set to max. I am not sure how complete or compatible the dynamic core is in jDOSBox, yet.
Outside of that, I think that the best way to speed things up is to ZIP/JAR the IMG files to make it a much smaller (i.e. faster) download.
-
Okay, I'm finished. All the games (except the NAGI ones) are playable either on-line or off-line (both from within a browser). The archive consists of:
- An index page of all the games in a sortable html table, nothing fancy.
- A generic, parameterized page to launch jDosBox
- jDosBox itself, current stable version
- All games in 10 meg images, zipped up
The NAGI games are listed in the index, but are not playable.
The file is 30 meg, couldn't upload it. Cloudee & Raf, PM me so I can get this to you guys - assuming you'd like to host it. I guess I don't see a problem releasing the package for the community to download as well.
On to testing the sarien.net solution.
PM sent. Now, for me, the biggest issue's the NAGI games. Those tend to be the best showcase games (Enclosure, Klownstein's Hobbits, ...), so it'd be nice to get those working as well. Things should calm down here soon, so I'll be able to look into it as well.
-
Okay, I'm finished. All the games (except the NAGI ones) are playable either on-line or off-line (both from within a browser). The archive consists of:
- An index page of all the games in a sortable html table, nothing fancy.
- A generic, parameterized page to launch jDosBox
- jDosBox itself, current stable version
- All games in 10 meg images, zipped up
The NAGI games are listed in the index, but are not playable.
The file is 30 meg, couldn't upload it. Cloudee & Raf, PM me so I can get this to you guys - assuming you'd like to host it. I guess I don't see a problem releasing the package for the community to download as well.
On to testing the sarien.net solution.
For my understanding, why is there an issue with the NAGI games? In fact what exactly is a NAGI game? I thought NAGI was just a Windows AGI interpreter that runs against the same data files that the original interpreter runs against. For example, I can run The Ruby Cast with NAGI. Does NAGI have extensions? I recall that some people did write extensions such as 256 colours, mouse, etc. but I didn't realise that NAGI was like that.
-
When I attempted to run NAGI-required games with the AGI executable I was only able to get so far, sometimes through the intro screen. Then I got an 'out of memory' error. I think that it's a backward-compatibility issue, AGI games run fine in NAGI not necessarily the other way around.
-
When I attempted to run NAGI-required games with the AGI executable I was only able to get so far, sometimes through the intro screen. Then I got an 'out of memory' error. I think that it's a backward-compatibility issue, AGI games run fine in NAGI not necessarily the other way around.
Yep. Some agi games only run with nagi.
Robin Gravel
-
For my understanding, why is there an issue with the NAGI games? In fact what exactly is a NAGI game? I thought NAGI was just a Windows AGI interpreter that runs against the same data files that the original interpreter runs against. For example, I can run The Ruby Cast with NAGI.
You are right. The issue is not with NAGI itself, but the games. Most likely games that do not run on the original Sierra interpreter have errors that NAGI ignores. If the source of the games in question was available and someone was willing to go through it he might be able to spot what is wrong. Nick Sonneveld might have an idea from the NAGI end. Perhaps a "JavaScript port" of NAGI? ;)
Does NAGI have extensions? I recall that some people did write extensions such as 256 colours, mouse, etc. but I didn't realise that NAGI was like that.
I have never run across any kind of reference of a plugin/extension for NAGI. Sarien was incorporating extras, like mouse support and graphic filters, etc.
-
OK, I did a little research. These games most likely have stack errors. I fixed most of the game using the interpreter of one of the demo packs. Open Mic Night makes use of mouse support, so use of the Sierra interpreter is out. Space Quest 0 - Replicated, versions 1.03 and 1.04 give not enough memory errors. V - The Graphical Adventure demo just does not like the original at all. All others are fixed. At least they start. I cannot say if there might be errors further into the games.
Edit, again I hit the brick wall of not being able to upload anything here. It is only a little under 3MB. I'll upload the fixed games to SHP and post a link here later. I really wish it was possible upload attachments here.
-
Didn't I already explain this earlier in this thread? :P
The original AGI interpreters have a very limited amount of memory. Some fanmade games (Enclosure, Hobbits, etc) have some resources that're too big for that memory, or load in too many resources. The original AGI interpreter can't handle that, as it's made for computers from a different age. NAGI allows bigger memory usage (I don't know whether it's by design or not). That means that some games that have at least one room which requires more memory than the original interpreter can handle, can only run on NAGI.
For the record, most of the time, those resources're background pictures with lots of dithering. There're some techniques to do that without any problem, outside of Picedit. But once it's in the AGI picture format, it's a whooooooole lot of commands to draw single-pixel lines. That eats up an ENORMOUS amount of memory (enormous to AGI terms)
-
OK, I did a little research. These games most likely have stack errors. I fixed most of the game using the interpreter of one of the demo packs. Open Mic Night makes use of mouse support, so use of the Sierra interpreter is out. Space Quest 0 - Replicated, versions 1.03 and 1.04 give not enough memory errors. V - The Graphical Adventure demo just does not like the original at all. All others are fixed. At least they start. I cannot say if there might be errors further into the games.
Edit, again I hit the brick wall of not being able to upload anything here. It is only a little under 3MB. I'll upload the fixed games to SHP and post a link here later. I really wish it was possible upload attachments here.
Ah, crap. I should have updated my list of what I classified as NAGI (if you are going off of my list) there were a few changes. Please, correct me if there are inaccuracies:
- AGI Combat
- Bob the Farmboy
- Enclosure
- Gennadi
- Hobbits
- Journey of Chef
- Open Mic Night
- Save Santa
- Space Quest 0 - Replicated
- Star Pilot 2 - Bigger Fish
- Tales of the Tiki
- The Long Haired Dude
- V - The Graphical Adventure
EDIT: Oh yeah, you might want to check that the games are at least playable - it seems like one of the characteristics of these games is that they will sometimes start up, play the intro, then bomb out.
-
Didn't I already explain this earlier in this thread? :P
The original AGI interpreters have a very limited amount of memory. Some fanmade games (Enclosure, Hobbits, etc) have some resources that're too big for that memory, or load in too many resources. The original AGI interpreter can't handle that, as it's made for computers from a different age. NAGI allows bigger memory usage (I don't know whether it's by design or not). That means that some games that have at least one room which requires more memory than the original interpreter can handle, can only run on NAGI.
For the record, most of the time, those resources're background pictures with lots of dithering. There're some techniques to do that without any problem, outside of Picedit. But once it's in the AGI picture format, it's a whooooooole lot of commands to draw single-pixel lines. That eats up an ENORMOUS amount of memory (enormous to AGI terms)
Wow, there is a lot that I missed when I was away from the AGI scene for 10 years or so. I guess what we are saying is that they are not technically AGI games, and thus the reason they are being called NAGI games. Makes sense.
Is the Sierra interpreter the only fully working DOS interpreter? Maybe there is finally a reason to resurrect and complete MEKA. Or perhaps a Java version of MEKA. Or perhaps we can look at that Java AGI project and see how far that got towards a working interpreter.
-
Or could Sarien.net be altered to allot more memory to the games?
-
This issue with sarien.net is probably more to do with conversion to Javascript issues rather than memory related issues. If we think about the four AGI resources, we can discount SOUND because as far as I know that wasn't implemented in sarien.net, but for the VIEW and PICTURE resources, the conversion would be fairly exact I would have thought. The size of the images generated I doubt would be an issue for a browser. The LOGIC resources are a different thing all together. These are converted to Javascript, so I guess there is potential for conversion issues in this area. The core engine is also written in Javascript and might include differences not in the original Sierra interpreter. I remember when I was working on MEKA that there were weird things happening in some AGI games that I couldn't explain, which must have been something to do with subtle differences between how I had written the interpreter and what the Sierra interpreter did.
-
There is another DOS-compatible fan-made AGI interpreter that's supposedly allows games with more memory than the original interpreter can handle. Can't remember the name. Starts with Y. I could never get it to work, though.
-
I somewhat remember it, too. Wasn't it something like YAGI or YAAGI as in Yet Another Adventure Game Interpreter?
-
Yeah, that rings a bell.
-
I did a little Googling on it, but didn't get any hits. I didn't spend too long on it. I had some memory of a link to it on Nick Sonneveld's site, but could not find anything when I looked there. Half of the links there are now dead, anyway.
-
Did a quick google for AGI interpreters, and found these:
DAGII (http://linux.softpedia.com/get/System/Emulators/DAGII-21508.shtml) -- written in Portable C++ (hehehe, "Interpreter Interpreter" ;D )
AGI (http://sourceforge.net/projects/agi/) -- written in Java (VERY confusing name, that!)
MeAGI (http://wressle.chipit.se/) -- written mainly for phones'n such, and doesn't seem finished
That's all I can find (besides the typical ones: NAGI, Sarien and ScummVM). No YAGI or such.
-
Another thing I've found:
http://web.ist.utl.pt/antonio.afonso/agi/
I can't check it out, cause I'm at work right now (LSL might have a boss key, but still...), but'll check it out further this evening.
-
Yeah, that looks like the very first AGI interpreter written in Javascript. Sarien.net was the second such interpreter but is obviously the more advanced one these days. The one you've linked to was written in 2006 I think, and sarien.net was around 2008. Incidentally, I know of a third AGI interpreter written in Javascript that is being worked on at present but I have no idea what the status is. It hasn't been released.
-
I somewhat remember it, too. Wasn't it something like YAGI or YAAGI as in Yet Another Adventure Game Interpreter?
I recall that Sarien had an earlier name that started with Y... something like Ydrassil (I've definitely got that spelt wrong... might have had a g in it as well).
-
Yggdrasil
-
That's it!
-
Anyone have some old DOS binaries of Sarien?
-
Anyone have some old DOS binaries of Sarien?
Dunno if it's this one, but modified: 2004-07-21... Comes pretty close, no? Especially since all the Win versions I find that clearly state they're win versions, are from 2007.
http://sourceforge.net/projects/sarien/files/
-
There is an MS-DOS version there, but it loads the title screens (after complaining that it couldn't ID them) and then lock up.
-
Stuart George is still contactable. I was talking to him about 6 months ago. He might be able to answer the DOS question for us. He might even have a version sitting around.