Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
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   
  Show Posts
Pages: [1] 2 3 ... 11
1  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-25 03:24:49
One interesting note that I learned from the person (thanks glacialthinker@reddit!) who showed me supersampling.  If using the supersampling approach in the shader you actually don't want to use mipmapping as you'll lose some of the detail that the supersampler would otherwise pick up on.

Supersampling shader without mipmaps (left is downscaling and right is SDF):



And going back to the original non-thick SDF font:



To conclude this thread SDF fonts can look good at small pt sizes if you use supersampling and no mipmapping.

Reminder of how crappy the SDF looked when this saga began:

2  Games Center / WIP games, tools & toy projects / Re: [Slick2d] Retro-Pixel Castles >>MAP EDITOR TECH DEMO RELEASED!!<< on: 2014-06-23 04:04:42
Having trouble running this on my MacBook Pro 2013 with Retina.

1  
2  
3  
4  
$ java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
$ java -jar RPC-InDev-6-21-2014c.jar 
Mon Jun 23 05:08:03 IDT 2014 INFO:Slick Build #237
Mon Jun 23 05:08:03 IDT 2014 INFO:LWJGL Version: 2.8.5
Mon Jun 23 05:08:03 IDT 2014 INFO:OriginalDisplayMode: 1440 x 900 x 32 @0Hz
Mon Jun 23 05:08:03 IDT 2014 INFO:TargetDisplayMode: 1440 x 900 x 32 @0Hz
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
Mon Jun 23 05:08:05 IDT 2014 ERROR:Could not get the JAWT interface
org.lwjgl.LWJGLException: Could not get the JAWT interface
   at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
   at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
   at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
   at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
   at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
   at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
   at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
   at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
   at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
   at org.lwjgl.opengl.ContextGL.<init>(ContextGL.java:132)
   at org.lwjgl.opengl.Display.create(Display.java:847)
   at org.lwjgl.opengl.Display.create(Display.java:754)
   at org.newdawn.slick.AppGameContainer.tryCreateDisplay(AppGameContainer.java:302)
<snip>
org.newdawn.slick.SlickException: Failed to initialise the LWJGL display
   at org.newdawn.slick.AppGameContainer.setup(AppGameContainer.java:378)
   at org.newdawn.slick.AppGameContainer.start(AppGameContainer.java:317)
   at rpc.launcher.Game.launchGame(Game.java:53)
   at rpc.launcher.Launcher.main(Launcher.java:16)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)


I then adjusted the settings.properties:
fullscreenUseNative=false
fullScreen=false

1  
2  
3  
4  
5  
6  
7  
8  
$ java -jar RPC-InDev-6-21-2014c.jar 
Mon Jun 23 05:06:21 IDT 2014 INFO:Slick Build #237
Mon Jun 23 05:06:21 IDT 2014 INFO:LWJGL Version: 2.8.5
Mon Jun 23 05:06:21 IDT 2014 INFO:OriginalDisplayMode: 1440 x 900 x 32 @0Hz
Mon Jun 23 05:06:21 IDT 2014 INFO:TargetDisplayMode: 1280 x 720 x 0 @0Hz
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
_NSJVMLoadLibrary: NSAddLibrary failed for /libjawt.dylib
JavaVM FATAL: lookup of function JAWT_GetAWT failed. Exit


I also tried copying over the 2.9.1 lwjgl natives but that gave me a linker mismatch:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
$ java -jar RPC-InDev-6-21-2014c.jar 
Exception in thread "main" java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.LinkageError: Version mismatch: jar version is '23', native library version is '25'
   at org.lwjgl.Sys.<clinit>(Sys.java:118)
   at org.lwjgl.opengl.Display.<clinit>(Display.java:132)
   at org.newdawn.slick.AppGameContainer$1.run(AppGameContainer.java:39)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.newdawn.slick.AppGameContainer.<clinit>(AppGameContainer.java:36)
   at rpc.launcher.Game.launchGame(Game.java:42)
   at rpc.launcher.Launcher.main(Launcher.java:16)
   ... 5 more


Let me know if you want me to try anything else.
3  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 12:53:02
I'm also using a supersampling technique suggested by "glacialthinker" that also gives improvement in the small pixel details.  My current shader source:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
// GLSL 1.2 to correspond with OpenGL 2.0
#version 120

