My FFMPEG player can  run any codec that ffmpeg supports. You can simple compile FFMPEG on any platform that you want to run the player on.

There are ways to get around licensing issues with FFMPEG, even if that means requiring a simple external installer not packaged with your program.

My opinion in regards to android Dev:

Because Im used to using LWJGL, I program in android directly. I find that the OpenGL handling is relatively similar. Also because android handles ogg natively, It means that you dont really need to learn any 3rd party libraries.

Its easy enough to handle touchscreen events (Activity class), as its not that different to mouse events in java (Applet class).

One other thing that may surprise a new developer is how android resets that application on orientation change, you just need to setup a few lines of code in the xml file (there is heeps of examples on the net) to make your application work like a solid game without any surprising behaviour.

I made a video player a while back using ffmpeg (link)
It wasnt the best didnt really spend much time on it. But it might be a good idea to look into ffmpeg command line tool.
you can feed any video compression type out to jpeg over a socket (aswell as .au for sun audio). And just have a server waiting to upload any images or audio data.
On stopping the video you can simply close the port, and ffmpeg will close.
you can also set a whole bunch of custom settings into the command line tool, also read the video information with the ffmpeg output.
It would also mean that it would automatically updated with any new release of ffmpeg.
The bottle neck is weather or not FFMPEG real time encoding is fast enough. That said, even if the computer isnt fast enough you can always change the export screensize, or framerate so that even the slowest computers can view something.

Released the final version of this app. Going to start workng on something new.

Note to anyone thats interested. Word searches are in very little demand 

edit: *Deleted didnt check the dates

It seems all that is needed is arrows and a select button.

So I think you could use the dpad without problems, and remove dependency on the touch screen by default. As for touch screen devices have no extra buttons on screen, if people touch around in the corner areas, the character moves in that direction, or touches the center he shoots/selects.

Most of the work would just be to setup a view to display a bitmap with the current pixels values.

My opinion might be tainted by my new found excitement with android. Have you considered porting it?
It seems like a simple enough game to release on android, and would be really awesome to see on a portable device.

If you ever want quick android assistance, like copy and paste code snippets and such. Feel free to add me to MSN (msn contact link is under my image on the forum post).

I was thinking I would do this aswell, but I purchased an Asus Slider. Money well spent. Its really great for development to actually have an android device. The emulators are so slow and really discouraging. I also find that once I have invested money in something I am more likely to stick to it. Either I waste money on movies or a new tech device to develop on . I was always hoping to get into android dev, but getting the android device is what pushed me over the edge.

I tested 'Hexara' this game would be perfect for android.

Yeah i take in a list of words from a text file. This game is only a free test game, but I will be releasing an amped up version to purchase with more word lists and extra game modes.
The game automatically fills words into the table then fills characters in the remaining empty spots.

Fun game.

The sound adds a lot to the atmosphere of the game. It will defenitely be a lot better with ogg support as the load time is a considerably excessive.
That said with all the graphic effects, I didnt notice any lag or flickers.

Running on:
OS: Win7
Browser: mozilla firefox.

Started a simple word search app to get myself familar with the Android market place.

Even though its still in beta version you can play a complete game on the hardest level.
Planning on adding a timed game mode.

Android Market Page

Youtube demonstration

Happy to hear any ideas of how to improve the game.

No system of government is perfect. Corruption is inevitable, the only thing that the people (might) have to protected themselves is a united "faith" in a constitution, as a piece of paper has no power in itself.

I know im adding to the off railing of this thread, but I just dont get the point of any extremest views, as the "right" way.

Personally, I think it would be great to have a front page with a menu.

Something clean, non-intimidating even for non-developers, along the lines of:

-- MENU BUTTONS: -- [PLAY GAME] [GAME DEVELOPMENT] [FORUM] [ABOUT JGO]

[PLAY GAMES]
* Links to a clean game navigation tree.
* showcase quality games (applet only).
* Should give broader JGO traffic

[GAME DEVELOPMENT]
* list to introduction java tutorials (setting up, basic game loops)

