Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 39
1  Discussions / General Discussions / Re: The Oculus Rift on: 2014-02-25 02:09:51
Yeah, I've tried one of the older kits. I'm keen to see how the new ones have improved.

I helped develop and test a bubl + Rift prototype and it's made me realize the VR film has a lot of potential. Imagine a horror movie where you hear and see something something over your shoulder, creeping up behind you..

It's also fairly easy to get up and running with vr.js or the Unity plugins.
2  Java Game APIs & Engines / OpenGL Development / Re: Reusing depth values from FBO on: 2014-02-25 01:56:21
gl_FragDepth is really on supported in GLES3, or in GLES2 through an extension:
http://www.khronos.org/registry/gles/extensions/EXT/EXT_frag_depth.txt

Most desktops running WebGL should support this extension, though.
3  Java Game APIs & Engines / OpenGL Development / Re: Reusing depth values from FBO on: 2014-02-24 13:54:00
Well, interesting problem. Smiley

For older devices that don't support depth textures, another idea is to use a "multi texture" batch like so:
http://webglsamples.googlecode.com/hg/sprites/readme.html

I wrote a version in JavaScript that dramatically reduced my draw calls per frame in a pretty large game (with hundreds of assets that would not fit in a small number of sprite sheets).

4  Java Game APIs & Engines / OpenGL Development / Re: Reusing depth values from FBO on: 2014-02-24 04:36:20
Firstly, why are you using depth testing for 2D? If your sprites are semi transparent it probably isn't worth it.

Secondly, have you actually benchmarked and found that you are vertex bound? If there is no bottleneck, or the bottleneck lies elsewhere, you will probably just further degrade performance.

A sprite batcher and texture atlases should be fast enough to render hundreds of thousands of triangles. Introducing FBO binds means less batching and more state switches, ie. generally worse performance. So it's best to just avoid them if you don't need them.
5  Discussions / Miscellaneous Topics / Re: Github Report Card Toy; What did you get? on: 2014-02-22 15:57:01
Nice toy.

http://osrc.dfm.io/mattdesl

Apparently I'm one of the 14% most active JavaScript developers.. Shocked It also correctly connects me to some colleagues.
6  Java Game APIs & Engines / OpenGL Development / Re: Straight line between two points (shader) on: 2014-02-14 00:22:46
What are you trying to solve?

BTW, regarding anti-aliased lines, I wrote about it in this thread:
http://www.java-gaming.org/topics/lwjgl-antialiased-lines/30894/msg/285889/view.html#msg285889

Quote
GLSL is not made to draw stuff
Tell that to iq, the author of Shader Toy. Tongue

I actually wrote my first ray marching shader the other day, not nearly as daunting as I thought it would be. Still; though, I can't wrap my head around much of the crazy stuff the demo sceners come up with.
http://glsl.heroku.com/e#14157.0
7  Game Development / Newbie & Debugging Questions / Re: Libgdx shaders not working. on: 2014-02-04 15:53:18
Query GL_MAX_VERTEX_UNIFORM_COMPONENTS on those machines to see if you're going over the max.

There are some quirks with this query, see here:
http://www.opengl.org/wiki/GLSL_Uniform

Instead of a single flat array, try using a vec3 array to define the light position, and another parallel vec4 array to define their colours. This should clean up code and remove the need for dynamic indexing.

Also I'm just quickly glancing at your code; but you should avoid if statements and try using built-ins like length(), distance(), abs(), clamp(), max(), etc. as it will lead to a big boost in performance.

If you really feel like you need that many lights, maybe a deferred solution would be more suitable.

I have some tutorials on shaders that you might find useful. They cover some basics like the built-in smoothstep() and other useful functions.
https://github.com/mattdesl/lwjgl-basics/wiki/Shaders