// predefined variables
uniform sampler2D tex0;

float contour(in float d, in float w) {
    // smoothstep(lower edge0, upper edge1, x)
   return smoothstep(0.5 - w, 0.5 + w, d);
}

float samp(in vec2 uv, float w) {
    return contour(texture2D(tex0, uv).a, w);
}

void main(void) {

    // retrieve distance from texture
   vec2 uv = gl_TexCoord[0].xy;
    float dist = texture2D(tex0, uv).a;

    // fwidth helps keep outlines a constant width irrespective of scaling
   // GLSL's fwidth = abs(dFdx(uv)) + abs(dFdy(uv))
   float width = fwidth(dist);
    // Stefan Gustavson's fwidth
   //float width = 0.7 * length(vec2(dFdx(dist), dFdy(dist)));

// basic version
   //float alpha = smoothstep(0.5 - width, 0.5 + width, dist);

// supersampled version

    float alpha = contour( dist, width );
    //float alpha = aastep( 0.5, dist );

    // ------- (comment this block out to get your original behavior)
   // Supersample, 4 extra points
   float dscale = 0.354; // half of 1/sqrt2; you can play with this
   vec2 duv = dscale * (dFdx(uv) + dFdy(uv));
    vec4 box = vec4(uv-duv, uv+duv);

    float asum = samp( box.xy, width )
               + samp( box.zw, width )
               + samp( box.xw, width )
               + samp( box.zy, width );

    // weighted average, with 4 extra points having 0.5 weight each,
   // so 1 + 0.5*4 = 3 is the divisor
   alpha = (alpha + 0.5 * asum) / 3.0;

    // -------

    gl_FragColor = vec4(gl_Color.rgb, alpha);
}
4  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 12:47:03
So, are you using mipmaps or not? You should. You'd still have the same code, a single shader and a single texture.

If you mean by using the GL commands and the work it does behind the scenes I am:

1  
2  
3  
4  
5  
6  
7  
8  
// Using MipMaps instead of glTextImage2D() and GL_NEAREST
// gives us much better scaled down textures.
//glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
//glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 16*64, 16*64, 0, GL_RGBA, GL_UNSIGNED_BYTE, pixels)

gluBuild2DMipmaps(GL_TEXTURE_2D, 4, sheet.width, sheet.height, GL_RGBA, GL_UNSIGNED_BYTE, pixels)
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR)
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR)


But I don't actually have pre-rendered SDF textures for multiple point sizes.
5  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 12:39:04
Do you have mipmaps?

Thought about it but putting in different code and different shaders depending on the font size is too unwieldy for my tastes.  Dynamically switching could affect performance too as I would have to split up all my VBOs by pt size.

Using a single shader + source texture for all text is the most elegant.
6  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 12:35:30
libgdx I think has SDF.  Forget that fwidth exists.  It was a bad idea, try doing the correct computation.

https://github.com/OpenGLInsights/OpenGLInsightsCode/tree/master/Chapter%2012%202D%20Shape%20Rendering%20by%20Distance%20Fields

I think this has a survey:
http://jcgt.org/published/0002/01/04/

It seems that fwidth() returns a number that maps to one pixel or less.  Trying it versus Stefan Gustavson's:

1  
float aa = 0.75 * length(vec2(dFdx(d), dFdy(d)));  // antialias


doesn't appear to make a perceptible difference.  Can you explain how calculating fwidth() properly will give other benefits?

Anyways an update on tests so far.  I've applied two improvements.  The first is a supersampling technique and the second is using a "thicker" original SDF texture.

Details about the second technique.  My original calculation used to create the alpha-channel texture was the canonical:

    val alpha: Double = 0.5 + 0.5 * (signedDistance / spread)

Where signedDistance = distance to an opposite bit and will be +ve if inside the glyph, -ve if outside; spread = 4

And in an attempt to make the original texture "thicker" I tried the following:

    val alpha: Double = 0.6 + (signedDistance / spread)


Original SDF (texture simply scaled on left, SDF shader w/ supersampling applied on right):


Versus thicker:


