Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


frob

Member Since 12 Mar 2005
Offline Last Active Yesterday, 08:35 PM

#5153261 Opinion needed: returning values without null checks everywhere

Posted by frob on 13 May 2014 - 02:47 AM

A NULL test is very nearly free on the x86 family. It usually is either one or two instructions, refers to objects likely in a register, and likely uses a local jump already loaded from memory.

Sanity checks are important in code. It seems that NULL is a legitimate value; you want to get something, and if the thing cannot be found you need a sane response. That response is NULL.

Your second option really does nothing different from the first. Instead of testing against a NULL value you are testing against a bool value. Either way a test takes place and the ultimate logic is the same. The object is not found the code needs to handle it.

Use pointers when NULL is a potential legitimate values. Use references when a value cannot ever be NULL and there must always be an object. If you could guarantee that the object always exists, return a reference. But since you cannot (it might not be in the map, and the map itself might store a NULL value) then just return the NULL and be done with it.

If you could build the code so the thing is always found, and you can guarantee that a valid object is always returned, then you can return a reference to the thing that is guaranteed to be there and eliminate the sanity check. But since that isn't the case, you are stuck with it.


#5153221 Issues with applying to a school with a Github portfolio.

Posted by frob on 12 May 2014 - 11:23 PM

I'm curious which schools would be wanting a game portfolio before entry. Please read the forum FAQs, especially about the problems that come from for-profit or very expensive "game schools". Many programs are not worth the money, and they are very career limiting, especially if you choose to leave the industry or have trouble finding a job within the industry, where a game school trade degree does not transfer to graduate studies, or to non-game fields.




#5153219 Is Unity 2D worth it?

Posted by frob on 12 May 2014 - 11:09 PM

Yeah, there are bugs in Mono, but mostly they are easily resolved.

 

For the IEnumerable issue, we have found other issues in the Mono implementation that break nested IEnumerable items. It is a serious problem for things like serialization of the entire mono simulator, and since we need to do that, using the enumerables (including foreach) are forbidden on the team. This actually works out to be a good thing, since enumerables also consume far more memory than most programmers expect, they lock containers, and they cause several other issues. The theory is good, but the implementation is less so.

 

We also avoid "getters and setters" (even as a quote I hate typing that: they are accessors and mutators). Mobile devices are slow, and the extra overhead of function calls adds up. If there is a reason to expose the raw data, just expose it publicly. If the design means you shouldn't be exposing it directly it probably means you should probably be using action verbs rather than direct access. Consequently I haven't ever tripped over incorrectly-linked accessors.

 

 

In any event, no program is perfect. Do your best, don't introduce new bugs, and QA until everything works good enough.  As a co-worker used to frequently remind everyone, a game doesn't need to be perfect, it just needs to delay crashing long enough to satisfy the player.




#5153216 Perfectionism and Programmer's Block

Posted by frob on 12 May 2014 - 10:58 PM

This is where a paper notebook or a sorted spreadsheet are awesome.

 

You don't need to do everything. If you see something you want to do, write it down or add it to the list.  Prioritize the list regularly. Cut things near the bottom of the list, you'll probably never get to the low priority things anyway.

 

For game designs, at work I view every design as a checklist, and my designers and our teems have had that work pretty well.

 

Do a single item, cross it off. Do the next item, cross it off. It is just a task to get done, like folding a load of laundry, feeding the pets, or doing homework problem 17. No stress in any of those, right?

 

When doing an item, you don't need to stress out. Most programmers are lazy (rightly so) and will just implement the minimum to get it done. Do just enough to check the task off the list. Don't aim for perfection. Don't worry too much about bugs. Don't worry about missing features. Don't worry about optimizations. You can find the obvious bugs by spot checking when done, just like you would verify your answers on a math quiz by working backwards; run the program, try the edge cases you can think of, and call it good enough. Instead of worrying about optimal, just think about minimally adequate; choose a single pass rather than nested passes, base implementation choices on how it will be used, but don't worry about optimization since if it is a problem QA will point it out.  Just implement the first thing on the list, verify it works in the program, test around it, submit, cross it off. Repeat every day. Don't worry about the list ever getting empty.

 

