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!


Member Since 27 Aug 2002
Offline Last Active Jan 29 2015 12:26 PM

#5138625 Controlling difficulty in a randomly generated game.

Posted by Krohm on 13 March 2014 - 01:59 AM

I used to be an hardcore gamer but I'm fairly casual now. I cannot last more than a few seconds.

I'd say the game requires a very accurate estimation capability. The enemies are large in number since start (so I cannot even tell if they follow a pattern or not) and the size of their bullets are massive compared to player's.

Personally, I haven't noticed any strategic component at all, it's just a matter of converging functions. Each enemy appears to require a few shots to go. Your ship takes a few shots to go. There are more enemies, and their bullets are bigger so there's basically an order of magnitude divergence to overcome. I suppose letting the blast charge is key, this would require some tactics, it might be possible as the player is experienced, but with no chance at understanding the mechanics in 10-second bites, my determination rapidly declined.


The language used by the game does not say "it never ends", it says "it ends now".


I'm not sure but... do you get damage by hitting the borders of the game area?

How often are you adapting enemy ships?

#5131948 Rendering Text from *.txt file

Posted by Krohm on 17 February 2014 - 01:07 AM

text rendering operations are notoriously hard to implement properly and flexibly, and if you're writing a game you probably don't want to spend time rolling your own
QFE. On Windows, Uniscribe can encapsulate you from most problems. On *nix, it's either Cairo or Harfbuzz, it is my understanding the FreeFont library is not enough. I wouldn't touch those unless forced to.

#5130981 From C to ?

Posted by Krohm on 13 February 2014 - 01:23 AM

I wouldn't go on C++ right now. Main problem is that there's no such thing as "C++" to start with. I mean just read this:

On Youtube you can find long presentations form Stroustrup where he talks about how not to look at at C++ as C with classes and how to do things the C++11 way. They might sound a bit advanced though (1).
This was the last one I saw: "The Essence of C++: With Examples in C++84, C++98, C++11, and C++14" (2)

Here's what I read "between the lines":

  1. The new, non-broken way. But wait, because the new not-broken way is complex.
  2. 4 versions. Four.

I'd probably go C# right now. Java left me a bitter taste and not in the good way.

#5130229 Towards better error handling constructs

Posted by Krohm on 10 February 2014 - 02:41 AM

A thing I do in my code since I've switched to exceptions is to take advantage of the following property:

  • many places in which stuff can go wrong;
  • usually one place in which we can trivially say "from now on, nothing can go wrong"

So, I push on stack a sequence of "undo" functions and disable them when successful. It's still far from the "fire and forget" construct I'd like but still better than writing an explicit try/catch in my opinion. The lack of error information however is a real concern, I suppose I could work out an half-decent interface for it... but in the end, I don't need that so my research ends here.

Continuation appears interesting; I have a testbed for this, maybe in the future I'll investigate.

For now, I'm following the thread.

#5130224 Structuring game engine code

Posted by Krohm on 10 February 2014 - 02:16 AM

A good architecture is a start but execution is key.

I'm also planning on adding 'Physics' and 'Network' projects once I get to those parts of the engine, and possibly a 'Resource' project that solely deals with loading and releasing external resources as the engine uses them.
When it comes to physics I can tell you we're talking about <1000 LOC.

Don't over-engineer. Use an iterative, explorative approach.

Over all, don't write a game engine. Always keep in mind your goal. You will never get to something usable without keeping your design documents at hand.

#5128440 assimp subsets problem

Posted by Krohm on 03 February 2014 - 09:25 AM

Is the sphere missing any triangles? You are concatenating all the vertices but on draw call, you don't use subset.VertexStart (LN54), maybe you forgot to use it to initialize offset (LN304)?

#5128355 Why would devs be opposed to the PS4`s x86 architecture?

Posted by Krohm on 03 February 2014 - 02:10 AM

People who have spent their whole programming lives on the x86 platform don't really notice
I have spent my life on x86, yet I feel uneasy with it. One just has to look at the details.

Example: compare the effective ALU size of a die to the control circuitry, most of it is for out-of-order execution. All the instruction dependencies could be accounted at compile time, so what is OOE useful for? To hide the memory latency I suppose... a problem that arisen exactly because there's no way to put the right amount of memory in the right place. OOE makes no sense for closed architectures where SW is heavily scrutinized.


