Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Jul 2003
Offline Last Active Today, 05:39 PM

#5247453 Windows 10 Game Programming

Posted by on 18 August 2015 - 01:17 PM

There's a donut shop near where I live that makes exactly one type of donut.  Despite no choices people flock from afar to enjoy them.

Sometimes just having one option is the easiest!

#5247404 Windows 10 Game Programming

Posted by on 18 August 2015 - 09:52 AM

I'm crafting some small games and decided to make a full leap into Windows 10.  I've been watching some of Microsoft's Virtual Academy presentations.  They've created a unified development environment called Universal Windows Platform (UWP).  The platform's objective is to create one code base that supports all Windows devices:  Xbox One, PC, phone, tablet, their version of smart glasses, and anything else under the sun that will support Windows.  The new development model is an 'App' which calls the Windows Run Time (WRT) and supports managed code.  (This is different then the CLR which still only supported PC development).

When I hear 'managed' code I automatically associate it with 'performance hit' via garbage collection, etc.  Is this concern justified?


Underneath the hood are now three models (I paint with broad strokes):

  1. Win32 -- classic API which uses structs to query and update the OS/App
  2. COM -- MS' object-oriented methodology for OS/App communication
  3. WinRT -- managed code which is largely supported across platforms

For you Windows developers, will the UWP model change how you do things?  Are there concerns over performance?  How many will still develop Win32 / COM?


I'm trying to get an understanding of the overall picture.


#5204235 Code appearance, is it really important?

Posted by on 14 January 2015 - 11:02 AM

Mind you, this is my personal observations and speculation from my own hobbyist projects; not the result of scientific studies. I'm not a AAA developer working in the industry, nor do I have a PHD in computer science.


Sorry to be a little off topic, but you do a disservice to yourself.  Experience is a huge asset.  Your accumulated knowledge has benefited this site quite often.

Consider this scenario.  You seek medical surgery and you have a choice:  (1) select a doctor who did nothing but read books and study theory but never did any medical procedure, (2) or one who learned no formal theory, yet learned by watching other doctors and performing surgeries under their watchful eye?

Obviously, to be the best doctor you want both and that's why there is such a strong requirement for medical school and residency.  Doctors need a strong competency in theory and working memory, because these areas stimulate different parts of the brain.  (Also, consider that doctors can't just practice surgery whenever they want;  they can only operate on maladies that people actually present them.  A computer programmer can simply learn whatever they want, whenever they want.)


To dovetail back to the OP and to echo an expression that GDNET continuously expounds.  You learn programming by programming.  Sure, take some suggestions, read books and articles, and maybe even get that PhD to get a deep, specialized knowledge of computers.  But make an effort to dig in and do it. Style seems to be such a simple question to ask yet its answer touches upon many root aspects of programming.

#5204029 Code appearance, is it really important?

Posted by on 13 January 2015 - 02:59 PM

That a computer language even exists is testament to the benefits of clarity.  We could all be doing punch cards or pure assembler programming if this aspect made no difference.

Some standouts:

  • Once you establish your style, stick with it.
  • Keep consistent tabs for each new lexical scope.
  • Organize headers / routines so public, protected, private, etc. functions appear in the same order.
  • When possible, keep functions relatively small -- no more than a page at a time.  If I start to see spaghetti code I build hierarchy to replace strands of code.  It's a good way to establish concepts and start to see patterns.  Spaghetti code is hard to understand especially when you're constantly scrolling up and down within the same function.
  • Give descriptive names to your functions, variables, files, etc.

You'll eventually write some code that you may return to later.  With a clean, consistent style you'll get to the source of your bug when you find things where you expect to see them.

#5148968 References or Pointers. Which syntax do you prefer?

Posted by on 23 April 2014 - 09:20 AM

A common style that I've seen is const-references for in-params (which should act like pass-by-value, but are expensive to copy) and pointers for all out params.
The rationale behind this is that it makes out-params very obvious at the call-site, similarly where in other languages the caller must use an 'out' keyword.

It'd be nice if the syntax were a little cleaner in C++, but then it'd also be nice if owning pointers (std::unique_ptr) were a built-in feature like in Rust. C++ is not for people afraid of typing or syntax spew. tongue.png

That would completely kill C++ as being a pay-for-what-you-use / opt-in language. Most embedded systems that I've worked on still use raw-pointers, or a smart pointer that acts like a raw one, but only performs leak detection during development.


Is a valid use of raw pointers for things within a class?  For example, if I construct an object (and correctly release resources if the object fails to construct) and then provide the correct release in the destructor would this be a valid use?  I guess that's the RAII paradigm in a nutshell.  Or would you advocate smart pointers even in this scenario?


I suppose if I need to share a dynamic resource to things outside of the raw pointer containing class then smart pointers become essential.  But even general purpose libraries intended for mass consumption avoid smart pointers because there's no hard bound guarantee that the same smart point convention is followed by programs which use different implementations.  How then is the problem of detecting resource leaks handled?  Is there a method to the madness or are designs/tools up to the task?


If there's any doubt, these are genuine questions and not quibbles with the concept of smart pointers.  I just haven't been on a large enough project to see what disasters might befall the unwary.

