weird idea #2: inworld applications

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

weird idea #2: inworld applications

Dirk Krause
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
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications

Dirk Krause

Nice!! Didn’t think of that.

 

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Dahlia Trimble
Gesendet: Dienstag, 27. Januar 2009 09:02
An: [hidden email]
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 <[hidden email]> 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
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications

Michael Emory Cerquoni
if we could get some level of flash support we could run a c64 emulator written in Flash.  I think supporting flash would open the doors to many applications inside OpenSim, but alas, without a new viewer or the lindens support for Flash this is nothing more than a dream right now.  Hopefully one day we get support for some useful tools in SL, but the fact that lindens have yet to even adopt a real way to load a website in their viewer leads me to beleive we may never see any level of flash support from them.

Neb

_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications

Paul Fishwick
Flash support seems to be supported in rex (with the rex server)
but has not yet been tested in modrex.
See:
http://rexdeveloper.org/wiki/index.php?title=Features_supported_currently
under "MediaURL: flash support"

So, the dream may be close to reality.

-p

Nebadon Izumi wrote:

> if we could get some level of flash support we could run a c64
> emulator written in Flash.  I think supporting flash would open the
> doors to many applications inside OpenSim, but alas, without a new
> viewer or the lindens support for Flash this is nothing more than a
> dream right now.  Hopefully one day we get support for some useful
> tools in SL, but the fact that lindens have yet to even adopt a real
> way to load a website in their viewer leads me to beleive we may never
> see any level of flash support from them.
>
> Neb
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  


--
Paul Fishwick, PhD
Professor and Director, Digital Arts and Sciences Programs
University of Florida
Computer & Information Science and Eng. Dept.
Bldg. CSE, Room 301
P.O. Box 116120
Gainesville, FL 32611
Email: [hidden email]
Phone: (352) 392-1414
Fax: (352) 392-1220
Web: http://www.cise.ufl.edu/~fishwick

_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications

Dirk Krause
In reply to this post by Dahlia Trimble
*sigh*
  http://www.raphkoster.com/2009/01/27/rogue-leaders-excerpt-on-habitat/


-----Ursprüngliche Nachricht-----
Von: [hidden email] im Auftrag von Dahlia Trimble
Gesendet: Di 27.01.2009 09:02
An: [hidden email]
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 <[hidden email]>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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev

winmail.dat (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications - access to client's widget set?

John Sheridan
In reply to this post by Dirk Krause
While on the topic of weird ideas and in world apps...  I posted this
idea to the Lindens about a year ago back when I was first trying to
figure out LSL, but it likely went off to the noobie duh bin as at the
time I pretty much asked them to include a copy of Visual Basic in world
:P  Anywho, as it is we already have the LSL language with our own
additions via the os functions.  What I'm thinking would likely require
client modifications which merely makes it something to think about for
the future, but why not cobble together something that gives lsl access
to the client's widget set? Optimally something like a Mono Winforms
type of addition to lsl that would let a scripter actually use a real
gui as an interface for their scripts instead of hacking one out with
prims or a dialog box?

Thanks, :)

John / Orion Pseudo

Dirk Krause 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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications - access to client's widget set?

Dahlia Trimble
That would most likely require modifications to the sl viewer. I think the Imprudence project is looking at providing a viewer with similar capabilities: http://imprudenceviewer.org/



On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <[hidden email]> wrote:
While on the topic of weird ideas and in world apps...  I posted this
idea to the Lindens about a year ago back when I was first trying to
figure out LSL, but it likely went off to the noobie duh bin as at the
time I pretty much asked them to include a copy of Visual Basic in world
:P  Anywho, as it is we already have the LSL language with our own
additions via the os functions.  What I'm thinking would likely require
client modifications which merely makes it something to think about for
the future, but why not cobble together something that gives lsl access
to the client's widget set? Optimally something like a Mono Winforms
type of addition to lsl that would let a scripter actually use a real
gui as an interface for their scripts instead of hacking one out with
prims or a dialog box?

Thanks, :)

John / Orion Pseudo

Dirk Krause 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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications - access to client's widget set?

John Sheridan
Well, I'm glad someone's at least taking a swipe at the client from a usability standpoint although it would be nice if they like a few of the other client projects I've seen would consider starting with a ground up rebuild of the code base.  At least not only to solve the gpl vs bsd vs <insert favorite license here> problem but as well to make it so one can actually read and understand the code without loosing all grip on reality (virtual or not) then curling up into a fetal position under their desk while the world around them crumbles into some sort of bad rendering bug ala The Matrix.  And yes, for those who actually can read and understand the Linden's coding style I am that much of a wimp.  :)

Thanks for the info Dahlia, :)

 - John / Orion Pseudo


Dahlia Trimble wrote:
That would most likely require modifications to the sl viewer. I think the Imprudence project is looking at providing a viewer with similar capabilities: http://imprudenceviewer.org/



On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <[hidden email]> wrote:
While on the topic of weird ideas and in world apps...  I posted this
idea to the Lindens about a year ago back when I was first trying to
figure out LSL, but it likely went off to the noobie duh bin as at the
time I pretty much asked them to include a copy of Visual Basic in world
:P  Anywho, as it is we already have the LSL language with our own
additions via the os functions.  What I'm thinking would likely require
client modifications which merely makes it something to think about for
the future, but why not cobble together something that gives lsl access
to the client's widget set? Optimally something like a Mono Winforms
type of addition to lsl that would let a scripter actually use a real
gui as an interface for their scripts instead of hacking one out with
prims or a dialog box?

