Posted by Khatharr
on 13 September 2013 - 06:26 PM
Stroustrup actually says that vectors are more efficient overall. Apparently the savings in insertion and deletion just don't add up to the cache misses that occur when traversing the list, or even the element search time to reach the insertion/deletion point. The vector can find an element and shove its data up or down very quickly, but the linked list takes a lot of cache-inefficient time to reach the element, and that outweighs the disadvantage of the shove.
Posted by Khatharr
on 09 September 2013 - 03:22 AM
3D spaces are not typically represented by grids of elements that contain one or zero objects. A 3D "space" is theoretically composed only of its terrain collision information. Each entity contains its own data on its position and rotation. You have to tell the game explicitly how to prevent the entity from overlapping solid parts of the world, and you have to tell the game explicitly what to do if one entity has similar position data to another entity.
You can do the same in a 2D space. Make a small tilemap and then have a 2D array of collision values for the tiles (true = passable, false = solid, etc). Then add entities that contain their own position data. You have to explicitly code in the collision testing: you have to tell the game that if the player tries to move to a tile that is 'solid' then it shouldn't be allowed, and you also have to tell it that if another entity is in the way, don't allow the movement. The tiles are not containers for the entities.
Posted by Khatharr
on 03 September 2013 - 06:14 PM
It also largely depends on how polished the product that you want to ship is. Usually its the polish that consumes the most time out of anything, and its also probably responsible for how well your customers receive your game to a very large degree. Having done most of it a few times, I can probably knock together a very functional console-style JRPG in 3 months or so if I were able to dedicate myself full-time to it. But for me to get from there to a product that's really polished in terms of its implementation, together with the *game* and its assets polished to a reasonably degree is probably another 9-18 months time, depending on the number of playable hours I hope to provide.
A polished game usually takes about 4-10 times longer to make than does a stable and mostly feature-complete prototype of it.
Aye. It's like sculpting a statue. The shape emerges quickly, but the details take forever.
Posted by Khatharr
on 01 September 2013 - 10:35 PM
That's actually easier. Just atan2 the point and check which area the angle is in. If you need to know whether it's inside the radius then that's just Pythagoras. You should probably run Pythagoras first to see if it's inside the circle, then if it is you can atan2 to determine the angle.
1) Don't assume that one or more cores are not in use in the background by the OS and improving your performance by not making the core you're using wait.
2) THREAD LIGHTLY. Threads open up the way to all manner of possible problems, and implemented naively they can and will harm performance rather than helping it.
3) General concurrency is a better perspective for taking advantage of multiple cores. Threading is not the only means of implementing concurrency.
4) Do not prematurely optimize. If you have no performance issues then don't waste time fixing what isn't broken, especially at the cost of consuming additional system resources.
5) In simple games, audio processing is a good first target for threading, since it generally does not need to interact much with the main program. You can simply send messages to the audio thread to control it like a jukebox.
6) Network updating can be used with threading, but it's not completely necessary. If implemented incorrectly this can cause excess work with no performance gain, so again, make an informed decision rather than just threading because you can.
Threading is one of those areas where you really want to spend the time to learn about all the features, quirks, and potential pitfalls before using it in a project. It often creates a lot of code work and can so very easily backfire either by causing hellaciously difficult bugs or just by doing everything correctly but ending up harming performance rather than helping it due to resource contention. I'd recommend picking a thread library, getting familiar with all of the available features, then using that as your jumping off point for studying articles about good and bad uses of threading, paying close attention to the reasons why the bad things are bad.
Of course. I'd like to understand cache effective strategies anyway, though. Firstly because it's interesting and secondly because if I ever do see a bottleneck of this nature I want to have some ideas about how to deal with it.
I was asked by an obnoxious dick some time ago at a project defense how many lines of code I had contributed to the project I was working on, which was a question I was in no way prepared to answer because I had absolutely no idea, nor a mechanism of finding out. I told him I had no idea, but a random guess would be in the ball-park of 20K of code written in areas that didn't exist prior to my creating them. He just sighed and rolled his eyes at me like I just admitted to doing nothing for the whole time I was there, and used that as justification for trying to give me a bad review.
Should have just told him I wrote a billion lines. What an ass.
The correct response in that situation is, "This is a stupid question, sir. Are you a stupid person, or are you asking questions on behalf of a stupid person?"
The question is analogous to asking a geneticist how many kilograms of DNA they've worked with.