[FORUM]
* This forum, (if it aint broke, dont fix it)
* Also maybe move the game showcase up the top of the forum, in case guests want to ask about game issues, or advise.

[ABOUT JGO]
* Blah blah blah

and maybe a large image of the pac ghost on the front page aswell.


Also Riven in regards to your current portal page. It might be a good idea to show a different showcase depending on the viewer. If its mobile, then mobile. If Desktop...
It does look great. As far as using the features are concerned, I'd probably be sticking mostly to the forum. So I think It really might be a better Idea to keep games, and development seperate. This way even an 8 year old could jump on the site, and have a fun time just going through games.

Looks like a really great 3D tool. Looking forward to the Java documentation.

I guess Im going to drop the job for the moment, its going to be too much work also implementing the 3D formats along with the model viewer program aswell.

I was hoping to package the file support in the applet itself. Ill ask the client if he has access to the server, maybe installing a converter server side would be easyer.

Thanks riven.

I tried this and Meshlab. Except they dont support UV co-ordinates.

I need UV support as Im trying to develop a realtime online model viewer for a client.

I am currently working on a job, I need to load some model formats into a java object. And I dont have the time to read up on each file specification.

I need support for vrml, 3ds, stl.

Either develop a class to load the models into, something like (seperating group by texture):


Or alternatively, create a converter to export them as OBJ with support for UV texture co-ordinates.

I honestly think they are avoiding questions, because the technology is relatively simple.
Its just an advanced culling algorythm done on each pixel (instead of the frustrum). Its the logical next step. Geometry is no longer the bottle neck.

NEW VIDEO:

http://www.youtube.com/watch?v=JVB1ayT6Fdc

The webcam is ment to.
But Im not sure about my FFMPEG binary. I only managed to get 1 static build of FFMPEG.
And I dont even know if its 32bit or 64bit. I dont want it to install on machines if it doesnt work.

Also in a similar program, I have started working on a webcam recorder app for a client.

Just so everyone knows. There is alot of simple java jobs on freelancer.com. IMO its a great way to earn a little bit of extra cash.

Wouldnt it depend on the resolution of data. If pixels (atoms) are storred at a further distance from each other, and a ray collides between pixels with a normal facing towards the ray, it would make sense that the resulting color would be a gradient between the atoms.

I think it makes sense that static objects are going to be easyer when developing an engine. But like I said before, even if scenes were static, you could always send a texture buffer, and depth buffer to hardware to handle post polygon rendering.

Its not technically unlimited. Just like Google doesnt technically hold all the data on the internet. Its just a advanced culling algorythm done on ever pixel. Instead of the Hardware Buffer approach, its all software.

Also I dont see how hard it would be to store meshes broken up into (rgb)cube diffuse maps + (grayscale)cube depth map + (rgb)cube normal map. As all meshes are basically 1 sided hollow objects.
Not saying this is how the engine does it. (Just exploring ideas)
Using this method: objects can be scaled down without problem, they are given a bounding box by default. the processor challenge comes when firing the ray into the depth map, It shouldnt be hard to group data in a cleverly indexed way.

As for data storage. If all models are stored as cube maps with a cubemap for its depth buffer. Object geometry detail would be dependant on distance, and not noticeble by the eye. Photo quality graphics.

Get ready for a Porno Industry revolution.

Not if you render to an image, and at the same time render the distance to a depth buffer.
Then pass the scene to DirectX or OpenGL for character handling.

But I honestly dont think animation would be much different then scene handling. When a bone moves, a new bounding box would need to be calculated. And when casting the ray in the call to render, you would need to do an extra calculation on the likely group of pixels.

Damn, the applet uses Java sound to capture from the Mic, so it may be a problem with Java, If you have the latest version of Java then Its probably not going to be fixable. Thanks for reporting the bug.

2hard 

is this for fullscreen openGL?

also if you really want to you can take screen shots of your own by copying the back buffer into images. then use virtual dub to record it into a video.

Also while were on the topic, is it possible to get LWJGL to access the image buffer while another applications is rendering with OpenGL?

Yeah its a handy little tool
I also use it to encode video for the screencast applet.