Thanks, :)

John / Orion Pseudo

Dirk Krause 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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________ Opensim-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications - access to client's widget set?

Dahlia Trimble
There are two "ground up" viewer projects that I'm aware of, Idealist and Openviewer. Here is a site which discusses them from a technical perspective: http://playsign.fi/engine/rex/viewerarchs

Openviewer can be found at: http://openviewer.org/

Then there is the Xenki viewer which aims to be a browser plug-in rather than a standalone viewer. Find it here: http://forge.opensimulator.org/gf/project/xenki/


On Tue, Jan 27, 2009 at 6:58 PM, John Sheridan <[hidden email]> wrote:
Well, I'm glad someone's at least taking a swipe at the client from a usability standpoint although it would be nice if they like a few of the other client projects I've seen would consider starting with a ground up rebuild of the code base.  At least not only to solve the gpl vs bsd vs <insert favorite license here> problem but as well to make it so one can actually read and understand the code without loosing all grip on reality (virtual or not) then curling up into a fetal position under their desk while the world around them crumbles into some sort of bad rendering bug ala The Matrix.  And yes, for those who actually can read and understand the Linden's coding style I am that much of a wimp.  :)

Thanks for the info Dahlia, :)

 - John / Orion Pseudo


Dahlia Trimble wrote:
That would most likely require modifications to the sl viewer. I think the Imprudence project is looking at providing a viewer with similar capabilities: http://imprudenceviewer.org/



On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <[hidden email]> wrote:
While on the topic of weird ideas and in world apps...  I posted this
idea to the Lindens about a year ago back when I was first trying to
figure out LSL, but it likely went off to the noobie duh bin as at the
time I pretty much asked them to include a copy of Visual Basic in world
:P  Anywho, as it is we already have the LSL language with our own
additions via the os functions.  What I'm thinking would likely require
client modifications which merely makes it something to think about for
the future, but why not cobble together something that gives lsl access
to the client's widget set? Optimally something like a Mono Winforms
type of addition to lsl that would let a scripter actually use a real
gui as an interface for their scripts instead of hacking one out with
prims or a dialog box?

Thanks, :)

John / Orion Pseudo

Dirk Krause 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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________ Opensim-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev







_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird idea #2: inworld applications - access toclient's widget set?

Dirk Krause
Ah, I wasn’t aware of this technical paper (anymore), thanks for the link.

Yes, I am very much hoping that one of these two emerges over the standard viewer.

Someone I know recently compiled it, and gathering of libs/versions and compilation seemed to be not for the faint of heart. It seems to be a tad easier with the Hippo trunk.

@john: nice picture you paint there ☺.

------
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Dahlia Trimble
Gesendet: Mittwoch, 28. Januar 2009 06:14
An: [hidden email]
Betreff: Re: [Opensim-dev] weird idea #2: inworld applications - access toclient's widget set?

There are two "ground up" viewer projects that I'm aware of, Idealist and Openviewer. Here is a site which discusses them from a technical perspective: http://playsign.fi/engine/rex/viewerarchs

Idealist can be found at: http://forge.opensimulator.org/gf/project/idealistviewer/
Openviewer can be found at: http://openviewer.org/

Then there is the Xenki viewer which aims to be a browser plug-in rather than a standalone viewer. Find it here: http://forge.opensimulator.org/gf/project/xenki/


On Tue, Jan 27, 2009 at 6:58 PM, John Sheridan <[hidden email]> wrote:
Well, I'm glad someone's at least taking a swipe at the client from a usability standpoint although it would be nice if they like a few of the other client projects I've seen would consider starting with a ground up rebuild of the code base.  At least not only to solve the gpl vs bsd vs <insert favorite license here> problem but as well to make it so one can actually read and understand the code without loosing all grip on reality (virtual or not) then curling up into a fetal position under their desk while the world around them crumbles into some sort of bad rendering bug ala The Matrix.  And yes, for those who actually can read and understand the Linden's coding style I am that much of a wimp.  :)

Thanks for the info Dahlia, :)

 - John / Orion Pseudo


Dahlia Trimble wrote:
That would most likely require modifications to the sl viewer. I think the Imprudence project is looking at providing a viewer with similar capabilities: http://imprudenceviewer.org/ 


On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <[hidden email]> wrote:
While on the topic of weird ideas and in world apps...  I posted this
idea to the Lindens about a year ago back when I was first trying to
figure out LSL, but it likely went off to the noobie duh bin as at the
time I pretty much asked them to include a copy of Visual Basic in world
:P  Anywho, as it is we already have the LSL language with our own
additions via the os functions.  What I'm thinking would likely require
client modifications which merely makes it something to think about for
the future, but why not cobble together something that gives lsl access
to the client's widget set? Optimally something like a Mono Winforms
type of addition to lsl that would let a scripter actually use a real
gui as an interface for their scripts instead of hacking one out with
prims or a dialog box?

Thanks, :)

John / Orion Pseudo

Dirk Krause 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
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev

________________________________________
_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
 


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev





_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Loading...