Java-Gaming.org Hi !
Featured games (88)
games approved by the League of Dukes
Games in Showcase (681)
Games in Android Showcase (196)
games submitted by our members
Games in WIP (744)
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 ... 115
1  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-27 12:46:48
If you were shrewd you'd basically implement Unity's shader language... thereby having access to thousands of free and awesome shaders and a huge amount of amassed expertise...

Cas Smiley
Well, that's why I started that discussion thread about this BEFORE I started coding it... That being said, I'm not entirely sure it'd work considering I'm aiming for emulating Vulkan's descriptor sets in OpenGL.

@theagentd You should definitely consider emitting the #line directives which allow you to get correct line numbers while debugging shaders.
That's a good idea. Hmm, it's a bit difficult though considering that $importset could be multiple lines in a different FILE... Hmm, actually the set-file structs and uniform buffers are verified completely when they're parsed into memory before compiling shaders, so the chance that there's a problem in there which passes into a shader when imported is fairly low. It might just be good enough to have it show the $importset line as the problem in those rare cases.
2  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-27 04:01:38
So I finally got time to sit down and play with my GLSL preprocessor.

When you're done, PM me a github link and I can port it to some standard text preprocessor for you, then put it in the shared code! This looks really useful, Ive always needed a better way of doing shader/client interoperability like checking for primitives and all.
Sure, that'd be lovely! I plan on integrating the whole thing with a couple of tools to write a binary shader file (char[] of GLSL source code + info about the shader for GL, byte[] SPIR-V code + descriptor set layouts for VK), so your port probably has to be written in Java. xd
3  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-27 02:30:28
So I finally got time to sit down and play with my GLSL preprocessor. Got quite a bit on the way, but I realized halfway through that I'll need to restructure the whole thing quite a bit. Regardless, it's gotten fairly useful already.

Set/struct definition file:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
$struct MyStruct{
   vec4 structVec;
   vec4 structVec2;
}

$struct My_Struct2{
   MyStruct struct;
   vec4 structVec;
   vec4[3] blargh;
}
/*
   Random star comment.
*/


$set MySet{
   $uniform uniformBuffer std140 {
      MyStruct myStruct;
      vec4
       testVec4;
   }
   //Comment.
   $sampler2D randomTexture;
   $subpassInput2D subpassInput;
}


Shader definition file:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
//Random comment!
$importstruct MyStruct

$importset
//Another comment in the middle of a $ command (and this comment also has a special character in it!)
/*And a star comment as well!
*/

      MySet

/**/
out vec4 fragColor;

//It really gets rid of all comments. >___>
/*
It can handle star comments now!


asdasdasd
*/


void main(){
   fragColor = uniformBuffer.myStruct.structVec + uniformBuffer.testVec4 + texture(randomTexture, vec2(0)) + subpassLoad(subpassInput);
}



This input produced the following GLSL code:
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  
#version 330

#define subpassLoad(x) texelFetch(x, ivec2(gl_FragCoord.xy), 0)

struct MyStruct{
    vec4 structVec;
    vec4 structVec2;
};

layout(std140) uniform uniformBuffer{
    MyStruct myStruct;
    vec4 testVec4;
} uniformBuffer;
uniform sampler2D randomTexture;
uniform sampler2D subpassInput;
 


out vec4 fragColor;



void main(){
   fragColor = uniformBuffer.myStruct.structVec + uniformBuffer.testVec4 + texture(randomTexture, vec2(0)) + subpassLoad(subpassInput);
}

It compiles! This is meant for OpenGL, emulating certain features. Descriptor sets are broken up to "free" uniform samplers and uniform buffers, subpass inputs are changed to normal textures with texelFetch() to read from them. It'll be easy to implement OpenGL ES and Vulkan support for the output writer, but I'll need to restructure the system a bit. I forgot I need to output extra info about descriptor sets and other things as well (and that Vulkan will output SPIR-V instead of GLSL). xd

EDIT: Added support for star comments (/* */)
4  Discussions / Miscellaneous Topics / Re: Mipmaps are pretty on: 2016-06-26 19:52:00
Somebody move this to the What I did today thread, and move this comment to the chitchat monster.
5  Java Game APIs & Engines / OpenGL Development / Re: VAO Index Buffer coupled with GL_TRIANGLE_STRIP: Avoiding flipped textured? on: 2016-06-26 01:12:00
I've never had bleeding problems in my implementations.
Really? Shit, I guess
 - all my OpenGL experience of ~6 years or whatever
 - plain logic in addition to knowledge of how texture filtering works, especially with mipmaps
 - all the existing topics complaining about bleeding on this forum
 - a quick google search for similar issues
