# Kasper Fauerby

Member

74

240 Neutral

• Rank
Member
1. ## What Is A Scripted Event?

In terms of gameplay you could also think of some features that are "core gameplay elements" such as enemy AI, picking up goodies, pulling levers to open doors etc. So when you run around a level, trying to shoot the bad guys, they will behave in a semi-intelligent manner that can be different for each playthrough (although it'll probably be a quite predictable behaviour). They'll do this by using the core game mechanics. Whenever the game needs something more complex and interesting (usually to further a story or something) the game designers will insert a "scripted event" where they take full control of the game world and game characters to make them do something that is so complex that the core game mechanics isn't enough.

3. ## A question about CRC32

Thank you for your replies, but I *do* need to save the values and use them across many machines, so memory addresses etc. will not work. I really need a (persistent) unique key for each string :) So, back to the original topic, Damon gave a probability figure that was radically different from the one I arrived at. I'm not sure I agree with his way of calculating it though, so if anyone else could verify his result it would be much appreciated. Alternatively, if you think crc in general is ill suited for the problem I'm trying to solve, I'm open for suggestions to other hash functions that will generate unique keys for different strings. - Kasper
4. ## A question about CRC32

Hi guys, Here's a question for the math-experts, since my own probability math skills are a bit rusty :) My problem is that I need an algorithm to give me a unique number for each member of a set of strings (variable and function names in a scripting language). The set can be quite large for a full game - for example, 10.000 different names or something in that order. I need the number to be unique, so there can be a one-to-one mapping from a variable name to a number. Furthermore the algorithm must give the same number every time it is called on a specific string (obviously). So, I've pretty much decided to use a CRC algorithm - but I need to figure out if a crc32 is good enough or if I have to use a crc64. If a clash occur it would not be completely fatal, but annoying since I would have my script compiler ask the user to rename the offending new variable/function. This should obviously only happen very very rarely - and hopefully not at all. So, assuming a set of 10.000 strings I've tried to estimate the probability of a clash if I only use 32 bits for my crc. Here are my thoughts on the problem: When the first string is inserted there is 0% risk of a clash. When the second string is inserted there is a 1/2^32 risk of a clash, next we have 2/2^32 risk - and so forth. This gives me a total risk of: Sum(1, 10000) / 2^32 = 5000*10000 / 2^32 = 0.0116 So, assuming my math is correct, there is 1% risk of a clash when using crc32 on a set of 10000 strings? My question then is: Is the calculation above correct? Or am I way of track here :) Thanks for reading! - Kasper

In a quadtree each node or "box" should fully contain all it's children, so the y-values of a "branch" should simply be the min and max y-values of all its children. You could do this in a depth-first recursive function that returns the min/max y-values of the current node. A leaf would then simply return the min/max y-values of all its points, a "branch" would return the min/max y-values of all the results it got from calling on its children. The return value of the root node would be a bounding box for the entire terrain. - Kasper
6. ## Ellipse/Plane Collision equation?

You can easily use pieces from the algorithm in my document to do what you are after - in fact one of the first steps in detecting collision between a swept sphere and a triangle is to detect whether the swept sphere intersects the general *plane* in which the triangle lies. In the case where you're looking for a static intersection test (ie. if the ellipsoid does not move) then it's very simple - transform to "eSpace/unitsphere-space", calculate distance from the center of the unit sphere and the plane, if abs(dist)<1 then your ellipsoid intersects the plane. - Kasper
7. ## d3dx9_24.dll etc. Missing

Or, you could consider if you really uses anything from the latest releases of the SDK - and if not, go back to using a relase from before they introduced this .dll hell. - Kasper
8. ## Singleton Question

Singletons can be great for many things, but they do not do what you think they do based on your question. What you need is the 'extern' keyword. In the header file you declare your array of textures like this extern GLuint Textures[nr]; This simply means: "when you (the compiler) see this line by including the header file then you should simply accept that an array 'GLuint Textures[nr]' will be available somewhere when the linker needs them" Then in *one* of the .cpp files (preferably the .cpp file matching the header) you have to actually declare the array like this: GLuint Textures[nr]; Now all files that include the header will know and use the same global array of textures that you have declared. - Kasper

10. ## I need your opinion on my scenegraph ^^

