# godplusplus

Member

12

102 Neutral

• Rank
Member

2. ## Cube-Cube collision detection

Hi! Ok, so, the rotated box you're talking about is called "OBB" (oriented bounding box). I don't have an AABB to OBB function handy at the moment, since I've never used it, but that's the keyword you're looking for anyway. Now, a small comment regarding your code... You could put all those checks in one line. Basically, something like: return (valueInRange(A.x, B.x, B.x + B.width) || valueInRange(B.x, A.x, A.x + A.width)) && (valueInRange(A.y, B.y, B.y + B.height) || valueInRange(B.y, A.y, A.y + A.height)) && (valueInRange(A.z, B.z, B.z + B.depth) || valueInRange(B.z, A.z, A.z + A.depth)); It will be faster, since there will be lots of early outs, instead of having to create 3 bools, calculate all of them and then check them. If you could, however, try using Lewis's version, it has less checks than the whole valueInRange thing. And it could be done even faster by doing: return (A.bbMin.x <= B.bbMax.x) && (A.bbMax.x >= B.bbMin.x) && (A.bbMin.y <= B.bbMax.y) && (A.bbMax.y >= B.bbMin.y) && (A.bbMin.z <= B.bbMax.z) && (A.bbMax.z >= B.bbMin.z);
3. ## Move to target

I know the question has been solved, but I just wanted to add: you have a potential division by 0 in case the length of the vector is 0 (ie. if the mouse clicks the player or very close to the player, since len is an integer). Then again, I don't know what type of game this is (maybe the mouse is never allowed to click close to the player or something), but just thought I'd point it out
4. ## Game Programmer's Portfolio

Hi! So, when I started looking for a job in the game industry, I was about to graduate from my Game Development BS, so I didn't have any job experience in the industry. I was looking for an entry level position, you know, a generalist programmer. You can take a look at my portfolio: http://www.miguelcas.../portfolio.html I decided to put all my game projects, even though they were for University, so I could show that, even though I didn't have job experience, I had been making games for quite a while (from small, crappy 2D games, to bigger 3D games). Now I had the chance to add an actual Industry game to my portfolio. Take a look at it, maybe you can get some ideas from it. Hope it helps! PS. If anyone else has any feedback on my portfolio, any comments are welcome, I know that there are always things to improve on it.
5. ## Triangle Mesh Collision

