Jump to content

  • Log In with Google      Sign In   
  • Create Account


Krohm

Member Since 27 Aug 2002
Offline Last Active Today, 12:34 PM
****-

#4996451 Sending lots of data to the GPU?

Posted by Krohm on 02 November 2012 - 01:25 AM

I was thinking a way around this would be to create an image at run time where each pixel represents the XYZ and intensity of the light as RGBA and send that instead to the shader. That way I could theoretically have a thousand lights with no problems.

I had implemented this back in... 2006 I think, on an entry-level GeForce6.
Main problem with that kind of hardware is they cannot loop arbitrarily. They can loop 255 times at best, but even when fitting the HW resources, the shader might eventually time out and abort. Hopefully this is gone now. If memory serves, it was possible to process about... perhaps 50 lights per pass?
Performance was interactive, but far from viable.

Real problem (which holds even now) is float textures take quite a lot of bandwidth and float texture lookup is often slower than int lookup.


#4996449 Time to write rendering engine from scratch

Posted by Krohm on 02 November 2012 - 01:18 AM

I'd be extremely careful as the goal is not clearly defined. I use AssImp for the loading yet I'd find hard to take less than 5 working days. But perhaps my definition of "without fancy shaders" is different from yours.


#4996447 What Sorts of Algorithms and Data Structures are Useful to Game Programmers?

Posted by Krohm on 02 November 2012 - 01:10 AM

Sorry but I disagree.

Sorting algorithms. Here's what you need to know.
std::sort().
Having spent several months at sorting algorithms, I feel safe stating that this is the only thing I care about sorting as an algorithm book would discuss.

Pathfinding algorithms.
Spending effort on them even before starting is a bit of a stretch. I'm not saying this is not necessary, but you can get a lot of mileage before this becomes a blocking stop.

Object pooling.
Studying that in theory is complete nonsense. Get a real problem first. Profile. Fix (if necessary).

What's really needed? How to build sane code. Documentation, style, engineering, knowledge of real-world problems.
Or more related to implementation: object lifetimes, smart pointers, proper OOP, various code patterns etc.


#4995048 Logic Game

Posted by Krohm on 29 October 2012 - 07:38 AM

Try drawing on paper what you want to obtain. In my experience having a clear, detailed goal is very useful to your morale.

You'll certainly need some minimal GUI, a way to display images and pick those cards.
Do you have an idea on what language/tech to use?


#4994961 Is it possible to draw Bezier curves without using line segments?

Posted by Krohm on 29 October 2012 - 12:39 AM

Let there be GPUs.
Seriously, not talking about this is all messed up.


#4994049 Using DirectSound

Posted by Krohm on 26 October 2012 - 12:53 AM

Is DirectSound still going? It was my understanding you should use XAudio2. It's supported since some XP service pack if memory serves.


#4994048 Level Editor - Reinventing the Wheel

Posted by Krohm on 26 October 2012 - 12:49 AM

Now i have a scene structure (xml based) that i code by hand and lay things out. So the next thing i wanted to do was investigate creating a Level Editor which got me thinking. ...

  • what language do they code the level editors in. I know the engines are written primarily in c++, but GUI in c++ is not fun.
  • If i wanted this to only run on windows ( for now but possibly go cross platform ), what would you suggest

I suggest sidestepping the problem completely. Consider using blender as an extremely powerful editor.


#4992690 Init/Shutdown methods

Posted by Krohm on 22 October 2012 - 12:39 AM

Yes, in general, it should be better to leave those in ctor/dtor.

Problem is that (I guess) MSVC didn't implement proper exception throwing for a while, therefore making RAII much, much harder to use. Consider:
int *avoidPlainArraysWhenPossible = new int[RequiredValue()];
// (1)
In old visual studio versions, new would return NULL on failure. Therefore at point (1)
  • In compliant C++, you could just assume the array to be allocated
  • In MSVC, you couldn't.
Furthermore exception handling was a bit problematic, often disabling some optimizations and generating a lot of extra code.
Those issues are pretty much resolved in 2010, but that's the likely reason for which they use Init calls instead of just relying on the ctor.

There's a complication however. Ctors cannot rely on internal virtual functions. That is, if your initialization is non-trivial, you cannot do RAII.
It is often possible in my experience to refactor those objects to not rely on virtual functions at construction by providing them with adeguate external support. But it takes effort.

Dtors are "worse" as they cannot be parametrized. The only way to provide them with reference to ... say Vertex Buffer managers... is to put a reference explicitly. This does not always makes sense.

For general code, your 1st choice should always be ctor/dtor only and pure RAII but this is just a sanity guideline. Alternatives are allowed and might make sense.


#4991704 The process of making a level editor

Posted by Krohm on 19 October 2012 - 01:22 AM

(1) Just keep it as simple and practical as possible ... (2) It was a completely separate entity to my game .. (3) decide how I was going to store the data, so I could parse it accordingly ... (4) use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;
Because I had such a short amount of time (5), I decided to limit the artists abilities (6) to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor.

Sorry but I disagree on some of the concepts here and I need to point those out so people can properly relate to the efforts involved.