are all just plain wrong and you've revolutionized texture rendering (although a bit late since that problem already got solved with....... texture arrays which don't have any filtering between layers). I can survive you making partly or completely off-topic posts in every single thread like it's your duty to report in on each and every one of them, but if you start spreading misinformation you're literally hurting the community as a whole. And yes, technically you're just stating your "opinion" based on your experience in this case, but it will be interpreted by a lot of people as that the texture bleeding problems they're having are lying somewhere else, since you're implying that I'm wrong.
6  Java Game APIs & Engines / OpenGL Development / Re: VAO Index Buffer coupled with GL_TRIANGLE_STRIP: Avoiding flipped textured? on: 2016-06-25 16:24:21
And they also do texture atlases. So you got 1154 * texture and limited by units and ram.
No, the whole point of texture arrays is to NOT have texture atlases, as they don't handle filtering well (individual textures bleed together). Texture arrays do not have that problem.
7  Java Game APIs & Engines / OpenGL Development / Re: VAO Index Buffer coupled with GL_TRIANGLE_STRIP: Avoiding flipped textured? on: 2016-06-24 03:20:06
Use a TEXTURE_2D_ARRAY texture, let each vertex have 4 texture layer indices and a weight for each layer. Each vertex can represent a mix of 4 different textures, from a pool of however many you can fit in your texture 2D array (probably up to 1024 or something, depending on texture size/memory usage).

A GL_COMPRESSED_RGB_S3TC_DXT1_EXT texture is 1/6th as small as a standard GL_RGB8 (padded to GL_RGBA8) texture. Add 33% for the mipmaps, and you end up with ~908kb per 1024x1024 texture, or 1154 textures per GB of VRAM, or 4619 512x512 textures per GB.
8  Game Development / Newbie & Debugging Questions / Re: Skeletal Animation on: 2016-06-24 02:19:27
Hmm. That all looks correct.

 - Are you trying to do some kind of conversion from Y-up to Z-up or something like that? It's not easy to do that with quaternions.

 - You've shown the code for generating the bind pose matrix. Where's the code for computing an animated matrix?


The intuitive idea behind skeleton animation is to create a local coordinate system for each bone, which is constructed from a translation and a rotation (and a scale, but ignore that for the intuition). Basically, we want a way to calculate the position of a vertex relative to a bone. This is done the exact same way we compute a view matrix: Create a matrix with the transform of the camera, then invert it.

Example: We have a camera at position (1, 1, 1) and construct a matrix:
matrix.translation(cameraPosition);
is a matrix which simply adds the camera's position to each vertex. If we have a vertex at (0, 0, 0) relative to the camera and want to know where it is in the world, we just add the camera's position to it. Since the vertex is at the same point as the camera in this case (it is at (0, 0, 0) relative to the camera after all), the vertex is at (1, 1, 1) too. Easy to understand. However, we already have vertices in world space, and want to know where they are relative to the camera so we can draw them on a screen. So, we just invert the matrix we made, which in this case is the same as
matrix.translation(-cameraPosition);
since it's a simple transformation. It's clear that if we have a world space vertex at (1, 1, 1) and apply a (-1, -1, -1) translation to it, we end up at (0, 0, 0) relative to the camera again, as we should.

We do the same thing when computing the "inverse bind pose matrix" or whatever you want to call it. We first calculate the default transform matrices of each bone of the bind pose, then invert it to create a matrix that takes us from model space to a coordinate system relative to the bone. Simply put, it allows us to calculate where a given vertex is compared to a bone. Now, why is this useful? By calculating where a vertex is relative to a bone, we can move the bone and calculate a new position of every vertex affected by it easily by simply calculating the relative position of a vertex and then taking it back to model space again using a different (animated) bone matrix. The result is what we call skeleton animation.

What you want to do is simply this:
1  
2  
vec4 localPosition = inverseBindPoseMatrix * modelSpacePosition;
vec4 newModelSpacePosition = animatedBoneMatrix * localPosition;
which can be rearranged like this:
1  
2  
vec4 newModelSpacePosition = animatedBoneMatrix * (inverseBindPoseMatrix * modelSpacePosition);
vec4 newModelSpacePosition = (animatedBoneMatrix * inverseBindPoseMatrix) * modelSpacePosition;

