Jump to content

  • Log In with Google      Sign In   
  • Create Account

MaxDZ8

Member Since 27 Aug 2002
Offline Last Active Sep 24 2016 03:22 AM

#5254781 Is computing translation matrices directly in the shader more efficient then...

Posted by on 30 September 2015 - 08:00 AM

The longer your shaders, the better. Push as much as you can into it. The more particles you have the more you'll gain, you have hundreds of ALUs waiting for commands, graphics shaders are very often too short for nowaday's architecture.

Keep your CPU free for stuff you cannot trivially GPU-ize!




#5253264 C++ Question About Objects

Posted by on 21 September 2015 - 03:37 AM

A final note FYI.

Do not call overriden functions (pure virtual) from base class ctor. So you cannot do something like:

class Asset {
public:
  Asset(const std::string &foo) { Load(foo); }
protected:
  virtual void Load(const std::string &foo) = 0;
};

class Level : public Asset {
public:
  Level (const std::string &foo) : Asset(foo) { }
protected:
  void Load(const std::string &foo) {
    // Pull physics
    // Pull textures
    // Pull sound resources
  }
};

To build a Level object the runtime first builds the Asset object. When the Asset object ctor is run, it has no information about what's really running and you'll be screwed big way. I think some compilers warn you or even prevent you from doing that. I am 100% sure I have been screwed in the past.

If memory serves, Java allows this for some reasons I don't remember. I'd suggest to be careful with that.

 

EDIT: see Brother Bob for a more "technically correct" explanation. I still suggest to stay away from those things but that's opinion at this point.




#5249847 Looking into fix my time step

Posted by on 31 August 2015 - 04:36 AM

As a start: next time, put the link to article on top. It is necessary context.

 

(Q1)Like why do they have the accumulator in a while loop?

Most likely for easiness of explanation (?). I don't see much of a point either.

 

(Q2)does that loop do the update or do you wait until the loop ends.

It does a thing called integrate and a thing called render... I assume you don't crunch English well.

In the given context, to integrate means "run the computations and produce new values [from the RK integrator]".

To render is to draw.

 

(Q3) What is t with long waits this just counts up and up each time you do a pass.

"Yes"

Seriously, I cannot make any sense of what you're really asking there. Anyway, t is the sum of tick time which in theory is the time passed since t0.

 

(Q4)lloks like it only works when frame time is small

You are correct, sort of. If physics tick time is too big then you're screwed forever. This problem has no solution and even Bullet (physics library) warns about that case. Decoupling rendering and physics makes the whole problem way less concerning.

 

(Q6)How do you proccess 8000 objects in a small amount of time. That will not make the time delay blow up.

8k (moving!) objects are pro stuff. Let me put that easily for you: use a physics library.

Even for them, 8k (moving) objects are quite a stretch. In general, when you start having thousands objects you can try move those to GPU.

You might be suprised to know 8k (mostly static) objects are a breeze. The key is fast reject of objects surely not interacting (broadphase) and then further refinement (narrowphase). Physics libraries get much smarter.

 

This does not look wright if I add a 1 second delay at the end of the loop the while accumulator will spin for like depending on the wait can spin

upto 615 steps in the loop and more, this seams wrong why waste that loop.

It is not 'wasted'. It is the correct behavior. To properly integrate arbitrary functions, your dt must be "approaching zero" (talking mathematical here) so if your frame time is too big you go over and over and over until you iterated the state enough.

In other words, the state can only evolve in small steps.

 

I noticed in the article they put a if(frameTime > 0.25) frameTime = 0.25; whats the point of calling thy timer. In my current setup I just hard coded a 0.20 as my frame delta and vsync thats why I want to change to this, But I'm missing something.

What you miss is that vsync is unreliable (as a start) as drivers can force it off or on and you would be screwed. Plus, there's no current guarantee your software will be faster than vsync so you actually do your computation in vsync multiples. Last and perhaps more important, the whole point of the article is that you have a flexible tick which is predictable, not an hardwired one.

Or, condensing to core: fail.

 

Just found this post Now if I set a DT of 1/120 and a sleep(1000) there is over 23000 steps lol say good by to your game loop hehehe. 1/30 seams to work a lot better

Once again, you failed to grasp the whole point of dt 1/120, the user specifically mentions it works in higher-precision simulation.

 

 

Can't  you just set a timer to fire every 0.03 seconds and update.

And then, when your update takes 0.035 seconds your timed updates will just happily enqueue forever and after a while you will have a problem anyway. That's of course assuming they don't stump on each other with no remorse.




#5246160 Refined collision response - a small discussion on brushes

Posted by on 13 August 2015 - 02:26 AM

1) I'm guessing brush-based collision either is or is becoming passe in modern engines in favor of a more expensive polygon soup approach, which is woven directly into the physics engine.

 

Let's see that happening. As far as I am concerned, using graphical assets for collision purposes is no more doable. It has been predicted quite some time ago. It is a necessary evil for some special effects but those hopefully run much more rarely than collision.

 

 