As you can see this gives me a much more solid-looking distance field glyph that also gives me better results with the shader esp. at small pt sizes. However, knowing that any alpha of > 0.5 (which becomes "distance" within the shader) is inside the glyph I figure I could using a more abrupt transition in the shader instead of recreating the alpha images.

I'm tending towards using the simple thicker texture because that means I can use the same texture for both SDF or simple scaling (when shaders aren't available).
7  Java Game APIs & Engines / OpenGL Development / [Solved] Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-20 04:16:24
Hi all, I've successfully implemented signed-distance-fields as described by the Valve paper:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

As advertised it has created excellent looking characters at very large pt sizes.  However at small pt sizes (<12 or so) they look like crap.  Normal 64x64 glyph simply downscaled on the left, SDF on the right.



My distance fields fonts are 64x64 pixels per character calculated from a 1024x1024 pixel original using a brute-force exhaustive distance function.   Thus I figure that they encapsulate enough information to technically be able to render a good looking font event at small sizes.


(^ alpha SDF font is hard to see but provided to show that they are of high quality)

According to the creator of TextMesh Pro it is possible:

Quote
A big misconception about SDF Text Rendering is that large text looks great but small text looks bad. Well, that is not the case with TextMesh Pro's Advanced Signed Distance Field shaders. TextMesh Pro's SDF text looks awesome at large sizes and looks as good or better than bitmap text at small sizes.
http://forum.unity3d.com/threads/textmesh-pro-advanced-text-rendering-for-unity-beta-now-available-in-asset-store.227790/

Here's the source for my fragment shader which does the basic implementation:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
// GLSL 1.2 to correspond with OpenGL 2.0
#version 120

// predefined variables
uniform sampler2D tex0;

void main() {
    // retrieve distance from texture
   float dist = texture2D(tex0, gl_TexCoord[0].xy).a;

    // fwidth helps keep outlines a constant width irrespective of scaling
   float width = fwidth(dist);

    float alpha = smoothstep(0.5 - width, 0.5 + width, dist);

    // antialiased
   gl_FragColor = vec4(gl_Color.rgb, alpha);
}


Anyway have any of you worked in this area and have suggestions towards a custom fragment shader that may accomplish this?
8  Game Development / Game Play & Game Design / Re: Creating good game UI on: 2014-06-15 00:29:51
I haven't seen any mouse release methods in lwjgl. How would I go about this, yet keeping things simple?

Just go into it knowing that it's not going to be simple.  I have great appreciation for the developers who have written major UI libraries.

Abstracting raw mouse/key events into an event dispatch system is tricky especially when you consider drag/drop, focus, window z-stack, and modal.

_If_ you want want to write things from scratch count on spending at least a month full time to get something useable and definitely not complete.  This is considering you are working off the shoulders of giants e.g. looking at how awt, TWL, nifty, etc. are implemented.

You will have to start with a UIComponent that stores a location + dimension, can paint itself, have children, and can handle events.

I've probably spent between 30-45 days on mine.  I think it's worth it in the long run - good learning experience and I have a framework that avoids spaghetti code.  If you don't want to spend that time e.g. would rather write your game then your only option is to learn a library.

Good luck.
9  Game Development / Game Play & Game Design / Re: Creating a UI. Questions. on: 2014-06-13 03:28:46
Pretty much what the Lion King said, draw your 3D stuff first then change the projection matrix so that you can use easy coordinates for 2D stuff.

The following will allow pixel coordinate accuracy for drawing with 0,0 being in the bottom-left corner.  If you want the more standard 0,0 in the top-left you can adjust the projection matrix to do so.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
  override def toggleOn2D() {
    if (!is2D) {
      val viewport: IntBuffer = BufferUtils.createIntBuffer(16)

      glGetInteger(GL_VIEWPORT, viewport)

      glMatrixMode(GL_PROJECTION)
      glPushMatrix()
      glLoadIdentity()

      glOrtho(viewport.get(0), viewport.get(0)+viewport.get(2), viewport.get(1), viewport.get(1)+viewport.get(3), -1, 1)
      glMatrixMode(GL_MODELVIEW)
      glPushMatrix()
      glLoadIdentity()
      glTranslated(0.375, 0.375, 0.0)  // slight transition for exact pixel positioning

      glPushAttrib(GL_DEPTH_BUFFER_BIT)
      glDisable(GL_DEPTH_TEST)

      is2D = true
    }
  }

  override def toggleOff2D() {
    if (is2D) {
      glPopAttrib()
      glMatrixMode(GL_PROJECTION)
      glPopMatrix()
      glMatrixMode(GL_MODELVIEW)
      glPopMatrix()

      is2D = false
    }
  }