(4), (2) We could discuss that. There's a code dependancy.
(3) this is not future proof. How my code loads its own data is the last of my concerns. What concerns me is compatibility across other DCC tools as...
(6) telling artists "you must use my editor" and "you cannot do that" is pretty far from best practice.
(1), (5) If I'm in a hurry, I don't write a level editor. I bolt my features on pre-made programs. Took me two days to write the blender scripts, and a week to refit the whole asset workflow. And I can guarantee my feature set is pretty rich.

My first (and last) attempt at a "slick" 3D level editor is something around 2001-2004 I think. Words fail to describe how limited it was and how much effort it required. In the end, it was just easier to filter input from other programs (not to mention this is required anyway as there's a large availability of test data on the net).


#4991031 The process of making a level editor

Posted by Krohm on 17 October 2012 - 12:55 AM

Have you considered custom properties? They work like a charm for me.
CustomProps.png
Here's how my (hopefully) final workflow goes.
  • Level geometry is generated normally.
  • Adding static meshes. The meshes are authored externally and imported. The basic mesh is annotated with a special customprop instructing the filter to alias those meshes.
  • Adding other resources such as gameplay elements. They are similarly annotated.
  • When done, export to collada.
  • A python script in blender walks over the scene graph (it's basically a vector in blender) and pours out a nodename, properties set for each annotated node. It dumps everything to json.
  • Filter loads the exported collada, short-circuiting parsing of anything having an allocation. Done.
This way you still get the benefit of having an editor "almost ready to go".
Couldn't you encode this in collada directly? It's very likely but it's my understanding that AssImp won't load the data so I found another way.

Edit.
As a side note, make sure you write the custom props in the correct place. It is possible to put custom props pretty much everywhere. In nodes and materials for sure. I think meshes also have a custom prop capability but I'm not sure. Sure there are other places where custom props could be used but I'm not all that good with Blender.


#4990289 Thoughts on making a 'living' world

Posted by Krohm on 15 October 2012 - 01:15 AM

The problem mentioned is it would be near impossible to keep all areas loaded and tracking the individual NPC's within them.

Nobody cares about that. As you noticed, the whole point is to do that at the correct level of detail. Keeping the whole world loaded is ... ok, probably possible now. Sure it wasn't at release.
But if we drop the graphics representation... and the sound... ever looked at the scripting in TES3? It probably takes less than 4 MiBs of state.

I'm not sure what you're trying to say with your whole message, but yes, if you focus on that feature, it should be possible. Nobody says it'll be easy.


#4990280 Animations and Models in a Game Engine

Posted by Krohm on 15 October 2012 - 12:49 AM

  • Are weapons typically designed as classes with information about animations contained within?
  • What about other information about the weapon (damage, which animations to play and when, etc.)?
  • Are there any examples or articles that might point me in the right direction?
  • I really want this design to be as robust as possible.

  • Define what a weapon is. A weapon has logic. A weapon has appearance. Most of the time, the two representations are decoupled. The representation is an ordinary model and there could be some loose connection with weapon animation... but to my knowledge, everything that's vital is in the logic.
    Say you have a laser beam. A typically "model" information could be "point from which the beam starts".
  • Damage, or cooldown is an example of key value which I suggest to store in logic (or at least, not in the model itself). I've also seen a few games which relied on the actual mesh animation to cooldown ("fire again as soon as the cooldown animation has finished"). I don't consider it good practice.
    Animations to play are stored in the mesh, but the logic drives them.
  • When I'm out of ideas, I read stuff about system proven successful. I'm not saying I'm cloning them, but sure UDN has been very valuable source of inspirationto me.
  • Having been in the "as robust as possible" mindset myself, I'd rather suggest to design it to support what you really need. And very little more.



#4988627 Making holes on a heightmap based terrain

Posted by Krohm on 10 October 2012 - 12:56 AM

I strongly advice to not do so at vertex level.
It's worth noticing it is not possible, in a VS to set "each of the 3 vertices to the same position". This is Geometry/Primitive shader capability, for which you could just avoid emitting a primitive to rasterize.
Also note that moving vertices has a consequence on shading and rasterization on all primitives using it.

In the past, I've been moderately successful using height map parametrization to encode hole points. It required some uniforms and I didn't consider it good enough for general use so I didn't invest on it. However, this technique has re-surfaced in L4D2.
I'm currently inclined to use precomputed low-res distance fields instead. But given the availability of large (for my purpose) uniform storage in SM4 and beyound, I guess I won't spend more effort on it.

edit: typo


#4988625 Fixing terrain tearing

Posted by Krohm on 10 October 2012 - 12:47 AM

If the faces are disjoint, they are likely to cause this problem (much more if the normal isn't the same).
If the heightmaps are disjoint, they are likely to cause this problem.
If the independent patches have independant LOD they will be worse.

Either add skirts or make your mesh continuous (it does not really have to share vertices, but it must at least use numerically equal vertices, end even this is not guaranteed to produce the same rasterization).

Solidifying independent meshes is a serious task.


#4987049 Enumerate multiple keyboards?

Posted by Krohm on 05 October 2012 - 01:58 AM

Maybe my memory is at fault but I'm rather sure RAW input will do it way easier.
I've worked my way with WiiMotes, I guess it'll work with keyboards!

I don't know what's about. Why all this effort in keeping DirectInput alive? For keyboard input?




PARTNERS