Norman Barrows

i'm interested in frustum culling large chunks of the game world.

in this case a "chunk" is 26400 x 26400 in size, and the frustum is just 300 units deep. 

so a simple AABB frustum cull that checks BBox corners won't work, due to chunks that entirely span the frustum.

so i'm thinking calculate relative headings to chunk centers and corners, and compare them to the horiz FOV. perhaps combined with some range checks. i don't really need to clip to the upper or lower planes, i'm just trying to figure out which chunks are "not in front of" the camera, so i can skip drawing them entirely. so i don't really care about the y component.

in most cases, only the chunk the player is in will be visible. but adjacent chunks can be visible when the player is near the edge or corner of a chunk.

any other (possibly less ugly) approaches come to mind?

i know that i could  convert the chunk into a quad of 2 triangles then edge clip them to the frustum, then check what's left of them to see if the chunk is in the frustum (as though i was drawing and clipping 2 tris myself), but that seems like overkill.

from the directx 10 docs, Resource Limits:

just what do they mean by this?

the original mesh (vb) can only have 232 vertices? IE its the limit for IndexCountPerInstance?

or you can only create 232 instances of a mesh (vb) with one call  (InstanceCount limit) ?

or ALL the meshes (original + created) can only have a total of 232 vertices?  this i would find hard to believe.

has anyone tried using a 2d texture array vs setting individual textures to reduce the overhead of texture state changes?

similar to using texture aliases to reduce the number of texture state changes.

I'm working on implementing paraly in a RPG.

the basic rules of how it works are:

1. selecting a hostile during combat lets you "parlay" with them.  combat with them stops for a moment, and you can interact with them (talk, bribe, etc).

2. if you talk with them and relations improve enough, they stop attacking.

however there's already the following rule in the game (which is behavior programmed into the game engine):

1. if you're attacked while performing an action (like in The SIMs, microwaving dinner, or in this case talking to a NPC), you stop that action so you can fight.

if there's more than one hostile, the combo of these two sets of rules (parlay rules, and "combat stops actions") is that you start to talk to the first hostile, the second hostile continues to attack, the talk action get cancelled (you stop stalking to hostile #1), and hostile #1 starts attacking again.

should the player be able to parlay with the entire group at once?

or should talking during parlay take unrealistic zero time, and the disposition of all hostiles await its outcome?

or should one simply be unsuccessful at attempting to build a rapport over common interests in say travel and nature with a hostile during parlay, as long as his buddies are still trying to whack you with a big old nasty stick?

i guess group parlay that takes non-zero time is the right way to do it.

hmm...

parlay success depends on your relations with the hostile you're talking to. 

would it be unrealistic to let the player parlay with any hostile, and have the result of that parlay affect all hostiles in the group?

hostiles are now persistent in the simulation, so you can run into the same hostile again and again, and it tracks your relations with them over time. the player COULD select a known hostile from the group with whom they have better relations, in an attempt to increase their chances of successful parlay. but then again, thats what one would do in real life, so maybe thats ok?