*sigh* http://www.raphkoster.com/2009/01/27/rogue-leaders-excerpt-on-habitat/
-----Ursprüngliche Nachricht----- Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Dahlia Trimble Gesendet: Di 27.01.2009 09:02 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] weird idea #2: inworld applications 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.kra...@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@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
<<winmail.dat>>
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev