Author Topic: Japi Experiments  (Read 4183 times)

0 Members and 2 Guests are viewing this topic.

Arnold

  • Hero Member
  • *****
  • Posts: 599
Re: Japi Experiments
« Reply #30 on: December 01, 2016, 01:01:51 AM »
Hello,

I almost forgot about my main purpose for this topic. These are the C-examples which I found at www.japi.de ported to Oxygenbasic, modified a little bit sometimes. Some demos should be revised a little bit more. My main purpose here was to check how much of the C-code could be used unmodified. (about 90%) It should be no problem to convert the remaining code to nice Oxygen syntax.

The examples should run anywhere on disk or usb-stick. I tested them with Win 32-bit and Win 64-bit. The file japi.inc expects Japi.dll and japi.h in folder projectsC. If using a previous distribution of OxygenBasic then projectsC must be changed to projectsB in japi.inc

Although the examples run quite ok, there are some issues with the japi library:
using some japi commands incorrectly will cause a program to freeze and it will not terminate correctly. Closing an application via the debug window can also prevent gxo2.exe / co2.exe from terminating. I often had to use the task manager to kill a process. Sometimes there is also a problem with user access control. As japi calls Java there is much memory used with javaw.exe. And last but least there are many missing controls which would be necessary to create a more ambitious application.

Nevertheless it was very interesting to see that OxygenBasic had no problem with running Japi. No wrapping at all like in many other programming languages.

John

  • Hero Member
  • *****
  • Posts: 3000
Re: Japi Experiments
« Reply #31 on: December 01, 2016, 01:46:59 AM »
Quote
Nevertheless it was very interesting to see that OxygenBasic had no problem with running Japi. No wrapping at all like in many other programming languages.

As I mentioned before, JAPI is a socket interface to the JVM running in a JAR.


Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3581
    • Oxygen Basic
Re: Japi Experiments
« Reply #32 on: December 01, 2016, 09:19:58 AM »
Mike, these are 800x800, 100% quality png, sample sampled from a 1024x1024 texture.


Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3581
    • Oxygen Basic
Re: Japi Experiments
« Reply #33 on: December 01, 2016, 09:37:10 AM »

JAPI seems to require an internet connection, at least on my PC, which likes to isolate itself occasionally.

Arnold

  • Hero Member
  • *****
  • Posts: 599
Re: Japi Experiments
« Reply #34 on: December 01, 2016, 12:30:12 PM »
Hi Charles,

this really scared me and I immediately disconnected my pc from the net. But the demos worked ok. (sigh). So if an app using japi seems not to work maybe there is a messagebos or console window iconized in the taskbar. When porting the provided demos I sometimes found that some improper used statements could hang the program and I had to use taskmanager to kill the process of gxo2.exe / co2.exe.

I only used the java installation as provided by Oracle. I did not need a folder C:/JRE as stated in japi.de.
If I understand it correctly the used classes of the specified jar file in the developer's homepage are coded into japi.dll and there are some functions provided to call the classes, properties and methods. This could be interesting to learn some principles.

But I now think it would be more effective to learn Java and use and extend the classes directly.

Roland
« Last Edit: December 02, 2016, 01:21:43 AM by Arnold »

John

  • Hero Member
  • *****
  • Posts: 3000
Re: Japi Experiments
« Reply #35 on: December 01, 2016, 02:45:40 PM »
Quote
this really scared me and I immediately disconnected my pc from the net.

Don't be paranoid!

JAPI embeds a binary image of a JAR running a socket connection (server) to communicate with Windows.  Look at the code if you don't believe me.

Quote
But I now think it would be more effective to learn Java and use and extend the classes directly.

You should try B4J. (BASIC for Java) It's FREE and is done by the same author that does the commercial B4A. (BASIC for Android)



« Last Edit: December 01, 2016, 08:47:52 PM by John »

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3581
    • Oxygen Basic
Re: Japi Experiments
« Reply #36 on: December 02, 2016, 01:07:36 AM »
Chocolate Aero Delight: :)


Arnold

  • Hero Member
  • *****
  • Posts: 599
Re: Japi Experiments
« Reply #37 on: December 02, 2016, 01:31:40 AM »
Charles,

