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 Yesterday, 12:46 PM

#5196191 C++: Easiest way to implement an in-game Time/Date system?...

Posted by Krohm on 04 December 2014 - 02:07 AM

...  maybe a real-life second is an in-game minute or some such, and time acceleration allows it to progress faster...
Is it just me or posts here are assuming the in-game time  will increase at a more or less constant rate?


If you plan to run the simulation for a lot of time with "time scale" changes, I suggest against using a single reference point in time. In the past I've had some nasty things with accumulation errors and I cannot be completely sure the new frameworks solved them. Keep around a list of "time speed" changes and reset your time reference to last time multiplier change.

#5190857 Tower Defense game - How to manage towers ?

Posted by Krohm on 03 November 2014 - 01:02 AM

Two replies on implementation but ... hey, looks like nothing on the game design yet (I see game design as tag)!


Be warned: those numbers are very hard to tune. 


In a tower defense game "with a twist" I was working on about 10 months ago I had a similar design: there were 4(+1) towers, each with three "incremental" upgrades and a final "specialization" upgrade.


Everything you do must have a specific role. While some overlap between roles might be beneficial, it should be an exception.


Inherited classes are to be used only for logic. Whatever can be made by simple data should be simple data. Cost, range, ROF and dmg does not justify use of derived classes. Logic by contrast does: consider the difference between a "point damage" tower and a "area damage" tower.


In the latter case you should prefer enemy clusters to easy choices. In the former, you might want to optimize to... finish off enemies? Most games seem to just distribute the damage by selecting the nearest.


Try to make an "horizontal" prototype before getting to the upgrades. I found out the amount of playtesting required to tune the exact values is fairly involved.


As a side note, I'm thinking about:

  • Cutting the number of levels to 1/3
  • Removing the whole upgrading system completely
  • Simplifying the buffing system

In practice, I want to make a simpler iteration first. It is a viable product anyway.

#5188092 Loading multiple 3D models in the VBO

Posted by Krohm on 20 October 2014 - 01:42 AM

How is loading multiple 3D models in the VBO?
I'm afraid your English is prone to misunderstanding. I assume you're asking about usefulness and performance.


Putting multiple models in the same VBO is debatably useful. If the models feature a different vertex layout, then it will become a debugging hell as debug tools typically consider each VBO as containing a single type of vertices.


Years ago, I used to slap everything in a single VBO. That usage originated from an old OpenGL extension ("NV_VAR") which were fairly slow to switch.

Modern VBOs are much, much faster. When I switched from "all in the same VBO" to the new approach, I observed no performance difference.


As such, optimize your life and time to finish: do whatever comes easier to you, explore the problem, learn and... maybe you won't need to fix anything and there's no punishment for coming back and iterate your code to meet new requirements.

#5187353 scan a string character one by one & hexadecimal code

Posted by Krohm on 16 October 2014 - 04:51 AM

I know nothing specific about Arabic BUT

I know it is a context-dependent "complex script".


Thereby, it goes through a whole thing called Unicode which considers clusters of characters (I think the Unicode standard calls them "runs"). Unfortunately this means splitting the clusters into pieces might not work as expected. Besides this (which is hopefully an ELI5 version of what Bregma wrote) I'm sorry I cannot help because I'd love to learn about this.

#5187316 Load Meshes

Posted by Krohm on 16 October 2014 - 01:10 AM

If you have doubts about an OBJ loader then don't use it.


I second suggestions about using ASSIMP. Why?

Because work put in ASSIMP interfacing, even for a demo, is work invested in a library you're going to use. By contrast, you will drop OBJ support a day. It gets quite some mileage but it's just insufficient for modern uses and BTW, the real OBJ format includes nontrivial stuff such as NURBS usually not supported by easygoing file loaders.

#5180386 BSP portal visibility

Posted by Krohm on 15 September 2014 - 12:11 AM

How does a BSP compiler decide which leafs make up a cluster or 'room' and which windings make a portal?
Nontrivial question.

ID software took three product iterations to get this right and that was still not enough.


I'd link to a message I wrote years ago but it seems I'm getting a virus positive (???).


I honestly don't know why you guys keep pulling this BSP thing. The simple fact we need to do splits was enough for me to look elsewhere and it's not like there are no alternatives. It's a boatload of work simply put. If you want to just have a lot of work, write your own Z-only rasterizer, it looks quite more promising!

#5178884 how to design a virtual world

Posted by Krohm on 08 September 2014 - 10:53 AM

