Just a couple of technical questions...

D'raekmus · **Joined:** Sat Nov 29, 2008 2:47 am **Posts:** 35

I've heard of some people making noises about making shards, so I have a simple question:

Would it be possible to use the files from CC (the .age files in particular) in an OU server, just to test functionality? I understand it's against licensing. If this is implausible, even for a single-user testing environment, where may I find Ages to use as test platforms (I.E. testing new functions.)

And, as another question: I'm aware that Bink videos (used for the Linking panels, and animated textures, I believe) Is not open, so it cannot be implemented (to my knowledge)

So, here's what I'm wondering: How hard would it be to use, say, an open-source media player, such as VLC, as the animation program (VLC can also support a wide variety of videos, allowing users to make high-quality MP4, Xvid, etc).

I mean, integrating VLC's media capabilities could also bring back custom canten songs via live streaming. It might also be possible to add video playback abilities to KIs, as well.

So, those are my questions for now. How feasible are these, and, if so, how difficult would implementation be? I'm considering taking up a C++ and maybe a Python class so that I might be of some... small help in the future. Besides, I think it'd be fun to see how it's put together.

JWPlatt · **Posted:** Tue Apr 12, 2011 3:03 pm

The Bink format was reverse-engineered by the FFmpeg project and Bink decoding is supported by the open source libavcodec library. Our focus at OpenUru.org for the initial open source release of the CyanWorlds.com Engine was to give you the ability to open a shard with a working MOSS server and a working MOULa client. Bink support was not critical because it only meant being able to play the opening videos. However, Bink videos can be played on any Plasma surface, so it is considered essential to support it from a feature perspective for new content. We plan to get this going as soon as possible. Any developer is welcome to join the effort in speeding up the process.

For your content, you can use everything downloaded from MOULa for your testing.

D'raekmus · **Joined:** Sat Nov 29, 2008 2:47 am **Posts:** 35

Ah, thank you, Mr. Platt.

Now... just to get off my lazy rear and actually learn to program XD

Nye_Sigismund · **Posted:** Tue Apr 12, 2011 3:24 pm

JWPlatt wrote:

However, Bink videos can be played on any Plasma surface, so it is considered essential to support it from a feature perspective for new content.

Moving linking plates. That's one of the more important things it can do. Also, something like the message left for Catherine on Myst. Might as well mention this so that people can stay in the loop of what Bink support means.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

libavcodec support should allow a generic plLayerVideo that can handle any video file the artist wants. Currently Cyan has two totally different video implementations (BINK and win32 AVI). IMO unifying these is a Good Idea (tm).

D'raekmus · **Joined:** Sat Nov 29, 2008 2:47 am **Posts:** 35

Thanks for that info, Paladin.

So, the basic idea is to provide a wrapper that lets CWE's builtin video player run libavcodec, at least, until a modification is written to allow the player to run the lib?

I'm sorry if I seem a little ignorant; I'm not very programming-savvy, so I'm not sure how hard these steps are, though I'm willing to understand what kind of steps are needed to reach the end goal.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

Most video APIs are (reasonably) similar, so we can hopefully just tear out the existing ones and plug libavcodec in directly. It's probably not hard, but I haven't looked at it yet (working on some other issues first).

D'raekmus · **Joined:** Sat Nov 29, 2008 2:47 am **Posts:** 35

Thanks for the info, Paladin.

I have another question: Is it possible to build x64 client binaries now? I mean, I've seen some beta PhysX packages for 64-bit systems.

To be honest, I might be interested in helping provide some 64-bit programs (assuming I can find a free or relatively inexpensive compiler to build the exe files for it. My college offers a copy of VisualStudio 2010... but only the x86 version.)

I believe the extended array of functions 64 systems allow would allow Uru to run a little faster on the enhanced systems. And, by allowing native x64 compatibility, Uru would also circumvent a common problem I've read regarding the systems (32-bit programs sometimes run very slowly).

However, I don't know how much work would be put into converting the source code over (a simple "x64" flag, if I'm reading the Gcc manual correctly. But, not entirely sure.), but, if it's relatively simple, I could do it, and give some kind of small contribution back, for those few who run 64-bit systems.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

There are a huge number of assumptions in the code about 32-bit. 64-bit support will happen eventually, but probably not until around the timeframe when we're working on mac and linux support, as 64-bit is still easier to work with on those systems. In other words: several months out. Hopefully many of the 64-bit issues will be noticed as we work on cleaning up other parts of the code, but the majority will probably go ignored until I start trying to build it in my 64-bit linux environment.

Just a couple of technical questions...

Who is online