10  Java Game APIs & Engines / OpenGL Development / Re: LWJGL and breaking awt/swing dependencies on: 2014-06-08 23:29:49
Great thanks for the links and thoughts.

Compact profiles look like they won't be of much help unless I am completely free of java.awt.* and it the grand scheme of things it will only save about 30 MB if I go down the route of building and distributing the JRE.
11  Java Game APIs & Engines / OpenGL Development / LWJGL and breaking awt/swing dependencies on: 2014-06-08 21:08:32
I'm currently in the process of making my entire game engine in LWJGL only.  I've learned the hard-way that Swing won't give me the raw performance I want and mixing Swing and OpenGL is a tricky proposition for games.

Now that I'm mostly through the process (active rendering with LWJGL and custom GUI components) I'm wondering how far should I take it?  Right now I'm completely free of Swing but I still rely on awt for font metrics.

1. Is it possible to be completely free of awt i.e. never import anything from java.awt?  Can one obtain enough display information from LWJGL to calculate DPI and scaling?
2. Is it worthwhile to do so?  I'm imagining future deployments of my game and would cutting out the awt/Swing libraries really save that much download space?  I can see a benefit if I write for Android etc. I figure there won't be any awt there.
12  Discussions / General Discussions / Re: Give to charity, get a copy of Excelsior JET (commercial JVM with AOT compiler) on: 2014-05-17 01:35:36
I just made my first build with this, and I must say I'm impressed with how easy it all is. A native build of a project with some libs and dlls is literally just a few clicks away.

Is it possible to script this?
13  Discussions / General Discussions / Re: Is it just me, or does everyone's GUI code look like spaghetti? on: 2014-05-16 02:22:27
I've written a "simple" (1) panel-based UI system for OpenGL that operates somewhat like Swing except its painted 60 fps.

It has mouse (move, drag, press, release, enter, exit, click, etc.) and key events (press, release) that are dispatched to the panels which in turn dispatches events to any child components.

I've really come to appreciate the amount of effort required to write any UI library.  I've probably spent close to 30 working days in total on it and each time I revisit it to add functionality I find new bugs and new ways to do things.

Recently I've added some more complicated UI controls such as auto-paginating text areas, single-selection lists, and drop-down selection lists.

Overall the code is clean and manageable but wowsers, it took considerable effort.

(1) "Simple" in functionality but not simple in code.
14  Game Development / Game Mechanics / Re: Axis-aligned cylinder-triangle collisions on: 2014-04-22 13:51:58
Why not start with the center point of the base and determine whether or not that point is above or below the terrain?

Can you approximate by comparing against the vertices instead of the triangle plane?

Due to the cylinder being axis-aligned, you can get away with several optimizations.

[edit] If you need supreme accuracy, could you shift the center point of the base in the opposite direction of the normal for the distance of your cylinder radius and then do collision detection?
15  Game Development / Game Play & Game Design / Re: Overall design strategy. on: 2014-04-22 13:46:16
I don't create complicated design docs etc. because my project is a solo one.

However, I try not to sit down and program unless I have a clear mind and conceptually have a plan of action of what I'm trying to do.

This often requires multiple hours of not being in front of the computer, going for a walk, or some other activity to encourage the subconscious.

With a clear mind I can sit down and bang out a feature in an hour or so.  Without one, I can sit in front of the computer all day and whatever comes out is pure crap.

And to answer the OP's questions: get it working first and then refactor until you can stand the smell.  It's pretty much impossible to plan something you don't yet know how to do.
16  Games Center / WIP games, tools & toy projects / Re: Android : Jumpy Hoppy on: 2014-04-19 22:46:00
I like your apartment clipart background.  I used the same image on my house-warming invitation last autumn!
17  Game Development / Shared Code / Re: My entity properties... a bad idea? on: 2014-04-16 00:28:21
> There will be thousands of entities so I want to multithread processing of the entities.

Premature optimization.  Also thousands of entities isn't even a blink in the eye of today's CPUs.

