next »

[oahda]

So what's the job you're getting paid for here? What is this particular implementation going to be used for?

Thanks for making me aware of both 2D and 3D libraries that exist!

[RandyGaul]

That's cool! I can see many uses for that. Would you care to elaborate a bit on the technical details?

M'self I'm a happy programmer today for having gained an increasing understanding of shaders – supports for which I just recently added to my game/engine – and have managed to add lights as well as a wobbly water effect to the (underwater) game! Also a bit of general ambient colouring, of course. Particles for floating algæ will supposedly be the next big shader thing I add!

By far the easiest implementation uses BSP trees. Each node in the tree represents a plane. A fully constructed tree encodes information about what geometry is on each side of every triangle (or polygon) in a mesh.

Then you can perform an operation on two trees together through a recursive step. The step you take ends up defining what kind of operation is performed. Common ones are intersection, union, and subtraction.

[BorisTheBrave]

It's the lib which Blender uses. Unfortunately, it's LGPL and therefore incompatible with Assimp's ZLIB license.

Uh? My understanding was that you'd have your LGPL code silo'd off in a shared lib, then you could use what license you liked for the rest.

[Schrompf]

So what's the job you're getting paid for here? What is this particular implementation going to be used for?

There's a cool company that wanted a new file format in Assimp. I only came to it later when the original coder wasn't available anymore, I'm tasked to fix some bugs in it. We agreed on a sub-standard hourly rate because the code is publically available for everyone under Assimp's standard license.

Indie game development doesn't pay, so I need to earn my money otherwise.

Uh? My understanding was that you'd have your LGPL code silo'd off in a shared lib, then you could use what license you liked for the rest.

I'm not an expert by any means. I *thought* that LGPL allows linking dynamically (.dll or .so) without polluting your code with its license. In my understanding that would require bundling the lib with prebuilt binaries for all platforms we support. Which are a lot. Not feasible.

[Sik]

I think it was understood backwards. You can use Assimp in a program that's LGPL, but you can't add LGPL code into Assimp (it's actually more complex than that but let's not get into the loopholes). If anything the real question is whether it's OK for the program using the libraries to use LGPL'd code.

[BorisTheBrave]

I'm not an expert by any means. I *thought* that LGPL allows linking dynamically (.dll or .so) without polluting your code with its license. In my understanding that would require bundling the lib with prebuilt binaries for all platforms we support. Which are a lot. Not feasible.

Ok, I misunderstood slightly, I see now you are modifying Assimp, not writing an application that depends on it. But I think the answer is the same. No, you don't need to distribute prebuilt binaries, that's merely the most common use case. You *are* required to enable any end user to freely modify the LGPL bits while keeping the rest of the program the same. For any FOSS library, that is pretty much true by default as the user has control over the entire build process.

For example, consider Eigen. It is MPL licensed, except for certain bits taken from other projects that are LGPL. As they are optional to the core functioning, they provide a macro to disable all LGPL parts as a convenience.

That said, there's still a lot of value in not including LGPL dependencies, as the license will effect any users of assimp. They'll still have to worry about dynamic libraries, and include various bits of license text with their programs.

[jethro.]

Got it right for the first time when instead of sending the position of instances , I send the whole transformation matrix for each instance. (Okay, second time, but I just had to transpose the matrix..)

For anyone asking: I'm using instanced drawing of 3d tiles in OpenGL. Couldn't find a better way to draw 10000+ tiles with 60 fps.

[Geti]

Depends how high poly the tiles themselves are + if they do or dont share materials but you could batch chunks of them into VBOs in some 3d grid (8x8x8 chunks perhaps).

[kverkagambo]

It happened several months ago, but I have to share this:


My first try to understand Bresenham algorithms and first try at programming in Game Maker. It all worked fine and I was happy.

[Kyle Preston]

Tis a good feeling isn't it; congrats on getting through bresenham algorithms.

I finally got my large animated backgrounds to play nicely in the game engine without crashing constantly (without saving btw). Havin a cup of tea to celebrate!

[jechadwell99]

I just finished getting my tweening system working properly. Now I understand what all those articles online were trying to say.

 

[TheLastBanana]

I'm mucking around with an entity-component-system engine that I built. I finally got some time to work on it this week, so I got to work on collision detection!