Let's see if I got all the questions.

  1. How to load 3d world from file?
  2. How does that relate to underling containers of entities?
  3. What are standard map file formats ...
  4. ... what info do they include?
  5. Do i split the world in x,y,z cell grid, maybe use some other approach?
  6. How are the containers important in relation to client side/render engine?
  7. is it possible to export (lets say from some terrain generator program) a heighmap, textures and navigation meshes, collision detection rules, etc?
  8. How do I manage {a terrain scene}? As in, how do I get the size of the landscape (bounds of those 3 lists), so I can later place objects (trees, etc) to specific locations.
  9. Can I use any existing solution for this?



  1. First you figure out at high level what your game/app needs to do. Then you figure out what information you need to make that happen. Then you take this abstract information and sketch out a document specification where you describe how info x gets mapped to a certain set of bits and you get a file format out there. At that point you probably know already how to load it. I suggest writing your own format for engine use and go with standard formats for DCC tools.
  2. In general, there will be a special structure being "the world". The world might be solid or not or include "solidity" info. If the world is nonsolid then it's likely there will be another special entity being "the physical world". The rest of the structures might be for example put a light here, there and there. They usually have a very bland correlation with the world, both graphical and physical, at this stage of your app. I strongly suggest using a physics library.
  3. No standard.
  4. ID based engines basically include (3). Unreal based engines are fairly more advanced but if you cut a lot of corners they're basically the same thing and you can bet at this 10,000ft of abstraction everything looks pretty much the same.
  5. Splitting in fixed sized cells is relatively inflexible but some games go with it and they work fine. For a first iteration, I suggest to just reduce the batch count as much as you can and optimize your life by minimizing your efforts first. Then you figure out what you need with the experience you got from rigging up the prototype.
  6. What are you asking here?
  7. Yes... for some program... for some import filter... for some data. 
  8. Size of terrain is a 3D vector. Terrain has an origin which is a 3D vector. It might also have a orientation which is either a quaternion or a 3x3 matrix. Placing terrains is often not very different from placing entities, and entities are usually (but not always!) very loose on definition.
  9. Yes, a pre-made engine. You will also get a ready to go toolchain. Have a look at Unity or UDK.

#5170827 Collision Detection Issue

Posted by Krohm on 01 August 2014 - 02:46 AM

Since I have to explain it to you, I'll explain a more complex (but more powerful) way.

We want to see if the ball hits the odd shaped poly.



Then what we want is to take those two sprites and run a threshold of some kind.

Example: if alpha is >= 25 consider solid.

We mark "solid" pixels "white" to obtain two 1-bit per pixel masks.

ball.png poly.png


Now, we count the amount of stuff that could be colliding (this might be not trivial) and decide

- black pixels are "empty" and do not collide

- white pixels do.

But all masks are "white" so we decide to assign a bit of color to each sprite. So 32 bit color --> 32 collidable sprites.

Say we decide the ball gets red=128 while the poly gets blue=128.


Now the tricky stuff. You need to figure out where the ball sprite is located relatively to the poly sprite.

Then you "draw" them on top of each other by adding the values of the "colored masks" pixel-by-pixel.

What you get is (of course I moved the ball here, otherwise it would be very uninteresting):



So this tells you "sprite red hits sprite blue".


My previous approach with XOR is simplier as you don't need to choose colors (you can just XOR the original masks) but it doesn't tell you what collides with what. It's not even so reliable. You decide what's going to cut it for you.

#5170515 Profiling results, GPU or CPU bound?

Posted by Krohm on 30 July 2014 - 11:36 PM

This is because D3D drivers are generally lazy and only fully initialize things on first use.

As a side note: other drivers do this as well. Current AMD OpenCL sure does.

#5168095 In need of some architecture help

Posted by Krohm on 21 July 2014 - 02:28 AM

I might have missed something in there, but it seems to only really be useful on window creation, but doesn't really provide anything useful if I want to resize or move the window mid-session does it?
What it gives you is the ability to pass there a pointer to an object you can use to interface with your "real" object so even though the WndProc is static, it can forward calls to non-static functions through a object pointer.

#5168075 C++ avoiding pointers

Posted by Krohm on 20 July 2014 - 11:30 PM

The real proper use of these are all based on _lifetimes_. Who is responsible for creating the object? Who is responsible for destroying? Are users of the object just borrowing it for a while or do they need to take over responsibility of the lifetime? If they're just borrowing the object, how long do they need to borrow it for?
Quoted for emphasis.

I honestly find given proper design thinking about ownerships and lifetimes beats smart pointers at large.

#5168073 In need of some architecture help

Posted by Krohm on 20 July 2014 - 11:21 PM

On creation, the window gets its messages in a well defined order. In particular, CreateWindowExallows you to fetch an LPARAM to the WM_CREATE message. Pack there a pointer to your struct. You can also do something similar on the window class but I'd consider it a bit ugly.

#5168072 The next step?

Posted by Krohm on 20 July 2014 - 11:16 PM

I'm afraid you have to begin considering engineering your code. You have probably just wrote your game code so far. Now the next step is to make sure the code can scale. Engineering it to be "better fitting" your head is a thing. The other way is to reduce the code size.

It's not this XOR that. You have to acquire both tools. 


How are you with data-driven systems? Is that term new to you?


Writing your code to be data-driven means writing your code to be flexible, ultimately reducing the amount of code. It takes some more effort but scales up better. That's why you see so many people writing about "engines" in those forums. "Engines" are data-driven frameworks in the end.


Now, without going to that degree, what you need to find is a way so you code less and artwork more. Is that a verb? :P

#5168069 Funniest line of code ever ?

Posted by Krohm on 20 July 2014 - 11:05 PM

That seems desirable to me.
Not really. I have a scripting language where the only implicit casts allowed are: derived->base or pointer-compare-to-null. Notably, integers don't auto convert to bools. It stings me regularly every time I compile something with an if(integer) inside. It's not just a matter of being used to C/C++ autocasting feature. It's just more compact notation.

#5165943 Scaling on available memory

Posted by Krohm on 09 July 2014 - 11:13 PM

It is my understanding they do. This is the case especially for terrain related things such as in Frostbite. Perhaps ID megatexturing, in the case somebody still cares about them. Even games which are not streaming can still be more conservative before trashing old data.


There's of course the option of higher res assets.


My suggestion is to not mind those issues. It's a boatload of work and in the end, not required for market.