Whenever someone sends you a request, write it on the list so it doesn't get lost. Someone might complain if you put the work off for several days as a lower priority item, but it won't get lost in the daily shuffle. Whenever you think of something to do or an improvement that needs to be made, put it on the list. Found a bug? Goes on the list. Thought of a crazy awesome optimization? Goes on the list. Idea for another great game? Goes on the list.

 

The list is awesome. Keep it on a notepad and put dates they were added and completed, and it doubles as evidence for your annual or semi-annual performance review. 




#5153159 Is Unity 2D worth it?

Posted by frob on 12 May 2014 - 04:53 PM

The Unity engine works very well on mobile devices. Assuming you write high-quality code, your game will also work well across all mobile devices. The supported languages are C#, UnityScript (a very slightly modified version of JavaScript), and Boo (a slightly modified version of Python).

Yes, that I do know, as I have learnt some stuff about Unity in the past, thank you. But what do you mean with "high-quality code" exactly?

Just because Unity works cross-platform does not mean your code will too.

The Unity developers invest heavily in testing on all platforms, and over the years they have fixed most of the major issues. Now you need to not write buggy software.


For example, you might assume specific screen resolutions or ratios (Apple devices use only a small number of ratios, Android devices have many ratios), or you might assume the presence of limited-availability functionality like phone vibration or accelerometers. Unity offers features to help you correctly build programs, but most programmers -- including me -- will occasionally introduce errors.

It doesn't matter how good Unity is if you as the game programmer introduce code that crashes or has serious problems on some devices. You need to write high-quality code too.


#5153111 Is Unity 2D worth it?

Posted by frob on 12 May 2014 - 01:05 PM

The Unity engine works very well on mobile devices. Assuming you write high-quality code, your game will also work well across all mobile devices. The supported languages are C#, UnityScript (a very slightly modified version of JavaScript), and Boo (a slightly modified version of Python).


#5153004 A stupid thought.

Posted by frob on 11 May 2014 - 11:53 PM

Yeah, probably not the most optimizer-friendly version of that code.

But I suppose it works, assuming you take care about negative numbers, that you "add" your number in the correct direction for the bit pattern.

Personally I would prefer the more straightforward if( i == a || i == b ). More friendly to those who must maintain it, and to the optimizer.


Great coding horror!


#5153001 Program can't locate .txt file

Posted by frob on 11 May 2014 - 11:46 PM

Google finds quite a few topics on it. It looks like by default they use a subfolder named 'bin', try making a copy of the file there, or adjusting the settings.

Also, the Bloodshed version of the compiler is quite old. It is known to have many bugs, and does not support modern C++ features. You might consider moving to a more modern compiler and environment, especially if you want to take advantage of the language changes made in 2005, 2007, 2011, and those being added in 2014. If you are content working with an older version of the C++ language, then continue as you see fit.


#5152996 Program can't locate .txt file

Posted by frob on 11 May 2014 - 11:29 PM

File locations can be tricky.

If you don't specify exactly where the files are located, usually the file names are considered relative the the executable.

There is the "current working directory", which may be different from the program's location, which may also be different from the source code location.

If you are running your program inside an IDE like Visual Studio or Eclipse, look inside the project settings for the program's working directory. It might default to a ../bin/ or ../output/ or some other directory. You write you are using "DEV", which could be several programs. If you mean Dev-C++, there are several different forks of the project (Bloodshed Dev-C++, WX Dev-C++, Orwell MinGW Dev-C++, Orwell TDM Dev-C++, ...) so specify which fork and the version.

Some options available to you include copying the files to the output directory (perhaps adding them to the project file and marking them to 'deploy' with the project), or to manually copy the files to the final destination, or to modify the working directory to the location of the files. You could also require the full path to the files rather than just the file name. There are many other options as well, those should hopefully be enough to unblock you.