In other words, you can precompute a single bone matrix which takes the vertex from its current model space position directly to its new model space position by precomputing (animatedBoneMatrix*inverseBindPoseMatrix).

Now, bone animation generally uses a weighted average of 4 different bones for each vertex. That just means that we compute the new position that each bone would give us and average together the results.

1  
2  
3  
4  
5  
vec4 newModelSpacePosition = 
        ((animatedBoneMatrix1 * inverseBindPoseMatrix) * modelSpacePosition) * weight1 +
        ((animatedBoneMatrix2 * inverseBindPoseMatrix) * modelSpacePosition) * weight2 +
        ((animatedBoneMatrix3 * inverseBindPoseMatrix) * modelSpacePosition) * weight3 +
        ((animatedBoneMatrix4 * inverseBindPoseMatrix) * modelSpacePosition) * weight4;
which can be rearranged to:
1  
2  
3  
4  
5  
vec4 newModelSpacePosition = 
        (animatedBoneMatrix1 * inverseBindPoseMatrix) * weight1 * modelSpacePosition +
        (animatedBoneMatrix2 * inverseBindPoseMatrix) * weight2 * modelSpacePosition +
        (animatedBoneMatrix3 * inverseBindPoseMatrix) * weight3 * modelSpacePosition +
        (animatedBoneMatrix4 * inverseBindPoseMatrix) * weight4 * modelSpacePosition;
and then to
1  
2  
3  
4  
5  
6  
7  
vec4 newModelSpacePosition = 
        (
            ((animatedBoneMatrix1 * inverseBindPoseMatrix) * weight1) +
            ((animatedBoneMatrix2 * inverseBindPoseMatrix) * weight2) +
            ((animatedBoneMatrix3 * inverseBindPoseMatrix) * weight3) +
            ((animatedBoneMatrix4 * inverseBindPoseMatrix) * weight4)
        ) * modelSpacePosition;
which is the most efficient way of doing it and what you're doing in your shader already. Wink

This may all look complicated at a glance, but it's really just multiplication and addition, just on coordinates and matrices. If you can grasp how this works, then you should be able to debug your code and fix it. There really isn't a shortcut to getting skeleton animation to just work without understanding it, and if you can grasp it you'll be one of the few people in the world who fully understands how this works.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-23 12:14:31
Well, depends on the scene and what you're drawing. If you have a smoke cloud of particles, you can easily get pretty big lists, but for just solid geometry it's usually not that high. If your geometry has a high opacity, you may only need to find the first few closest values instead of correctly sorting and blending all of them.
10  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-06-23 11:16:12
There is a way to get perfectly sorted transparency pretty easily. Use per-pixel linked lists and sort them at the end!
11  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-22 11:04:24
Summed up, I think the most efficient and flexible system is to just have a pre-processor and a compiler that compiles away precision attributes if not targeting OpenGL ES.
Yeah, I guess this will have to do.

precision qualifiers... "we want this crappy device to do 3D but it's a bit too crappy, but we can make everyone's lives more annoyingly complicated to squeeze out pointless extra performance so you can make games for it that nobody will play".
Nvidia's latest GPUs are claiming that they can do 16-bit float calculations twice as fast. If I don't need the precision, I'd love for my shader to be twice as fast.
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Universal Model Importer (JUMI) - Early Alpha on: 2016-06-22 10:38:47
Programmers find every excuse not to write the best code ._.
The best code is the code that does the job, is readable and doesn't take years to write. There's no point in optimizing something if a simpler solution is just as fast, making it the best solution.
13  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-21 22:38:00
Then again, see Unity shaders.

Bah, Unity again.

Cas Smiley
I tried to look into what they do, but I couldn't find anything useful. It's all VisualSuperShaderNoProgrammingRequiredWelcomingAllArtMajors nowadays for the big engines.
14  Game Development / Newbie & Debugging Questions / Re: Skeletal Animation on: 2016-06-21 22:18:43
It's probably <1000 bones, even for AAA games. It's not worth complicating the code for it.
15  Discussions / Java Gaming Wiki / Re: Java Data structures on: 2016-06-21 21:42:26
Android ain't Java, though Wink

