Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Online Last Active Today, 12:40 AM

#5152236 Fastest way to get all distinct colors in a texture

Posted by Krohm on 08 May 2014 - 01:11 AM

That's an interesting question. What do you have at your disposal? Perhaps compute shaders and atomics could do - they are so fast they can be used for OIT transparency. Building the acceleration structure seems to be perhaps the most important thing.

You could have something like a matrix transpose on Local Data Share... if the API using it supports it (I'm not sure DirectCompute does).

Assuming you use DirectCompute or some Profile 5 target, you could use a write barrier to gather information from the various work-items in a workgroup, reduce the various lists and then spill them out to a global buffer.

This global buffer would still not be unique but it would likely be much smaller.

#5150699 map design

Posted by Krohm on 01 May 2014 - 12:15 AM

The replies here are so generic they make me - me - confused.

So, let's start easy.


Back when computers had KiBs of RAM yes, levels were often encoded into the program. This practice is rarely justified nowadays as the need to squeeze out those savings are no more there but there might be some reasons to go.

Example: my tower defense game has all the assets and code in a single file. Javascript makes it easy and it saves me the hassle of pulling them from a server, as well as optimizing the bandwidth.

FPS games usually had some kind of editor. Every game had basically at least one major game-specific editor. Doom had them. Quake had them. Interestingly, some people have been able to produce Doom or even Quake maps by hand, doing the computations manually but they would still have to go through a data load phase (not in code anymore).

Unreal is perhaps the only major exception so far as it was always dominated by its own editor UnrealED.


Generally, those editors allow to work on simplified meshes (cubes, wedges, pyramids) to be manipulated through CSG operations. The resulting meshes are made solid by default.

This approach is inadequate for modern games (say in the last 10 years), it can still get a lot of work done, but it's no more sufficient.

Nowadays the level might be still "ironed out" in the editors but the contribution from other DCC tools is bigger and bigger. Those external program get integrated in workflow through filters or importers which are usually fairly fine in control. Keep in mind that using a DCC tool (such as Blender) for level creation is likely to be less time-efficient than using the appropriate editor but it's still way better to crack your head writing one.

#5149104 Weapon system (opinions welcome)

Posted by Krohm on 24 April 2014 - 12:05 AM

I think some particle effects might fit as well.

Ice might drop a subtle fog effect.

Fire, as usual, slightly deforms its surroundings.

Defense looks bulky.

Others... not so easy.

#5147559 Fast GUID generator

Posted by Krohm on 17 April 2014 - 12:01 AM

I always considered GUIDs to be pretty overkill for runtime purposes in a gaming environments.

I find myself much more comfortable with [pool, slot] pairs which give up some control and require some more attention but are much, much easier to debug in my opinion, as well as intrinsically better defined.

In particular, generating GUIDs for objects in a hierarchy as OP wants to do is overkill by several orders of magnitude. I have a similar need and I just identify objects by their sequential creation index. I cannot see any problem in the foreseeable future so I would encourage in elaborating the specific needs.

#5146818 [Design Question] How to access other classes

Posted by Krohm on 14 April 2014 - 12:36 AM

I read somewhere that each object should update itself. So i made a Update()-function for every class.
Maybe this is what is written, but I doubt it is what it's intended.

Personally, I'm starting to hate the word components and component based system, as many discussions about them end up being very high level and seldom useful. Many of their subtle problems are also rarely even taken in consideration, let alone discussed.


Anyway, your objects should not update themselves. That is, they should not have an Update call. Ideally.

Seconding Guns, and hopefully elaborating on the approach.


The Update call was basically an hack introduced to allow finer degree of flexibility, often going along with scripting. It suffers from being overly generic and if you look at systems using them, you'll notice there has been a growth of Update calls. Before rendering. Before physics. After everything.

Consider using this (anti?)pattern as a last resource.


Now, I see you're currently doing the physics yourself so you can manipulate speed and velocity. This is model data. There are also data related to presentation (m_Sound, m_AnimationManager) and stuff regarding gameplay-level model (powerups?). So your Ball is really a fusion of at least three different structures.

What it lacks is separation of concerns.

Let's pass the fact you're doing physics yourself (which is possibly appropriate for this kind of game). What you really want to have is a higher-level system keeping a list of collidable objects and dispatching calls appropriately, something like:

  1. Collision system build a collision list
  2. Gameplay system searches for the ball in the collision lists
  3. For each match, searches for the kind of hit object
    1. Is it an UFO? Call ufo->destroy, player->addPoints, signal ball bounce/collision/nothing
    2. Is it a powerup? Call powerup->remove, player->applyPowerup, ball->applyPowerup
    3. Otherwise, ball->collision.

In this way your Ball becomes a much smaller structure. It has a much more limited goal and knowledge. By delegating part of the low-level behavior to other components you get to avoid big god objects. For example, it does not need to have access to ufos or powerups anymore but only to react to them when informed.

Proponents of the component-entity model decided that this approach had to be glorified by giving it a sticker. 

#5142513 mouse time resolution, ?

Posted by Krohm on 27 March 2014 - 03:05 AM

Mousemove gets dispatched at least once every time a pointer position change "in pixels" is detected. Use a high-resolution timer to obtain temporal information. Some "legacy" timers might also do it in theory but in practice their granularity is insufficient.

Raw input is dispatched every time the controller reports a state change. Because it is unfiltered, this will be much, much higher frequency.

As far as I've understood, the device produces a constant stream of data (to its integrated controller) at a steady rate, but I doubt the data to be steadily streamed to host. This is very likely implementation-dependent and you're not really concerned with this anyway.

#5142502 raw input troubles

Posted by Krohm on 27 March 2014 - 01:52 AM

It seem to working though I am not sure how reliable (unfaliable) it is
(and if it will be working on all systems machines etc, this is a bit worry)
I've been using raw input for a while. I started using it... I think a year before D3D10 was announced. Reliability depends on the specific input device, some are just not so good but mouse support is solid.



how can i be sure which mouse detected by rawinput is the secondary?

RawInput will detect all devices, whatever you use them or not is your business. Enumerate them and use GetRawInputDeviceInfo, it gives you a blob of device-specific data, but it has a well known format for mice and it has a device index dwId.

It's a while since I've used that. If memory serves, the first mouse is a virtual mouse obtained by coalescing input from all mice, then the real mouse device follows. But I'd suggest to check that more accurately before going on.



the second mouse moves also my arrow -cursor, if I disable it by RIDEV_NOLEGACY then both are not moving cursor (it bacame hourglass) and it is wrong too

Unfortunately as far as I recall, windows pointer ballistics are always computed using all the mice connected. I'm following the thread in case someone posts a solution.

#5142498 Object initialization design issue

Posted by Krohm on 27 March 2014 - 01:38 AM

I'd be hard pressed to say exactly why I find this easier to deal with and maintain if I'm honest but over the course of an entire system, it feels cleaner to me.
I don't know Aardvajk, I'm not quite on it. The main problem I have here is that you cannot take a Texture object and poll which device created it (maybe we can pull out the creation device from the OS handle, but in isolation, that's still not enough). This information will have to be tracked with surrounding code. It's not like I'm against this idea in itself but I always considered statements like "parameter X must be creator" a last resort. If I am allowed to specify a different object "for every method", then I'd intuitively feel entitled in calling load on a device and bind on multiple.

#5142496 Scripting! What to script/what to not script?

Posted by Krohm on 27 March 2014 - 01:30 AM

Due to my code being used across a few different projects, I ended up rewriting a lot of it. I eventually insulated the stable code and ended up with some quite extensive scripting (due to historical reasons, the script is proprietary).

For a lot of games, you could get away scripting nothing. Yes, I wrote script nothing. Fact is you should first go through data-oriented design first and then add scripting to manage all those cases where data alone does not cut it. To do this effectively, keep in mind what you want to accomplish.


Say for example we want to make a breakout clone. Do we want to use scripting? For first iteration sure not. We build levels using pure data.

Do we need scripting in a breakout clone? Maybe to design a new powerup? Or for a new enemy?

New enemies from breakout does not seem to be so complex to require scripting to me. For powerups, it might be useful to script them since they're often very varied in effects but due to their limited number maybe we might still want to make them code.


The very important thing is to not think in a vacuum. Always think in your context first and in the near-to-mid term future then.

#5142492 what is Projective Aliasing

Posted by Krohm on 27 March 2014 - 01:18 AM

Consider a projector pointing perpendicular to a plane. Its projected area will be a square, or perhaps a rectangle. Depending on the distance between the projector and the plane (and the projector matrices) the resulting image to project will have to be minified or magnified.

Ideally, we want to keep the pixel mapping 1:1.

Now, move the projector away from the plane (keeping the camera in place)

What happens is that the projected texture (the problem is not shadow-map-specific) will have to cover increasingly more pixels of your viewport / plane. When the texture has to me magnified, you have projective aliasing because the distance between adjacent pixels "on the screen" once mapped to the projected texture are more distant than 1 texel.

In other terms, 1 projected texel ends up bigger than 1 pixel (or the defined threshold).


In general, perspective aliasing is discussed when considering oblique frustum but I don't think it's necessary.

#5141620 There got to be a better way to manage animations.

Posted by Krohm on 24 March 2014 - 12:05 AM

Your whole problem arises because you're trying to enumerate the animations. This is a fundamentally wrong way to a approach the problem. Animations states are strings, and they are asset-specific. You don't map them to uints, you can do it, but it really isn't a sensible way of authoring assets.

Animation names are strings. So you can have very specific animations such as PlayModelAnimation("cutscene4_bridgeCollapsed_teammateAlive") where your avatar and the sidekick note how they were doing great so far, but also have to cut another few seconds next time.

All those specific needs will give you serious issues.

But... let's suppose you have a filter cooking those strings to uints. Then your solution is to have that same filter build you an std::map<const char*, uint>.

I'm having myself some problems however in understanding how this could work for you since your IsState function seems to be smarter than I'd suggest to - so something is falling... or jumping... in combat or not. So basically IsState does non-trivial checking of variables which are of your own design.

In my design, I don't set animation as part of the loop. I start them event-based so no state polling is required and I found this to be a rather good solution so far.

#5139658 Collision detection for two cubes (3D)

Posted by Krohm on 17 March 2014 - 02:17 AM

In the past I used the separating axis theorem to partition space in 9 pieces.

By ranking all the points of the cube you could easily tell if a collision NOT happened. Extracting the collision data was a bit more involved but doable as a narrowphase.

I am concerned however you want to "a rigid-body physics engine, it's supposed to be easily compatible with Ogre and fairly straightforward to use, for beginning game programmers". Please. Please. Please, do not write yet another physics middleware.  For your own amusement I could let you go but for serious use, your embarking on a seriously difficult project. If you plan to go ahead, I suggest to look at Bullet implementation.

#5139653 HTML5: Broken lines...

Posted by Krohm on 17 March 2014 - 01:40 AM

You should be calling moveto only for the first point, all other lines are to be connected. You're currently terminating each path and starting a new subpath each loop.

You can - must - do this in a single loop, if you have constant line thickness then move out stroke for better perf (but I guess that's not really doable).

#5139651 How to efficiently divide files up?

Posted by Krohm on 17 March 2014 - 01:34 AM

The maximum number of columns in Open Office Calc is 1024... I need more than 3000 for what I'm doing... or I need to come up with another way for what I'm doing to work
Yes, absolutely. You are producing at least 3KiB of data for each row/monster/item, not a good workflow at all. This is going to be an hell to manage and tune.

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