Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Today, 01:12 PM

#5159191 Metal API .... whait what

Posted by Krohm on 08 June 2014 - 11:24 PM

Honestly I don't get the OpenGL is smart vibe in this thread at all.

To map a buffer you still have to bind it (p. 65 core spec 4.4). You bind it to target and then you map the target. You must be joking.

The best thing that could happen to OpenGL is to die instantly and be replaced by a set of built-in kernels in OpenCL. That's terrible.

#5159185 Bribes

Posted by Krohm on 08 June 2014 - 11:11 PM

The question is what is the purpose of these bribes.
For those who accept a bribe, the gain is always personal. Be it direct ("black" funds) or indirect (helping a friend of a friend I often go sailing with).

There's no other purpose than this.

#5157487 Memory allocator. Maintaining free list.

Posted by Krohm on 02 June 2014 - 12:31 AM

Now, to "free" a ByteBuffer slice, I'd need to find roughly its position inside the free block list.

You mean in the used block list. How do you plan to make things work roughly? I suspect I'm not getting the picture. I use a dual-list for my allocator.



The problem is that if the block I'm trying to free is between two free blocks, I'd need to merge all 3 (left free block, the block I'm freeing, and the right free block). That would mean, removing one of the adjacent free blocks, and expanding the remaining one to cover the block I removed and the block I'm freeing.

In my experience, found "forward merging" appeared to be sufficient. Keep in mind free memory is unreferenced, "useless" memory, so you can really do this every say 1024 free or every time an alloc fails. Making alloc performance nondeterministic doesn't sound like much of a big problem to me.

#5157484 Probably my last "What should I do?" thread for awhile. Need to sum t...

Posted by Krohm on 02 June 2014 - 12:23 AM

Only do one of those two things.

Go 3D


Go mobile.


Not both. It's a recipe for disaster.

Keep in mind that in both cases you're going to hit a thing often overlooked in those forums.

Gameplay mechanics and tuning.


Personally I'd suggest to look in Javascript as adding HTML5+JS to your skills can open a variety of roles. Hopefully paid.

#5154570 Do we isolate static and dynamic meshes in our games?

Posted by Krohm on 19 May 2014 - 01:07 AM

I could basically copypaste what frob wrote but I guess I'll elaborate what I do FYI.


Meshes in my system are to be approached with care.

In the DCC tool (Blender) you can just import a mesh from an external file. It will get fully pre-baked by the filter and become part of the world. This means if you have 100 repetitions you get 100 times the memory footprint. In the past, the filter would look for cloned nodes at file level and try to figure out what was instanced and what not. I found that quite brittle in practice as Blender makes super easy to duplicate instead of just cloning.

Nonetheless, in this case, meshes are always static.


To have instantiated meshes I have a very rough annotation system in place. Meshes are given a resource handle and their contents are really ignored at filter level (in Blender they are represented by the same mesh for convenience, but they don't have to). Those meshes are always instanced and can be marked static or solid on a per-instance basis.

The filter currently produces a separate list for guaranteed-to-be-static meshes. They are supposed to go through a different processing path involving, besides other things, extensive pre-batching. For the time being, they just generate collisions in the static rigid body domain instead of using the dynamic system.

#5154562 Where to go from my current progress?

Posted by Krohm on 19 May 2014 - 12:16 AM

Perhaps you need to start thinking outside the programming mindset. A game is not just logic and it seems you have enough working logic right now.

Are the level editors smooth enough? Are the input filters reliable? Are the mechanics well understood? Is the story well fleshed out? Do I want to add more detail? Remove some detail? From where? Do I want another weapon? A new enemy? Extra towns?


Once the plumbing is done, it's time to get serious with gameplay. It's surprisingly difficult considering the little technical requirements.

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