|
|
|
|
Development Log | |
|
|
|
|
Dream Land Java :: Development Logs :: Recorded Sessions
One of the best known morals of the Dream Land Java Project was to create games that can be played right inside your browser -- "no" downloads necessary. (At least, no executables or security threats.) The reason for this is simple: people are less want to play something they have to be wary of. Take the risk out of it, and you open up your potential reach. And yet, the internet still has its lazy types. Hell in a hand basket, folks, and I am unfortunately allying with one of the very causes. I, of course, am referring to recorded sessions of Kirbj on YouTube. Why? Just Why?Reach has very little to do with it. It is proven that social networking only has any noticeable impact if you put effort into it. I've read it takes hours of dedication to get any real business advantage. It also requires acting as though one does not completely and utterly detest those vainglorious mouth-breathers. Sorry, but I'd rather not be popular. I have ulterior motives for opening (at my most horrid admission) an official YouTube channel for this site.
How?I found that most continuous screen-capturing software hogged too much processing power to use, and even then, it wasn't guaranteed to work right. The capture software or the game could slow down, resulting in either a skip or a pause in the video. Solution? The software I used to capture the video is entirely custom-coded. (Well, I bummed some parts of a Swiss dude's AVI writer, but since he mostly dealt with QuickTime and had it largely untested with Microsoft, I had to rewrite all of the hard stuff, anyway.) First, things start with the AppletViewer. It is software packed with the JDK (Java Development Kit) which allows an Applet to be run outside of a web browser. Also, it is its own Java class. Thus, I created a Java application which chained to the AppletViewer after doing one thing in particular: disable security. Normally, Applets are restricted in doing this, but this wasn't an Applet (yet) -- it was a local Java application. With security disabled, the system was free to write the captured audiovisual data. Sound could be done in a lot of ways, but I opted for the easiest: mic, and only the mic. The speakers get picked up through it as does my off-the-cuff commentary. Now, I could have tapped into the speakers directly and mixed in purer sound, but that would require far more processing power (or a better sound card, at least). I could have recorded only from the speakers and dubbed commentary over it later at my leisure, but that would result in a much less organic feel. Actually, that woulda been the easiest route. I guess I went with #2. The video is where things get fun. To avoid any sort of latency problems, video capture is tied in directly to the game's timer. It only writes whenever the game draws; the two are not independent of one another (as an external capture system would do). Actually, the video capture only writes every other time the game does, resulting in half the frame rate. As a result, blinking enemies in the captured vids sometimes appear completely normal! To get the most out of the speed, I tied the code directly into some Sun specific classes. There are a lot of undocumented classes that Java's maker Sun uses to interface the language with specific target machines. It is subject to change at any time and is thus not intended for released code. Not released code, tho'; my own personal video-capture system. Previously, I had utilized the traditional method, which resulted in garbage collection (created and released data) very often. By reading the raster data directly, I could forgo creating any new objects, and presto! No new objects, no garbage collection, no reduced speed. The most important steps, I found, had nothing to do with the code itself, but rather playing with how the code is executed. Java defaults to what it feels is optimal parameters, but I had to play around with memory limits and what and how much to garbage collect to get my videos as blemishless as possible. It seems these parameters are always changing, too. I guess it depends on what kind of mood my computer is in, what the most recent compilation of the project looks like, or how much footage I'm taking. This system actually lead to a great deal of improvements in the game -- even when uncaptured -- since I had to try to get every ounce of speed out of it Java would allow. For the most part, this concerns the sound, which previously loaded on-the-fly. I always knew it was a problem, but I had it to a point where it was seamless enough. Not so seamless when most of your cycles are going to writing a video stream, tho'. I've finally got them to a point where they are preloaded properly well beforehand, thus ensuring some smooth runnin'. Can I play, too?Right now, there are no plans on releasing this code for others to make their own fun sessions. That would require adding creature comforts, like controls that don't involve pressing esoteric keys to achieve desired effects. Pfft, not in my debugging world~! Share my shame; check out Reality's End official channel!
No discussions exist yet for this. You can start one if you would like. |
||||||||||||||||||
| Copyright © 1999-2022 | |||||||||||||||||||