Getters/setters are overrated in my opinion.  Start with an immutable class (hey no threading problems) and then expose things as you need them.
18  Games Center / WIP games, tools & toy projects / Re: SCREENSHAKE: SixtyGig - Open World Retro RPG. on: 2014-04-14 15:53:36
Those pool balls must be stuck to the table.   Wink
19  Discussions / Miscellaneous Topics / Re: What are Anti-Virus Developers Protecting us From? on: 2014-04-14 15:51:03
I agree that MSSE is all that you need.  That being said, I would caution against claiming any kind of moral superiority on never getting a virus.

I've only gotten one once (that I know of).  It was some vulnerability about 7-10 years ago where just even viewing a malicious image in the browser would be enough to get infected.

If something that serious comes along again, there's not much that can be done to stop it and you'll be hoping that MSSE is doing its job.
20  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-08 05:16:40
What are your metrics like without iterating over every quad and calling Random?

Even on my system, if I iterate over every one of the 160000 quads and change the vertices using Random, it's quite slow... i.e. +15 msec per render frame where without the iteration+Random it's 1.5 msec/frame using VBO+glBufferSubData.  This is not something I would even consider as there shouldn't be any need to visit every single quad every single frame in this manner for a normal game.

Once you take this iteration out of the picture and the calls to Random you should be able to get better metrics of the throughput of memory to the video card.  Have you tried modifying just a small subset of the quads just so that you can verify that your render loop is picking up changes?
21  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-07 17:09:52
I've been exploring VBOs recently but on the desktop.  java.nio.FloatBuffers for vertices and textures + ByteBuffers for colors gives pretty good performance.  glBufferData/glBufferSubData is giving 1.5 msec render time for 160000 quads.  Note that I'm not put'ing every vertex every frame though.

No idea about ES and your platform though but have you confirmed that desktop performance is adequate?
22  Discussions / Miscellaneous Topics / Re: new computer purchase advice on: 2014-03-31 23:04:29
After using an SSD machine I don't think I can go back.  Sub 15-sec boot times and apps opening up pretty much instantly is pretty sweet.

And I've always been wary of what I allow to run on start-up + occasional re-installs to keep things speedy.
23  Game Development / Newbie & Debugging Questions / Re: Shaders not working on mac on: 2014-03-30 20:43:09
Maybe try glGetShaderInfoLog to get error messages?

1  
2  
3  
4  
5  
glCompileShader(fragmentShader)
if (glGetShaderi(fragmentShader, GL_COMPILE_STATUS) == GL_FALSE) {
  log.error("Unable to compile fragment shader")
  log.error(glGetShaderInfoLog(fragmentShader, 1024))
}

24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-29 01:51:07
Thanks SHC for the tip.  Using glBufferSubData reduced render from around 2.3 msec down to 1.6 msec.  Approximately 25% less time!

OP, did you manage to get your code working?
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-28 18:36:04
Good to know.  I'll give glBufferSubData a try and report back.
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-28 17:26:39
This is what I discovered last night.  The following are scala snippets but should be easy to follow.

My original vertex data are stored in java.nio buffers:

1  
2  
3  
private val vertices: java.nio.FloatBuffer
private val textures: java.nio.FloatBuffer
private val colors: java.nio.ByteBuffer


Assuming you have somewhere to store the int handles to your VBOs (I have 3, one for vertices, textures, and colors):

1  
2  
3  
private var vHandle: Int = -1
private var tHandle: Int = -1
private var cHandle: Int = -1


Create your buffers just once and upload your data to the graphics card.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
val ib: IntBuffer = BufferUtils.createIntBuffer(3)  // 3 buffers needed

glGenBuffers(ib)
vHandle = ib.get(0)
tHandle = ib.get(1)
cHandle = ib.get(2)
 
glBindBuffer(GL_ARRAY_BUFFER, vHandle)
glBufferData(GL_ARRAY_BUFFER, vertices, GL_STATIC_DRAW)

glBindBuffer(GL_ARRAY_BUFFER, tHandle)
glBufferData(GL_ARRAY_BUFFER, textures, GL_STATIC_DRAW)

glBindBuffer(GL_ARRAY_BUFFER, cHandle)
glBufferData(GL_ARRAY_BUFFER, colors, GL_DYNAMIC_DRAW)  // dynamic as this could change

