Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2010
Offline Last Active Today, 01:52 AM

#5095653 [SOLVED] Receive data into a buffer.

Posted by Khatharr on 20 September 2013 - 08:36 PM

A circular buffer isn't a bad solution, but it can be a little overkill in some cases. For something like this, you'd read until you had a full package, process it, then continue reading into the buffer at the position where you left off until you either have a complete package to work or else you reach the end of the buffer. When you hit the end, you just start reading into the beginning again (hence the 'circular'). You have to keep close track of what data is 'live' and what data is processed, so that you don't accidentally overwrite live data.


You'll end up moving data in either case, but the circular case will defer some of that so that you only have to do moves when you cross the end of the buffer (to reconstitute that package for processing). Circular buffers are usually used in a producer/consumer situation. The socket would produce and some other process would consume the data as needed.


In many cases you know how much you need to read, though. What's your use case here? Or are you just asking for general knowledge?

#5094170 c++ combat code

Posted by Khatharr on 15 September 2013 - 01:56 AM

Well, what he posted doesn't work right, so I guess the joke's on the communists.

#5093907 practica usability of linked lists

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.


#5092657 How do in-game player characters take up space

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.

#5091448 slow speedup of cpu's ?

Posted by Khatharr on 03 September 2013 - 06:17 PM

Waiting for my quantum holocore CPU....

#5091446 As a one man team, would it be possible to make these kind of games?

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.

#5091104 Stupid noob questions regarding radius...

Posted by Khatharr on 02 September 2013 - 02:38 PM

Are the values in 'arcPlayerList' correct?


What the hell is 'rangeIsOk'?


Are you aware that the && operator can combine conditions?

#5090932 Stupid noob questions regarding radius...

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.

#5090845 Stupid noob questions regarding radius...

Posted by Khatharr on 01 September 2013 - 01:44 PM

x = sqrt(L) * cos(angle);
y = sqrt(L) * sin(angle);


That totally looked wrong at first glance. Interesting.

#5090537 multi-thread

Posted by Khatharr on 31 August 2013 - 01:25 AM

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.

#5090320 Understanding Cache Utilization

Posted by Khatharr on 30 August 2013 - 01:31 AM

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.

#5089219 passing std::shared_ptr to a function?

Posted by Khatharr on 26 August 2013 - 11:09 AM

What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

#5089099 passing std::shared_ptr to a function?

Posted by Khatharr on 26 August 2013 - 12:33 AM

        catch(std::exception e)
            const char *wat = e.what();
            int i = 0;


'wat' indeed.

#5088125 collisions? n^2 checks?

Posted by Khatharr on 22 August 2013 - 10:14 AM

If you avoid double-checking then you only have 4,950 checks rather than 9,900.


Apart from that, some simple broad-phase tests can cut down on work if your collisions are complex. Just don't do more work eliminating work than the work that it eliminates.




You know what I mean.

#5087314 about lines of code

Posted by Khatharr on 19 August 2013 - 09:39 AM

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.