Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Online Last Active Today, 12:48 AM

#5254905 What exactly is API-First?

Posted by TheChubu on 30 September 2015 - 07:27 PM

I'm always gobsmacked at the number of people in software companies who can with a straight face extoll the virtues of agile development, while actually using a purely waterfall planning process to feed into a vaguely Kanban-like priority queue for the dev team.
Hahaha so true.

#5254484 What exactly is API-First?

Posted by TheChubu on 28 September 2015 - 03:13 PM

Self fulfilling prophecy. Author talks big about nothing, nothing becomes something because of what the author said. Bam, traffic.


Next year you'll be hearing about API First manifesto or something...

#5254073 XML Parser for Asset Manager

Posted by TheChubu on 25 September 2015 - 08:44 PM

Ah, so I should avoid XML.  I played around with serializing classes, but I was thinking it would be easier to tweak XML files during development. I
It will.


Thats why usually big game engines have two pipelines. The easy XML/JSON/YAML one for development where you can easily either tweak directly or through tools, and the content pipeline that "compiles" all of those resources into fast and compact binary data, which is what the final product will be using.


If you want to go the markup route for developing, I'd recommend YAML (using SnakeYAML in Java particularly https://bitbucket.org/asomov/snakeyaml), its much easier to work with than XML.


HashMaps in Java are quite fast for big volumes of data (you can find benchmarks using them for storing millions of elements) but they're kinda bad on the memory efficiency department. They're implemented as an array of entries/nodes, each entry object holding a reference to the key, to the value, int hash and reference to next entry.


Thats 12 bytes for the object's header, 4 bytes for the key ref, 4 bytes for the value ref, 4 bytes for the int hash, 4 bytes for the next entry ref. 28 bytes, 32 bytes in total given 8 byte alignment (gets 4 bytes of padding). And for each entry you need a reference to it in the entry array, so thats another 4 bytes. And thats only for keeping track of the data, not even the data itself.


(On 64 bit systems it will be the same unless you're using big ass heaps (think 10Gb+) thanks to compact pointer representation on HotSpot at least)


But who cares man! Use whatever is easier to use right now. HashMaps, LinkedLists, whatever... (well not LinkedLists, that would be stupid). Later you can worry about memory usage if it ever becomes a problem. As long as you're aware of it, it'll be fine.

#5253195 Is it possible to optimize this? (keeping a small array in registers)

Posted by TheChubu on 20 September 2015 - 11:53 AM

This reeks of http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

#5251944 Bad performance when rendering medium amount of meshes

Posted by TheChubu on 12 September 2015 - 04:54 PM

glBindVertexArray(vao) // Vertex Array (Vertex +UV +Normal Buffers)
Yep, thats going to be slow.


As Ryokeen suggested, you totally can pack meshes into a single buffer and just send an offset to the draw call. Check ARB_draw_elements_base_vertex, there are similar calls for drawing plain arrays, or instanced  arrays/elements draws.


That way you can just pack all your static meshes in one big buffer, managing the offsets yourself (which is fun :P) and have only a couple VAO switches. Since you're essentially doing memory management there, you need to have in mind things like memory fragmentation (ie, what happens if you pack 500 meshes then remove 200 randomly from the same buffer, things get fragmented), so beware.


The idea is not to use VAOs to specify "this is a single mesh that I can draw and the buffers attached have only that mesh" but more like "this is one kind of vertex format I support, and the buffers attached have tons of meshes with the same format".

#5250492 Using gatheralpha for alpha test - problem with BC3 (DXT5) textures

Posted by TheChubu on 03 September 2015 - 05:33 PM

On the plus side, your bugged screenshot looks like a nice world map :D

#5250169 entity component system object creation

Posted by TheChubu on 01 September 2015 - 02:45 PM

XML is totally viable awfulI'm using it myself if you ever see me using it, break one of my legs.

FTFY. YAML is so much more prettier than XML that it isn't even funny anymore. Its also measurably prettier than JSON.


Look at this:

    positioning: normal
    z_offset: 0
  position: { x: 0.0, y: 0.0 }
    texture: null
    blending: normal
    tone: {r: 0, g: 0, b: 0, a: 0}
    frame: 0.0
    angle: 0.0

Versus this:



#5249788 acos ( ) in Java has gone bezierk

Posted by TheChubu on 30 August 2015 - 05:07 PM

All Java's Math trigonometry functions use radians. Keep that in mind (or read the docs, thats why they're there).

