ScummVM port to Java: possible?

All the inane chatter goes in here. If you're curious about whether we will support a game, post HERE not in General Discussion :)

Moderator: ScummVM Team

SimonKagstrom
Posts: 6
Joined: Thu Dec 27, 2007 1:18 pm
Location: Stockholm, Sweden
Contact:

Post by SimonKagstrom »

fingolfin wrote: 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).
OK, this would simplify things.

fopen, fread, fseek etc are supported by Cibyl, so it's probably easiest to use those - the reason I had to implement it a bit differently in Sarien (with the archive files loaded to memory -- still using the same file operations in the code) is to avoid having to answer "Allow reading a file?" dialogues all the time (and some performance advantages).

If someone decides to look at this I would suggest starting with disabling all engines except one of the smallest and continue from there. I would also disable things such as sound (which I guess can use some "null driver").

// Simon
SimonKagstrom
Posts: 6
Joined: Thu Dec 27, 2007 1:18 pm
Location: Stockholm, Sweden
Contact:

Post by SimonKagstrom »

I started looking at a J2ME port and have implemented enough to have it compile against the Cibyl subversion trunk with all engines disabled except AGI (I thought it would be good to start somewhere familiar :-)). It will not work yet since very little of the OS support has been implemented, but that should be possible. If someone is interested I can mail a patch against the scummVM subversion trunk.

However, there is one problem. The Cibyl translator is currently seriously slow, to the point of being unusable for projects of the ScummVM size, so I'm doing some major restructuring to fix this. This will take a while.

Also, after waiting for the translator to finish, there was a problem with a jump directly to a different function, which is difficult to handle in the translator. I think this can be simply fixed with GCC flags though.

// Simon
User avatar
md5
ScummVM Developer
Posts: 2250
Joined: Thu Nov 03, 2005 9:31 pm
Location: Athens, Greece

Post by md5 »

SimonKagstrom wrote:I started looking at a J2ME port and have implemented enough to have it compile against the Cibyl subversion trunk with all engines disabled except AGI (I thought it would be good to start somewhere familiar :-)). It will not work yet since very little of the OS support has been implemented, but that should be possible. If someone is interested I can mail a patch against the scummVM subversion trunk.

However, there is one problem. The Cibyl translator is currently seriously slow, to the point of being unusable for projects of the ScummVM size, so I'm doing some major restructuring to fix this. This will take a while.

Also, after waiting for the translator to finish, there was a problem with a jump directly to a different function, which is difficult to handle in the translator. I think this can be simply fixed with GCC flags though.

// Simon
Good news :)

When you refer to a "jump directly to a different function", do you mean that you got one function calling another?
SimonKagstrom
Posts: 6
Joined: Thu Dec 27, 2007 1:18 pm
Location: Stockholm, Sweden
Contact:

Post by SimonKagstrom »

md5 wrote: When you refer to a "jump directly to a different function", do you mean that you got one function calling another?
No, calls are fine but jumps from within one function to within another is not. An example in MIPS assembly is below.

Code: Select all

fn_a:
       li  v0, 0
       jr  ra

fn_b:
       jal fn_a    # this is fine

fn_c:
       j   fn_a    # this is not
(actually the fn_c example is a "tail call optimization" and that can be handled, but the principle is the same). I've not looked at what actually causes it, but first the translator slowness has to be fixed first anyway.

// Simon
jamesu
Posts: 1
Joined: Mon Jan 07, 2008 10:34 am

Post by jamesu »

http://www.cuppadev.co.uk/2007/11/22/fl ... -take-two/ may be of interest to you guy's. Whilst it might not be written in Java, it is somewhat close.

~ James[/url]
timofonic
Posts: 254
Joined: Thu Jun 01, 2006 2:18 am

Post by timofonic »

Many months since last message. Any news if Cibyl status about building ScummVM to Java? :)

PD: I also found Adobe Alchemy, a tool for building C/C++ to Actionscript: http://labs.adobe.com/technologies/alchemy/
What went wrong

While Adobe Alchemy is cool, it was a nightmare to work with. For starters, compiling in C++ was broken (as the new operator didn’t work), so i could only compile programs written in C. This obviously meant no ScummVM port, which would have been far more featureful.
http://www.cuppadev.co.uk/platforms/c-t ... e-alchemy/
SimonKagstrom
Posts: 6
Joined: Thu Dec 27, 2007 1:18 pm
Location: Stockholm, Sweden
Contact:

Post by SimonKagstrom »

I've posted the initial parts of a port (currently fails with a linking error, much to be done still!) to the tracker:

https://sourceforge.net/tracker/index.p ... tid=418823

If someone would like to take this up, I'd be happy to assist with cibyl questions.

// Simon
Maveric
Posts: 35
Joined: Wed Nov 02, 2005 9:34 pm

Post by Maveric »

*bumping*
User avatar
Longcat
Posts: 1061
Joined: Sat Sep 23, 2006 3:15 pm

Post by Longcat »

What exactly are you bumping?

If you want progress, do the work yourself.
User avatar
bobdevis
Posts: 567
Joined: Fri Jan 16, 2009 10:52 am

Post by bobdevis »

clone2727 wrote:
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.
Forgive me for this 'blast from the past' by quoting something from 2007.
I just wanted to point out that Java IS open source now (the official compiler and all the default libs that is).
It's still slower then native (obviously) and you still (obviously) need to install the environment before programs run. That penalty will always be there for not going with native binaries though.
Maveric
Posts: 35
Joined: Wed Nov 02, 2005 9:34 pm

Post by Maveric »

Jonatan wrote:What exactly are you bumping?
The thread.

If you want progress, do the work yourself.
Thank you for believing that I'm a programer...
User avatar
md5
ScummVM Developer
Posts: 2250
Joined: Thu Nov 03, 2005 9:31 pm
Location: Athens, Greece

Post by md5 »

Maveric wrote:
Jonatan wrote:What exactly are you bumping?
The thread.
Not helpful. At all. No, really, do you think that people will jump in to do this big and time-consuming task now that you've bumped the thread?
Maveric
Posts: 35
Joined: Wed Nov 02, 2005 9:34 pm

Post by Maveric »

md5 wrote: Not helpful. At all. No, really, do you think that people will jump in to do this big and time-consuming task now that you've bumped the thread?
I can hope, can't I?

Perhaps this project has been forgotten and somebody is capable of doing it, and willingly?

Other ports have been made.
User avatar
Longcat
Posts: 1061
Joined: Sat Sep 23, 2006 3:15 pm

Post by Longcat »

Maveric wrote:
Jonatan wrote:What exactly are you bumping?
The thread.

If you want progress, do the work yourself.
Thank you for believing that I'm a programer...
Neither of the devs were programmers until they learnt HOW to program either.
rented mule
Posts: 70
Joined: Wed Jan 25, 2006 5:27 pm

Post by rented mule »

Jonatan wrote:
Maveric wrote:
Jonatan wrote:What exactly are you bumping?
The thread.

If you want progress, do the work yourself.
Thank you for believing that I'm a programer...
Neither of the devs were programmers until they learnt HOW to program either.
No, I'm pretty sure they were programmers before they learnt how to program. It's a state of mind. You either have what it takes or you don't.
Post Reply