#5152993 question regarding game developer

Posted by frob on 11 May 2014 - 11:16 PM

There are many good books out there about many subjects. Reading the books is one step to gain competency.

Reading books about plumbing doesn't qualify you to be a plumber. You need both experience and knowledge.
Reading books about music doesn't qualify you to be a concert performer. You need both experience and knowledge.
Reading books about management doesn't qualify you to be a manager. You need both experience and knowledge.
Reading books about graphics programming doesn't qualify you to be a graphics programmer. You need both experience and knowledge.

The books can help you learn about skills and techniques and methods, but reading alone is not enough.

In all cases, you gain experience by doing what you are able. Then you take on a larger role, and do it. Repeat until the experience is enough for the role you want.



If your intention is to get a job in the industry, much of the world requires a bachelors degree; when other applicants have a degree and you do not, generally employers will prefer those with a degree. I don't know if that is necessary in your part of the world.


#5152905 Accepting advice for game features on the internet

Posted by frob on 11 May 2014 - 02:32 PM

That is why many game companies prominently state in their TOS or website policies that anything you submit becomes property of the company, AND that unsolicited submissions will not be accepted. The lawyers usually include additional similar clauses.

They help protect against a company working on a game, and someone submitting an unsolicited idea about a very similar game, and then the unsolicited submitter claiming the company stole it.

When game ideas are solicited, the submission agreements tend to have language along the lines that the company might already have similar ideas in development, that they will try to keep the submitted idea isolated, but that the company won't be liable for anything if they make a game similar to the submitted game.


#5152811 Four pillars of object oriented programming

Posted by frob on 10 May 2014 - 10:39 PM

Sorry for implying you were a villain.

Unless you want to be the villain. I mean, being the villain can be awesome, especially when the bad guys win. So, if that is the case, um, go villains! Yay!

I wasn't paying too close attention to who said it, only that when someone specifies strict rules for an abstract concept it usually doesn't work. Often I read that kind of thing as an edict. "Thou Shalt Use All These Features Precisely, No More And No Less, Lest Thou Art Not OOP."

Good programmers are able to break the rules pretty easily; either to fill the exact wording of the requirements and utterly violate the spirit, or to completely violate the wording of the law yet completely satisfy the spirit of the law. I could spend an hour or two and write some programs that satisfy all of those requirements that no sane programmer would call 'object oriented'. I could also write a program that uses none of the features that looks clean and beautiful, treating non-abstracted, non-interfaced non-encapsulated chunks of data in an object oriented manner.


#5152809 opengl question

Posted by frob on 10 May 2014 - 10:34 PM

In the interest of being constructive, please read the FAQ on how to ask good questions.

* Before you post, make sure you have tried every option you can with respect to figuring out the problem yourself.
* Be prepared to answer the question (as part of your question, ideally) "what have you tried to solve the problem yourself?"
* Be as descriptive as you can; state the language, platform, compiler, et cetera that you are using, as relevant.
* When posting code (which you should do if the problem is at all code-related), post it verbatim without transcribing or omitted code you believe is relevant as you can easily hide the problem that way. If your problem exists in a very large code base, try writing a smaller test application that reproduces the problem so that you can post a smaller amount of code for others to search through.
* Make your question as understandable as possible -- go easy on abbreviation and Internet slang. If you ask a clear, concise question, you are most likely to get a clear, concise answer.
* Make your subject title as relevant as possible.
* Browse and search before you ask, to see if your question has already been asked and answered.


Programmers are normally a very self-sufficient bunch. We will try things out on our own and experiment. We are generally curious to why things work or don't work, and will solve the puzzle with our own reasoning skills. When we get stuck of have an issue, first we normally try some experiments, then we will search online to see what others have done, and try to apply that knowledge with even more experiments. We will also dig through the source code of other programs that have succeeded, and use the knowledge to experiment some more.

It is fairly rare for an experienced programmer to ask online for questions, usually we will discover the answers ourselves through a combination of research and experimentation.

