Jump to content

  • Log In with Google      Sign In   
  • Create Account


Krohm

Member Since 27 Aug 2002
Online Last Active Today, 12:26 AM
****-

#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




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






PARTNERS