2) Translating brushes is fairly trivial. However when it comes to rotating them, as best I can tell, it's easier to just rebuild the entire collision brush from scratch. I've yet to find a plane rotation routine that doesn't boil down to recalculating the plane equation. That being said, it's likely still cheaper than rotating a polygon-based collision mesh.

What truly surprises me is how much often I see polysoup collisions being used. Sure physics libraries use acceleration structures for them but in my experience it's still better to reject at broadphase... uhm.

 

 

3) I started messing around with a GJK handler for moving objects a while ago and got it to work with two spheres. However, I kind of got stuck extending the code to brushes. At least it wasn't as trivial as I would have hoped (more to the point, support calculation for brushes turned out to be less than trivial, especially with rotation thrown into the mix). Incidentally, GJK wasn't around when Q1 and Q2 were written, so who ever wrote the collision code opted for a fairly "cheap" workaround for the sweep test - essentially the collision brushes are expanded to simulate the Minkowski space, which then allows point-brush collision testing without using anything as fancy as supports. It's pretty nifty in theory, but I don't think it handles brush collision with anything other than a sphere (or a capsule that's squished into a spheroid).

That's nice to know, I personally always found collision in Quake engines fairly solid.

 

While points 2 and 3 are a matter of time and research to overcome, I'm still unsure what to do about point number 1. I've gone so far as to consider adopting Bullet, but frankly I've put so much time into this and learned so much, that I don't want to throw it all aside...

I'd strongly suggest to stop at this point. I wasted too much time on physics as well.

Let me reiterate: wasted.

Time is wasted as nobody I have talked to has seen any value in that. It's like the sewer system of a city. Have you ever met anyone happy of having a sewer? Maybe you did. Most of the time people just does not care about the plumbing and by the time you have your collision system done welcome to the world of dynamics.




#5245454 Question about nDotL across LOD levels

Posted by on 10 August 2015 - 07:27 AM

(a) Is the following output of nDotL correct, useful for physically based rendering

and must be used as a general guideline across all LOD levels, meaning that

(b) whatever the sampling rate, your nDotL should roughly follow this curve?

(a) n dot l is a convincing approximation, it has no physical basis as far as I remember, it only looks arguably convincing.

 

(b) I have no idea what curve you're talking about. What I see seems to be a normal map... in world space I assume. It seems convincing. Yes, in theory you should try to stick close to it.

 

 

 

But if I double the height map and normal map resolution, but adjust the sample rate (half it) so that the amount of vertices remains the same, I get this result, which changes the the nDotL curve:

Of course it does. You're sampling different points, you get different results. When it comes to terrains, you don't sample them at some random interval you decide: you sample them at native resolution, stepping across adjacent samples. If you have some interpolation method you might think about super-sampling but that's backwards. The heightmaps from which you pull normals must be the highest resolution you have and then eventually bake them to a normalmap.

 

 

How should the normal map on full resolution look? More like the one in the first screenshot, but with more detail, or more like in the last screenshot, flat.

You are not going to figure it out with a test set like the one you're using. Pull in a special test case, you will find the correct result should be pretty trivial to identify. Besides, artistic decisions might apply.

 

 

How consistent should be the various MIP levels of the normal map as I go down in resolution?

Good question. In my experience you can have quite some variation if you use at least trilinear. What I did however was to re-compute all normals from the mipmapped heightmap. Mipmapping normals does not sound so convincing to me. Note however I did those tests for generic bumpmapping. Following discussion.




#5244442 What does mapping mean?

Posted by on 04 August 2015 - 12:20 AM

Just in case the questions are serious, I am against this type of explanation as the metaphor used is possibly more complicated than what really happens, which I consider a bad habit (in particular, geologic activity is one of the most complicated phenomena in the world).

Besides, as a non-native English user, I had some difficulty putting the things together and even re-reading it, some concepts appear to clash such as the use of the word layout with cartographic quality but in practice we're just talking about a blob of memory with a size.

 

It is not obvious in my opinion Andy is referring to layout of the virtual memory address space, in this specific context I consider this prone to misunderstanding.

 

I also argue that a buffer is never re-arranged as it is in itself a blob of linear memory. It might map to a different pointer (virtual memory address) but its layout does not change in the sense that buffer[i] will always go to the same element of the buffer as long as buffer holds the correct base value, which is always the result of the Map call. I understand this might be a subtle nuance of English interpretation.

 

I also argue there's no point in ELI5'ing this. There's no need to pull in extraneous concepts. Anyone not understanding mapping does not need a metaphor; they need to re-read the documentation and check their basics.




#5244253 C++ Operator Overloading: Bitwise Operators & If-Check

Posted by on 03 August 2015 - 03:18 AM

Maybe I missed the objections but... why do you have to use flags and masks? Unless I have a lower-level component requiring it, I'd stay away from them.




#5244252 What does mapping mean?

Posted by on 03 August 2015 - 03:09 AM

I suggest to discard/ignore the above post.

 

It's very simple. Your VB is a blob of memory. Most of the time, it resides on VRAM (but it does not have to). The GPU is working with it; you don't touch it. You have an handle to it, but not to its memory.

 

Mapping a buffer means you get a pointer to something that is (not quite) the buffer memory. Stuff you write there will go to the real buffer; depending on flags you can get its contents.

 

Mapping a buffer does not give you any information of how the data is stored, you don't know layout, you don't know type.

 

Most of the time, you map a buffer to write to it. Your modifications are not guaranteed to happen until you unmap the buffer.

 

The relevant function calls are ID3D10Buffer::Map and  ID3D10Buffer::Unmap, note there are map/unmap calls for other resource types as well.




#5242912 To use mana or not? (that is the question)

Posted by on 27 July 2015 - 01:39 AM

Working without mana is viable.

Oldschool pen-and-pencil RPGs had you select your spells every RPG-day. You're given 'slots', you allocate them, you consume them, you're done.

More recently, you were allowed to select them on the fly.

I'm not up do date with the most recent advancements. Nonetheless, requiring to go back to town seems an immensely slow mechanic. Unless magic is extremely powerful OR you give many more slots OR you want to nerf magic on purpose, that seems to reduce casting effectiveness quite a lot.




#5242910 steam hardware survey

Posted by on 27 July 2015 - 01:32 AM

As a side note Norman, you might be interested in comparing installed base to unity.

Note for the time being Steam reports the most common video card is NV GTX 970 (3.54%), while 750 is less common (2.56%). Considering the 970 can easily be 300 bucks I'm inclined to assert steam samples mostly core gamers demographics (which is known to to). It could be debated whatever this is the best for you.




#5238572 Text adventure design in C

Posted by on 06 July 2015 - 02:33 AM

Holy shit.

There's so much wrong in this thread I can hardly believe.

 

Do not hardcode locations/rooms in code.

Do not produce structs by using C code.

 

Lenny, seriously, I sympathize with the structure you proposed, but you should really have spared us from demonstrating the terrible practice of mixing code with assets. Have phun managing the numeric index for 'touch' information.

True solution: data driven architecture. Here's a JSON to populate areas (not the same thing, as I couldn't be bothered in keeping track of the indices), then you only have to parse it and get your structures out.


