Play community-created games in a browser

[Cloudee1]

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.

[gumby]

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.

[Collector]

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.

[Cloudee1]

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.

[gumby]

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?

[Collector]

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.:

Code: [Select]

[autoexec]
cls
@ECHO OFF
mount c "C:\Sierra\Conquests of Camelot"
c:
cd \
SCIV.EXE
exit

[gumby]

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...

[Raf]

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!

[Collector]

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

Code: [Select]

[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.

[gumby]

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.

[lance.ewing]

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.

[lance.ewing]

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.

[lance.ewing]

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?

[lance.ewing]

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.

[lance.ewing]

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.