If you want to ask good questions in a programming environment, demonstrate that you have experimented a great deal, and researched a great deal, and that despite all your efforts you are still unable to resolve the issue. When you finally get to the point of asking, you should have enough experiments and research to know exactly the error message or problem, and know approximately where the problem lies.


In the past many of your posts have not shown that you have put in any effort, simply asking and expect the community to answer. This time seems to be similar, announcing "I have a problem, this source code doesn't work", with no real evidence that you have experimented and researched on your own.


#5152648 Four pillars of object oriented programming

Posted by frob on 10 May 2014 - 01:00 AM

OK, I got it:
 
5 pillars of OOP:

  • encapsulation
  • inheritance
  • composition
  • abstraction
  • polymorphism
5 pillars of OOD:
  • Single Responsiblity
  • Open-Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Injection

Got it.

So if I write a program, in order for it to be OOP, I must use all of encapsulation, inheritance, composition, abstraction, and polymorphism. If for any reason I do not include any one of those features, my program is not OOP compliant. As long as I include all of those features, my program is 100% OOP and the gods of OOP are satisfied.

 

Similarly, if I use all the features (or do not use all the features) of the second set, my design is similarly satisfying the deities of OOD.

 

For some reason, that doesn't sit well with me.

 

There are lots of programming languages that don't support all of the first five language items, and yet people seem satisfied that they can be used for object oriented programming.

 

The design pillars are generally good principles of design for object oriented programs, but are you suggesting that if I give a class more than one responsibility it suddenly ceases to be object oriented? If my interfaces are not completely segregated, my design ceases to be object oriented? I don't think so.

 

 

These are paradigms and general principles, not stone-etched laws.

 

Object oriented is a term from the 1960s, used to differentiate from other practices of using memory. There are many other data-centric ways to process data. Lots of stream-based and DSP-based algorithms work better without discretizing the data. And that's okay too.




#5152599 Four pillars of object oriented programming

Posted by frob on 09 May 2014 - 03:11 PM

If it seems that no one can agree what the "four pillars of OOP" are, perhaps you should take that as a sign that the idea of "four pillars" is bullshit.

 
LOL, perhaps that's true. :)

I have heard all kinds of definitions and descriptions over the years. Most of them are garbage.

The paradigm of "object oriented" is that actions are based around a consistent clump of data called an object. The object is treated as a whole rather than as parts. You do operations on the object generally. One person I recall had a long story about it involving a gorilla, based on the old "teach a pig to sing" story. You treat the gorilla as a single object, rather than trying to pass around the individual eyes when you want the gorilla to see, passing the stomach when you want the gorilla to eat, or passing the limbs when you want the gorilla to walk. Constantly reaching into the internals is inconvenient to the zookeepers and it annoys the gorilla.

You can try to add things to make a formal definition for yourself, but over the decades most people realized this is futile. There are always exceptions to the rules, there are things some people want to add, things other people disagree with. Ultimately there is no formal definition for the paradigm, just a general concept of "objects are independent chunks of data that are treated as a unit."

There are many paradigms. Some of them work well together, others do not. Event driven paradigms, for example, can play very nicely with object oriented paradigms. An event happens, generating an event object. The object is passed around in response to the event, often with a chain of command pattern, until it is processed. If you consider functional paradigms, they often do not play well with imperative paradigms. Parallel paradigms may or may not play well with linear paradigms.



The C++ language, for instance, can be used for object oriented paradigms. The classes that contain data and operations for that data are useful to the paradigm. But that does not mean you need to follow it. You can treat data as raw data rather than cohesive objects. You can pass around object internals rather than full objects. You can follow non-OO paradigms if you want. Just because the language is designed toward the paradigm does not mean the code actually uses the paradigm.


I can very easily write code that uses classes, encapsulation, inheritance, polymorphism, and everything else listed above, and craft the code so that it quite clearly does not follow an object oriented paradigm.

I can also use languages that are not built around object oriented themes, but then organize the data and code to clearly perform object oriented work.




PARTNERS