Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Offline Last Active Today, 07:31 PM

#5259825 Singletons and Game Dev

Posted by TheChubu on 30 October 2015 - 08:29 PM

However, I've looked at some game libraries and engines (most prominently libGDX and Unity) and I've noticed they have no shame with exposing a lot of data structures globally.

libGDX? You're using libGDX as a reference of some sort?


Take a look:




Thats exactly what it looks like. A static float[16], whats its used for? Oh nothing too important, just holding effin intermediary results in math functions.


What does that means? That you can't possibly  invert a matrix on two separate threads because it will fuck something up. Read that again: You can't use libGDX's math functions on more than one thread. And you know what? Its not the only static used that way in libGDX.


I'll just leave you with that bit of information.


EDIT: More on topic -> Eff singletons. All of them. I'd simply copy-paste swiftwcoder's words here.

#5257825 Changing city names

Posted by TheChubu on 18 October 2015 - 04:56 PM

Plural people, plural.


Los Juegos -> Literally "the games". Juego can be used for gambling but its more of a context thing. "Las Apuestas" it would be more direct. From where I'm from "timba" is slang for gambling, so the name would be "La Timba", sort of "the gambling" literally.


Los Paraisos -> The paradises. Singular "El Paraiso", the paradise.

#5257365 GLSL Error C1502 (Nvidia): "index must be constant expression"

Posted by TheChubu on 15 October 2015 - 11:27 AM

Thanks, sadly the same error still occurs.
Have you tried what Mathias suggested? Redefining the array inside the block, not outside?


layout (std140) uniform LightSourceBlock
    LightSource lights[MAX_LIGHTS];
} LightSources;


This works. Its how I define UBOs. Tried it on nVidia hardware (GT21x, Fermi), and AMD (HD 5xxx, HD 4xxx), GLSL 330.

#5257280 GLSL Error C1502 (Nvidia): "index must be constant expression"

Posted by TheChubu on 14 October 2015 - 09:33 PM

lol yeah, I remember when I got this issue (same GLSL version, nVidia hardware), apparently "const int" isn't constant enough for nVidia :D As Mathias said, a #define works fine in this case.

#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.