The search index is currently processing. Leaderboard results may not be complete.
1. ## GoliathForge

GDNet+

2

• ### Content Count

544

2. ## lawnjelly

Member

1

• ### Content Count

977

3. ## Irlan Robson

Member

1

• ### Content Count

631

4. Member

1

307

## Popular Content

Showing content with the highest reputation on 05/04/19 in all areas

1. 1 point
Keeping up with the twitter hashtag of screen shots on Saturday!
2. 1 point
Definitely not the way I would simulate a car crash but I would try to decrease the streching stiffness after detecting such a crash in order to make the car more soft for a couple of seconds, then would restore the stiffness value to bring back the car to the undeformed configuration. It seems that the streching stiffness in your code is 0.005, but it could be a relaxation factor, so I don't know. Anyway your position-based solver loop would look something like this: void b3Cloth::Step(float32 h, u32 iterations) { if (h == 0.0f) { return; } // Damping float32 d = exp(-h * m_kd); // Integrate using semi-implicit Euler for (u32 i = 0; i < m_pCount; ++i) { b3Particle* p = m_ps + i; p->v += h * p->im * m_gravity; p->v *= d; p->p0 = p->p; p->p += h * p->v; } // Solve position constraints for (u32 i = 0; i < iterations; ++i) { SolveC1(); } // Estimate current velocity float32 inv_h = 1.0f / h; for (u32 i = 0; i < m_pCount; ++i) { b3Particle* p = m_ps + i; p->v = inv_h * (p->p - p->p0); } // Solve velocity constraints (e.g. friction, etc)... } void b3Cloth::SolveC1() { for (u32 i = 0; i < m_c1Count; ++i) { b3C1* c = m_c1s + i; b3Particle* p1 = m_ps + c->i1; b3Particle* p2 = m_ps + c->i2; float32 m1 = p1->im; float32 m2 = p2->im; float32 mass = m1 + m2; if (mass == 0.0f) { continue; } mass = 1.0f / mass; b3Vec3 J2 = p2->p - p1->p; float32 L = b3Length(J2); if (L > B3_EPSILON) { J2 /= L; } b3Vec3 J1 = -J2; // m_k1 is the streching stiffness in [0, 1] float32 C = L - c->L; float32 impulse = -m_k1 * mass * C; p1->p += (m1 * impulse) * J1; p2->p += (m2 * impulse) * J2; } } Hope it helps.
3. 1 point
Any 32 bit hash is going to have a high chance of collision, and should therefore be avoided. With as few as 9300 assets, there is already a 1% probability of a collision, assuming an ideal hash function.
4. 1 point
5. 1 point
Lots to do. I feel I have a decent setup ready now and some basic communication going on. For the sound system, I went with a companion module in the series I'm currently following. It was nice after cleaning up the implementation and tweaking it slightly to act as I wanted. Copied and tweaked a couple of instruments, wrote two bars of music that worked well wrapped, turned an instrument concept into a game effect and we were off and running. Still focusing on the challenge requirements because, well my game idea is a little weak but that is not the point. Thank you for the challenge opportunity. I know some decent game play will come out if I stick with the basic ground rules. (and maybe a twist in there somewhere) head scratching over here. But here's what my input strings look like for my music format. // Author : mark kughler (goliath forge) // Lick : Do Diddley |_............_||_............_||_............_||_............_| std::string strKick = "X..X....X.......X..X.....X......X........X......"; std::string strSnare = "......X.......X.......X.......X.......X.......X."; std::string strHiHat = "..X.X............XX.........X......X........X..."; std::string strCymb = ".........................e..X..................X"; std::string strBell = "......c...e...g................................."; std::string strHarmon3 = "b.............c.......b...............b.......e."; std::string strHarmon2 = "e.....................e.....d...........g...c.c."; std::string strHarmon = "............................a.......a.b........."; // lower case notes (c major) - upper case sharp // c = c d e f g a b c // d = d e F g a b C d // e = e F G a b C D e // f = f g a A c d e f // g = g a b c d e F g // a = a b C d e F G a // b = b C D e F G A b Moving Forward...
6. 1 point
Not an expert and just self teaching me game programming. I had a similar question a few weeks ago, and following this i implemented that what you called alternative. They call it "Radar Approach". In principle, you can frustum cull in view or in clip space, this is view space. Dragging planes around for complex tested didn't sound very effective to me, but i may be wrong. From the above tutorial, here's the frustum method (OpenGL) to call when fov changes (angle, near/far plane). It intakes angle in y and calculate the x value via the ratio. void ViewFrustum::setFOV( const float angle, const float ratio, const float nearD, const float farD ) { m_ratio = ratio; m_nearD = nearD; m_farD = farD; m_angle = glm::radians( angle ); // compute width and height of the near plane for point intersection test m_tangensAngle = tanf( m_angle * 0.5f ); m_height = m_nearD * m_tangensAngle; m_width = m_height * m_ratio; // compute sphere factors for sphere intersection test m_sphereFactorY = 1.0f / cosf( m_angle ); float anglex{ atanf( m_tangensAngle * ratio ) }; m_sphereFactorX = 1.0f / cosf( anglex ); } The method to call on cam movement (every frame, that is). void ViewFrustum::setCameraVectors( const glm::vec3 &pos, const glm::vec3 &front, const glm::vec3 &up ) { m_cameraPosition = pos; m_z = glm::normalize( front - pos ); m_x = glm::normalize( glm::cross( m_z, up ) ); m_y = glm::cross( m_x, m_z ); } Intersection tests are in the tutorial linked above. It works. But i am curious too if there is a better way :-)
7. 1 point
8. 1 point ## Benchmark for Search Algorithms in Common Games Development Data

Neither of these are always (or even often) true. Not knowing the hardware is rather common now with multiplatform being the norm. Hardware varies a lot and it is subject to change. Trying to make broad generalisations may have worked maybe 35 years ago but modern CPUs do all kinds of craziness, out of order pipelines etc, which are probably not public info. And what they do depends on what they are trying to optimize - speed, or power use etc. On top of that the best choice of algorithm often depends on the data itself, which is why compression for example might use different techniques depending on the data in a block. Generally the rule of thumb these days with any optimization is to do empirical testing, rather than come up with an a priori method. Computers are now complex systems, and hoping to plug in some values into a formula and come up with how well an algorithm will work on any particular hardware is often less practical than just trying the thing with some test data, and modifying the technique accordingly.
9. 1 point
I'm going to skip a blog week and just throw up a video progress. This week was character/animation controller. Nice to start thinking about the action bits. Thanks for playing.
10. 1 point
Thank you all for responses! You've been very helpful. Happily, I was given the opportunity to take the almost exact same role, but with C++. I accepted the offer obviously.