There is also a section on lighting, and you'll probably be able to take some aspects of it (like falloff etc).
https://github.com/mattdesl/lwjgl-basics/wiki/ShaderLesson6
8  Game Development / Newbie & Debugging Questions / Re: Libgdx shaders not working. on: 2014-02-04 01:49:43
You should print the log after creating a shader as it will give you a clue.

You also have a pretty ridiculous number of lights, I wouldn't be surprised if some devices don't support that many uniforms.

Further, some drivers don't support dynamic indexing.

Ps longarmx this is only necessary if you want custom attribute locations.  It's unrelated in the OPs case... Also it has to be done before linking, which I'm not sure LibGDX even supports.
9  Java Game APIs & Engines / OpenGL Development / Re: Shaders & Programs - validation, info log... on: 2014-02-01 16:32:31
I haven't seen too many uses for glValidateProgram, since you can just try to compile and see the error logs. There are some issues with Macs and NVIDIA cards around validating:
https://bugzilla.mozilla.org/show_bug.cgi?id=657201
https://bugzilla.mozilla.org/show_bug.cgi?id=593867
10  Game Development / Newbie & Debugging Questions / Re: LibGDX - change the brightness of a texture on: 2014-01-25 02:45:15
See here:
https://github.com/mattdesl/lwjgl-basics/wiki/LibGDX-Brightness-&-Contrast
11  Game Development / Newbie & Debugging Questions / Re: Libgdx how to send arrays to Shader on: 2014-01-23 02:46:24
You need to use
uniformfv
calls.

An example of a float array:
1  
2  
3  
4  
5  
GLSL ...
    uniform float a[3];

Java ...
    shader.setUniform1fv("a[0]", new float[] { 1.0f, 0.0f, 0.0f }, 0, 3);


An example of a vec3 array:
1  
2  
3  
4  
5  
GLSL ...
    uniform vec3 a[2];

Java ...
    shader.setUniform3fv("a[0]", new float[] { 1.0f, 0.0f, 0.0f, 1f, 1f, 1f }, 0, 6);


The last parameter, length, is the total number of floats you are passing to GL.
12  Java Game APIs & Engines / OpenGL Development / Re: 2014 - What OpenGL versions should I target? on: 2014-01-22 21:32:24
quew8 - FBOs and shaders are supported in > 90% of drivers. Any device that doesn't support them probably won't be fast enough to play your game, anyways.

Some other 3.0 core features are also really common in older devices, like VAOs.
13  Java Game APIs & Engines / OpenGL Development / Re: 2014 - What OpenGL versions should I target? on: 2014-01-22 19:40:21
2.0 may be old, but it's the basis for OpenGL ES, which is still the primary choice for the vast majority of devices (iOS, WebGL, Android, etc).

I would just stick to GL 2.0 using as little deprecated code as you can, unless you are particularly interested in modern graphics programming (AAA titles and the like).
14  Game Development / Newbie & Debugging Questions / Re: GLSL - add effect to all screen instead to a specific texture on: 2014-01-22 14:44:11
Shape renderer uses it's own shader. It is unrelated to SpriteBatch.

You don't need a shader. Just use SpriteBatch to draw a feathered vignette across your screen, with linear filtering. Set the batch color to make it black.
15  Java Game APIs & Engines / OpenGL Development / Re: A note on OpenGL ES 2.0 shaders and floating point on: 2014-01-21 14:27:38
The default version of GLSL (version 110) doesn't support implicit float casting. You need to specify #version 120 at the top of your shaders for cross-platform code. Annoyingly, some drivers will just allow implicit floats regardless.

The default GLSL ES version (100) also doesn't support implicit floats. I'm fairly sure the new ES version (300) supports them.
16  Discussions / General Discussions / Re: Considering Java for game development, looking for brains to pick on: 2014-01-21 04:42:11
Java may be "bloated" in the sense that it has a pretty rich standard API, but it's definitely not slow and usually the "memory hog" status is attributed to Swing or other Java GUI toolkits (most of which are pitiful).