{
    "locations": {
        "beach" : {
            "desc": "A sandy beach covered in shells.",
            "near": [ [ "north", "forest" ] ]
        },
        "forest" : {
            "desc": "A dark and spooky forest.",
            "near": [ [ "south", "beach" ], [ "east", "hill" ] ],
            "items": [ "temple_key" ]
        },
        "hill" : {
            "desc": "A windswept hilltop covered in tussock.",
            "near": [ [ "west", "forest" ], [ "north", "mountain" ] ],
            "items": [ "tin_can", "rotting_adventurer_corpse" ]
        },
        "mountain" : {
            "desc": "A tall lonely mountain.",
            "near": [ [ "south", "hill" ] ]
        }
    }
}

Bonus: here's how it looks in notepad++ json viewer.

Left as an exercise: HTML5+CSS landscape editor!

Attached Thumbnails

  • 103246-GameDev.net Community Forums.png



#5237995 Best approach for long computations, threading or timeslicing?

Posted by on 02 July 2015 - 08:07 AM

In this day and age, I would suggest to just make them async. Be careful of dispatching new work faster than they get processed.

In theory I would suggest std::future but it is my understanding it has no "is result ready" call so I'm afraid you will have to go with std::thread.

 

Now, you should carefully approach threading but you don't have to be scared by them. In a certain sense, they don't introduce really new concepts in terms of data safety. Just try to figure out a minimal data set they need to work on and the minimal "interface".

 

EDIT: SeanMiddletech reported below that it is possible to obtain a "is result ready call" by having a sleep-by-0-seconds call. I consider it a bit quirky but it sure will do. Go upvote that post.

 

EDIT: I have noticed WFP reply is more recent. Whoops. Go upvote that as well. Note: use the quote button, it gives notifications to the quoted person.




#5236704 The Story of a Roman Slave - 2D RPG set in an alternate history Britannia

Posted by on 25 June 2015 - 04:06 AM

Ah yeah pretty sure that was it. Other precursors appear to be "fallen london" and something related an "echo bazar". I don't remember much. Maybe worth checking mostly to make sure you strive away from it. Or at least don't look too much like them.




#5236689 The Story of a Roman Slave - 2D RPG set in an alternate history Britannia

Posted by on 25 June 2015 - 01:38 AM

I think the starting idea has a lot of potential. The historic background seems sound and you're basically "augmenting" the true tech advancements.

 

It made me think of a game... but I don't remember the name really. Those are currently two games in the same universe. The last one is about a ship exploring an unknown underground sea. I don't remember much but I think the setting was similar. Was it similar?




#5236684 What performance will AMD's HBM bring for graphics programmers?

Posted by on 25 June 2015 - 01:22 AM

On the topic of whether HBM is a huge game-changer -- Not yet, at least not for end-users, because today's HBM1 bandwidth isn't all that much larger than the bus on the 390x (512GB/s vs 320Gb/s)...

... is merely top-end, thus having little to no market share.

 

Corrected that for you. Perhaps this is irrelevant to you AAA guys but really most cards are sold at 150 bucks; my card has 75 GiB/s, a two-chip binned HBM would bring close to 200.






PARTNERS