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: <a href="http://playsign.fi/engine/rex/viewerarchs">http://playsign.fi/engine/rex/viewerarchs</a><div>
<br></div><div>Idealist can be found at: <a href="http://forge.opensimulator.org/gf/project/idealistviewer/">http://forge.opensimulator.org/gf/project/idealistviewer/</a></div><div>Openviewer can be found at: <a href="http://openviewer.org/">http://openviewer.org/</a></div>
<div><br></div><div>Then there is the Xenki viewer which aims to be a browser plug-in rather than a standalone viewer. Find it here: <a href="http://forge.opensimulator.org/gf/project/xenki/">http://forge.opensimulator.org/gf/project/xenki/</a></div>
<div><br></div><div><br><div class="gmail_quote">On Tue, Jan 27, 2009 at 6:58 PM, John Sheridan <span dir="ltr"><<a href="mailto:john@pseudospace.net">john@pseudospace.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
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. :)<br>
<br>
Thanks for the info Dahlia, :)<br>
<br>
- John / Orion Pseudo<br>
<br>
<br>
Dahlia Trimble wrote:
<blockquote type="cite"><div><div></div><div class="Wj3C7c">That would most likely require modifications to the sl
viewer. I think the Imprudence project is looking at providing a viewer
with similar capabilities: <a href="http://imprudenceviewer.org/" target="_blank">http://imprudenceviewer.org/</a>
<div><br>
</div>
<div><br>
<br>
<div class="gmail_quote">On Tue, Jan 27, 2009 at 12:18 PM, John
Sheridan <span dir="ltr"><<a href="mailto:john@pseudospace.net" target="_blank">john@pseudospace.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">While
on the topic of weird ideas and in world apps... I posted this<br>
idea to the Lindens about a year ago back when I was first trying to<br>
figure out LSL, but it likely went off to the noobie duh bin as at the<br>
time I pretty much asked them to include a copy of Visual Basic in world<br>
:P Anywho, as it is we already have the LSL language with our own<br>
additions via the os functions. What I'm thinking would likely require<br>
client modifications which merely makes it something to think about for<br>
the future, but why not cobble together something that gives lsl access<br>
to the client's widget set? Optimally something like a Mono Winforms<br>
type of addition to lsl that would let a scripter actually use a real<br>
gui as an interface for their scripts instead of hacking one out with<br>
prims or a dialog box?<br>
<br>
Thanks, :)<br>
<br>
John / Orion Pseudo<br>
<br>
Dirk Krause wrote:<br>
> Hi,<br>
><br>
> this thing came up when I was thinking about what to do for
OpenSims 2nd birthday.<br>
><br>
> 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 - <a href="http://tinyurl.com/def8fn" target="_blank">http://tinyurl.com/def8fn</a>
)<br>
><br>
> 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 ( <a href="http://tinyurl.com/bobw9y" target="_blank">http://tinyurl.com/bobw9y</a>
) but then came to think where such an emulator would run.<br>
><br>
> (the following holds probably true for all kinds of applications
running in the OpenSim context, namely:<br>
> - graphic-heavy c# or c++ applications<br>
> - flash/silverlight/moonlight applications<br>
> - 'co-browsing', works in Rex with this nice trick: <a href="http://therexfiles.cybertechnews.org/?p=183" target="_blank">http://therexfiles.cybertechnews.org/?p=183</a>
)<br>
><br>
> So, to stick with the arcade example, the good question is - where
does the process run?<br>
> I think there are these possibilities in general<br>
> 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.<br>
> 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<br>
> a) nothing but the standard texture as long as they are not
playing it or<br>
> 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<br>
> 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.<br>
> 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)<br>
><br>
> All in all you are in synchronicity hell the more 'real' the
output for everyone gets because there can be no real simultaneousness.<br>
><br>
> So sorted by applications:<br>
> - Physics:<br>
> 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.<br>
> - Video:<br>
> 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.<br>
><br>
> - Turn based games<br>
> 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.<br>
> Same goes for<br>
> - co-browsing web pages, powerpoint projectors<br>
> Could be either server sided (like it is now via the php render
trick) or client sided (via the Rex trick)<br>
><br>
> 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?<br>
><br>
> 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).<br>
><br>
> Best regards,<br>
> Dirk/Barth<br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div></div><pre><hr size="4" width="90%"><div class="Ih2E3d">_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</div></pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>