LibGDX is an indie toolkit; while XNA is not. So don't expect both to carry the same level of documentation. But LibGDX is really easy to get up and running; tons of open-source demos/docs/tutorials/etc, and it has some really powerful tools, extensions, and third-party libs that should make it a breeze. Especially if you're already comfortable with the basics (like a sprite batch).

PC Java is there, sure. It's a matter of preference, target audience, etc.

Jobs -- depends. Java is really rich in terms of jobs, but most employers won't care about Java game development (many will just laugh). But OpenGL, GLSL, audio programming, game mechanics, etc. are all good things if you're looking to enter these fields.

LibGDX is already pretty complete; you probably won't find many (mature) libraries that build on top of it. If you're aiming more specifically for 3D, maybe a scene-graph like jME or Ardor3D would be more up your alley.
17  Game Development / Newbie & Debugging Questions / Re: Libgdx - What Graphic Settings can i expose? on: 2014-01-21 04:01:16
You can read about filtering and wrapping here:
https://github.com/mattdesl/lwjgl-basics/wiki/LibGDX-Textures

Mipmapping is a little different. It basically exists to make textures look smoother when they are rendered really small. Here's some brief info:

  • It's only used on minification (making something smaller). And it's only really useful if you plan to significantly scale down your textures -- e.g. for distant objects in 3D games, or in a 2D game with, say, a very high zoom level.
  • When mipmaps are generated (LibGDX has a boolean in Texture constructor for this), the GL Texture will be associated with a "mipmap chain." This is just a series of images, each one halved from the last -- e.g. 128x128, then 64x64, then 32x32, etc. Example here.
  • This increases texture memory by 33%, which isn't too much. But no point in using mipmaps if you don't need to down-scale your image.
  • Often the driver uses a higher-quality filtering than bilinear, e.g. like bicubic instead. This is more expensive, but since you generally only do it once (when you create the texture), it's no big deal.
  • In the vast majority of applications, the choice of filtering or wrap modes will have zero impact on performance, so it should be a non-issue. There are some rare exceptions -- like on Android with large images -- that you might want to be weary of.
To describe the basic difference between the different mipmap parameters, first you need to know "nearest" vs. "linear." NEAREST picks the single closest sample -- so if you were to plot somewhere "in between" pixel A and B, it would choose whichever is closest to your given value. Whereas LINEAR will blend the two pixels using a weighted average, aka linear interpolation. It's technically "bilinear interpolation" since we are interpolating in both directions (X and Y, or more specifically, the S and T tangents), leading to a weighted average of the four nearest colors.

The GL_*_MIPMAP_* parameters first describes the filtering between mipmap levels, and then the filtering on that particular mipmap texture.

GL_NEAREST_MIPMAP_LINEAR will use nearest-neighbour filtering to sample one mipmap, determined by the size at which you're drawing your texture. Then it will use linear filtering between the samples from that mipmap texture. Whereas GL_NEAREST_MIPMAP_NEAREST will sample from a single mipmap level, and then sample a single pixel.

GL_LINEAR_MIPMAP_LINEAR on the other hand, will blend with a weighted average between the two closest mipmap levels, and then blend again the nearest sampled pixels from the resulting image. This is also known as trilinear filtering, and it leads to the smoothest result. (At the expense of performance, on low-end devices.)

Likewise, GL_LINEAR_MIPMAP_NEAREST first blends between two mipmap levels -- but then samples from the result using nearest-neighbour sampling.
18  Java Game APIs & Engines / OpenGL Development / Re: glCopyTexImage2D error - GL_INVALID_ENUM on: 2014-01-20 00:17:43
What are you trying to achieve? It would probably be better done through FBOs, since glCopyTexImage2D introduces pipeline stalls and can really impact performance.