OOE reloaded: Intel puts two cores into one, then figures out most threads are dependancy limited and provides HyperThreading to perform OOE across two threads. Kudos to them for the technical feat but I wonder if that's really necessary and BTW, no HT-enabled low-end processor years after introduction.


There's no such thing as x86: x86-Intel is a thing. x86-AMD is another. The latter is at least somewhat coherent in features. With Intel the thing is a bit more complicated (albeit we can discuss those advanced features to be currently useful).


So, I can absolutely understand at least one good reason for which developers didn't take this nicely. X86 is just cheap, in all senses, good and bad.

#5127400 Raw draw functions in Game Engine (C++)?

Posted by Krohm on 30 January 2014 - 01:33 AM

Don't use .obj to do animations. Don't even try. It is a long, painful way with nothing at the end.

Personally I would suggest you to try prototyping it using an existing game - UDK will sure do but it's a bit complicated. You could be able to set up simple time-based scripting by just dealing with delays (from the editor) and input mangling.

Do not hardcode limits in your system. It's just easier to ensure all your levels are "boxed" correctly. The collision library Bullet has a special primitive for this specific purpose: a wall of infinite thickness if you want to have it easy. Personally I don't use it as its restitution is a bit different compared to standard "finite" rigid bodies.

#5126652 Concatenation of vertex buffers and performance

Posted by Krohm on 27 January 2014 - 12:18 AM

If I use 16bit indices then I could no longer use more then 65535 vertices right?

It means that each single batch can consume up to 64*1024 vertices since there's no way to address more. I suggest to stay away from index 0xFFFF however: on some hardware I tested, it had odd performance behavior (likely because interactive with primitive-restart functionality). Those implementations are old, and the issue is probably gone right now. You can still put a million indices in each VB and use batch offsets to select the correct sub-region.




How far can I stretch vertex buffer merging for performance gains?

Switching vertex buffer is not even nearly half expensive as it used to be. Doing a new buffer for each resource is often doable. Personally, I merge my buffers according to "resource load rounds" and vertex format so I don't have to write complex code and the inspected buffer looks good in debugger.

Are there any rules of thumb of how many vertices that should be in the same buffer?
Dynamic buffers should be below 4MiB for best performance (according to AMD, referring to GCN drivers). Static buffers can likely be a gazillion vertices with no problem.

#5126645 Making a new game?

Posted by Krohm on 26 January 2014 - 11:57 PM

I strongly suggest to produce a document explaining your game first. If the game is "extremely complex" do not even start. The game must be well understood and "compact" at least in your mind. I suggest to start producing a game design document.

#5126641 Physics and huge game worlds

Posted by Krohm on 26 January 2014 - 11:28 PM

Performance is bad because the algorithm cannot make any assumption about the collision data. This is not the case for other collision shapes, which also have a fully parametric representation.

I am currently using proxy hulls for everything (hand made). This is standard about now albeit we could discuss on the amount of automation.

#5125789 Physics and huge game worlds

Posted by Krohm on 22 January 2014 - 11:12 PM

As an aside, Havok deals with that kind of problem with their concept of Islands.  I'm guessing Bullet doesn't have a similar built in structure? 

It does, but sadly, it doesn't expose them at library level.


Also btBvhTriangleMeshShape takes some time to build the hierarchy, so  serialize or not to serialize??
Do not serialize, do not use. Performance is terrible to start with and I cannot understand why so many people go for it.

#5124087 I'm having doubt about my map loading method and its performance.

Posted by Krohm on 16 January 2014 - 02:17 AM

For starters, switch from text to binary It will be much faster, since you don't have to go through hundreds of characters, you just read a piece of data and there you are.
I have to point considering binary files to just be "the data, right there" is likely to be a good way to be in trouble. Soon. TheUnnamable points out a first example, dealing with endiannes. While a true problem, its relevance is overstated in my opinion.

What the binary file does is to guarantee each chunk of data has a known footprint, easily inferred from state. It does not guarantee the value itself is coherent with previous state. Input sanification is still required - what you gain is a much, much more compact parser, which can be ideally 5 LOC for a pure data blob.


