Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


TheChubu

Member Since 13 Sep 2012
Online Last Active Today, 09:27 AM

#5212891 How do game engineers pack their data?

Posted by TheChubu on 25 February 2015 - 05:06 AM


Well that was a stupid question. I totally forgot that you can load files into a MemoryStream. So you would just load the zip file contents into a MemoryStream without having to decompress it to the hard drive. 
Exactly, the whole point of adding compression is that sometimes reading uncompressed data takes longer than reading it compressed into memory and uncompress it on the fly.

 

Although ZIP is kinda heavy weight for decompression AFAIK, you could try with other faster methods like LZ4 (that dont give such good compression rations though). As with anything, you'd need to test it out.




#5212848 How are the TF2 classes programmed?

Posted by TheChubu on 24 February 2015 - 10:58 PM

Actual player classes needn't be an actual class in the codebase. There is nothing preventing them from just asigning one specific model with a few specific set of weapons, and switch those based on what the user selects in some UI widget.

 

Hell, making a Scout class seems to me like heavy handed hardcoding of how the weapons/models/abilities should be distributed. You don't want that, you don't need that, and doing it in a generic way will make your life easier when modifying classes, adding, removing or merging classes, etc.




#5212631 Max performance and support

Posted by TheChubu on 23 February 2015 - 11:59 PM


Not 3.2, but on 2.1 I used dynamic indexing of an array of uniform variables inside a fragment shader, and my FPS dropped from 60 to 1 -- a sure sign that the driver has reverted to software emulation 

Of course but I asked for OpenGL 3 hardware examples for a reason, as to raise the point that this complaint keeps coming up. It seems as if OpenGL users are like the ARB, holding onto the past too much tongue.png

 

In any case, knowing if feature X is emulated in Y cards is good knowledge to have, which is also why I asked.

 

 

 

iOS partially does in certain circumstances, such as when attributes in a vertex buffer are misaligned.

ie, not aligned to 16 bytes? ES 2? I've seen thrown around that explicit 16 byte alignment is good for some desktop hardware too, AMD cards apparently. I'm assuming if you're using another API (Mantle? ES 3?) you'd have to do proper alignment in any case.




#5212577 How were you learning programming at the age of 5?

Posted by TheChubu on 23 February 2015 - 06:03 PM


I cut my teeth on this language, and some days I look at C++ and miss the simplicity of my old 8 bit...
Looking at C++ makes you miss the simplicity of everything else ever made.

 

More on topic: Well, there are 5 year old learning how to play piano, or how to dance, or how to paint, or how to read (reading is a very complex thing mind you), I don't see how learning to code is that much different. Hopefully they'll code 5 or 10 more years and then choose a more sane hobby/profession when they get out of high school :D




#5211068 Modern game development/programming for a not-quite beginner?

Posted by TheChubu on 16 February 2015 - 04:51 PM


Also, does anyone have any advice on 32 bit versus 64 bit development?  Is it worth starting out doing both?  Or should I just stick with 32-bit to start and worry about 64 bit later?
If you go the C# route, it probably wont matter.


#5210710 Entity-Component Confusion

Posted by TheChubu on 14 February 2015 - 11:51 AM

- optimizing single-threaded code is 100x simpler than multithreaded.
Eh, on that link, reads don't produce false sharing. And if he really is writing to globals from multiple threads he definitively knows less than I do about multithreading (and I don't know much btw).

 

Laying transforms in a way which each thread doesn't steps on the other is really straightforward: Contiguous arrays of transforms, give 1/4 to each thread. By the time one thread reaches the transform that *might* trigger a cache reload, the other thread will be writing far away from there. 

 

Not the best example IMO.




#5210397 Entity-Component Confusion

Posted by TheChubu on 12 February 2015 - 07:25 PM


The main issue is that I am writing in C++
Look at this C++ port of Artemis?


#5210388 Entity-Component Confusion

Posted by TheChubu on 12 February 2015 - 06:28 PM


Does Artemis actually say that it is a solution for optimising your game?
Actually, original Artemis doesn't stores components in maps. I know Ashley (libGDX sponsored ECS framework) does, and in fact gives pretty crappy iteration performance. Artemis, its most popular fork artemis-odb and my own fork, all store components in arrays.

 

What Artemis did is have a component manager storing components in an array of arrays of components. So each slot in the array would correspond to a component type, and the array in that slot would contain all the components of that type for all entities that had them.

 

Thats why if you look at the source, you got a Bag of Bags of components. For retrieving a component you'd do componentsByType.get(componentTypeIndex).get(entityID). Thats esentially componentsByType[typeIndex][entityID]. Array of arrays of components.

 

Now, Artemis is made in Java, so the thing is, its not arrays of components but arrays of pointers to components. Yes, this gives bad cache locality*, but thats all you have in Java unless you want to go the way of the ByteBuffer and pretty much implement array of structs by hand, which is only viable if a) You have a lot of experience with this stuff and know exactly what components will get processed often in which groups or b) You already have a semi complete game and can profile to see what components are worth having close to eachother.

 