You should set up min filter to NEAREST or LINEAR since the default expects mipmapping (which you aren't using, i.e. it will cause an invalid operation somewhere down the line).
19  Java Game APIs & Engines / OpenGL Development / Re: Double VBO no performance increase or decrease? on: 2014-01-17 14:49:11
Why bother? It's a lot of extra work for very little gain. Pretty much a premature optimization, unless you've actually benchmarked and found that buffer syncs is causing a problem.

Anyways, you should use mapped buffers for this.
http://www.java-gaming.org/index.php?topic=28209.0
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Libgdx overcoming color limitations? on: 2014-01-16 15:19:09
LibGDX packs the RGBA components into a single float, and sends it along the pipeline. This is much faster than sending four floats (R, G, B, A) to the vertex shader. Unfortunately, this means that OpenGL will "normalize" the value in the range 0.0 to 1.0.

One option is to add a uniform value for "brightness." See here. This is useful if you have a whole bunch of sprites that need the same brightness value. This should probably be fast enough for most use cases.

If you need better performance (e.g. per-sprite brightness), you should use a vertex attribute for brightness, instead of a uniform (so it can be batched). You basically have two options. Either you hack it, or you re-implement SpriteBatcher to have a proper brightness attribute.

To hack it, you could pass in a U texture coordinate larger than 1.0, and in the vertex shader, the brightness is taken from the integral part of the coordinate, and the actual U coordinate is the fractional
fract(..)
. Then you send both of those along to your fragment shader. This means no "texture repeat" wrapping (which is pretty rare in 2D games, anyways).

The "proper" solution is to have a brightness attribute in your sprite batcher; but this is more work. You'd have to implement the Batch interface, copy over most of SpriteBatch's code, and then add in the extra vertex attributes. Read more about working with mesh here.

And if you are just looking to change the brightness of the whole screen (rather than individual sprites), you should just use shaders and a post-processing step.

Cheers.
21  Java Game APIs & Engines / OpenGL Development / Re: Normal for glClearColor and glClear to be slower than the actual rendering? on: 2014-01-10 17:48:14
Gxu1994 - Well, it's not a "bottleneck" since you're at 200 FPS. It might just be slower in comparison to everything else (especially if the other stuff is working on the GPU).
22  Java Game APIs & Engines / OpenGL Development / Re: Normal for glClearColor and glClear to be slower than the actual rendering? on: 2014-01-10 15:50:56
Throw a glFinish in to see if that does anything to your profiling.

Chances are it's just queueing commands, and only executing them on glClear. Nothing to worry about if you're getting 200 FPS.

Also; you don't need to set the clear color every frame. Since GL is state-based, you can just set it once during initialization.
23  Game Development / Newbie & Debugging Questions / Re: How to make sprites in Java possibly using Arrays? on: 2014-01-10 03:31:57
If you're new to programming, Java4K might be a bit of a challenge. First you might want to get acquainted with general programming and Java2D graphics before jumping right into such a challenging competition. Smiley

Anyways.. if you're still keen.. Here is a little template I made for last year:
http://www.java-gaming.org/?action=pastebin&id=321

It includes procedural music and a 3D lambert sphere... Have fun.

EDIT: There are some other old templates in this thread:
http://www.java-gaming.org/topics/applet-templates/21626/view.html

Not sure how many of those will still work with today's JVMs.


EDIT 2:

Also, don't use any extra classes if you're writing J4K. Just keep everything in a single method; avoid objects and imports where possible, etc.
24  Game Development / Newbie & Debugging Questions / Re: How to make sprites in Java possibly using Arrays? on: 2014-01-09 01:15:45
A couple of people chimed in here on different techniques for J4K:
http://www.java-gaming.org/topics/j4k-tools/28323/view.html

Although really it depends on the game. Some games need to use images, others are handling everything per-pixel and can make up their own encodings, others might be using g.drawLines everywhere.

Of course, do not attempt this sort of stuff if you're not building a J4K game.
25  Java Game APIs & Engines / OpenGL Development / Re: Shaders & VBO Spritebatcher on: 2014-01-08 22:12:04
Poke around the tutorials here, a few discuss a sprite batcher and how it's made. If you're using the modern pipeline you'll probably want shader, matrix, texture, and VBO utils to make things easy and clean.

https://github.com/mattdesl/lwjgl-basics/wiki

See the API and it's source as an example of how it might be implemented. Lots is inspired by LibGDX, which is another good source reference for sprite batching.
26  Discussions / Miscellaneous Topics / Re: I had an idea involving .gifs! on: 2014-01-07 01:25:07
OpenGL doesn't know what a GIF is, it just understands textures. If you pack each frame into a single texture, you can utilize sprite batching to reduce draw calls and improve performance. Using a different texture for each frame is not as optimal.

Some desktops support "texture arrays" which could work with GIFs, but at that point you may as well just have an image sequence so you can take advantage of full 32-bit color.

Artists are pretty used to exporting image sequences; tools like Maya and After Effects have it built-in. New versions of AE do not even export to GIF anymore, since nobody is using it these days. Smiley

Plus, with texture atlases, you can pack multiple animation sequences into the same image, which should help with filesize and load time. Another thing... with texture atlases you can trim away white space for each frame, leaving you with a much smaller overall image.

Since Java2D uses OpenGL/DirectX under the hood; the more "hardware-friendly" your rendering is, the better it should perform, in theory.
27  Java Game APIs & Engines / OpenGL Development / Re: GLSL How to access UNIFORM array? on: 2014-01-04 14:55:08
Some more tips for cross-platform uniform access:

1. Initializing uniforms (and arrays) with default values was only added in GLSL 120 +. Make sure you add
#version 120
to the top of your shader.

2. It's usually good practice to specify a length:
1  
float a[5] = float[5](3.4, 4.2, 5.0, 5.2, 1.1);


3. Certain drivers will not support dynamic indexing. For example, if you're using GL ES (WebGL, iOS, etc) then don't expect dynamic indexing of uniforms to work across all platforms. In your case the index won't be dynamic, but it's best just to stick to "static" indices where possible.

4. Initializing arrays in the shader doesn't work at all in Mac OSX <= 1.7. I haven't tested later versions of OSX.

5. You can access certain elements of an array by including the index in the name when using glGetUniformLocation:
1  
 glGetUniformLocation( program, "LightPos[0]" ) 


Oddly, in WebGL, I found this was the only way I could update an entire array of values with glUniform4fv.
28  Game Development / Newbie & Debugging Questions / Re: Rendering Tiles and Sprites in Java on: 2014-01-03 18:34:35
Although I could probably use LibGDX, doing something simple first and them moving on is probably my best bet.
If you know you'll eventually use LibGDX, why waste time working with Java2D?

It's not like Java2D makes everything easier. Many things are actually much harder with Java2D -- e.g. handling input, drawing rotated sprites, adding themed UI, handling sprite sheets and animations, enabling fullscren, or even just getting sprites to render at 60 FPS.

If your game needs any of these things, then Java2D is probably the wrong choice.
29  Discussions / General Discussions / Re: Method Chaining on: 2014-01-02 17:14:07
It can be useful in certain APIs where you are manipulating the same object in many ways -- see jQuery or LibGDX vector math.

But it can also create an inconsistent API. If everything returns "this", what about methods that need a meaningful return statement?

As a rule of thumb, IMHO if you don't need it then don't use it, and when you do use it, use it scarcely. Most of the time if you have tons of consecutive method calls on the same object, it might just be a sign of code smell.
30  Game Development / Newbie & Debugging Questions / Re: Check if RGB is transparent. on: 2014-01-02 16:20:05
First check if the image has an alpha channel.

Then you need to loop through each pixel and see if the alpha value is zero.

Google buffered image to RGBA array and you'll find plenty of  options. 
Pages: [1] 2 3 ... 39
 

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

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!