Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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 ... 12
1  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3; how's it getting along? on: 2014-11-14 01:05:23
I spent about 5 minutes on that site.  Do you have a short primer on the new things in 3 that aren't in 2?  Or a set or release notes?
2  Discussions / General Discussions / Re: OpenUI5 on: 2014-11-03 22:00:38
Cool, glad to hear that your experience with it has been good.  The main competition to this seems to be Google's angular.js but I have no experience with it.

We'll see how the next 2 weeks go.
3  Discussions / General Discussions / OpenUI5 on: 2014-10-28 03:26:02
A bit tangential to Java gaming but I just started looking into OpenUI5 for work and was wondering if anyone has had any experience with it?

http://openui5.org

From the FAQ:
Quote
OpenUI5 is an Open Source JavaScript UI library, maintained by SAP and available under the Apache 2.0 license. OpenUI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice. It’s based on JavaScript, using JQuery as its foundation and follows web standards. It eases your development with a client-side HTML5 rendering library including a rich set of controls and supports data binding to different models (JSON, XML and OData).

Looks interesting to me because it's not just another JavaScript UI framework.  SAP (huge multinational company worth billions in the CRM area) recently open-sourced it in summer 2014 after heavy internal use over the last 4 years.  Sources tell me that they are likely repositioning their entire future product line on it. The following presentation shows it working nicely in the browser and on mobile.

Overview (37 mins):
https://www.youtube.com/watch?v=y7iR3RBUUpY

Yeah, and someone created Pac-man in it:
https://www.youtube.com/watch?feature=player_detailpage&v=y7iR3RBUUpY#t=1634
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: What engine/library shoud I use for 3D game development? on: 2014-10-27 22:03:29
My gaming path went from Java2D (Swing) -> lwjgl.  I ran into performance problems with Swing once I started rendering > 10k sprites per frame and Swing/AWT doesn't mix well with OpenGL.  Going to the bare metal (lwjgl) has given me all the power and flexibility that I need.

However you do have to implement everything from scratch.  In my case this meant creating a UI library, handling the input events, writing a signed-distance field shader, rolling my own collision detection using an octree, etc.  Overall a lot of work but I get exactly what I want.

Perhaps a balance can be struck.  Can you use libgdx but write your own shaders?  I wouldn't know as I haven't used that library but it looks like it provides a lot of useful things.
5  Discussions / General Discussions / Re: cant remember the name of a game. on: 2014-08-17 19:35:46
First game that came to mind was Rampart.

http://en.wikipedia.org/wiki/Rampart_(video_game)

6  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-25 01: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:

7  Games Center / Featured Games / Re: [Slick2d] Retro-Pixel Castles >>MAP EDITOR TECH DEMO RELEASED!!<< on: 2014-06-23 02: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.
8  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 10: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);
}
9  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 10: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.
10  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 10: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.
11  Java Game APIs & Engines / OpenGL Development / Re: Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-22 10: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).
12  Java Game APIs & Engines / OpenGL Development / [Solved] Signed-distance-field fonts look crappy at small pt sizes on: 2014-06-20 02: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?
13  Game Development / Game Play & Game Design / Re: Creating good game UI on: 2014-06-14 22: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.
14  Game Development / Game Play & Game Design / Re: Creating a UI. Questions. on: 2014-06-13 01: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
    }
  }
15  Java Game APIs & Engines / OpenGL Development / Re: LWJGL and breaking awt/swing dependencies on: 2014-06-08 21: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.
16  Java Game APIs & Engines / OpenGL Development / LWJGL and breaking awt/swing dependencies on: 2014-06-08 19: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.
17  Discussions / General Discussions / Re: Give to charity, get a copy of Excelsior JET (commercial JVM with AOT compiler) on: 2014-05-16 23: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?
18  Discussions / General Discussions / Re: Is it just me, or does everyone's GUI code look like spaghetti? on: 2014-05-16 00: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.
19  Game Development / Game Mechanics / Re: Axis-aligned cylinder-triangle collisions on: 2014-04-22 11: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?
20  Game Development / Game Play & Game Design / Re: Overall design strategy. on: 2014-04-22 11: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.
21  Games Center / WIP games, tools & toy projects / Re: Android : Jumpy Hoppy on: 2014-04-19 20:46:00
I like your apartment clipart background.  I used the same image on my house-warming invitation last autumn!
22  Game Development / Shared Code / Re: My entity properties... a bad idea? on: 2014-04-15 22: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.
23  Games Center / WIP games, tools & toy projects / Re: SCREENSHAKE: SixtyGig - Open World Retro RPG. on: 2014-04-14 13:53:36
Those pool balls must be stuck to the table.   Wink
24  Discussions / Miscellaneous Topics / Re: What are Anti-Virus Developers Protecting us From? on: 2014-04-14 13: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.
25  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-08 03: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?
26  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-07 15: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?
27  Discussions / Miscellaneous Topics / Re: new computer purchase advice on: 2014-03-31 21: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.
28  Game Development / Newbie & Debugging Questions / Re: Shaders not working on mac on: 2014-03-30 18: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))
}

29  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-29 00: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?
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: modify the contents of VBO on: 2014-03-28 17:36:04
Good to know.  I'll give glBufferSubData a try and report back.
Pages: [1] 2 3 ... 12
 

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

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (50 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (57 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (113 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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