Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Sep 24 2016 03:22 AM

#5103040 Practical benefits of the restrict keyword

Posted by on 21 October 2013 - 01:00 AM

In my engine I've adopted a functional style at a low level and I could apply this keyword to most, perhaps all, my functions. My question is: is it really worth it ?
No. Completely unnecessary for anything that is not performance critical. How is performance distribution in your program? For me it's about 85/15 and about 10% out of my control. Do not consider optimizations before you have profile data. Adding this keyword to "most, perhaps all" of your functions only makes them harder to read and gives you nothing back.

#5102048 How should i learn to make games in c++

Posted by on 17 October 2013 - 12:58 AM

I'm afraid I have to point you to ApochPiQ's Become a Good Programmer in Six Really Hard Steps.

Long story short: you crack your head open till you can figure out how to make those classes comminicate. There's no reading, nor learning. Adding more APIs might make it worse instead of better. Designing interfaces and protocols (sequence of function calls) comes from experience and you have to build that.

What you need to do is to really focus less on implementing and more in designing, or engineering if you want.

Also try to keep a decent documentation for your own code using doxygen: if you find that you cannot document something clearly, that means the concept regarding that class is unclear even to you.

And this is why you cannot connect the classes together: they don't have a "shape" you can perceive.


Also, if you tried to make a game (a single game) I'm afraid that's just normal. Just keep doing that.

#5101204 goto considered harmful within global macros

Posted by on 14 October 2013 - 12:53 AM

I feel something in my bowels. I'm going AFK a few minutes.

#5099285 Pro and Cons to building a game engine

Posted by on 07 October 2013 - 01:36 AM

My question is: if building an engine takes too long, eventually when you need to use it, you can start popping out games using that engine when it is done because of the reusable code in the engine, no?
Maybe something is getting lost in translation for me, but this statement makes no sense to me. It looks like:
bool EnoughEffortSpent() { return false; }

if(EnoughEffortSpent()) {
  while(true) PopGame();

As a side note. My "engine" emerged from iterations of various games which, for one reason or the other, never came to completion. It is a surprisingly stable and flexible codebase but if I could go back and change the past, I'd still prefer to just finish the games instead.

#5099284 Implementing Audio into my game engine, what should I use?

Posted by on 07 October 2013 - 01:31 AM

A simple API like XAudio2 or DirectSound is ok if all the game needs to do is play wave files in response to game events.  But that is considered extremely basic these days and note really sufficient for all but the simplest of titles 
I considered XAudio2 fairly flexible in design (albeit not necessarily efficient in terms of price/benefit). Would you elaborate please?

#5098418 Maps or level editors

Posted by on 03 October 2013 - 12:20 AM

how would they add multiple levels or maps?
They don't really add "the maps" to the game. Rather, they give the game the ability to load a map at time. They then have somewhere a small script telling which level is first, and each level has annotations of other levels to follow. So in the C++ code itself probably does not even know about the levels. The scripts might know about the first or for some simple games, they could be whole level lists.

Would they have to input everything manually?
In the C++ code you mean?

This is referred as hardcoding and it's well known to be a source of problems. It is only adequate for extremely small datasets. achild above suggests "pacman" to be simple enough to go with manual input and I sort of agree for a single level.

Would they have to build their own level/map editor? Could they take a preexisting level/map editor and adapt their game to recognize what another level editor puts out?

The opinions here are more varied. There has been a time in the past when having your editor was necessary. Right now it's more like an option. People pointing out simple games having editors on their own don't get the point. Those talking about UnrealEd forget Unreal Tech is a large share of the whole game development industry.

Personally I think dedicated editors are done - there are a lot of advantages in allowing an artist to use the editor of his choice and just import the work.

#5097750 Rendering only what the camera see

Posted by on 30 September 2013 - 12:50 AM

To elaborate on Tom KQT, here's another example.

Say you have a particle system generating 1000 particles. Do you cull each particle? Not at all! You cull the particle system itself.

A particle system with 1M particles? We might try to split it in spatial chunks.

Granularity is key. Personally I've found that even on rock bottom hardware vertex transform is so fast that I can draw 2x more vertices at 10% more cost (at worse). So I made all my batches (and thus their culling box) twice as big. The performance was about the same. I then made my batches even bigger and found out there was an improvement in performance. Right now the batches are about 10x the original size and they still give better perf than the original. Why? Probably because D3D9 batch dispatching is really that slow.

#5097743 hardware instancing?

Posted by on 30 September 2013 - 12:29 AM

I'd suggest to just merge all cubes of the same type in the same batch. Even with extreme interaction rates (say 5 per second) you should have no problem in updating the buffers correctly if you did your octree right.

What mhagain states is completely correct, but there's no need to do that on the complete dataset each frame - just draw all the "surface", potentially visible cubes.

#5097741 Well Structured Code

Posted by on 30 September 2013 - 12:26 AM

As I'm learning JavaScript myself, I cannot avoid noting how JS documentation is really dependent on data types being there.

This separation between data types as something that just exists in our mind to understand against data types as something understood by the language is JS main problem in my opinion. Code readability, as well documentation is seriously hampered.

So sadly, in the long run, I consider static, traditional languages to be far superior.

#5097740 Help with browser game

Posted by on 30 September 2013 - 12:21 AM

I googled it up and found various images, I'm not sure what it is really as I'm not going to sign up to try it but I'd say it's a browser-based game like ogame or something.

For a start, learn HTML, CSS, JavaScript. See you in a few months.

You will very likely need to learn PHP for server side programming as well.

#5097046 How to draw the heightmap properly?

Posted by on 26 September 2013 - 12:16 PM

My suggestion is to not worry about it. Implement pure geomipmapping (which I consider easier than geoclipmaps) with 1 drawcall per batch. Then eventually iterate. Doing superchunks is surely not trivial.

It doesn't need to split buffer objects on the fly. It's just a matter of playing with index values smartly and modifying drawcall data.

But again, I suggest to start simple and scratch your head after you are sure you got a problem with draw call count. I am serious about that.

#5096967 How to draw the heightmap properly?

Posted by on 26 September 2013 - 07:28 AM

Thanks! So first I have chunks like 1x1, 2x2, 4x4,.... every chunk containing 4 smaller ones. and then in every frame I decide which chunks should be drawn. But then if every chunk means a separate drawcall then thats a lot. Im not sure I understood it right though.
It seems I somehow didn't convey the message.

You must use a "hierarchical" approach. The whole point is: as chunks move away from the observer, they require less detail --> less triangles. Also, nearby chunks will likely have similar (if not equal) LOD level.

So let's say we have a 64x64 vertices chunk (4k, it's still a bit conservative). Next LOD level will have 32x32 vertices. You still resolve their LOD levels separately{1} and find out your terrain is like:


