ScummVM port to Java: possible?

timofonic · Post by **timofonic** » Tue Dec 18, 2007 1:11 am

Hello.

While I don't care of Java and I prefer native code, there are certain devices that make use of it in an exclusive way. An example of this is Android.

I found two projects for porting to Java bytecode.

NestedVM: Converts MIPS code generated from GCC to Java bytecode. The generated code seems to be 5x ties slower than the original.
Cibyl: Builds C to Java, it has limited C++ support.

What users think of a Java port without need to rewritting? And the ScummVM Team?

I found this exploring the CVS of Atari800, an emulator for the 8bit family of Atari computers and Atari 5200 (same architecture).
http://atari800.cvs.sourceforge.net/ata ... c/javanvm/

I found Cibyl in some blog reply by salty-horse when mentioning NestedVM. It's mentioned in some forum post too:
http://forums.scummvm.org/viewtopic.php?p=9939

Some apps that use Cibyl:
http://spel.bth.se/index.php/Cibyl#Showcases

Some more URLs about NestedVM:
http://wiki.brianweb.net/NestedVM/NestedVM

Regards.

clone2727 · Post by **clone2727** » Tue Dec 18, 2007 2:14 am

ScummVM probably will not convert to Java. Java's not as portable as it says on its label and it's much slower. But, you are welcome to use the code however you want. It's possible to do it.

But, this has been mentioned several times in the past. Please search for it.

fingolfin · Post by **fingolfin** » Tue Dec 18, 2007 11:09 am

See http://forums.scummvm.org/viewtopic.php ... light=java

Post by **eriktorbjorn** » Tue Dec 18, 2007 12:04 pm

fingolfin wrote:See http://forums.scummvm.org/viewtopic.php ... light=java

That thread seems to be about porting ScummVM to Java, though. I thought this one was about compiling C/C++ to Java bytecode. Apparently Sarien has been ported that way, but I don't know how much work that was.

Tramboi · Post by **Tramboi** » Tue Dec 18, 2007 1:51 pm