this is another very impressive view. Did you use zooming?

Roland

Arnold

  • Hero Member
  • *****
  • Posts: 599
Re: Japi Experiments
« Reply #38 on: December 02, 2016, 01:34:02 AM »
Hi John,

thank you for clarification. Sometimes I am very vague and inaccurate.

Roland

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3581
    • Oxygen Basic
Re: Japi Experiments
« Reply #39 on: December 02, 2016, 08:42:28 AM »
Hi Roland,

Yes, zooming in around 3000x. You can see the approx coords xo,yo and other metrics on this similar snapshot.

Photo quality function, ctrl-Q included

« Last Edit: December 02, 2016, 08:54:30 AM by Charles Pegge »

Mike Lobanovsky

  • Admin Support Member
  • *****
  • Posts: 1768
Re: Japi Experiments
« Reply #40 on: December 02, 2016, 03:32:11 PM »
Great! :D

Two more animated sweeties for your choco table using FBSL's standard include class COGLApp v1.1 (~50KB of raw code) that also handles GLSL.

If you have a nVidia GTX series video card then the apps (see the attached zip) shouldn't use more than 0.5% of your CPU though of course your GPU usage may rise up to 70..80% when the app windows are maximized:
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, 2 x nVidia GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

Mike Lobanovsky

  • Admin Support Member
  • *****
  • Posts: 1768
Re: Japi Experiments
« Reply #41 on: December 02, 2016, 04:09:43 PM »
Don't be paranoid!

John,

Well behaved MS Windows apps are expected to inform their users that they are going to use net interfaces/protocols for whatever purposes. Otherwise their behavior is presumed suspicious and ill-intended on default. Hence Charles' and Roland's natural base-instinctive actions that I can only share and approve of.

MS Windows offers a wide variety of native system facilities to ensure Win32/64 apps' interaction with their constituent modules, and using sockets for the apps' intrinsic needs is a sheer oddity. Probably you're used to this in your alien Andr-omed-oid environments but we -- in MS Windows -- aren't.

I thought we elaborated on that Java issue exhaustively when Rob was still around. Let Java live in my browsers once it's built in them as well as in the net itself by joint *nixoid efforts but that's about as far as Java is going to ever get on my machines.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, 2 x nVidia GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

John

  • Hero Member
  • *****
  • Posts: 3000
Re: Japi Experiments
« Reply #42 on: December 02, 2016, 06:03:08 PM »
My only point was that it was an internal socket connection and not a call to mother Oracle.

The other point I tried to make is JAPI has been dead for years and not using the modern Swing UI. I gave up on it years ago,

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3581
    • Oxygen Basic
Re: Japi Experiments
« Reply #43 on: December 04, 2016, 01:37:13 AM »

Thanks Mike, I look forward to analysing your glsl chocolate delights :)

Paired Spirals in the SeaHorse valley:


Mike Lobanovsky

  • Admin Support Member
  • *****
  • Posts: 1768
Re: Japi Experiments
« Reply #44 on: December 04, 2016, 07:17:40 AM »
I look forward to analysing your glsl chocolate delights :)

Absolutely no mystery there. The entire FBSL code is just an OpenGL canvas that only renders the final quad whose pixels are colorized by the fragment shader. It also supplies the shader with just two uniforms -- a vec2 with current horz and vert sizes of the canvas, and a float time in seconds (accurate to three decimal places) since the app started.

On default, the GLSL engine applies the entire fragment shader sequentially to each pixel in its intrinsic gl_FragCoord.xy or gl_TexCoord.xy range and yields the final color of this very pixel as the result of complex transformations that you see in this fragment shader. Neither C nor Asm can compete on the 4 to 8 CPU cores with GLSL speed (though fragment shader code is relatively easy to port to at least ANSI C) because GLSL uses hundreds if not thousands of cores available on modern (nVidia) GTX GPUs for parallel processing in real time, and even so GLSL programs may be difficult for your PC to render (see below).

Back to our OP Julias. What you see below is an animated 3D Juliabulb (cf. Mandelbulb) GLSL program. As usual for Íñigo Quílez with his ray marching techniques, the vertex shader is nearly empty while the fragment shader is a killer. :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, 2 x nVidia GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)