Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Online Last Active Today, 09:47 PM

#5300033 Finding that balance between optimization and legibility.

Posted by frob on 10 July 2016 - 03:23 PM

After crunching some numbers, I calculated that my cache hit was approximately 70%, so I'm thinking about keeping this example in my code for now (if not for the performance gain, then at the very least as a reminder).  


Given your usage pattern, and considering the size of the CPU's data cache on today's processors, this may work out well in your use pattern.  If you are frequently computing the trig functions on a small set of common angles, and you are doing it frequently enough that they stay local to the CPU instead of getting evicted from the cache, it will absolutely help.


But as others point out, keep measuring and monitoring.  


It looks like for now you are only using it where it makes sense. But add some debug blocks to your code to notify you when the situation changes.


If you reach the point where your comparisons are no longer in the cache, or if you are multithreaded and your writes need to be slowly propagated to all the processors, then you'll need to revisit your design.  If you start doing more operations on a wider variety of values, or values that are not quite identical, those could also trip your routine up.

#5300018 LibGDX Multi-touch finger index tracking

Posted by frob on 10 July 2016 - 01:16 PM

It looks like LibGDX does some slight behind the scenes and calls both IDs and indexes 'pointers', so you'll need to double-check with the code to verify the details of which one you've got.
Here is what happens in the raw, underneath LibGDX.
On Android devices there are pointers that generate MotionEvent data.  Each pointer can be a mouse, a finger, multiple fingers, etc. It is a potentially confusing name with some programming languages using the word pointer to mean the address of an object.  Here a pointer refers to something generating input data at a position.
Pointers have both a pointer index and a pointer ID.  Both are integers. 
Every time there is a new touch or pointer a new data structure is created. That data structure contains a unique ID.  Those data structures are placed inside an array of MotionEvent data, and the position inside the array is the index.  Between events and behind your back the system can move items around inside the array, which changes their index.  That is why index values may change between calls and should not be kept around between calls. ID values should remain the same between calls.  
The system provides convenience methods to switch between the ID and index.  getPointerId(int) takes an index and returns the ID of whatever value is in that array position.  getPointerIndex(int) takes a pointer ID and returns the index in the array, or -1 if that ID is not in the array.
Do not rely on index values, they are just array locations that are meaningless between calls.  If you need to track over time use the ID, which should remain the same between calls.

#5300009 Having 2 names, instead of 1 on a contributor agreement?

Posted by frob on 10 July 2016 - 12:40 PM

Written contracts generally are not there for when things are working out. While things are working the contract is in the file cabinet gathering dust.

The contracts are there for when things go bad.

When things go bad people start going back to the contract to figure out exactly who is responsible for what, exactly what must be done, and the exact details of who is responsible for what.

When a contract says multiple people are responsible for a single thing it gets complicated. Which person is responsible? If there are problems, which do you call upon? If things go extremely bad, which do you sue? Making to people equally and jointly responsible is possible, but the lawyer is right that it needs some specific language.

Making two people unequally responsible in an agreement with a third, so both are responsible for different things, would require a major revision to most contracts. It is basically two or three contracts between three people combined: contracts between A&B, A&C, and possibly B&C. Each with their own responsibilities, each with their own termination clauses. Don't do that, because if things get bad, it will be difficult to figure out exactly who is responsible for what.

#5298740 SDL Game Programming in C

Posted by frob on 01 July 2016 - 02:43 PM

They are either not in C or outdated


The "not in C" part you'll have to cope with because of your choice to use C rather than C++.  


The system by itself is C-based and all that knowledge can be directly used. Tutorials that use C++ stuff should be easily adjusted assuming you actually know C. Note that if you don't know how to program, picking a graphical game system like SDL is not the ideal place to learn the basics.  If you don't already know how to program in the language you should start simple, with 'guess the number', 'tic tac toe', and other simple games instead of complex graphical games.




