Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6 ... 10
 31 
 on: 2014-07-30 22:19:47 
Started by kevglass - Last post by kevglass
Any chance we can get a mobile version of the forum?

m.java-gaming.org

Cheers,

Kev

 32 
 on: 2014-07-30 22:06:30 
Started by philfrei - Last post by BurntPizza
You can do libGDX the old way, downloading a zip of the libs srcs, etc. or you can be cool and use gradle which handles everything for you. Either way there is also a project setup gui which is basically idiot proof.

 33 
 on: 2014-07-30 21:50:21 
Started by CogWheelz - Last post by CogWheelz
Post the native output error from the console.



Then you pick a scale, such as 1/100f. Then you can multiply any pixel values to convert them to meter values.

Can you give me an example of what you mean by this?

 34 
 on: 2014-07-30 21:47:21 
Started by princec - Last post by gouessej
For outdoor environments I'd focus on octree partitioning with an emphasis on texture / geometry streaming and further tessellation for enhanced detail. For indoors / non-destructive you simply can't do better than portal/bsp/pvs to my knowledge. One could still support some level of streaming & dynamically loading BSP and other data for expansive indoors environments.
Some scenegraphs support cells and portals, JMonkeyEngine supports BIH trees:
https://jmonkeyengine.googlecode.com/files/Scene%20Partitioning.pdf

jKilavuz can be used with JPCT to compute portals and "sectors":
http://www.jkilavuz.com/features.html

IsoSurface demo uses JMonkeyEngine 3:

I don't find it ugly.

 35 
 on: 2014-07-30 21:41:45 
Started by princec - Last post by Danny02
I really liked this blog post:

c0de517e.blogspot.nl/2014/04/how-to-make-rendering-engine.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+C0de517e+(c0de517e)

Quote
Today I was chatting on twitter about an engine and some smart guys posted a few links, that I want to record here for posterity. Or really to have a page I can point to every time someone uses a scene graph.

 36 
 on: 2014-07-30 21:40:23 
Started by kevglass - Last post by kevglass
FileHandle searching was getting lost. Silly lack of testing.

Cheers,

Kev

 37 
 on: 2014-07-30 21:31:21 
Started by CogWheelz - Last post by Gibbo3771
Post the native output error from the console.

Also your whole PPM conversion is overly complicated.

To keep things simple, use a fixed viewport like so:

1  
camera = new OrthographicCamera(16, 9);


^ This here will set the viewport to 16x9 meters, which is obviously a 16:9 ratio.

Then you pick a scale, such as 1/100f. Then you can multiply any pixel values to convert them to meter values.

EDIT:

I suspect you have this error -

1  
2  
3  
4  
5  
6  
7  
AL lib: (EE) alc_cleanup: 1 device not closed
Assertion failed!

Program: A:\Java 7\bin\javaw.exe
File: /var/lib/jenkins/workspace/libgdx/gdx/jni/Box2D/Collision/Shapes/b2PolygonShape.cpp, Line 397

Expression: area > 1.19209289550781250000e-7F


This means your shape is far to small and the vertices are reversed and it can only be creating, I believe counter clock wise.

 38 
 on: 2014-07-30 21:30:21 
Started by princec - Last post by EgonOlsen
JMonkeyEngine3 appears to be quite old and the result of many chefs, and supports all sorts of daft legacy rendering paths making it far more complicated than maybe it should be. Ardor was sadly abandoned. Xith and Java3D are ancient.
...and jPCT/jPCT-AE are being ignored...as usual. Anyway, 3D for desktop Java isn't very common these days, but for Android it is. For jPCT, i would estimate that the ratio between desktop Java and Android projects is somewhere between 1 to 10  and 1 to 20.

 39 
 on: 2014-07-30 21:29:04 
Started by Wiki Duke - Last post by Mike
Just in case data0 was changed by another thread? Tongue Sometimes people write funny code Smiley

Mike

 40 
 on: 2014-07-30 21:20:22 
Started by princec - Last post by Catharsis
I was wondering what the current thinking is on 3D engines' design might be these days.

I'd say there are many dimensions to this and I'll answer from the perspective of what I'd build..

For outdoor environments I'd focus on octree partitioning with an emphasis on texture / geometry streaming and further tessellation for enhanced detail. For indoors / non-destructive you simply can't do better than portal/bsp/pvs to my knowledge. One could still support some level of streaming & dynamically loading BSP and other data for expansive indoors environments.

Technologically speaking especially for outdoor and streaming data parallelism is crucial. This means supporting multi-threaded GL and CPU side architecture. From a Java perspective I personally would really like to start using the Disruptor on the CPU side of things which would handle anything routing between the disk and the network to threads streaming through to GL. I am bit sad though that the Disruptor doesn't work on Android due to its reliance on sun.misc.Unsafe. If Android is a target and it should be this means sticking to OpenGL ES for the time being though that could be different a couple years from now and things may properly converge to just OpenGL across all mobile SoC/GPU vendors. This means though supporting OpenGL ES 3.0 and the GL threading API and while one is at it all the other goodness 3.0 brings.

OpenGL AZDO is important of course. There are many aspects there that support texture streaming / binding concerns. I'd figure out the limitations of MultiDrawIndirect. I really wished that the first Android Extension Pack covered AZDO extensions. I'll be able get started with them on the K1 though since it supports OpenGL 4.x too. Though I'll have to think about how the majority of the engine work must remain compatible with GLES 3.0 right now.

Compute shaders and OpenCL is very important. Particle engines will all be compute based. In fact the first demo I'm going to port to Java is this one:
http://docs.nvidia.com/gameworks/index.html#gameworkslibrary/graphicssamples/opengl_samples/computeparticlessample.htm

For other modern GL demos check out all of them:
https://developer.nvidia.com/gameworks-opengl-samples

To have any chance at maintaining an engine now and into the future modularity must be a concern from the get go or go the way of all past Java engines. Component architectures (CA) are key in this direction IMHO. If you don't think so, well, I can't help you there much. Wink A CA is flexible to support structuring both the engine subsystems at a high level that is compatible with data parallelism in addition to other aspects like entity systems. It also happens that it supports various rendering paths and hardware diversification concerns which is quite important for long term evolution of an engine. It is what is going to make relatively painless my efforts to support OpenGL ES 3.0 for the majority of Android devices and have a GL 4.x path compatible path with the K1. It also makes tooling possible hence the nice user experience Cas also mentions when he speaks favorably of Unity.

I'm so excited that I get to start down parts of the rabbit hole above tomorrow when my Shield Tabby arrives.. Cheesy

The only real shortcut is picking a specific visual style and focus on gameplay...

Gameplay is king at the end of the day. From an indie perspective one could consider procedural content generation and have great gameplay.

The first example that pops to mind in regard to picking a specific visual style and procedural content is Love:
http://www.quelsolaar.com/love/

I never have gotten around to checking it out though so, I'm not sure about game play.
 
-----

What I think would really benefit the larger Java game dev community is as many folks as possible getting their hands some of the leading tech today (Right at this moment on Android that is the Tegra Shield Tabby, desktop there are various high end GPUs to pick) and start building new engines that may not be compatible with the wider ecosystem. OpenGL ES 3.0 should be the absolute minimum supported for new engine development right now and experiments with OpenGL 4.x should occur on mobile and if you are on the desktop only ignore anything that isn't the latest GL 4.x point releases.



Pages: 1 2 3 [4] 5 6 ... 10
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (14 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!