#5249278 Accurate Analytic Approximations for Real-Time Specular Area Lighting

Posted by TheChubu on 27 August 2015 - 10:47 PM

It smells like patented.

#5246935 Tinted bloom?

Posted by TheChubu on 16 August 2015 - 11:48 AM

Well I did the dir to center thingy, apparently with a normalize you get artifacts in the sampling near the center of the screen (its like as if the samples are sucked into the center). Multiplying by a small factor like L. Spiro suggested did the trick.


  float aberrationStrength = 0.02;
  vec3 toCenterTint = normalize(vec3(0.9372549, 0.26666668, 0.1));
  vec3 fromCenterTint = normalize(vec3(0.20392157, 0.0, 0.9372549));

  vec2 dirToCenter = passTexCoord - vec2(0.5, 0.5);
  vec2 offset = dirToCenter * aberrationStrength;

  vec3 tintedBloom = txMisc2.xyz; // Normal bloom texel.
  tintedBloom += texture(gbMisc2, passTexCoord + offset).xyz * toCenterTint;
  tintedBloom += texture(gbMisc2, passTexCoord - offset).xyz * fromCenterTint;


I'll prolly have to move the tint and strength parameters into the directional/sun light constant buffer so they're configurable.




#5246098 nVidia's OpenGL Core debugger for Linux

Posted by TheChubu on 12 August 2015 - 05:39 PM

nVidia released a OpenGL debugger for Linux, 4.3 core profiles and above.




...as long as you get a Gameworks dev account that is.

#5246096 Core OpenGL shader designer tools?

Posted by TheChubu on 12 August 2015 - 05:34 PM

This one is a recent project but looks pretty nice:



#5245184 Vulkan is Next-Gen OpenGL

Posted by TheChubu on 08 August 2015 - 09:50 PM

And that is news? Isn't that how OpenGL specs had always been released?

THATS the issue right there. I don't care if it always has been like that. That is the crappiest way anyone (Khronos and devs alike) could even try to rationalize the thing.


Right now I have to wait months for that "big reveal", hope I get Linux drivers from nVidia in a reasonable time, hope they support Fermi cards (Fermi D3D12 drivers aint here yet!), hope that LWJGL guy can work on Vulkan bindings in a reasonable time and then, only then I can start to work with it.


If a Khronos member reads that and thinks "THIS SOUNDS PERFECTLY FINE AND THIS IS HOW IT SHOULD BE UNLESS YOU SIGN UP FOR THE 10K USD MEMBERSHIP" they need to be slapped. Hard. With a hot iron. In the genital area.


By the time it gets released, I'll might end up too pissed off to bother with it to be honest...


EDIT: I'd totally buy that shirt tho :D

#5245034 Tinted bloom?

Posted by TheChubu on 07 August 2015 - 06:16 PM

Looks like the bloom buffer is tapped 2 times with a centered radial UV shift and each tap is tinted with a purple and orange tint and added together.
... okay, but I'm going to need to know what does "tapped 2 times" and a "centered radial UV shift" means.

#5244993 Tinted bloom?

Posted by TheChubu on 07 August 2015 - 12:01 PM

Hi! Please look at these pictures (they're from Planetside 2)





As you may notice, the glow of the sun and the bloom of the surfaces has this tint that looks to depend on the direction. I'm not terribly sure whats going on.


I added (for teh lulz) a chromatic aberration shader on the bloom pass:



But it doesn't quite looks the same. Besides, from the Planetside 2 pics you can see the tinting doesn't always follow the same direction (sometimes its reddish to blueish from right to left, sometimes from top to bottom, and so on).