The engine uses a fixed timestep, but I wanted to go the extra mile and make sure that collisions are as accurate as possible. Each step, I keep track of where a collider currently is (green circles) and where it's going to move next step (red circles). If it's going to move in a discrete jump (magenta line), then it'll be considered stationary for this timestep. Otherwise (yellow lines), the collision system checks the entire path it sweeps for collisions with any other circle's path (cyan circles) using this algorithm as a base.

Once the times of all the collisions are determined, the list of collisions is sorted and they're resolved in chronological order. The colliders call any callback functions attached to them and each of those callbacks returns a set of any entities which had their states changed in the process. The collision system then re-runs collision detection for any collisions which may have been affected by those changes before it continues to resolve the collisions, meaning an entity could change direction or stop moving in response to a collision and everything will still work out nicely!

As it turns out, MSVC's STL iterators are ridiculously slow in debug mode, which is kind of problematic given that my ECS implementation relies on hashmaps at a low level to retrieve components. I spent a bunch of time refactoring the collision system so that it could run the debug test shown above (30 objects) at a reasonable speed and pushed it from <1 FPS to a solid 60 FPS. In release mode, it can handle about 150 collisions per time step at 60 FPS, which is way beyond anything I'm planning to do with this engine. So I'm pretty satisfied with the results!

[Geti]

That looks great TLB!

Re: MSVS STL slow in debug mode - sure is, we swapped to EA's implementation a while ago and saw improvements in both release and debug so might be worth looking into

[Canned Turkey]

degree=-degtorad(point_direction(myPlanet.x,myPlanet.y,x,y));

I think I spent about 4 strait hours figuring out this one line.
This is the first time I've been happy about a piece of code.
Circles r hard.

[Layl]

degree=-degtorad(point_direction(myPlanet.x,myPlanet.y,x,y));

I think I spent about 4 strait hours figuring out this one line.
This is the first time I've been happy about a piece of code.
Circles r hard.

Have you considered switching entirely to radians to simplify your code?

[surt]

I presume that a function named "degtorad" would return a result in radians but you are storing that result in a variable named "degree". 

[Siesatia]

My path-finding algorithm crashed and burned I started over from scratch. A couple hours later I've got something that is (Mostly) working, so feeling pretty good.

[Canned Turkey]

Have you considered switching entirely to radians to simplify your code?

I presume that a function named "degtorad" would return a result in radians but you are storing that result in a variable named "degree". 

Both these problems come from using someone else's code, they had a really nice system for rotating around a point with a fixed radius, but he had used trig and radians, two things I still don't fully understand.
I was trying to figure out where to start the rotation based on the players coordinates, and this was the line to do that math.

[ThemsAllTook]

trig and radians, two things I still don't fully understand

These are simpler than they might seem. Radians are the same thing as degrees on a different scale; 180 degrees is equivalent to pi radians. Some people describe trigonometry in terms of triangles, but I've always found it much easier to understand in terms of circles. Here's a somewhat-hastily-made diagram:



Radians describe the angle of the line being measured from the center of the circle to its outer edge. The cos() and sin() functions compute x and y coordinates at the edge of the circle, assuming a radius of 1. The tan() function measures the slope of the line.

To get more of a feel for the numbers: The result of sin() starts at 0, initially rises quickly as radians increase, then slows down as it reaches 1 at half pi radians. As radians continue toward pi, sin() starts decreasing slowly, then more quickly as it goes back to 0. The same thing happens in the negative as radians continue around from pi to double pi.

The result of cos() starts at 1, starts decreasing slowly as radians increase, then decreases more quickly as radians reach half pi. It then decelerates toward -1 as radians reach pi. The process reverses as radians tick over to double pi.

The result of tan() increases slowly from 0, then accelerates toward infinity at half pi. It then decelerates from negative infinity back to 0 as radians reach pi.

sin(), cos(), and tan() take radians and return a coordinate. asin(), acos(), and atan() take a coordinate and return radians. atan2() takes two coordinates and saves you the trouble of dealing with negatives and infinities to compute the inverse of tan().

That's trig in a nutshell.

[gimymblert]

Also mental shortcut, whenever you see pi thinks half a circle, 2pi = one circle
So any fraction of pi (you see angle express in them a lot) became a fraction of half a circle.

Another shortcut is to define tau = 2pi
now any fraction of tau = fraction of a circle
So when you meet a fraction multiply it by 2 then you will have a new fraction that is exactly a fraction of a circle which is easy to visualize.



Things will make sense intuitively faster



SO rad can be understood as fraction of pi