With small modifications by me

Binary formats are not necessarily faster and they have a bazillion other drawbacks.

  1. Disk seek time will completely swamp any CPU processing time.
  2. Text files can in many cases compress better than binary equivalents and so (using a ZIP asset file or zlib to compress your source assets)...
  3. you can actually get faster loading time with text than binary.
  4. To be sure, measure, measure, measure.

I would like to know what those drawbacks are supposed to be as...

  1. not a binary file problem. Seek is always a problem, no matter if binary or text. But with text you have the additional complexity of parsing, especially if the format is designed to be human-usable;
  2. to a smaller file? Or in percentage? Information is information. Both files store the same amount of information, with data preferring one representation or the other depending on values themselves;
  3. sure you "can" in some circumstances. I don't recall it happening to me however;
  4. please stop with that "to be sure..." thing. Time is not free. Either you think something is worth or not.

Now, back to the original problem.

Text files are suitable for small amounts of data, such as level configuration in a tower defense game, a set of tile indices for parts of levels in a tile-based game.

If you can guarantee the syntax is simple, loading text has the inconvenience of variable-length but loading complexity will still stay low. If you care about performance, you might cheat by terminating each buffer with a null temporarily and removing that after processing the token. Or, more nicely, you might switch to a pointer-length approach where string termination is not assumed. This way, memory allocations are lower and performance goes up.

If you need even more performance, it's probably time to drop text. Filters to binary can cook the data for you in awesome ways.

Also consider json.

#5121713 How efficient are current GPU schedulers?

Posted by Krohm on 06 January 2014 - 02:42 PM

I am very well aware of the latency-hiding strategies involving block read/write.

There's no heavy math in the memory-heavy section. I don't understand what you're saying

while you're doing extra work ... the kernel actually runs faster while doing the heavy math at peak rates

I don't understand what kind of extra work are you referring to: changing layout or decompressing/transforming data appears something I'd have to do, not the HW.

if you wonder about some optimization you come up with, it's indeed best if you just try and profile it.

Are you reading my posts? We don't have easy access to neither GCN nor Kepler devices. I'm sorry to write this but so far I haven't read anything I didn't know already and I start being aware I am not able to express my thoughts.

#5121585 How efficient are current GPU schedulers?

Posted by Krohm on 06 January 2014 - 03:08 AM

While I had a quick look on GPU releases in the last few years, since I've focused on Development (as opposed to Research), I've haven't had the time to deeply inspect GPU performance patterns.

On this forum I see a lot of people dealing with graphics is still optimizing a lot in terms of data packing and such. It seems very little has changed so far, yet on this forum we care about a widespread installed base.


In an attempt to bring my knowledge up-to-date, I've joined a friend of mine in learning CL, and we're studying various publicly available kernels.

In particular, there's one having the following "shape":


The kernel is extremely linear up to a certain point, where it starts using a lot of temporary registers. After a while, those massive amount of values are only read and then become irrelevant.


What I expect to happen is that the various kernel instances will

  1. be instanced in number to fit execution clusters, according to the amount of memory consumed.
    What happens to other ALUs in the same cluster?
  2. Happily churn along until memory starts to be used. At this point, they will starve one after the other due to the low arithmetic intensity.
  3. The scheduler will therefore swap the "threads" massively every time they starve by bandwidth.
  4. When a "thread" is nearby the ending, compact phase, the swapping will possibly end.

It is unclear to me if the compiler/scheduler is currently smart enough to figure out the kernel is in fact made of three phases with different performance behavior.


However, back when CL was not even in the works and GPGPU was the way to do this, the goal was to make "threads" somehow regular. The whole point was that scheduling was very weak and the ALUs should have been working conceptually "in locksteps". This spurred discussions about the "pixel batch size" back in the day.


Now, I am wondering if simplifying the scheduling could improve the performance. On modern architectures such as GCN (or Kepler).

The real bet I'm doing with him is that the slowdown introduced by increased communication (which is highly coherent) will be smaller than the benefit given by improved execution flow.


Unfortunately, we don't have easy access to neither GCN nor Kepler systems, so all this is pure speculation. Do you think it still makes sense to think in those terms?


Edit: punctuation.