| 2 | 1 | 1 | 1 |


| 1 | 2 | 1 | 1 |


| 2 | 1 | 0 | 0 |


| 1 | 1 | 0 | 0 |


See the four chunks at top right. In this case, instead of drawing four LOD1 chunk you might draw a single LOD1 "super chunk".

Similarly, you might be able to draw the two LOD1 chunks at bottom left by splitting in half a LOD1 superchunk (by just limiting draw call primitive count).

So what I'm trying to show is that you specifically don't need to do one call per chunk.


This is of course if you're using geomipmapping. Clipmapping doesn't work that way but I personally don't like it much for small terrains.

And how do I handle the "lines" between chunks of different sizes? .....if one has 2x the resolution than the other.
This is a well known problem. You must resolve possible combinations in advance and fill the gaps. Those "filling" triangles are often referred as "skirts".

Clipmapped terrains have an advantage here as the skirts are basically static.

There's another method having the term "contiguous" that does not need explicit skirting. A beginner told me that it perceived it as a definite advantage. It is basically a vertex-interpolated geomipmapping. By a signal analisys standpoint it is a bit too liberal in my opinion.


{1}: or not, if you want to be super efficient, but I don't suggest to do so.

#5096076 Would this be a good idea? (Episodic release)

Posted by on 23 September 2013 - 01:10 AM

This is going to sound harsh.


I'd say it's too expensive. Take a look at Desura, Humble Bundle or Indie Royale, a lot of games are shipping below 5USD and I got my games for 1-2 USD, including 5 episodes of a Sam and Max franchise.

that decent pc game has hundreds of devs and thousands of dollars of budget.I'm the only programmer with little to no budget
Irrelevant by consumer point of view.

buy one hour at 7$,the next part will be longer at the same price

#5096070 Game Logic: Creating a Scripting Language

Posted by on 23 September 2013 - 12:32 AM

I also have my own scripting language.

My raccomandation is: give up.

Differently from others, I had extra requirements which made pre-existing scripting languages difficult to use (if possible at all). It's currently core for my game and yes, I trust it well enough.

It appears to me however this thread is considering the goal with a technical mindset only. Besides the technical, I don't see discussion about the why OP shall embark on this project. It seems OP is considering the language in a vacuum and that's not what's going to give good results.

#5095104 This beauty...

Posted by on 19 September 2013 - 12:44 AM

Amateur. I've once dealt with code written... I think in Korea. The variables were numbered up to... like 74, in a convenient 800 LOC function.