When you import the GameCircle Unity package, Unity will override existing files in your project with those in the package. Before importing the GameCircle Unity package, review the list of included files and compare this list with your current project to check for overlap. If a file exists in both your project and the package, verify that any changes you have made locally are backed up somewhere outside of your project.
okay, GameCircle for last.
I just couldn't expect Amazon to provide any better anyway
C# also has multi-dimensional arrays (Color[,] has two, for example), though I couldn't tell you if they're better or worse in terms of runtime and locality in comparison to arrays of arrays (Color[][]). Profile for yourself when you end up needing them, I guess.
@Lasse OpenGL ES 2.0 requires you to assign the same normal over and over again for each vertices. With regular OpenGL you can get away with having an indices buffer which indexes both the vertices and normals. But OpenGL ES 2.0 on indexes the vertices so you basically have to duplicate your normals.
Should I be embarrassed of how little I use arrays? I just like working with lists much better. The exception is when I can do some fancy index manipulation to get the logic down that I want. For example if I'm representing a grid then arrays make a little more sense logically.
In the most general sense, no. OpenGL and Direct3D only allow one index per vertex; the index fetches from each stream of vertex data. Therefore, every unique combination of components must have its own separate index.
So if you have a cube, where each face has its own normal, you will need to r...
It says there that using it like that it would decrease performance
Yeah, @Lasse I don't know whether they've changed it for the recent versions of OpenGL though. I wrote an object loader about 2 years ago that had it like that.
@ToddersLegrande Three reasons: First, Tuple is a class, so creation of one (for inserting and querying the values) is rather expensive. Second, Directory uses hashes to speed and generalise lookups, which means lookups are way slower compared to the two FMAs a two-dimensional array represented as one memory block has to do ((sizeX * x + y) * sizeOfValueClassOrStruct + baseAddress). Third, with an array you at least have a chance to keep all the data in the same memory block ...
@MartinSojka The second was the one I was pretty sure of. Hadn't considered the third one. I was thinking the first but wasn't sure. That being said, technically its all preoptimization :P
But it is situational in the mobile domain I think. If memory constraints weren't an issue for the mobile domain I'd be more inclined to use a 1:1 relationship for my vertices and normals.
But as it stands you either want performance or memory and the memory option isn't supported. T.T
Thinking about it further since Tuple IS a class we would have to new Tuple() everytime we wanted to access an item in the grid... UNLESS WE STORE THE TUPLES IN ANOTHER DICTIONARY :O
jk
There's probably a better way than using Tuples that still leverages a dictionary... I dunno
It is not that costly if you have like 20 objects on screen and move camera a bit and one or two more appears, which would be comparable to updating vertices of a lot of particles
You'll have to translate your eye position to the light source and orientate the camera to look down at the scene. You then have to produce a map based on the z coordinates from the light source to get your shadow map.
The projection matrix has always gone over my head slightly and I've always resorted to using similar triangles to get my perspective to work when I'm writing a 3D engine from scratch.
I am struggling on how to calculate this, such that the blocky-ness is the least, or put otherwise, such that I can use an as low as possible resolution
The left, right, bottom, top, near and far should be the same as your perspective projection. What is different is how the matrix handles these values.
In the link I gave you there are 2 matrices. One perspective matrix and one orthogonal matrix.
All (left, right, bottom, top, near, far) defines is your viewing frustum (What sits in the camera's view) those values are then transformed into a projection matrix. At least that is how I understood it.
user4704
4:43 PM
(the term "orthographic" does, but an orthographic projection matrix isn't necessarily related at all)
This is an amazing article, and I think everyone should read it when they get the chance. It mostly has focus on politics but it's still related to games. Events related to games after the Sandy Hook Shooting.
user4704
5:10 PM
@skiwi You don't need an AABB.
user4704
The parameters to the method that constructs your ortho projection matrix are the top, left, bottom, right, near and far clip plane coordinates.
user4704
You just need to compute those. You should have most of them.
The same as what? I'm using an fps view (eye, roll, yaw, pitch) and perspective projection (fovy, aspect, near, far) - Not using (left, right, bottom, top) anywhere else
There is a perspective projection function for left, right, bottom, top. You've used the overloaded version which just takes in fovy and aspect instead.
user4704
A frustum and a matrix are two different things; you can't assign a frustum to the projection matrix.
user4704
5:37 PM
You can compute a matrix from a frustum (or the other way around).
All left, right, bottom, top, far and near define is your frustums size. Those values get put into the matrix and the frustum is created from the matrix.
Yes. An orthographic projection won't take into account perspective and as such the object will be the same size no matter how close or how far it is away.
void Function( int, char )
versus:
void Function (int,char)
My friend keeps saying otherwise. What is objectively the best way to write brackets?