glBindBuffer(GL_ARRAY_BUFFER, 0)  // unbind


Now in your draw method you can paint statically which is the fastest:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
glBindBuffer(GL_ARRAY_BUFFER, vHandle)
glVertexPointer(3, GL_FLOAT, 0, 0)

glBindBuffer(GL_ARRAY_BUFFER, tHandle)
glTexCoordPointer(2, GL_FLOAT, 0, 0)

glBindBuffer(GL_ARRAY_BUFFER, cHandle)
glColorPointer(4, GL_UNSIGNED_BYTE, 0, 0)

glDrawArrays(GL_QUADS, 0, 4 * capacity)  // 4 vertices per quad

glBindBuffer(GL_ARRAY_BUFFER, 0)


But if values change, i.e. you've directly modified the values in vertices, textures, and colors, you can intentionally do an upload.  Here's an example of me uploading the colors also during the draw/render phase:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
glBindBuffer(GL_ARRAY_BUFFER, vHandle)
glVertexPointer(3, GL_FLOAT, 0, 0)

glBindBuffer(GL_ARRAY_BUFFER, tHandle)
glTexCoordPointer(2, GL_FLOAT, 0, 0)

glBindBuffer(GL_ARRAY_BUFFER, cHandle)
glBufferSubData(GL_ARRAY_BUFFER, 0, colors)  // upload colors
glColorPointer(4, GL_UNSIGNED_BYTE, 0, 0)

glDrawArrays(GL_QUADS, 0, 4 * capacity)

glBindBuffer(GL_ARRAY_BUFFER, 0)


At some point in time you need to free the VBOs but that is only when you're done with them and not necessarily every frame.

1  
2  
3  
4  
5  
6  
7  
val ib: IntBuffer = BufferUtils.createIntBuffer(3)

ib.put(0, vHandle)
ib.put(1, tHandle)
ib.put(2, cHandle)

glDeleteBuffers(ib)


On my system, I can render a frame in about 1.5 msec with pure static VBOs.  If I need to upload the colors on 160000 quads, the render jumps up to around 2.0 msec.  Yes technically, I am not modifying the VBO purely in video memory and instead I'm uploading an entire data set.  However, the performance hit appears negligible and note that depending on how I manage things, I may not need to upload data every frame.

[edit] use glBufferSubData instead of glBufferData on upload
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-27 21:20:13
I'm looking for an answer to this too.  My vertices and textures are fixed and I have VBOs bound for them.  However, the colors change possibly every frame.

How does glBufferSubData compare to glMapBuffer?
28  Discussions / General Discussions / Re: Programming Careers and Life Lessons... on: 2014-03-27 15:56:22
Do you guys regret or are depressed for being programmers in a company?

it seems like it.

Not I.  It's been a good career so far and solving problems while programming brings me quite a bit of satisfaction.

Luckily it can be quite well compensated too.  The only thing I would have done differently is something I would tell my younger self: "Congratulations on graduating!  Work hard and enjoy the ride but also save a lot of dough to ensure you have options when you turn 40 because it won't be as exciting then".
29  Discussions / General Discussions / Re: Fewer end users? on: 2014-03-27 02:11:47
I'm all for an embedded JRE.

Pretty much boils down to if your game requires more than a single download and a double-click it isn't packaged right.
30  Discussions / General Discussions / Re: Programming Careers and Life Lessons... on: 2014-03-26 17:40:30
One paradox I face ended up being a battle between my day job and programming games for fun.

When you're working for the man in a typical development job, it can be hard to find the time and more importantly the energy to work on your game.

Now I'm doing professional services--less programming and more training, installation, and troubleshooting and lots of face time with the customer.  It's boring because it's the same thing over and over again and most of my value is knowledge in a niche product.  However because I travel a lot (getting really annoying now) and don't have a social life I've had more free time to pursue game development.

I've made more progress in the last few years than I did 15 years prior to this job but now I'm dissatisfied with my day job and am mostly here for the money.  Cas' path speaks to me as I'm deciding between points 1-4 now.
Pages: [1] 2 3 ... 11
 

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 (15 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

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

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

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

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

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

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

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

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

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

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

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

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
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!