Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
131 user(s) are online (122 user(s) are browsing Forums)

Members: 1
Guests: 130

samo79, more...

Support us!

Headlines

 
  Register To Post  

Jamiga GUI/sound support
Just popping in
Just popping in


See User information
Moved here from here

Quote:

kas1e wrote:
@Jaokim

Can Jamiga in current form run some GUI kind code and handle graphics/sound and stuff ? I mean i thinking about porting of some Java based games, so want to know how much to do (and what need to implement) to make port of some basic/initial java-game to os4 ?

There is some GUI support in form of AWT stuff. Look at classpath examples for stuff that should work. No sound though.

Some work has been done since 0.0.6, but not much in regard to graphics or sound (i.e. nothing). But it'd be an interesting thing to try and make some real stuff work for an upcoming release.

The next release (0.0.7 or so) is planned, and will include a few basic stuff like jar-loading, MOS and AOS3 support, networking, which is mostly done already. Following version will hopefully add some content, and a game would certainly be good content.

Do send an e-mail to the Jamiga mail group and perhaps we could collaborate.

Go to top
Re: Jamiga GUI/sound support
Home away from home
Home away from home


See User information
Nice to see more progress with this.
Hope you get more helpers.

X5000
Go to top
Re: Jamiga GUI/sound support
Home away from home
Home away from home


See User information
@jaokim
Quote:

Some work has been done since 0.0.6, but not much in regard to graphics or sound (i.e. nothing). But it'd be an interesting thing to try and make some real stuff work for an upcoming release.


I assume it will be not the trivial part, as for sound need to use AHI, for graphics need to choice what to use: plain graphics/inutition/etc libs, sdl, or opengl.

I know, the best way to have all the answers its just do some google, but well, while we start to talk about, imho will be better if you will explain all the stuff here, so not only i , but others will have a clue about technical details. so, correct me if i wrong, but that how java on amiga should works:

- Java VM which are "library", and always in the memory, like java.library

- Tons of classes, which implement all what need it for.

- All java apps can be as classic .exe file , which will use all the classes and java.library, and also, can be not as .exe, but just as . java. files.

It is right ?

What Jamiga2 have already in compare with say latest user-java archives for win32/unixes (i think current one are 1.6.x?) and what the most important parts are missed ? Only sound/graphics parts are missed ? Is there any GUI related parts as well, where we need to implement all those gadgets/menus/etc ?

Just for case i go at happypenguin.org, and do search on all the games which want Java (there is result). You can see there is lots, but for begining, we can choice some crappy-small-easy games, which just have some privimite graphic and sound, like:

Boomberman - Jre1.1 minimum

Boxit - Jre1.4.2 minimum

Cassiopeia - Jre 1.4 min

Colossus

DroidQuest - Java2 env 1.4.2 min

Dusk - Jre 1.3+

So we can choice few of them with sound, and give them a go.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Jamiga GUI/sound support
Just popping in
Just popping in


See User information
I'll try to answer any questions. I have also gathered some questions at the Jamiga2 project page, but they're not very technical.

Jamiga can simplified be said to consist of two things:
* The JVM, Java Virtual Machine. This handles execution of the compiled Java programs, the bytecode.
* Class libraries. The class library is what builds up Java. These are all the standard Java classes for handling lists, threading, file I/O and other standard stuff. Jamiga uses the GNU Classpath class libraries, and we're also looking in to using Oracle's OpenJDK.

What is a Java program?
A Java program consist of class-files, files with bytecode instead of machine code. Class files can be run by issuing a command like
java HelloWorld
This will start a Java Virtual Machine process, that tries to find a class named HelloWorld.class with a main-method to run (much like C's main-function).

Java applications usually come packed in so called JAR-files. This is basically zip-archives that contain several class files. The aim is of course that these Jar-files can be double-clicked and started like any Amiga program.

So Java program does not have a single .exe-file -- rather they have class files run by the main Jamiga executable, "java". These class files are the same, no matter where they are run, be it AmigaOS 4, MorphOS, Aros, Windows or MacOS.

What does Jamiga's java.library do?
The java.library and Jamiga's other libraries (javanio, javanet, etc) are only for internal use by Jamiga. No other programs should use them. All Jamiga stuff could easily reside in one big executable, but the library usage is consistent with how the GNU Classpath is done.
The java libraries (java.library and so on) contain code that "hooks" the class libraries to native Amiga stuff (so called native methods). So whenever you in java do:
java.io.File = new java.io.File("myfile.txt");
a call is made to IDOS->CreateFile(); which reside in javanio.library.

How does graphics in java work?
GUI and graphics stuff is supported in the standard Java classes using what is called AWT (Abstract Window Toolkit). this contain classes for buttons and windows and such GUI stuff. There are also methods for primitives such as "draw me a line"-methods.
The current Jamiga AWT implementation uses GadTools and Intuition. We're currently looking at using MUI for this, since that is supported by all Amiga platforms.

There are also classes for OpenGL and sound stuff -- some of it is standard official JDK-stuff, and other is un-official. But basically its only a matter of writing native C code to create the necessary native methods.

What can Jamiga currently do?
If one were to try and run any of the games you suggest, it should preferrably not run with a "ClassNotFoundException", or just plainly crash.
Currently Jamiga supports threading, some AWT/graphics stuff, file I/O and upcoming network stuff. What's missing feature wise is sound support, some graphics stuff (can't say exactly what atm) and other low level/internal stuff.