Cas Smiley
Hmm???
16  Game Development / Newbie & Debugging Questions / Re: Skeletal Animation on: 2016-06-21 21:41:39
I'm not awake enough to go through your code, but you're definitely doing something wrong.

Here's my code for this:

1. Precompute bindpose: matrices = translationRotateScale(offset, rotation, scaling).invert(). Make sure that this is transformed by the parent as well:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
Vector3f translation = new Vector3f(joint.getTranslation());
Quaternionf orientation = new Quaternionf(joint.getOrientation());
Vector3f scale = new Vector3f(joint.getScale());
if(joint.getParent() != null){
   parentOrientation.transform(translation);
   translation.mul(parentScale).add(parentTranslation);
   parentOrientation.mul(orientation, orientation);
   scale.mul(parentScale);
}
matrix[i] = new Matrix4f().translationRotateScale(translation, orientation, scale).invert();


2. When animating, interpolate between two frames, transform by the (animated) parent joint, generate a matrix and multiply it with the precomputed matrix:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
//Interpolate between translations, orientations and scales. Use lerp() for Vector3fs and slerp/nlerp/nlerpIterative() for quaternions.

Vector3f translation = ...; //lerp()
Quaternionf orientation = ...; //slerp()
Vector3f scale = ...; //lerp()
if(joint.getParent() != null){
   //Note that this is the already lerped/slerped values of the parent.
   parentOrientation.transform(translation);
   translation.mul(parentScale).add(parentTranslation);
   parentOrientation.mul(orientation, orientation);
   scale.mul(parentScale);
}
matrix[i].translationRotateScaleMulAffine(translations[i], orientations[i], scales[i], bindPoseMatrices[i]);
17  Java Game APIs & Engines / OpenGL Development / Re: Discussion: The mother of all shading languages on: 2016-06-21 21:29:28
Thanks for the input. I'm gonna roll with a minimal GLSL preprocessing system just to get things running in the first place, but it doesn't feel like a good long-term solution.

Is it common for people to just write the same shader for different languages?
18  Game Development / Newbie & Debugging Questions / Re: Skeletal Animation on: 2016-06-21 19:34:56
How do you compute the matrices?
19  Java Game APIs & Engines / OpenGL Development / Discussion: The mother of all shading languages on: 2016-06-21 18:43:19
TL;DR: I'm trying to come up with a write-once-run-everywhere system for shaders, so that they can be run on OpenGL, OpenGL ES and Vulkan (and possibly others in the future) without having to write the shader once for each API. There are also lots of other problems concerning reusing of shader code (lots of shaders share descriptor sets, shared functions, etc), and this is a good opportunity to tackle these problems too. In the end, the choice is between simple preprocessed GLSL (limits us to GLSL-based APIs), inventing a new shader language, or trying to use/adapt a system that already exists as the big game engines must be solving this problem somehow. I want to start a discussion about this.


Hello, everyone!

I've recently been working on an abstraction layer for OpenGL, OpenGL ES and Vulkan. The idea is to design an engine that allows for maximum performance in all three APIs while only requiring you to write your code once. It won't necessarily be easier to use than Vulkan, but it will definitely be less work to use it if you plan on supporting Vulkan at all. For example, Vulkan command buffers will be emulated on OpenGL as they're required for maximum performance with Vulkan, and they can actually be very useful for OpenGL as a kind of software display list, allowing you to generate an optimized list of OpenGL commands to call, with a lot of state tracking done internally to remove unnecessary calls. On the other hand, OpenGL has VAOs that can improve performance significantly if used correctly, while Vulkan has a much simpler system, so the abstraction will support something similar to VAOs as well. I'm getting sidetracked, but in short it'll give you the union of all the features of OGL, OGLES and VK that are required to cram the most out of each API.

The issue I want to start a discussion about is the shaders. OGL, OGLES and VK all use GLSL, but there are significant differences between them.
 - OpenGL needs assigned binding slots for textures, UBOs, images, etc, which can either be set with a layout()-qualifier or from Java. Shader-defined layouts are not supported in Vulkan, but Java-defined binding slots is a valid workaround.
 - Vulkan requires grouping descriptors into descriptor sets which AFAIK must be set in the shader (but can be set using compile-time constants, so from Java). Set/binding aren't supported by other APIs.
 - OpenGL ES is very similar to OpenGL, but can heavily benefit from mixed precision computing (lowp, mediump, highp) to improve performance. These identifiers are not supported in other APIs.

