[Opensim-dev] weird idea #2: inworld applications

[Dahlia Trimble]

Not sure how to get a c64 emulator to work in opensim, but if it can be done
it should be playing Habitat: http://www.youtube.com/watch?v=VVpulhO3jyc

One solution may be to stream a video of the emulator display.


On Mon, Jan 26, 2009 at 11:51 PM, Dirk Krause <dirk.krause at pixelpark.com>wrote:

> Hi,
>
> this thing came up when I was thinking about what to do for OpenSims 2nd
> birthday.
>
> I thought it would be really funny to reconstruct the Sony Home Arcades in
> OpenSim, basically for giggles. I unfortunately don't have access to Sony
> Home for now so I don't know exactly what effort it means to model this,
> being not a good builder myself (for reference - http://tinyurl.com/def8fn)
>
> The interesting point would be the ability to play either MAME or C64 games
> on the machines in these 'OpenSim Home (tm) Arcades'. So I looked up a C#
> c64 emulator on the web ( http://tinyurl.com/bobw9y ) but then came to
> think where such an emulator would run.
>
> (the following holds probably true for all kinds of applications running in
> the OpenSim context, namely:
> - graphic-heavy c# or c++ applications
> - flash/silverlight/moonlight applications
> - 'co-browsing', works in Rex with this nice trick:
> http://therexfiles.cybertechnews.org/?p=183 )
>
> So, to stick with the arcade example, the good question is - where does the
> process run?
> I think there are these possibilities in general
> 1) SERVER - the application totally runs on the server side. One av takes
> over the game machine and his key strokes are transmitted to the server (via
> HUD?) and the emulator creates the graphic output. This would be a series of
> textures (not really good) or a video stream of sorts.
> 2) CLIENT - the applications totally runs on the client. This is possibly
> the easiest way to implement it (and out of scope for opensim-dev) since it
> needs hacking the client. But just for the record: as soon as the client
> detects arcade.jp2 as the texture, it fires up ye old space invaders and
> renders2texture the graphic output to the client.  Other people would see
> either
> a) nothing but the standard texture as long as they are not playing it or
> b) a screenshot every 5 secs or so,  since the client sends every 5 secs or
> so a screenshot to the server, updating the view for the cheering bystanders
> c) the real game, since their clients also fire up the emulator, receive
> the key strokes from the current player (while they are near him) which must
> be sent from the server of course.
> 3) BOTH- the application runs on both server and client with synchronicity
> calls every N secs with some prediction by the client side when the calls
> don't get through fast enough (basically like networked physics in
> professional games works)
>
> All in all you are in synchronicity hell the more 'real' the output for
> everyone gets because there can be no real simultaneousness.
>
> So sorted by applications:
> - Physics:
> either only server sided (like it is now) which is sufficient for most use
> cases, or both when the physics is fast and heavy like in games.
> - Video:
> Number 2c is used to play video in SL right now - one av activates the
> script that start the media playing on all clients in the vicinity. if they
> didn't activate media support then they see nothing. If they did the video
> starts on all clients, probably 1 to N secs off each, depending on their
> network, also slowly drifting into asynchronicity the longer the video runs.
> If it should be more synchronous then a streaming server is mandatory.
>
> - Turn based games
> could be implemented completely on server side. So a simple text adventure
> (Zork, anyone) or even a MUD could be implemented even on a different server
> with a gateway of sort. Come to think of it this could even be a tty
> terminal.
>   Same goes for
> - co-browsing web pages, powerpoint projectors
> Could be either server sided (like it is now via the php render trick) or
> client sided (via the Rex trick)
>
> So the interesting part stays where to implement, say, a moonlight
> application? Let's say people want to create micro/casual games or small
> apps,then it would be interesting to see whether there would be an
> infrastructure to hook these things into?
>
> I would even go so far that there could be a mechanism that handles LL or
> OS scripts in a way that it either runs on the client (libomv Test.exe with
> some script) or on the server side (the existing scripting architecture).
>
> Best regards,
>  Dirk/Barth
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090127/a4209e87/attachment-0001.html>