@Paic: Overall your design sounds pretty good but you should be careful not to do too many "visits" of nodes that doesn't need to be visited. For example, if your scene-graph contains many nodes that should not/can not be rendered then it could introduce quite an overhead to visit them in the graph each frame to collect nodes for rendering. The same goes for an "update" pass through the graph - if you have many nodes that does not overload the update function from a base class (for example) then it'll be an overhead to visit them each frame. The overhead could come from the additional traversal time as well as the fact that you'll visit more memory and thus probably get more cache misses. We just release our first 3d game for PC, PS2 and Xbox and one of the things we'll change for the sequel is exactly the way we traverse the scene graph. For this game we did it pretty much the way you described - but we have many "logical" nodes that are only used to implement some level design or to group nodes ("folder" nodes in the tree). There are several ms per frame wasted by doing a full tree traversal compared to when we extracted certain nodes to linear lists that we have beside the scene graph. For example we have a list of all those nodes that we know we'll call "update" on each frame and so on. For rendering we have a seperate tree that contains only the sub-tree of the scenegraph that are the nodes that can be rendered. But you also loose some power by using extracted lists. For example it's harder to control the order of updates or for one update to trigger the update of its nodes children. Regarding the sorting: this should *definately* be done after the visible nodes has been retrieved somehow. Why? Because different rendering techniques or even different rendering passes will want to sort the nodes/geometry-bits differently. Hope this helps a bit.. - Kasper Fauerby
11. ## DX10 question

I'm not sure about input and sound - but the graphics part will be quite different from what we have now. The concept of 'caps' will go away - which also means that DX10 will *only* run with hardware created for DX10. They are also doing some major changes to improve performance and interestingly the overhead cost of a DP will go down a lot.
12. ## Skeletal Animation Question

Yeah, the fact that artist started to animate individual fingers instead of the good old "look as I wave my wooden box around" really upped the bone count :) But now, at our studio, we've also begun doing simple physics stuff on some extra bones to do pony-tails, ties, breasts, bellies and even hair. That stuff also eats up bones like they were snacks... :) - Kasper
13. ## World Creation System - Where to start?

Not to scare you off or anything, but it *really* sounds like you should try and team up with a skilled programmer! The skills you seems to have - those of a technical artist - are skills that are becomming more and more important in the game business because it requires both technical and artistic skills to design a really cool game editor with a practical work flow for the users. Programming is really cool (I'm a programmer myself) but as other people has mentioned it is also a field that takes *years* to become great at. I'm afraid that if you start this project of yours all by yourself then you'll eventually become very frustrated that you cannot express your ideas in code - or your implementation will be limited compared to your visions. I was lucky enough to team up with a technical artist years ago and we met when we were both at the same level! Together we've been around first doing a "Wolfenstein 3D" engine in DOS, then up to a simple DirectX game (Tetris) in Windows and finally a full 3d game engine with its own integrated editors, plugins etc. This has really been perfect for both of us and we probably owe each other the fact that we now both have jobs in the game industry (actually in the same company) :) But if you are already at an advanced point on the "art side" and "team up" with yourself as a programmer at the "Wolfenstein in DOS" level - then it just won't work out! But if you are skilled as an artist and have nice ideas - then I'm sure you can find an equally skilled programmer to help you with your visions. Whether or not my words sounds like wisdom I'll leave for you to decide - but those are the words I'll offer :) - Kasper
14. ## Skeletal Animation Question

Yeah, I'm having a hard time keeping the bone count down - our animators basically just wants as many as its technically possible for me to handle :) Since I'm doing skinning in vertex shaders I had to impose an upper limit of 70 bones and they kinda accepted that (with some grumbling :) Anyways, Alex, since you brough up the topic of terminology; You can think of skeleton animation as consisting of two parts - animation and skinning. Animation means the setup of the bones... you animate those based on some recorded animation track (key frames) from some animation tool. Once you've animated the bone setup you 'apply' them to a mesh - this is called skinning. So animation is the first step you do and it will always happen on the CPU. Skinning, on the other hand, can be done either on the CPU or on the GPU using a vertex shader. If you do the skinning on the CPU you don't have to pack any special data into your vertex format but if you're using a shader you'll have to pack the weights and skinning indices into the vertex format somehow. - Kasper
15. ## ellipsoid normals

The normal to a point on a regular surface (like an ellipsoid) can be found like this: N(p) = (f'x(p), f'y(p), f'z(p)), where f is a function for all points on the surface. If f is the function f(x,y,z) = (x^2/a^2 , y^2/b^2, z^2/c^2), where (a,b,c) is the radii of an ellipsoid then the set A = {(x,y,z) | f(x,y,z)=1} defines all points on the surface of the ellipsoid. From the above we see that we have to differentiate f: f'x(x,y,z) = 2x/a^2 f'y(x,y,z) = 2y/b^2 f'z(x,y,z) = 2z/c^2 So the normal to a point on an ellipsoid is: N_ellipsoid(x,y,x) = (2x/a^2, 2y/b^2, 2z/c^2) You might want to normalize that though... For fun you might notice how this also works for a unit sphere (where a=1, b=1 and c=1). In this case the formula becomes: N_sphere(x,y,z) = (2x/1, 2y/1, 2z/1) = (x,y,z) So the normal to a point on a unit sphere is the same as the vector going from origo to the point on the surface - which makes sense doesn't it? - Kasper