Funny how you completely disregard my suggestion of, you know, using spheres instead of aabbs (you know, me trying to help out, since by your wording you made it sound like you didn't know how to do a BVH and I was gonna offer my help, even sample code) you instead go directly at my comment of how your definition of brute force is flawed. Anyway, good luck in finding that magical algorithm that checks two triangles at once (short of checking two triangles on two threads).
6. ## Triangle Mesh Collision

I don't know why you would say a bounding volume hierarchy is "brute force". Brute force would be to test each triangle without any attempt to minimize the number of triangles to test. So, what are you going to test against the triangles? Are you gonna test spheres? Depending on what you're going to test is the volume you should use for your hierarchy. Many people just go for the "hierarchy of AABBs", but this one is not necessarily the best or the most efficient. Depending on the shapes of the meshes and what they are testing against. For spheres, you may be better off testing against a hierarchy of spheres, since sphere to sphere collision is faster than sphere to AABB collision. For a game I made last year, I used a spherical BVH and it worked really well to calculate collisions with spheres, rays and line segments. But yeah, I doubt the whole process of creating a BVH is a "brute force" approach.
7. ## To goto or not to goto?

I work mostly with C++, objective C or other languages that are not "pure C". I never had the need to use a goto statement, the reason is that there are usually other ways to do things, at least in these languages. So, goto statements never really cross my mind as alternatives anyway. The thing about goto statements is that they are easy for the computer to understand, after all, when code is compiled into assembly language, everything becomes a bunch of goto (jump) statements (basically, yeah, in assembly language, goto is the only way to go. See what I did there?). However, we humans are more prone to messing up when doing a goto statement. I don't think using goto is necessary, at least in the languages that I use. But if it really makes you feel better (or worse?), remember that your code will eventually be compiled into more goto statements than you can imagine.
8. ## Help optimizing insertion sort in asm x86

This function wasn't a separate function, I just had it in the main code, and I had two arrays (an unsorted one that was gonna be kept in order to test it with the different algorithms) and a second array that would be sorted and printed out, so I just called it "vSortedArray". The current index thing is because I'm using that variable in the code as well (the whole thing is a windows forms program that allows to add numbers to the list, reset the list, choose which algorithms to use, etc). That's the reason the variables are named like that. If I were to put this as a separate function, of course I would rename it, but for here I just copy pasted and made a fake function header. I'll edit the post to make the names more readable. Anyway, back to the assembly… What's wrong with pushing and popping inside the loop? I thought it would be a fast thing, after all, I'm also doing it in my other sorting algorithms and it didn't cause a performance issue. About the cache thing… I already tried different combinations, I tried combining different array sizes with different loop sizes, I even tried using different numbers for the possibilities of numbers within the array (in order to test arrays with many unique values and arrays with lots of repeated values), and the difference in performance was the same.
9. ## Help optimizing insertion sort in asm x86

Here's the C++ code: void InsertionSort(int* vArray, int nNumElements) { int j(0), key(0); for(int i = 1; i < nNumElements; i++) { key = vArray; j = i-1; while((j>=0) && (vArray[j]>key)) { vArray[j+1] = vArray[j]; j--; } vArray[j+1] = key; } } The test is simple, I make an array with 10,000 random ints, then sort it and time the function. This test is run 100 times and the average time is calculated.
10. ## Help optimizing insertion sort in asm x86

Yes, I did. It looks quite similar, except that it has more MOV operations than mine and the for loop is done in a different way (that I can't really understand). I tried my code in a different computer and I realized that, even though it's still slower than the C++ version, the percentage of difference is quite contrasting. In one computer the difference is of more than double, while in the other one the difference is just about 15%... Which is kinda baffling.
11. ## godplusplus

I worked on Cosmic Mischief, but I haven't heard anything about those rumours #FSGD
12. ## Help optimizing insertion sort in asm x86

Good question. I forgot about EDX at that moment. Anyway, I made the change and used EDX for the key but there was no difference in the performance unfortunately.
13. ## Help optimizing insertion sort in asm x86

Hello everyone! I was doing some sorting algorithms in asm x86 (gnome sort, insertion sort and quicksort) to sort some ints based on c++ versions I made of them. They all work, and I wanted to test them against my C++ versions to see if I had managed to make my asm x86 versions faster (or, at least, as fast) as my C++ versions. My gnome sort and quicksort are pretty much the same speed as their C++ counterparts... But my insertion sort is waaaay slower than my C++ version. If someone could please look at it and tell me any ideas to make it faster, or at least help me find out which part is slowing it down so much. Here's the assembly code I wrote: .386 .model flat, c .code ;Code by Miguel Casillas. ;This code can be used and reproduced, please give credit ;void InsertionSort(void *pArray, int nItems); InsertionSort PROC ;These registers must be restored at the end push EBP mov EBP, ESP push EBX push ESI push EDI ;EBP + 8 is the array ;EBP + 12 is the number of items in the array ;setting ECX to the number of items ;we multiply by 4 (size of the element) in order to put ECX ;at the last address of the array mov EAX, [EBP+12] mov ECX, 4 mul ECX mov ECX, EAX ;We will move 'i' and 'j' in increments and decrements of 4, ;which is the size of the elements mov EAX, 4 ;EAX will be our 'i' xor EBX, EBX ;EBX will be our 'j' (setting it to 0) mov ESI, [EBP+8] ;ESI is the array MainLoop: ;If 'i' >= the number of items, exit the loop cmp EAX, ECX jge EndLoop ;Save our "number of items" value, we will restore it later push ECX ;ECX is now our "key", so, ECX = array mov ECX, [ESI+EAX] ;j = i-1 mov EBX, EAX sub EBX, 4 EnterWhile: ;If j < 0, exit this loop cmp EBX, 0 jl EndWhile ;If array[j] <= key, exit this loop cmp [ESI+EBX], ECX jle EndWhile ;array[j+1] = array[j] push [ESI+EBX] pop [ESI+EBX+4] ;j-- sub EBX, 4 ;Go back to the top of this loop jmp EnterWhile EndWhile: ;array[j+1] = key mov [ESI+EBX+4], ECX ;i++ add EAX, 4 ;restore our "number of items" value pop ECX ;Go back to the top of the main loop jmp MainLoop EndLoop: ;Restoring the registers pop EDI pop ESI pop EBX pop EBP RET InsertionSort ENDP END If you can help me out, I will really appreciate it!!!