#5098745 Procedural Game Generation

Posted by on 04 October 2013 - 08:23 AM

While I have no specific recommendations about how to go about it, I do remember a game I loved:  Adventure Construction Set


You could make adventures yourself or let the computer spit-out an entire adventure after it spent about 1 hour doing its thing.  All the more amazing is that it ran on the Commodore 64, a 64k machine!  There's a ton of nostalgia for it on the web.  Walk on over to Google for some ideas.

#5098085 about keyword and include

Posted by on 01 October 2013 - 09:46 AM

If I understand your question correctly, you're asking why the keywords of C++ do not need a header file.  


Simply, they are a part of the language.  A compiler / parser is essentially hard-coded with the rules it needs to understand what keywords are, and what it is supposed to do with them.  Several international C++ standards exist which give precise definitions, depending on the version of C++ you're using.  


While it might be possible for a tool to construct a language from a set of rules, such as the keywords, you would have to require that tool to have certain rules to understand those definitions.  At some point a tool must have some set of basic definitions for it to do its job.  And that's what keywords partially represent -- an internal skeleton that guides the parsing / compiling processes to choose the appropriate rules when translating your code.

#5095293 Effective C++ (book)

Posted by on 19 September 2013 - 04:58 PM

Why not make it a trifecta?  Grab 'Effective STL'.  The formatting and cross-referencing are the same.  You're given 50 specific points for improving your code with a copious amount of rationale behind the decisions in each of the books.


But maybe that's getting ahead of things.  C++ kinda grows on you.  If you pile up on books but don't do much programming you won't absorb the knowledge and fully understand what Scott Meyer is trying to explain.

#5094562 CS Degree - Is it worth it?

Posted by on 16 September 2013 - 06:46 PM

As has been referenced earlier, if you want a job you need your resume in the hands of the hiring manager (obvious, right?).  What are the most effective ways to do this?

  1. You have interned for the company.
  2. You know the manager.
  3. You know someone who knows the manager and who vouches for you.
  4. You attend any seminar / conference / job fair that puts you into direct contact with the manager.

As Washu mentioned, HR receives and rejects thousands of resumes before any manager gets a whiff of them.  At larger companies they use "search" terms to create a score.  This leads to resume padding, sometimes to ludicrous levels.  Bypassing HR, if possible, dramatically increases your odds.  Tying the above knowledge to a university.....


One overlooked aspect of education at a university is that they tend to have great connections to industry.  Often they will have a resource center where they invite recruiters to interview.  Typically the recruiters are either professionals who visit with hiring managers, or the managers themselves.  Put all those big dollars you're spending into good use and attend these interviews!


The job resource center will usually host co-ops and internships as well.  As I've mentioned earlier, if you spend some time with an employer you get some "face" time that no resume can supplant.  If you're at these jobs learn as much as you can.  Make as many friends and connections as possible.  Even if you discover that the actual internship or company isn't exactly what you want to do, there's a good chance one of your connections will know a perfect match for you.  They'll refer you through a friend or have direct contacts with a manager (which allows you to bypass HR).


Also, internships tend to pay money.  I remember mine well.  Instead of pouring concrete with the local construction company for a summer, I was in air-conditioned bliss, making 3x that salary and following my educational goals.


Anyways, best of luck!

#5093771 to improve wide or better narrow knowledge ?

Posted by on 13 September 2013 - 07:18 AM

Here's some back story that may have relevance.  YMMV.
I've interviewed probably 50+ candidates over the years.  I'm not a manager.  I don't get to pick who I interview.  As part of the interview team I typically cover basic programming in Perl, C, C++, and ARM assembly.  I've discovered that PhD candidates cannot program at all (this is not a sweeping assessment of PhD holders. I personally know plenty of PhDs who are amazing programmers).  We were looking for people who could demonstrate they could program at a bare minimum without much hand-holding.  I'm sure a PhD could eventually figure this stuff out, but our needs were such, at the time, that they needed to hit the ground running.
I spoke with a co-worker about this puzzling trend.  He holds a long list of degrees and I figured he'd be the best to discuss the matter.  He put it this way:  "Imagine that all computer programming knowledge (or all knowledge) can be represented by a circle."  He would then draw a much smaller circle on the edge of the bigger circle.  "This smaller circle represents the pimple of knowledge where the PhD is an expert.  They have focused on this piece of research for so long that they've clouded out the rest of the general knowledge.  PhDs typically spend many years in this focused state.  This is why, despite people's general understanding of what a PhD means, reality is quite different."
The next natural question was, "Well, is there a degree program that makes you expert of general knowledge?"  


"Yes.  That's called industry."
How is this relevant?
Well, if your idea of programming involves highly focused research based projects, in order to get anywhere you'll probably have to devote considerable effort to reach any level of competency.  The thing you sacrifice is time spent on becoming proficient in a wide range of activities.  My impression of game programming is that if you're doing it all by yourself, you want to master as many of the fundamentals as possible.  Don't spend too much time in any one area.  If anything, rely on the generous support of the open source environment for when specialization is necessary.  You don't have enough time to do it all, but you do have enough time to learn tools and flows that cover that aspect of programming for you.
As Álvaro says, it's a judgment call on your part.  Maybe somewhere along the way you decide you really enjoy something.  Or maybe you have some novel idea that you really want to explore.  It's largely dependent on what your goals are.