Since each of these APIs require some fairly different shaders, I would really like to avoid having to fill my shaders with a crapload of #ifdefs just to define the different behavior with different APIs. This is also extremely error prone as you have to rewrite a lot of the shader for each API, making it easy to introduce errors that will only occur once you actually test the shader on a specific computer/phone. I really want to keep the "write once, run everywhere" idea here too, so it makes a lot of sense to have some kind of intermediate/abstract representation of the shader that in turn is "compiled" to different kinds of GLSL for each API, with different parts automatically injected (descriptor set bindings) or removed (precision qualifiers) depending on the compilation target.

A major feature of/requirement for Vulkan is descriptor sets, so these will have to be emulated on OpenGL. An important point of descriptor sets in Vulkan is that you are able to bind a descriptor set and then change shaders, and if the new shader shares some descriptor set layouts the old sets will remain bound and continue working (just like how texture/UBO/image/etc bindings remain bound between shader switches), hence it will be very common for people to want the same descriptor set in lots of shaders. For example, probably 90%+ of my shaders will use the camera information (matrices, depth info, frustum info, etc), and having copy-pasted code in each and every shader I have that needs to be maintained is a perfectly paved way to a huge amount of future pain. Hence, it would make sense to also have some kind of import feature, so that I can define shared descriptor sets in a separate file and import it into each shader instead. At that point, I might as well add import functionality for shared functions as well, like random value generators, dithering, tone mapping, g-buffer packing, etc, since I have those copy-pasted everywhere as well.


At this point there is actually very little raw GLSL code left in the shader. Here's an example vertex shader:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
//#version injected depending on API

//Samplers/UBOs imported from predefined descriptor sets
#importset "MyDescriptorSet1"
#importset "MyDescriptorSet2"

//Vertex attributes are semi-automatically set up, so they need to be parsable:
#in highp_vec3 position;
#in mediump_vec2 texCoords;

out mediump_vec2 vTexCoords;
out lowp_float color;

//Shared function imported from separate file:
#import float rand(vec2)

void main(){
    gl_Position = viewProjectionMatrix * vec4(position, 1.0); //viewProjectionMatrix comes from imported descriptor set.
    vTexCoords = texCoords;
    color = rand(texCords);
}



At this point, the GLSL is pretty hard to recognize. Considering the pretty big number of features that I want to add, it almost makes sense to make an entire new shader language for this. That would also have the advantage of allowing us to support other APIs, like Metal Shading Language (ugh), DirectX's HLSL, maybe even console shading languages one day. I can think of a few ideas:

 - I go with my original idea, the bastardized GLSL above, and use a simple preprocessor to replace #-commands with code and injecting #defines. It'd be the least work, but only works with GLSL-based languages.
 - Creating a whole new intermediate shading language which passes through a compiler that spits out shaders for all the different APIs.
 - Using an already existing intermediate format/system to generate the shaders. Unity and presumably other engines must be tackling this issue as well somehow to support OpenGL/DirectX/consoles.
 - A crazy idea I had was to convert Java bytecode to GLSL shaders so we could write them in Java, but I don't think that'd actually be feasible.


What do you guys think? Would anyone be interested in working together to build such a shader system? Does anyone know how the big engines tackle this problem? Discuss, tell me what you would need to use such a system and if you'd be willing to contribute!
20  Game Development / Artificial Intelligence / Re: euler numbers (discussion and explanation will be continued) on: 2016-06-21 12:00:02
Consider making an article about it instead. This sounds interesting!
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Universal Model Importer (JUMI) - Early Alpha on: 2016-06-21 07:34:52
I think that last part is a big issue. There should be a copious amount of polymorphism. This allows me to box and unbox.
It would save on the millions of booleans created, too. isWhateverSupported()

You do NOT want one class per file format. The entire point is to be able to write your own code to convert JUMIMesh to your own internal format. If you have to do that per file format anyway, then JUMI is pointless.
22  Game Development / Shared Code / Re: Hydro's Game Engine on: 2016-06-18 18:33:45
Understanding someone else's code completely takes a huge amount of effort. I know it's cynical, but the chance that someone will use or look through your (not yours specifically, just a general "your") engine is miniscule. At best someone may sift through it to rip some specific feature from it, but even that is rare. It's just much more effort than using a well-known, well-documented library with lots of discussion and tutorials around it already. I mean, ask yourself how many of the undocumented open-source engines you've used or looked through made by the people of this forum. I bet you haven't even tried out LibGDX at all. =P I am/was like that too.

