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 Jul 31 2015 04:24 AM

#5204463 Did I do this vertical parallax scrolling correctly?

Posted by Krohm on 15 January 2015 - 07:04 AM

The second image makes me think the nearest layer of rocks must be really close to the camera. If that's the idea, then it's success!

#5201955 a better fix your timestep?

Posted by Krohm on 05 January 2015 - 09:04 AM

I keep asking myself: is this really necessary?

A physics library will fix its time step by itself. Another problem solved.

#5199519 Tile Map Editor - Individual Tile editing

Posted by Krohm on 22 December 2014 - 08:21 AM

The tiles look unique in this screen, yes.

Try to compare across various screens. I think the brown/white bricklike decoration is perhaps the easiest repetition to spot.


In a tile-based game I prototyped about 1 year ago, I had "tile decorations" on top of tiles. They were basically mini-tiles themselves. Each cell had a tile and a list of decorations to be applied.

#5198933 Serializing individual entities

Posted by Krohm on 18 December 2014 - 07:42 AM

Yes, you've talked about prefabs previously. What I really mean "between the lines" is that just doing new SpecialEntity() in some way might likely end up being just as fast as the whole de-serialization thing. Of course in this case we're no more talking about a generic de-serialization but a more specific kind of spawning. You can see this has plenty of advantages for your mental sanity.

#5198289 When you realize how dumb a bug is...

Posted by Krohm on 15 December 2014 - 05:20 AM

Reference data does not match data from new code.

Checked again, again, again and again.

Did I forgot an offset?


Reference data comes from a different project. It's basically a for(...) <do stuff> and I'm interested in a certain loop iteration.

In a certain loop iteration. Not in two different loops iterations. Changed iteration to debug to same value. Realized there was no problem to fix. Called it an intense day.

#5198280 Serializing individual entities

Posted by Krohm on 15 December 2014 - 04:50 AM

That's an interesting problem I faced some time ago.


Mind that system was fairly involved. It was built around flexibility so pretty much everything could have arbitrary scripts attached. My plan was to re-use the garbage collector machinery to isolate and entity data set and serialize it (I know I can serialize full heaps and restore correctly).


However, when it comes to partial serializations, there were so many other difficulties I couldn't solve such as handling shared data. In general I wasn't sure of validity of this operation so the thing never made it.


Can you describe your use-case in gameplay terms and how it relates to the system envisioned here? Are there any special properties you can exploit to cut corners?

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