Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java Library written IN Java  (Read 7921 times)
0 Members and 1 Guest are viewing this topic.
Offline SirMathhman

Junior Newbie


Exp: 3 years



« Posted 2016-03-20 15:32:51 »

The other day I was considering the fact that most of the Java libraries that the community uses - they all use native code. So I was thinking, - why doesn't the community together write a rendering library, or something like that, and put it all together. So I realized that I could have an engine that has 3 components:

The rendering:
The math:
The physics:

But then again, this may take a long time to do. So I would really appreciate the community's support for this!

Also at the same time, OpenGL is not community - based, and cannot be built upon freely.

https://github.com/RTEKGamesInc/MangoOrange
Offline theagentd
« Reply #1 - Posted 2016-03-20 15:38:29 »

The rendering:
The math:
The physics:
JOML is already fairly complete for the math part.

Myomyomyo.
Online Riven
Administrator

« JGO Overlord »


Medals: 1324
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2016-03-20 16:56:42 »

Also at the same time, OpenGL is not community - based, and cannot be built upon freely.
While it is not community based, it can be built upon freely.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ecumene

JGO Kernel


Medals: 195
Projects: 4
Exp: 8 years


I did not hit her! I did not!


« Reply #3 - Posted 2016-03-20 21:18:29 »

Java already has a built in software renderer called Java2D, (java.awt, java.awt.geom, java.awt.image) which doesn't rely on native libraries.

If you're talking about using hardware acceleration, even if you do write a rendering library it's going to need some form of machine-code. Meaning natives for different system architectures and all. persecutioncomplex

I'm not bashing your project it's always cool to see a new software renderer now and again! But the definition of software rendering means it's all done on the JVM side, meaning no GPU! The performance will not compare to LWJGL.

If you write a good graphics library that's decoupled from the AWT framework that'd be cool! (Assuming it can render to a AWT canvas). Think about it, we can render stuff on the CPU side and send it to the GPU later, and fix the TTF problem!

Offline SirMathhman

Junior Newbie


Exp: 3 years



« Reply #4 - Posted 2016-03-20 21:31:34 »

If you're talking about using hardware acceleration, even if you do write a rendering library it's going to need some form of machine-code.
Java actually has full hardware acceleration, using Buffer Strategies. https://docs.oracle.com/javase/tutorial/extra/fullscreen/bufferstrategy.html
Offline philfrei
« Reply #5 - Posted 2016-03-20 22:11:28 »

JavaFX

music and music apps: http://adonax.com
Online jonjava
« Reply #6 - Posted 2016-03-20 22:59:37 »

Stop making engines. Make geimz!

Offline gouessej
« Reply #7 - Posted 2016-03-20 23:03:13 »

Hi

What is wrong with using "native code" under the hood? Java2D has some hardware accelerated pipelines (it has a software renderer too), OpenJFX / JavaFX too. Whatever you will create, you will rely on "native code". JOGL has its own windowing toolkit, it's mainly written in Java but it needs to communicate with the native windowing system somehow and it's the same for Swing and even more for SWT. Moreover, there are already several excellent 2D and 3D software renderers, 3DzzD is the fastest that I know. Why not spending your precious time in writing a game instead of writing another tool that you'll be mostly alone to use? What's the point of creating yet another library / engine / framework?

Julien Gouesse | Personal blog | Website | Jogamp
Offline SirMathhman

Junior Newbie


Exp: 3 years



« Reply #8 - Posted 2016-03-21 12:17:09 »

Here's the thing.
As a programmer, I can't fiddle around with the native code. I don't understand how it works. And if there's some bug in the native code, there's nothing I can do about it. Nothing.
Offline KaiHH

JGO Kernel


Medals: 472



« Reply #9 - Posted 2016-03-21 12:31:16 »

And if there's some bug in the native code, there's nothing I can do about it. Nothing.
You can report it to the respective library owners. They are sure to fix it, because it lies in their own interest that their own libraries are bug-free/usable.

So unless you want to drive a nuclear power plant with 100% mathematically-proven bug-free code, in which case you would not even use a Java Virtual Machine or not even off-the-shelves OS'es and PCs, then it is perfectly fine to use native libraries and their respective Java wrappers.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #10 - Posted 2016-03-21 12:34:28 »

If I follow your reasoning, then you can't use the standard Java APIs. Moreover, if you're able to understand Java, you're probably able to understand a bit well written code written in C.

Do you know JavaOS and JNode? Both are operating systems mainly written in Java. The latter uses some code written in assembly language as writing a full Java stack is impossible.

Actually, it's possible to minimize the recourse to Java libraries heavily relying on native code (especially bindings) but it's impossible to use a 100% Java software stack to write a software.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Opiop
« Reply #11 - Posted 2016-03-21 13:11:34 »

Here's the thing.
As a programmer, I can't fiddle around with the native code. I don't understand how it works. And if there's some bug in the native code, there's nothing I can do about it. Nothing.
And how many times do you run into this in major graphics libraries? I'm going to guess very rarely as these libraries are tested extensively before being released. And if you do encounter a bug, it will most likely be fixed swiftly.
Offline Cero
« Reply #12 - Posted 2016-03-21 15:12:51 »

I never walk on public roads... imagine there was a pothole... I cant fix that shit, why even bother. :D

Offline SHC
« Reply #13 - Posted 2016-03-21 15:16:46 »

Okay I understand you didn't like native code, but why exactly? Your idea is completely wrong. I have a question for you on this regard.

Why develop in Java? The code is run on a JVM, which is written in C++, so IF THERE IS A BUG IN THE JVM, YOU CAN'T DO ANYTHING!!!

The answer is, there is native code under everything that you are using. Consider a basic swing application in Java. Here is what you will be having.
  • You create a frame, and frame requires native code.
  • The frame requires a window, and a handle to paint on, requires native code.