If these games only require Java 1.4, the aim is to have them running. If they require 3rd party libaries, there is a bit more work to do. But once we get Java 1.4 running, 3rd party libraries is as easy/complicated as porting other applications.

Perhaps not very good answers. Its rather hard to tell what will work, and how much work it will be to get things to work. But it should be possible to get things running without for instance sound support, and only create empty native methods.

But I doubt that they will run without adding more stuff to Jamiga.

Go to top
Re: Jamiga GUI/sound support
Home away from home
Home away from home


See User information
@jaokim

Quote:

This will start a Java Virtual Machine process, that tries to find a class named HelloWorld.class with a main-method to run (much like C's main-function).


So, every new java applicatoin will all the time run JVM ? I.e. if for example i will run 10 hello words, that mean that it will run 10 processes of JVM => everything will be very slow. Or if i will run many apps at one time, still, only one JVM process will be in memory, which will handle all of this ?

As you say JVM are interpretator of byte-code,and so, 10 versions of interpretator at the same time, will be not the same as if someone will run 10 versions of helloworld done on C, and done as plain aos4 elf binary ?

Quote:

Java applications usually come packed in so called JAR-files. This is basically zip-archives that contain several class files. The aim is of course that these Jar-files can be double-clicked and started like any Amiga program.


I.e. just via tooltypes settings in the OS ? I mean maybe it possible just to make a JVM as independed binary/libary/process, which can be runs from says startup-sequence, or just from Kickstart directory, and so, for every .jar files (and even just .jar files renamed to .exe), java interpretator can handle it and processed through one process).

Quote:

The current Jamiga AWT implementation uses GadTools and Intuition. We're currently looking at using MUI for this, since that is supported by all Amiga platforms.


As far as i see from all the tests with porting apps from os3 to os4, gadtools have some bugs by itself (like non rounded areas there and there) Intuition are good way, but MUI for sure will be better, as it will works everythere.

Quote:

There are also classes for OpenGL and sound stuff -- some of it is standard official JDK-stuff, and other is un-official. But basically its only a matter of writing native C code to create the necessary native methods.


Imho for now all what is really important, its just finish fully AWT/Graphics class, so, we can run any game without sound and without opengl (and that will be a start for not only games, just with games as tests we can prepare jamiga for Eclipse and stuff)

Quote:

But I doubt that they will run without adding more stuff to Jamiga.


Can Jamiga currently give some debug output to serial or kind, where we can see what is missed after running of game ? I mean we will take some small game, run it, it will not works, and so, how we can understand what is missed and what need to add ?

Anyway, all sounds promissing, good that you not give up with it and works on it all the time.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Jamiga GUI/sound support
Home away from home
Home away from home


See User information
@jaokim

It's great to hear that JAmiga is progressing. Just one thing though, while AWT is a good starting place for JAmiga, it was superseded by Swing years ago. Even the small connect 4 applet that I wrote at university in 2002 used Swing. Have you had a look at what Swing needs?

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work
Go to top
Re: Jamiga GUI/sound support
Not too shy to talk
Not too shy to talk


See User information
If wikipedia it's not wrong, swing it's written in java
(but I think it use some AWT part), so there is no need
to port it, but only the libraries it use

Go to top
Re: Jamiga GUI/sound support
Home away from home
Home away from home


See User information
Quote:

pvanni wrote:
If wikipedia it's not wrong, swing it's written in java
(but I think it use some AWT part), so there is no need
to port it, but only the libraries it use


Correct. Swing does its own rendering, which goes through a 2D graphics library. It's the native part of that 2D library that is needed. I don't know if the native part is also shared with AWT, which also needs to do some rendering in addition to using native GUI gadgets.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work
Go to top
Re: Jamiga GUI/sound support
Not too shy to talk
Not too shy to talk


See User information

Hey guys,

I've used a classic Amiga web development system called
"WebLord"...

http://ringlord.com/weblord.html

A while ago, the developer switched this system to Java
from Amiga C code.

Without any graphics, etc., I am wondering whether the new
Java versions this software should be able to run on
JAmiga.

What do you guys think?

Thanks,

PJS


Go to top
Re: Jamiga GUI/sound support
Just popping in
Just popping in


See User information
I couldn't find any jar-file on their webpage, but if it's only text based, and does not use any to advanced stuff in Java, it should run. Its certainly an interesting program to use as a test-case for a non-GUI enabled JAmiga version.

Moreover, the link pointed me to a "Retrotranslator" which might be used to enable post-java 5 programs to work. Needs a closer look... :)

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project