I'm not a performance guru but I advocate for the following: Just do plain arrays of pointers to components. Right now it will probably be enough for whatever use case you have, and its something you can perfectly optimize for later when you have enough test cases to try. Its easier to optimize for a specific target rather than thinking right now months (or years!) ahead what your use cases might be in the future to warrant such optimizations.

 

Moreover, having array of pointers to components means that you don't need to do any complex entity -> component mapping. Just have an array of pointers, and to get a component just index into it with the entity's ID. ie:

 

Spatial* sp = spatials[entityID];
Velocity* vel = velocities[entityID];

 

This means that you'll have one indirection when you access the component BUT the important point right now is have something working and nail the ECS way of doing things. Systems shouldn't know the particulars of how components are stored, so you can come up with an interface for the systems to retrieve components, and resolve the way they're stored behind their backs so to speak. That way if in the future you want to optimize further by storing components contiguously or compacting their arrays, you can do so transparently.

 

* Actually it depends of the GC algorithm, if the component objects are discovered by the GC pass via said array, they'll get copied to an older generation one next to the other. Which helps a bit.




#5210273 Does draw calls number always matter?

Posted by TheChubu on 12 February 2015 - 08:35 AM


The advice from about 5 years ago
Which is more like 12 years ago :D


#5210157 Deferred optimization

Posted by TheChubu on 11 February 2015 - 05:32 PM

ie, read that Killzone PDF I linked, there it explains a two pass stencil optimization. No third pass is necessary.




#5210000 Deferred optimization

Posted by TheChubu on 11 February 2015 - 05:43 AM


Actually, you mentioned that you already tried stencilling your point lights... Did you use sphere meshes for this? If you used fullscreen quads to initialize the stencil buffer, that might explain why you didn't gain any performance from it...
Yeah this. I was assuming OP was using regular spheres for point lights. If you use a fullscreen quad for each light indiscriminately, its bound to run slow, and even slower doing the stencil pass (hell I don't think it would even work, can't mark any pixels in front of the volume).


#5209895 Deferred optimization

Posted by TheChubu on 10 February 2015 - 05:34 PM

Am I just hitting the wall on my laptop ? What are some common tricks I can use to reduce the time required for the lighting passes?

Dont store position, reconstruct it from depth. Don't store specular color as kalle_h said.

 

I don't know what exact stenciling method you use but the one from Killzone 2 is pretty straightforward, lighting is done in two passes: First mark all pixels in front of all the light volumes, then compute lighting on those marked pixels. Say for point lights, it would be two draw calls in total with instancing for example.

 

If you're okay with limiting yourself to 255 lights per pixel at most (and you're not using the rest of the stencil bits), you could use a different trick, instead of marking each pixel, increment the stencil, then in the second pass, decrement it and test for stencil greater than 0. That way it could save up some computations in the case of overlapped lights (from the camera perspective).

 

 I think compressing this to 3rts is do-able, reconstruction position from z + screen space, compressing normals to 2 channels, etc, but am worried that this will be a wasted effort if it increases the pixel shader complexity.

 Often the issue is not number crunching but going through hoops in memory to sample various textures around. Thin G buffer -> Less memory trips.

 

EDIT: And I insist the text editor should eat a bag of dicks for still messing the quote blocks. Here is the thread where I reported this issue.




#5209889 What version of opengl should i learn?

Posted by TheChubu on 10 February 2015 - 05:15 PM

my graphics card supports opengl 3.0

Whats your graphics card?

 

What about that, is it that difficult? Are there any alternatives to doing that?

 

Kinda. Thing is, do you want learn to do cool stuff or not?

 

EDIT: Text editor should eat a bag of dicks for messing the quote blocks AND adding whitespace out of nowhere.

 

Here is the thread where I reported the editor issue: http://www.gamedev.net/topic/665337-editor-messes-up-quote-blocks/




#5209705 ASTC compressed textures on normal OpenGL

Posted by TheChubu on 09 February 2015 - 06:04 PM

Look here: http://www.g-truc.net/project-0034.html#menu

 

Grab the January 2015 matrix PDF, ASTC isn't supported on desktop. So DXT all the things.




#5209508 Article suggestions

Posted by TheChubu on 08 February 2015 - 05:42 PM

From the engine building standpoint I often find the following thing: I don't know what I'm designing for exactly.

 

See, when you have little experience building actual games, its kinda hard to say "well, I'll start with the rendering system", because you have no idea how exactly will such system will be used in the future. You can have a vague idea of what you want, but since you havent implemented those parts yet, you simply lack the knowledge to identify all of the concrete requirements the subsystem must fulfill to be useful.

 

In that regard I often end up refactoring a lot of code simply because at the time of writing it, didn't imagined my now current use case would need XYZ feature, or doing ZYX thing in a different way.

 

A guide on what normally you would expect of each subsystem would be nice. My most recent example is a physics system, I had to dig out an old Gamasutra article to find out what kind of things a physics subsystem would need to offer to the rest of the engine so it can be useful.

 

Having that kind of insight of what you might need of certain parts of the engine in the future is valuable knowledge, since those are usually discovered by experience or trial and error, which are at the very least time consuming.






PARTNERS