That out of the way, what specifically do you want to learn about SDL that is not addressed in the links or contents of their wiki (https://wiki.libsdl.org/Tutorials) or documentation?


#5298581 Is using one the switch statement better then using multiple if statements?

Posted by frob on 29 June 2016 - 08:52 PM

Unless you've provided additional information for C++, it probably doesn't do anything to improve performance. It may for other languages that accept non-integer values or systems using JIT with profile-guided results or hotspot analysis, which Java is pretty good at, but most programs using C++ intentionally prefer the payment up front at compile time rather than a performance stutter on a live system.



If you know in advance one condition will be prevalent and the others rare, it should be pulled out with an if statement before the switch.  Note that "rare" should really mean on the order of many thousand to one, when 99.99% of the cases will result in a specific expected outcome. Some compilers and tools provide extensions like that, __builtin_expect() or likely() or similar, but those need truly be almost certain results  or they'll actually introduce performance penalties instead of benefits.




Unlike some other languages, in C++, a switch statement is just an integer table of blocks of code.  The compiler is free to heavily optimize it.  The language standard is very terse on the requirements, just six short clauses, so any optimization that keeps those requirements intact is legal.





Exactly how it gets optimized depends on the compiler and the specifics of the code in question.


Just because the C++ code falls through to another branch does not mean the compiler cannot unroll it for each value.  The compiler can unroll each value's flow into its own independent chunk of code if it wants to, or leave them consecutive to run into each other.


When there are only a few values and the commands inside each condition are small, the compiler may implement them as jumps exactly as they appear.  The compiler may decide an if/else chain jumping from condition to condition is the most efficient choice for that segment of code.


When there are many condition values and all the values are sequential -- even if they appear in a non-sequential order in the source code -- the compiler may turn them into a jump table. For example, if the range is 0-40 and all of them are used, and if x is the selected value, jump to the table value x condition and run it. If the range is something else, 2130-2190, subtract the lower number and do the same.  Jump tables are easy enough.


When values are wide spread and especially if they are not continuous, I've seen compilers build a binary searches of the values.  if value>73 jump here; if value>36 jump here; if value>18 jump here; if value>9 jump here, etc, quickly jumping with short forward jumps to find the correct condition in a way that is still friendly to the instruction cache. 


And the compiler may take a different approach as well, if the rules inside it say there is an efficient alternative.  


That's the benefit of using a compiler in the first place.  It does the right thing so you don't need to think about it.

#5298482 Dear people who actually work at videogame industry:

Posted by frob on 28 June 2016 - 07:57 PM

I have no idea about your location in the world.  Perhaps in your city university education is not a necessity.  Perhaps in your region few people finish their primary education.  But in that case, it means people in your area are not technically advanced.


When I review applications -- which I do frequently -- nearly every person has at least a bachelors degree. Some have links to a portfolio, many list their hobby projects.


You do not compete in a vacuum.  If there are other people who look better on paper or on the job application your portfolio will never be looked at.  


There are some people in the forum who live in regions where formal education is less important, or who did not get college degrees.  If you happen to live in one of those places where college or university studies are not required you should still finish your regular school education. 




I was thinking in leaving school, and then read books, forums and take classes of digital arts online, with books and forums like this, with the internet maybe i can learn more, and learn what i really want to, what is going to actually be useful in my future.


That is a terrible idea. Stay in school. Get the most education you reasonably are able. 


Stay in school AND read books AND read forums AND read technical papers.  If possible for you in your region, also go to university or college studies.


While you are reading material online and in books, talk to your school teachers and ask them to help explain topics as you encounter them.  


Take advantage of the opportunity you have been given.

#5298412 Best way to showcase C++ programming experience

Posted by frob on 28 June 2016 - 11:08 AM

Yes, apply anyway for entry level work.  Don't apply for the senior roles they are advertising.


Most entry level positions are not advertised since there is no need.  A little word-of-mouth discussion to key people and plenty of qualified applicants apply, plus unsolicited applications are always coming in.  They may drop the word at some nearby college campuses and online groups, but there is no need to pay for advertising for the position due to high applicant interest. 


It is better for you to work your social network if you can, find the friends or friends-of-friends who work in the industry and ask them about jobs and send in your application.  Even so, continue to submit your application to every company nearby.


You didn't state your location on the globe, but you might also consider moving to a game development hub if you aren't there already.  Companies usually do not pay to relocate entry level workers. Location is one of the first things observed when reviewing a job application.

#5298403 Is using one the switch statement better then using multiple if statements?

Posted by frob on 28 June 2016 - 10:33 AM


All major compilers take steps to detect the thing and replace it with alternatives that fit better with today's hardware.

An amusing possible consequence of this, which I haven't been bothered to test, is that if you code up a Duff's Device you may yet get better performance than if you code up some other hand-optimized, but misguided, alternative.  But the better performance won't be coming from the Duff's Device....



I'd guess the answer is no.  The rather infamous discussion from XFree86 (which used it extensively) found that the compiler's rewrite was generic and very large. Their own rewrites were far more compact.


The compiler makes a good general attempt at avoiding the worst-case scenario but the expansion is huge. Humans can do better by replacing the algorithm entirely with a better fit.

#5298342 Have I been aged out of the industry? And where else can I go?

Posted by frob on 28 June 2016 - 01:05 AM

No kidding - I over-simplified and omitted a large part of my intelligence-gathering operatus to avoid confusing you or boring you. ... The only help I need is to hack the minds of humanity so I can get past their prejudices. But very few psychologists are willing to share their knowledge in an offensive capacity.

With that, I take it we're all done with the "aged out of the game industry" and "looking for other fields where game development skills are useful" topics.



If the discussion here is even remotely similar to how you act in the workplace, I can assure you it isn't your age or software development skills that are keeping you unemployed.  Please seek professional help.

#5298338 Is using one the switch statement better then using multiple if statements?

Posted by frob on 28 June 2016 - 12:39 AM

... Duff's device ...


Duff's Device was an interesting optimization about 40 years ago when different conditions existed.


On today's hardware it introduces essentially the worst case pipeline stall.  All major compilers take steps to detect the thing and replace it with alternatives that fit better with today's hardware.


All optimizations depend on details of the system. Last year's details are different from this year's details, and next year's details will be different again.  


Many optimizations that were once fast now introduce problems.  Duff's Device, the XOR Swap, they're terrible on deeply pipelined processors.  Fancy memory tricks are terrible on new processors, while memory is faster than it used to be every new chip is relatively more faster, meaning memory access is more and more costly as time goes on. Calculating trig functions like sin() and cos() are faster than lookup tables thanks to relative speed differences, though the reverse was true on most processors about 15 years ago. Decrementing loops to continue when equal to zero hasn't been an optimization on x86 for two decades. Low memory addresses are no longer faster than higher ones and haven't been for nearly three decades. Writing to shared objects in continuous pools is absolutely terrible for cache coherency on multi-core processors, and hasn't been viable for speedups since the 1970s.  Manually marking every little function for inline compilation is usually a terrible decision in modern C and C++, it is typically better to provide information to the compiler and allow it to decide what works best with the target caches and memory performance for the target architecture.  (That last one is so bad most compilers now completely ignore the inline keyword unless you force them to.) Etc., etc., etc.


Yet all these little tips and tricks are still found in books and occasionally taught online as though they were gospel truth for modern software performance, never mentioning that the conditions that made them true have changed, and now they slow processing down.


... what prevents you from (options)? Too much more conforming or not? If not, why?  I am not bashing switch as is, I am just saying that an impotent c++ feature recomendation based on performace blasphemy is too ridiculous?


The performance difference in the general case is so small it doesn't really matter in the real world. 


If a programmer is in a situation where the performance of this condition is critical --- and I honestly cannot fathom such a case --- then they would probably not be using C++ switch statements for the code.


The famous quote applies here:  Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -- Donald Knuth


This is part of those enormous amounts of time.


Much has been written about this quote but it withstands the test of time.  Don't do stupid things that introduce inefficiences, don't introduce pessimizations, but almost always this is something you shouldn't bother with. If you have additional knowledge that the compiler doesn't, such as knowing that a specific path is highly likely, then do something that uses the knowledge. In that rare case, do something.  If you know you can avoid nearly all the work with a simple test, then do the simple test.  But don't worry about it.


The best advice I've heard for optimization is:  


Beginner: Don't optimize your code.  

Advanced: Don't optimize your code yet.

Expert: Don't optimize your code until you have proven with instrumentation that it needs improvement, then verify and document the changes for those who come after.



The vast majority of the time it just doesn't matter.  Your compiler is smart, and can find smart ways to optimize this.  The compiler may use jump tables, or a branching if/else tree, or a series of conditionals, or even a binary search. Next year's compiler may have additional techniques available and it may do something different.  Profile-guided optimizations may allow your compiler to recognize even more advanced things. ... But none of that typically matters to the programmer.  


I'm not saying make intentionally bad code, don't write bad code if you can help it. If you know something specific is a concern then write the simple version with a comment of //TODO: This is probably slow, measure it with a profiler someday.


If a person has chosen to use C++ then they need to let the C++ compiler do its job. That job includes optimizing the code.  Let your compiler do its job.



If (1) you are using C++ for you code and (2) you are concerned about the performance of a single switch statement, one of those two things is a flaw. Most likely you can find far bigger performance gains in other areas of the code by swapping out algorithms or fixing up data structures and access patterns.  Alternatively, if the performance is absolutely critical in this section and the implementation of a switch statement is paramount, then the development should be done in assembly language where you can control it rather than c++.



And since we're off track enough at this point, let's get back to the original with all these debates in place:




(1) I am currently learning C++ and I was just wondering if using the switch statement is better and/or a better and more efficient way of using multiple if statements?

(2) Is there advantages to using multiple if statements?

(3) If there is what are they?

(4)Are switch statements good in game development?
(1) Switch statements are a tool in the language.  There are many tools available for alternating behavior. See the above discussion. The efficiency of a switch statement is not typically a performance concern in the real world.
(2) If a switch would have worked but the programmer choose a series of if statements, that decision would be about specific control. If you have specific knowledge for a situation against it, a switch statement may not be the best solution. When the problem naturally fits a switch statement, use a switch statement. Note that a compiler might rearrange your if statements according to the optimization rules as allowed by C++, and might even implement it exactly the same as it would have implemented a switch statement.  Again, this is not typically a performance concern in the real world.
(3) There are many others options. Jump tables, function pointer tables, branching if/else trees, binary searches, conditional operations, virtual functions, hand-coded assembly with code tuned for specific processors, to name a few. Various options fit different problems more naturally than others. The compiler is programmed with all kinds of details about the target processor and the optimizer can pick and choose between many different options when it encounters a switch statement.  Exactly how it is implemented internally doesn't matter, that's an abstraction in c++.  However, this situation is not typically a performance concern in the real world.  
(4) Yes, switch statements are used all the time in game development.  As are branching is/else trees, jump tables, virtual functions, and the rest.  You should generally use the tool that your problem suggests as a solution.  In C++, if you've got a bunch of potential routes of code and the decision of which branch is based on an integer value, then a switch statement is a natural fit.  If there are other similar situations, those may be a better fit.  If instead of branching based on an integer value you want to select behavior based on the type of an object, a virtual function is probably a better fit.  If instead you are branching based on the value in a string, a series of if/else branches may be better.  If you have some other situation, a different solution may be a more natural fit for it.

#5298250 Best way to showcase C++ programming experience

Posted by frob on 27 June 2016 - 09:51 AM

Game studios know that recent graduates have very little experience they can showcase.


If you don't have a big collection of demos and showpieces, provide what you have got. If you've had an active github account, consider showing it.  If you've got some finished coursework, consider showing it.  It will not be impressive, but it will be something that provides evidence that you can program.


Apply for jobs now, work your social network now.  Don't put it off until working through an additional certification.  You just finished a certification, your computer science degree.

#5298063 Have I been aged out of the industry? And where else can I go?

Posted by frob on 25 June 2016 - 07:52 PM

There are far more former game developers than present-day game developers. 


Also as I wrote a big list on the first page of the discussion, there are many fields that absolutely love former game developers on their teams.  Even if you feel 'aged out' of games, there are other industries where the skills directly transfer.  Military simulations are probably the biggest of those.


Many of those fields pay better than game studios will pay by default, as most game studios struggle to pay employees.




junior web developer at 40?


You don't need to apply to a job as a junior web developer. I don't know if you wrote that as hyperbole or because you honestly believe you need to restart your career from the beginning.  There is no need to reset your career.  If you've got two decades of experience you can apply the experience in other jobs.  Lateral career moves take some thought, but are done quite often.

#5297904 Have I been aged out of the industry? And where else can I go?

Posted by frob on 24 June 2016 - 01:15 PM

I'm interested in getting a paycheck in an environment where I won't be immediately ostracized.
What I was hoping for was that someone who had additionally more out-of-industry experience could tell me what area of the computer programming field in general my skills would fit best in if I needed to change direction, and what other skills I would need if I chose to follow that path.
You may not be able to tell me where I should go, buy maybe you can tell me where I can go, where my skills are most wanted - and then I can choose from there.


Given these further updates, I STRONGLY recommend reading (or re-reading) a recent edition of the book "What Color Is Your Parachute?".  Three specific things in the book I'll call out:  First, the book talks about how to effectively engage in a "non-traditional job hunt", since the current idea of a "traditional job hunt" is generally to spam out resumes. These are more important as you get older since they help you overcome age discrimination and other factors. Second, the book has a segment called the Flower Diagram, where you follow some guides to figure out what transferrable skills you have, but also aspect about employers that you really want. Figuring out your passions is important, it turns your career into much more than just a paycheck.  Third, the book discusses ways to transition your career from one industry to another, or from one job title to another. This sounds like something you want to do as well.


Working through the exercises in the flower diagram takes some time, but it really is worth it to identify where your passions are, and then letting them serve as a guide to your future.
As for non-game areas that use game developer skills, there are quite a few:
* Military simulations (many former co-workers are working as government contractors for simulating all kinds of environments)
* Medical imaging (many co-workers moved to the industry, including some using Unity and LibGDX for medical displays. Medical scans use lots of images and volumetric data but need programmers who understand how to work with the data)  
* Related media like TV and movies (I spent nearly two years working on TV news display software)
* Education and training software (I spent a few years on interactive meeting polling software)
* Graphics editors and tools (several former co-workers now working for Autodesk and for Adobe)
* Property remodeling visualization or architecture visualization, such as "bring in your kitchen measurements and we'll make a simulated remodeled kitchen".
* Oil companies want visualizations and simulations, I was once surprised to learn they relied heavily on former game developers and game technologies.
* Chemical companies run all kinds of scientific simulations, but executives and marketers want interactive mini-game style simulations based on the scientist results.
* Law firms often contract out certain presentations for game-like visualizations of crime scenes and walkthroughs of virtual environments.
* etc. 
There are many industries that use the same tools and technologies as games.  There are industries that use the same techniques but different tools.  There are even the industries that create the tools and equipment games use.
If you work through the "What Color Is Your Parachute?" book flower diagram you may discover there are many industries that are not games but still lie within your "fields of fascination" as the book calls them, or as some of us around here call it, following your passions.  You may discover that while you like simulations and AI, you may also enjoy something else like auto engines, then realize you might look for a job in future auto technology.
I know someone who loved digital signal processing and mechanical data processing, and he was also interested in construction.  He ended up co-creating products where heavy chains are dragged across a bridge by a vehicle and hammers hit the structure at various locations. The sound, vibrations, and other digital signals are processed to analyze structural integrity of the bridge, discover weak points, and provide all kinds of engineering data.  He took the things he enjoyed and was passionate about and built it into a successful product.
You write your main thing is to get a paycheck and I completely understand that.  The paycheck is the primary reason for working, and if the paychecks stop I immediately begin looking for new paychecks.  But there is also your life energy and your passion and your life fulfillment, these are important too.

#5297778 Have I been aged out of the industry? And where else can I go?

Posted by frob on 23 June 2016 - 09:23 PM

Ravyne just hit the ones I was thinking.


Unfortunately yes, age discrimination is rampant.  Some people interpret "culture fit" as "young white male", instead of "intelligent, creative, and passionate".


The good news for you is that studios with age discrimination also tend to be terrible places to work, with late hours, hard crunch, and poor work-life balance. Working at places where everyone has a spouse and children tends to mellow out the worst offenders, and encourage people to think about things like time off, insurance plans, retirement plans, and other benefits.



USE YOUR CONTACTS.  You've got 10 years in the industry so you know people. Hopefully you've taken the opportunity to grab email addresses, facebook contacts, linkedin recommendations, and more. Spam your facebook account, google groups, linkdin account, and any social networks where your former co-workers work. 


The number I've heard from recruiters, business web sites, and books like "What Color Is Your Parachute?" is that one hour of working your social network is worth about ten hours of spamming resumes and blind applications. That doesn't mean don't send in applications that way, but when you have a choice between the two prefer the more effective one.  You have a much higher chance of finding a job.  For me with a recent job change and far more than a decade of experience, I made a single facebook post with "Hey former game co-workers, I need a new job!" and within the day I had several interviews lined up.  This works best if you live in a game development hub.


Make your resume specific for the individual job, and let them know you are flexible.  If they're looking for a senior software engineer, adjust it for that.  If they're looking for a team lead, adjust it for that.  If they're looking for tools or gameplay, or build system, customize it.


The higher up you look, the smaller the pyramid. If you're focusing on senior positions and lead positions there will be fewer openings.  Consider taking a lower job, and trimming your resume accordingly.  Also, consider using recruiters.  


While some places in the world have a custom of including every job you ever had in your life, other places just look for relevant stuff.  Generally it is okay to let stuff drop off the end, and omit the graduation year if you want. Rename it to "relevant experience" if you wish.

#5297763 Hundreds of timers...

Posted by frob on 23 June 2016 - 06:36 PM

5000 integer compares? If they're in a linear array, and on an x86 chip (with its out-of-order core and clock-speed multiplied integer comparisons) you could probably reach about 6 per clock cycle, or under 300 nanoseconds.

Implement it cleanly and you'll spend more time in cache misses looking up a single item in a spatial grid than you will traversing that entire collection linearly.

If the collection uses something like a priority queue kept inside a ring buffer, the time drops to just checking the first few elements in a linear array, in practice meaning just about the cost required to load the first few elements into memory.  It is about as close to a zero-cost as you can get with actual work.