Jump to content

  • Log In with Google      Sign In   
  • Create Account


Krohm

Member Since 27 Aug 2002
Offline Last Active Jul 10 2014 12:34 PM
****-

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




#5161467 Too large shaders - micro specializations.

Posted by Krohm on 19 June 2014 - 06:48 AM


- I am drawing about 58 type of different materials each frame!
It is a very affordable amount. What's about the '!' ?

Personally if I would still have to be stuck in D3D9 I'd drop all optimizations. It's not going anywhere.




#5160786 Build a render farm using DirectX and radiosity?

Posted by Krohm on 16 June 2014 - 02:05 AM

D3D11.1 can be used in session-0 processes in Win8 but googling I've read someone seemed to have issues with it.

OpenCL can definitely run without a monitor but I'm fairly sure it needs the drivers installed for AMD since it uses the internal AMD IL compiler.

 

Nonetheless, I wouldn't use D3D for long-running tasks. You need to set a flag to allow it to not timeout. The performance seemed to be considerably worse for large datasets in my case. I cannot tell if this is a driver problem by my side but it seems likely D3D11 Compute might have been optimized to work in a latency-sensitive context of small datasets used for realtime manipulation. 

 

OP:

never think about using FFP again. Not only you'll be shooting yourself in (at least) one foot, but you'll also have to go through ROPs instead of just streaming to memory and this can be a problem in modern architectures.




#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

XOR

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.






PARTNERS