If your goal is to learn more and get a deeper understanding of engines by rolling your own engine, then by all means do so. It's a massive learning experience, not to mention fun as hell. However, if you want other people to actually use and benefit from your work, then either contributing to an existing lib/engine (LibGDX, jME, LWJGL, JOML, anything) or building tools/utilities that build on top (or work alongside like Artemis) of other popular libraries is the way to go. That way you have a 1000x better chance to contribute something that matters.
23  Game Development / Newbie & Debugging Questions / Re: Counting Vertices to Triangles on: 2016-06-18 11:00:44
You're drawing a 2D grid using triangles.

Let's do this in 1D. You want to form a line from vertices. You draw a line from vertex i to i+1, but the last vertex has no other vertex to draw a line to. You end up with n-1 lines for n vertices.

Now, expand to 2D. You want to draw quads from a grid of vertices. You form a quad between (x, y, x+1, y+1), but again, the last vertices along x and y have no pairs. You end up with (n-1)*(m-1) quads from n*m vertices. A quad can be split up along the diagonal to get two triangles --> *2. Each triangle is 3 indices --> *3
24  Game Development / Shared Code / Re: Hydro's Game Engine on: 2016-06-18 10:29:09
His point is that it'd be better for the community in general if we all just helped outwith jME instead of creating our own engines.
25  Java Game APIs & Engines / OpenGL Development / Re: Global Illumination via Voxel Cone Tracing in LWJGL on: 2016-06-18 10:25:13
The default is in.
26  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-17 21:43:51
Looking quickly, the follow should all be good of the fp routines:
sqrt,ceil,floor,rint,round,abs,min,max,ulp,signum,copySign,next{Up,Down,After},scalb
Are all functions in StrictMath OK in that sense as well?

EDIT: Apparently that's the whole point of StrictMath. According to this: https://gist.github.com/ijuma/840120, the only things slower are sin, cos, tan, exp and log.
27  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-17 11:46:18
yeap, but you have to take care with things like "java.Math" functions.
Which functions?
28  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-16 10:00:56
The problem is that this can lead to very weird situations. An error in one object's position can cascade out to all nearby object through physics etc, so a huge pile of AI could constantly be pushing each other into the wrong positions if not all of them are updated at once. That would require the server not updating random objects each update, but identifying all touching objects to resync the entire batch. At the same time, we can't afford to use lock-stepping either since it's not responsive enough. I'm just scouting my options here, and if floats are reliable enough, then that's another tool I can use if I need to.
29  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-16 09:41:29
Yes i have tested this ages ago. It is one of the reasons the base java math class is fairly slow since IEEE 7 whatever  is fairly strict and java requires 2ulp accuracy (also Part of IEEE IIRC). It is *bit perfect*.
The reason why I thought it wasn't exact was the ULP requirement. If the result has to be within 2 ULP of the correct result, then technically there are up to 5 possible answers that are all deemed correct. Is there really a requirement that says that all hardware must round all results exactly the same way?

Thanks for all the info everyone!
30  Discussions / General Discussions / Re: Question: Bit-exact floats on different computers? on: 2016-06-15 21:55:01
Even on ARM and for both floats and doubles? Can I be 100% sure that if I run the exact same deterministic program on both the result will be bitwise exactly the same?
Pages: [1] 2 3 ... 115
 
CopyableCougar4 (39 views)
2016-06-25 16:56:52

Hydroque (75 views)
2016-06-22 02:17:53

SwampChicken (76 views)
2016-06-20 13:22:57

SwampChicken (76 views)
2016-06-20 13:22:49

SwampChicken (71 views)
2016-06-20 13:22:26

Hydroque (114 views)
2016-06-15 08:22:50

Hydroque (106 views)
2016-06-13 06:40:55

DarkCart (229 views)
2016-05-29 02:30:33

Hydroque (190 views)
2016-05-26 14:45:46

Mac70 (181 views)
2016-05-24 21:16:33
Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42

FPS Camera Tutorial
by Hydroque
2016-05-22 05:40:58

Website offering 3D Models specifically for games for free
by vusman
2016-05-18 17:23:09

Website offering 3D Models specifically for games for free
by vusman
2016-05-09 08:50:56

Website offering 3D Models specifically for games for free
by vusman
2016-05-06 11:10:21

Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56:17
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!