Now assume that you are writing an application in C++, and here is how you'll be having native code.
  • The application is linked into a stub program which calls your main or WinMain, it's native code.
  • You create a GUI application and start an event loop, the events comes from the OS, which are native code.
Finally assume that you are writing an OS itself, the OS depends on a bootloader to open, which is native code. The bootloader needs a kernel, which is native code.

As you see, you CANNOT avoid native code, and there is so many layers that help you run your program, what if the support for them was dropped or if the OS got security issues??

That's none of our business, all we have to do is report them if we find any such bugs/issues, and I can guarantee that these issues will be fixed by the respective developers pretty quick, as they have large user base, and they don't want their users to suffer.

I don't want to offend you, but I doubt whether you're having a Not Invented Here syndrome..

Offline trollwarrior1
« Reply #14 - Posted 2016-03-21 18:47:02 »

Writing custom renderers just for fun is cool, you just need to realize that you only do it for fun and it will not be usable in any real world scenarios.
Offline ziozio
« Reply #15 - Posted 2016-03-21 19:07:40 »

For those that like writing everything from scratch in Java there is plenty of opportunity to and there is also plenty of opportunity to contribute to existing project written in Java. For those that like to use what ever is out there, which includes JNI projects then again there are plenty of choices.

Luckily for us there is enough to satisfy everyone  Cheesy

The opening poster was merely suggesting, for those that are interested in writing some java only libraries that they could get together and do that. Saying Java is written in c++ does not really help, Java code can be written / compiled once and deployed to where ever the c++ JVM is. JNI code needs a per environment compile and that is what the opening poster is trying to avoid.

So staying on topic, good luck SirMathhman on your endeavour. It is not a bad one, I won't have time to help out but would be interested in your physics engine if you get one going. JOML is already quite mature for a pure java solution in the math regards and for rendering opengl / vulcan is the way of the future so I will be sticking with that.
Offline Longor1996
« Reply #16 - Posted 2016-03-21 21:02:23 »

Writing custom renderers just for fun is cool, you just need to realize that you only do it for fun and it will not be usable in any real world scenarios.

Actually, there is a good use for software rendering: Occlusion Culling by Software Depth Testing.

Draw a bunch of occlusion bounding boxes with a software renderer into a depthbuffer, then check with another pass if the bounding boxes of any object are hidden by the pixels in the software depthbuffer. Its one of the fastest ways to do occlusion culling; the company Umbra is selling a library that uses this technique.

Someone should write a software renderer for occlusion culling in java...

Offline philfrei
« Reply #17 - Posted 2016-03-22 18:13:37 »

Someone should write a software renderer for occlusion culling in java...

There are depth buffers in JavaFX. Doesn't the 3D rendering in JavaFX include occlusion culling? Isn't JavaFX 3D now a standard part of the JVM? I think the only limitation with it is whether or not the graphics cards support the functions being called.

What am I missing?

music and music apps: http://adonax.com
Offline princec

« JGO Spiffy Duke »


Medals: 973
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2016-03-22 18:35:41 »

Almost a standard part of the JVM... they've (very inconveniently) pulled it from the ARM builds.

Cas Smiley

Offline MatthewNicholls
« Reply #19 - Posted 2016-03-22 18:39:42 »

I use JNA so I can get the access to native code, but don't have to write any myself. I have an OpenGl library, use glfw3 for windowing....

my blog My YouTube

"...Muahahhah... pull the lever Egor!" ..."Yesh mashter"..click... click...click..buzzzzz".......Its Alive!
Offline theagentd
« Reply #20 - Posted 2016-03-22 20:33:57 »

Actually, there is a good use for software rendering: Occlusion Culling by Software Depth Testing.

Draw a bunch of occlusion bounding boxes with a software renderer into a depthbuffer, then check with another pass if the bounding boxes of any object are hidden by the pixels in the software depthbuffer. Its one of the fastest ways to do occlusion culling; the company Umbra is selling a library that uses this technique.

Someone should write a software renderer for occlusion culling in java...
The primary reasons for doing this was either having a very weak GPU where culling a single triangle no matter the CPU cost was a win (Playstation 3) or attempting to avoid a number of expensive single-threaded draw calls with threadable occlusion testing while avoiding expensive synchronization by reading back the depth buffer. Hopefully with Vulkan-based engines this won't actually be needed any more, as draw calls can be threaded and there's no high driver overhead of doing GPU occlusion culling.

Myomyomyo.
Offline trollwarrior1
« Reply #21 - Posted 2016-03-22 20:36:17 »

Writing custom renderers just for fun is cool, you just need to realize that you only do it for fun and it will not be usable in any real world scenarios.

Actually, there is a good use for software rendering: Occlusion Culling by Software Depth Testing.

Draw a bunch of occlusion bounding boxes with a software renderer into a depthbuffer, then check with another pass if the bounding boxes of any object are hidden by the pixels in the software depthbuffer. Its one of the fastest ways to do occlusion culling; the company Umbra is selling a library that uses this technique.

Someone should write a software renderer for occlusion culling in java...

This is a very specific case. I meant that writing an entire API like OpenGL purely in Java has no real world applications.
Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (107 views)
2017-09-30 02:57:34

theagentd (134 views)
2017-09-26 18:23:31

cybrmynd (244 views)
2017-08-02 12:28:51

cybrmynd (237 views)
2017-08-02 12:19:43

cybrmynd (237 views)
2017-08-02 12:18:09

Sralse (251 views)
2017-07-25 17:13:48

Archive (863 views)
2017-04-27 17:45:51

buddyBro (1006 views)
2017-04-05 03:38:00

CopyableCougar4 (1565 views)
2017-03-24 15:39:42

theagentd (1372 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!