Jump to content

  • Log In with Google      Sign In   
  • Create Account

imoogiBG

Member Since 16 Jan 2011
Offline Last Active Today, 03:10 PM

Posts I've Made

In Topic: Coding-Style Poll

Today, 03:11 PM

@L.Spiro I think most of us are interested in the results. So I just wanted to ping you about that. :)


In Topic: the very best resources I found for game programming

Today, 09:37 AM

Also keep in mind that we've all been there (I mean at the start where you get a bazilion different opinions). So just pick something a start learning. it seems like a big deal now, but your 1st language isn't that important, when gain a bit of experience you will learn new languages pretty fast, and you will be able to understand different APIs(for the same thing) super fast.

 

Doing something is always better than doing nothing.

Just do not learn in isolation. Ask questions when you need to.

 

if you like python go Python, if you like Swift go with Swift ect..
In my case my 1st language was Javascript, after 3 months I've switched to C++. Now at work 95% of the code I write is in C++, but I also write code in Python, C#, Php, and other small languages. I write both code for D3D, GL and other APIs.


In Topic: Coding-Style Poll

Today, 05:22 AM

An important thing in any coding style IMHO is naming. We've currently have a bunch of issues because of that. Let me give you an example:

 

There is a very "quite" fight  between using "num" or "count" prefix/suffix for, describing a variable/functions that is counting something:

int numPoints = foo.getNumPoints()

vs 

int pointsCount = foo.getPointsCount();

and:

enum Colors
{
   Orange,
   Blue,
   White,

  NumColors VS. ColorsCount
};

I was a "num" guy, but in order to simplify searching i now use "count" as it is a suffix and it easy to find realtions to that count (it is easier to find all code that is all abount  points if everything is named like this getPoints*())

Additionally you should think about similar cases that happen in your company. In my case we internally have an issue with those pairs identifiers "cycle/step", "voxel/core", "node/object" ect.


In Topic: Coding-Style Poll

Yesterday, 10:54 AM

@work we write code exactly the opposite way that I was used to. I really hated it, but I kind of adapted over time.

 

Braces

@home the braces are always alone on a new line

@work the braces are always on the same line with if/else/ect. keyword without (usually without a space)

 

I think this is not that important, as long as the code is readable, to be hones @work I sometimes come across a code that is just bananas and it's looking like a dense block of logic that is hard to read, but that the same time, @home style braces sometimes make the code to be too long. 

So final verdict, I'm fine with both. Mixing them is not a big deal for seaching in code (at least in my code and the code at work)

 

Other

 

members prefix:
@home - for non "structs" (I think of struct for something that easily behaves like an int) no prefix, for all "classes" m_ prefix is a must.

@work - all prefixes are forbidden.

 

Well I hate no prefixes, it is a bit harder to search in code, it's harder to read, and shadowing arguments happens. I do not like it, but I can do my job with it. (this is pretty annoying)

 

class name prefix - I put prefixes if there isn't a namespace for that project. the prefix is something abbreviation of the project's name.

 

@work using underscore is forbidden for all identifiers - I really hate it as i cannot make things a bit more readable and when I need a new function that is used as a substep i like to do the following thing:
void DooFoo():

// These are intended to simplify the code in DooFoo, they I introduced only if there is no way to make them general purpose

void DooFoo_Dothing1();

void DooFoo_Dothing2();

I Can still do that but the underscore is some kind of "implicitly descriptive", at least for me.

 

I'm always adapting to the style of the project, it is cleaner, doesn't make the code *feel hevy* and it is searching friendly.

 

 

Other things that I do:
Methods names that are usually commonly used (like Create, Initialize) should be suffixed with the class name like so:
struct Texture { void CreateTexture(); }
struct Buffer { void CreateBuffer(); }

 

I do this in order to simplify code searching.


In Topic: 3D World Editor - Suggestions and Ideas

23 September 2016 - 12:08 PM

About uodo/redo I've implemented something reticently and I'm still not sure about my own implementation...

At work I write a lot of code for 3ds Max/Maya. In those softwares(especially Maya) Every data is stored in some sort of "nodes" as something called as an attribute(or parameter). That is it. The type of attributes in Maya are: floats, int(and booleans and enums masked as ints), reference to other nodes/attributes. An "Attribute" is really just a class that wraps all geters/seters for every type (and stores the animated data for every attribute, if you are interested in animated attributes I could give you more details here).

So using those unified getters setters we can easily record evey change (or if needed create a snapshot of the whole scene/level/..).

So knowing that every data for a node is stored as an attribute, each node gets a callback whenever an attribute is changed. So every node can take those changes in account whenever needed.

 

Another plus is that you can auto-generate UI for those attributes.

 

The problem is that that data doesn't directly translates to your "game object", but knowing that usually the data for the editor is usually different from the one used during game.

 

However a disclaimer - Maya is not a game engine and my experience with this is not professional. 


PARTNERS