#5093369 Strategy pattern.... am I on the right track?

Posted by on 11 September 2013 - 02:34 PM

Is the allocator parameter of C++ standard library containers an example of the strategy pattern? It customizes the logic based off of the allocator passed in, without changing the functionality of the container itself.

Yeah, I think that's about right.


In my listen() example, my creature class might implement it as a giant series of if/then/else statements every single time I call listen, even though the state of the creature rarely changes.  Rather than have a giant sequence of if/then/elses I could instead pay that cost one time.  For example when the creature goes deaf I can change the listen() strategy to the deaf strategy, which still happens to use the same interface.  Now I have tidier code.  If I call listen() a zillion times, I save a bundle of branch instructions on that if/then/else tree.  Pardon my poor syntax below, but it's enough to get the idea across (I hope!)

void creature_class::listen()
   // place this creature's specific code afterwards, if any, that is invariant

void creature_class::set_listen_strategy( <variables> )
  if( DEAF ) this->IntefaceListenStrategy = DeafListenConcrete;
  if( BUFFED ) this->IntefaceListenStrategy = BuffedListenConcrete;
  // etc.

#5093332 coin flip problem

Posted by on 11 September 2013 - 12:18 PM

Your loop continues as long as you don't enter 1 *or* you don't enter 2. To visualize that, here's a table:

1  |   2   | !=1  |  !=2  |  Loop?
Y  |   N   |   N  |   Y   |  Yes
N  |   Y   |   Y  |   N   |  Yes
N  |   N   |   Y  |   Y   |  Yes
So in other words, you will always loop forever, no matter what.


Quite helpful.


I find if you have trouble with testing the negative condition in your head, do this:


Determine which is easier to state in your mind.  In this case, "I want to exit the loop when choice is 1 or 2".  Then just negate this logic for the condition of staying in this loop:

"I want to stay in the loop when !(choice == 1 || choice == 2)".


You can also apply DeMorgan's rule to alter the check.  DeMorgan's rule is:

!(A && B) = !A || !B
!(A || B) = !A && !B

Thus the condition can also appear as:

!(choice == 1 || choice == 2) -> !(choice == 1) && !(choice == 2)

#5093292 coin flip problem

Posted by on 11 September 2013 - 09:45 AM

You are using 'randRange' as if it were an 'int' variable.  However, 'randRange' is a function so in this context it will return a function pointer.  A function pointer is an address in memory where the code for a function resides.  Essentially your initial attempt is comparing code to a data type.  CaptainKraft's solution will fix that particular compiler issue because you are now comparing against the result of performing that function, which produces an int and comparing it to an int type.

#5093266 Strategy pattern.... am I on the right track?

Posted by on 11 September 2013 - 07:42 AM

The high level view of the strategy pattern is that the interface to a behavior never changes but the behavior itself changes.  


A simple example might be a convex hull strategy pattern.  There are probably 10 different ways to solve the convex hull pattern.  Some perform better than others depending on the type of data that's input to the pattern.  If you need to do convex hull solutions frequently and you monitor data input patterns that you are receiving, you might decide that a different algorithm for the convex hull is more appropriate.  Rather than placing a series of 'if-thens' that surround each convex hull algorithm you can simply have your interface point to the best algorithm.


I realize the convex hull solution is a fairly simple example.  You don't really need much more than an 'execute' method, although if you could customize sub-steps that have a common interface it would start to get some benefit.


Let's take your example.  Maybe a certain class of creatures implement methods to listen(), assess_opponent(Creature &), look(), attack(Creature &), flee(), etc.  You could have a generalized opponent interaction function that does something like:

if( listen() == OPPONENT_DETECTED )
   Creature& opponent = get_detected_opponent();
   bool we_do_attack = assess_opponent(opponent);
   if( we_do_attack )

You could have a strategy pattern that provides interfaces to those methods with a possible default behavior.  You can then provide a way to change the underlying strategies at run time (this is a crucial difference from the template pattern which chooses behavior at compile time).  For example, maybe your creature has super ears that can echo locate creatures, but somewhere in the course of the game it sustains an injury that renders it stone deaf.  Rather than provide a series of 'if-thens' in the above code, you could change your strategy that implements a 'deaf' version of listen().


Essentially what this buys you is the ability to have code that has the same overall logic but lets you vary behavior dramatically.  It saves you from having to change the above code constantly despite changes in underlying behavior, which is really one of the major benefits of design patterns.

#5092826 Any interest in ARM CPU pipeline / programming article?

Posted by on 09 September 2013 - 04:11 PM

Thank you for your feedback.  You're correct.  Covering the entire ARM family is probably too ambitious for one article.  Maybe it would serve the community best if the article was focused on getting the best return of processor performance without giving too much consideration to the underlying specific implementation.  If it's a bust, well then I've tried, but if it's successful it may spawn interest in looking at more specific implementations.