I think Comeau C++ can compile to C code (it can use GCC or MSVC as backends if I'm correct).
Maybe doing this then cleaning the code and chaining with Cibyl might do the job

timofonic · Post by **timofonic** » Tue Dec 18, 2007 6:45 pm

clone2727 wrote:ScummVM probably will not convert to Java. Java's not as portable as it says on its label and it's much slower. But, you are welcome to use the code however you want. It's possible to do it.

But, this has been mentioned several times in the past. Please search for it.

I know it, I didn't said Java is the best thing ever. I'm against stuff like Java or .NET, I prefer native binaries and Open-Source is my priority. I just mentioned it because it's the only solution for running 3rd party apps on certain systems.

eriktorbjorn wrote:
fingolfin wrote:See http://forums.scummvm.org/viewtopic.php ... light=java
That thread seems to be about porting ScummVM to Java, though. I thought this one was about compiling C/C++ to Java bytecode. Apparently Sarien has been ported that way, but I don't know how much work that was.

Yes, I did think that this maybe could be an easy solution for having ScummVM ported to Java. Just see it as another supported platform, like the iPhone.

I don't know the difficulty of this, but it's an interesting tool for porting stuff to java bytecode without worrying on the language pain of Java itself.

clone2727 · Post by **clone2727** » Tue Dec 18, 2007 8:19 pm

The Madventurer wrote:I'm against stuff like Java or .NET, I prefer native binaries and Open-Source is my priority. I just mentioned it because it's the only solution for running 3rd party apps on certain systems.

I agree.

Reckless · Post by **Reckless** » Wed Dec 19, 2007 12:02 am

Why be against something that makes life easier for a developer thus [appropriately] allowing them more time to do more or provide a better product (well, that never happens but hey!).

Tramboi · Post by **Tramboi** » Wed Dec 19, 2007 9:13 am

Reckless wrote:Why be against something that makes life easier for a developer thus [appropriately] allowing them more time to do more or provide a better product (well, that never happens but hey!).

Yipeee we're in the Junkyard thus I can answer!

"Because there are far more users than developers and they don't care about ease of development : they want features, usability and performance".

Why stop there at JITTed language and not using Python or Ruby then? They are even more convenient! And even slower

SimonKagstrom · Post by **SimonKagstrom** » Thu Dec 27, 2007 1:36 pm

eriktorbjorn wrote:
fingolfin wrote:See http://forums.scummvm.org/viewtopic.php ... light=java
Apparently Sarien has been ported that way, but I don't know how much work that was.

As the author of Cibyl, I can probably comment a bit on this and the possibility of porting ScummVM to J2ME devices with it. As for the effort of porting Sarien, I'd say it was pretty small. The issues I had to deal with in decreasing importance were:

1. File handling. The J2ME "FileConnection" API is not very much like ANSI C file operations - in particular file seeking is not possible without some trickery. Even with the trickery, there is the problem of the user having to allow *each file open* in a dialogue and the operations were also quite slow.

What I did instead was to create an ar-like archive format to put the games in a single file which is loaded to memory and handles the file operations through that (this is now pretty transparent in Cibyl, but was developed for Sarien).

2. Savegame handling. I struggled a bit with this at first (it uses J2ME "RecordStores"), but I've since improved Cibyl and it now just looks like any ANSI C file operations.

3. Implementing the platform support for J2ME. Not difficult, but obviously had to be done. Sound support was a bit tricky and finally added by Zsolt Gurmai, but the other parts were pretty simple.

4. Text input. I implemented a t9-like system that uses the games' dictionaries and works pretty well.

5. The Cibyl compiler is currently pretty slow, which can be a bit irritating if you are compiling "big" programs like sarien on a slow machine.

I don't know the ScummVM source, but I presume it's significantly larger than Sarien. You would probably have the same file handling problems as I had, and it could perhaps be a bigger problem in ScummVM if the games are larger (might not fit in memory). As someone said, the Cibyl C++ support is more limited than the C support - in particular it has only very basic runtime support (new and delete, nothing from stdc++ yet).

If you don't depend on C++ standard libraries, compiling it is certainly possible. I've also ported the Frodo C64 emulator which is written in C++. It's currently stalled because of a pretty strange bug which I *think* is a GCC bug, but I've not been able to confirm that. It compiles and "boots" to the C64 basic at least.

// Simon

Tramboi · Post by **Tramboi** » Thu Dec 27, 2007 2:50 pm

By the way Simon, I'm very impressed by Cybil.
Is it a one-man project?
Why did you choose MIPS? Sentimental decision?

SimonKagstrom · Post by **SimonKagstrom** » Thu Dec 27, 2007 3:00 pm

Tramboi wrote: Is it a one-man project?
Why did you choose MIPS? Sentimental decision?

Well, it's open source so anyone can contribute

. In practice, I've written basically everything except a set of bugfixes and some of the library support (most of which is imported from other sources).

MIPS was chosen because I know the architecture quite well and as it's also fairly "similar" to Java bytecode (i.e., easy to translate - no partial register updates, special flags registers etc). NestedVM also translates MIPS->Java bytecode and predates Cibyl, but I actually didn't know about it when I started working on Cibyl. I looked at a few other architectures, but did not find anything that had any significant advantages compared to MIPS when translating to Java bytecode.

Obviously if someone would like to try to base a ScummVM port on it I'll give as much support I can.

// Simon

fingolfin · Post by **fingolfin** » Fri Dec 28, 2007 9:38 pm

SimonKagstrom wrote: I don't know the ScummVM source, but I presume it's significantly larger than Sarien.

Sarien is now the "AGI engine" in ScummVM, one o 17 engines we include. So yes, we are a quite a bit larger

SimonKagstrom wrote: If you don't depend on C++ standard libraries, compiling it is certainly possible.

We do not use the C++ standard libraries at all, for portability reasons. Also, we already provide custom file system, savefile and "input file" handling APIs, as many platforms have problems with those. (Right now, our File API still requires fopen, though -- but this is going to change, too).

Terming Boss · Post by **Terming Boss** » Sat Dec 29, 2007 1:57 am

Hello!

I am a very big fan of the ScummVM engine, and I use it on my computer, on my PSP and even on my Symbian phone!

I am glad to see a thread about ScummVM for J2ME, because I have been thinking about this for some time.
My brother have a phone that only support J2ME, and he really wants to play the good old adventures on it.

I would like to participate in a J2ME port of ScummVM.
At the moment I don't know so much about J2ME, but I have learnt Java in school and I am reading about J2ME now.

Will this port have to support all the 17 engines inside the ScummVM?
I think a J2ME port will only be able to run the first games from LucasArts and Sierra at an acceptable speed.

How many people will work on the J2ME Port?

Post by **eriktorbjorn** » Sat Dec 29, 2007 7:23 am

Terming Boss wrote: Will this port have to support all the 17 engines inside the ScummVM?

Every game engine can be disabled, as well as some optional features, like support for compressed sounds and graphics scalers. On Unix-like systems, this is done when running the "configure" script, before compiling ScummVM.