• entries
97
112
• views
86706

Ramblings of programmyness, tech, and other crap.

## Version Control.

First I must open with the simple fact that a lot of people just don't use version control. The main reason for this is because in all honesty a lot of people just don't understand it. Not to mention the major version control war going on at the current moment just tends to confuse people all together even more. I am going to do my best to give some informative information on the different version control systems (VCS) out there to try and help make sense of the decision I need to make for my next project as well as hopefully help others make the decision for their projects.

First there are currently two types of VCS's out there at the current moment first is the CVCS and next is the DVCS. CVCS systems like subversion and cvs have a central server that every client must connect to. The client basically pulls revision information from these system to a working copy on your hard drive. These working copies tend to be very small because it pulls only the information it needs to be considered up to date basically the latest revision. The major gripe people seem to have with these types of systems at the current moment is the lack of enough information to do a proper merge of a branch back into the main code base. DVCS systems are what people call distributed. I hate that term because I think it makes things harder to understand. Examples of these are git, mercurial, and bazaar. The reason I hate the term distributed is because currently a lot of people use DVCS systems just like a CVCS system but with benefits. Typically the main code base is stored in a central location so that people can stay properly up to date with the code base. DVCS pulls the entire repository to your system including all of the revision history not just the latest. This allows for you to not be connected to the server and do everything right from your machine without a internet connection. What I like about this is in its own right everyone has a complete copy so if something happens to the central repository numerous people have a backup of the code and revision history. The nice thing about DVCS and why I think so many people are fanatic about it is the easy branching and merging. Because you have the total revision history it allows you to easily branch merge and cherry pick changes at will without a lot of risk of "pain". So when looking at the two different types of systems think CVCS (most recent revision only in working copy), DVCS (total history in working copy).

*Warning opinionated*
My main gripes with the current arguments out there have to do with the fact of branching. The DVCS group of people seem to like the idea of branching every time they make a code change or add a new feature. They argue that this is insane and painful to do in SVN because of horrible revision/merge tracking. Ok I agree branching and merging can be painful in subversion but at the same time it is not as bad as people say because they are taking it to a extreme and not using the system properly. I am not the kind of person that likes to make a branch for every feature I add into a application. I feel branching should only be used for major changes, re-factors, and other changes that have a large chance to BREAK the current working development tree. Maybe this mentality is why I never really had to many issues with subversion to begin with when it came to branches and merges. Maybe it is because I was using subversion as the developers INTENDED according to the svn red-book. I don't know maybe I am just a hard sell.

So which one should you use. It is hard to say each system has its pros and cons as you have seen. The one feature I love about the DVCS camp is the speed at which you can get up and running and the fact that sites like GitHub and Bitbucket are amazing places to host your code. I also like the speed of DVCS systems, because you are doing everything from your local machine and not over a network DVCS is blazing fast compared to CVCS. Lastly the thing I like the most about DVCS is the fact that they are very flexible and you can use them with whatever workflow you desire. The main cons I have for DVCS are the lack of repository permissions, large file support is really not that good because of full repo history pulls, no locking for binary files and other code files to prevent major issues if both are modified at the same time. For example if you only want to branch when you feel something has a good chance to break the entire main line of development you can do so. If you want to be considered the central repo instead of a host like GitHub you can do so. What I like about CVCS is the fact that it can handle very large files quite well. Another thing I like is the fact you can have repository permissions making sure you know who can write to the repository. I also like the fact that you can lock binary files and other files if you wish to prevent other people from making changes to the file as you make your changes. This alone can save tons of time if you are working as a team and your art assets are in version control with your code. The major issues I see with CVCS are the required network connection and can cause speed issues *coffee anyone*, not having the full revision history present on the machine making it difficult to cherry pick or inject merges into different parts of the development line.

Keep in mind the pros and cons are as I see them other people may have different pros and cons. Yes I listed less cons for subversion however, there are times when these cons can definitely outweigh the pros. The cons of DVCS are hard to ignore and can outweigh the pros at times as well. So with these things in mind I am sure you can better make the decision you need to make. As for me I have used both and I like both a lot which make the decision for me extra hard. The one big pull factor for me is hosting and DVCS has the huge win there. So for my next project I will be using DVCS because I feel the pros outweigh the cons more so under most circumstances. Not to mention I really like the speed and the fact of having a whole repository backup on my machine. Ultimately the decision is yours but with this information hopefully you can weed through the google fluff that is out there.

In the future I just might have to return with my experiences and if anyone wants more detail into the inner workings of Version control systems let me know in the comments and I will go out and find the video that goes into the details of the internal differences of how revisions are stored.

## Farewell GDNet.

I figured before I bow out of this excellent community I would give an appropriate farewell. I have been a member of this site since 2006 and enjoyed a lot of moments here. But it is time to move on. The first thing bringing me to this conclusion is the lack of passion I have for game development anymore. I have fallen into a world where I am more enthused learning the inner workings of various data structures and languages as well as Security and Computer Architecture. These are things that will always give me something to strive for that does not involve needing art or music or even game play. The next thing bringing me to this conclusions is that although I truly love the new site design the overall community has taken quite a awkward turn from what I grew up in. This site shaped me as a effective programmer and problem solver. This was because I knew when to ask the proper questions to receive the right answer. Those kinds of questions seem to have long expired on this site. Despite the few great questions and discussions most questions anymore fall unto the answer of Learn to Google or RTFM. This has become the norm because a lot of questions out there are horribly thought out and downright inept.

I miss the days of the old GDNet where we would break threads because of truly great intellectual discussions. I also miss the days of the great news posts written by our own which are now nothing more then add blurbs. But most of all I miss the debates about implementation and algorithms. These days are gone and it is because there is a new generation of wannabe game developers that have less prior experience and less enthusiasm for self research.

I have a huge passion for learning. I force myself to try and tackle the same problem in different ways even if it means diving into the inner workings and re inventing the wheel because of this passion. For every answer I receive I have to know WHY it is that way and WHY it works that way and then HOW that conclusion is reached. This is the very essence that has left the community.

Thank you for all of the help and great discussions maybe I will poke in here and there but I am moving on to a place where I can dig a hole of learning that will never end.

If anyone out there has enjoyed my twisted musings of doing things the hard way on purpose and other general really geek oriented thoughts and questions. Stop by my new blog at http://partsaneprog.blogspot.com/ There is nothing up yet but keep checking in I am working on something totally crazy atm.

## Getting back into GameDev (for real this time) need some input

Hey everyone, finally got all those W8 issues sorted out. Had to do lots of patching for VS2008 for school and had to disable secure boot ect... to get the UEFI layer to allow the video card to function but all is setup and good to go.

Over the past few days I am been really pondering various aspects of my hobbies. Micro Electronics is really cool but it does not seem to give me the satisfaction I originally intended from it. My goal with the Micro Electronics was to learn development at a very low level. Through various projects and experiments I realize it is really much more about the hardware design and circuits then it is about the low level development. The thing is programming a micro controller really is not programming per say in most common applications it is mostly configuring the internal hardware of the chip to act on various sensory data. The most programming you do is setting some bits and possibly performing a few calculations and that is about it. At least for the cases of what I have been capable off as I am severely limited when it comes to circuitry knowledge. Even from a robotics level it really is nothing more then acting upon the various sensory inputs to make various decision about motor speed and direction.

So through much thought and pondering I think for sure I am going to be getting back into game development as I am not quite sure what I can obtain from micro electronics but I do know what I can obtain from a knowledge perspective with games that could be useful in other applications like data modeling.

Right now I already have 2 game ideas I want to work on that have really been poking and prodding at my brain for the last few years now. One such game should be simple to implement and the other should be a good stepping stone from the first. Both games are 2D as I feel when getting back into this I should start from 2D and once I have the 2 games under my belt then I can consider the move to 3D if it still feels feasible at the time.

In the case of target platform I am not sure at the moment and this will directly effect various technology choices I will have to make. If I choose the PC my options are limitless, however, if I choose mobile I would have to target Windows Phone 8 as that is the device I own currently which I think would be awesome as it is really a great mobile platform. The issue with Windows Phone 8 is I would probably need to find a target API because XNA does not work on windows phone 8 to my knowledge I would need to aim at a API which covers the platform like MonoGame or DirectX.

Also I think there is a fee in order to utilize anything other then the simulator to develop for the windows store but the advantage with targeting this is I can target both Windows 8 and the phone. So this may be the route I take not sure yet.

Any input is appreciated here as I am out of my zone on the Metro/Phone platform as I have always been mainly a C Developer.

So the question is out what do you guys think? Would it be a good choice to target Windows Phone 8 there is a huge open market on these devices for sure and may open options to publish on Xbox in the future as well as Window 8 itself? If so what technologies should I be looking at?

If I do not see too many comments here I will post up in the forums I have been out of the game dev scene for years.

## A bit about my game and some slow progress

Hello Everyone,

I feel it is time for some updates on my game as I really did not say much about it. So I would like to introduce you to the concept of a game I have been wanting to make for years. The game is called Orbis. The general idea behind the game is Asteroids with a twist.
So ultimately I will be making a Asteroids clone with a few twists to spice up an old game I use to love to play at the Arcades or even on the Atari!!!!
I am not sure if I am ready to really detail out all the features quite yet as I am not sure exactly what will make it into the game just yet. So we will leave it at Asteroids with a twist for now till I flesh out more of the concepts.

I also decided to make some tool changes for the game. I decided I would stay with C++ even though after my first foray back into C++ I wanted to scream back to C. Ultimately I ditched QTCreator and MinGW. For some reason I was having issues with MinGW on Windows 8 so I decided to install Visual Studio 2013 Express Windows Desktop edition. I must say I am really impressed. I also decided to stick with SFML. To use SFML with VS2013 I needed to rebuild the library and building SFML 2.1 did not work out to well so I ended up going with the Git repo and building from there. So far so good. So here is what my new environment looks like.

Visual Studio 2013 Express Windows Desktop
CMake 2.8.12.1
SFML (master)
Git Version Control (on BitBucket)

I am still using CMake because if I do decide to build the game on Linux for testing on my laptop CMake will save my life. So right now I use CMake to generate the Visual Studio projects and work from there. Not pretty but saves tons of headaches. Visual Studio leaves me out of my comfort zone as I am not a huge IDE fan period but we will see where this setup takes me.

Now a bit on the progress. Not much honestly. Much of my time is taken up by school and on top of it I am trying to get back into the groove of C++ after spending a few years in the world of C. So bear with me we will get there.

The first task I really wanted to get done was make sure SFML actually worked and it did. From there I felt the most important thing I should get out of the way is Resource Management because this is something I really can't have a game without. Sadly this was probably not the best place to start when I am trying to get my C++ groove back but none the less I think I was successful. My goal here was to put together a cache for my resources. This will be the core of ensuring all resources are properly freed up when no longer needed and will also be the core of my TextureAtlas system which is what I will be building next. I really needed this to be generic because SFML has many types of resources. So this resource cache is built to handle sf::Image, sf::Texture, sf::Font, and sf::Shader. There may be a few things but this is what I can think of off the top of my head. It will not handle music because sf::Music handles everything very differently so I will need to take a different approach for music.

I also wanted to ensure that the memory of the cache was handled automatically. Since I am not in the world of C and the fun void* generic programming world I figured I might as well try to use some C++11.

So my first foray into C++ after years and years of not touching it includes Templates, and some C++11. In other words AHHHH MY EYES!!!!
Sorry for no comments but here is the code I came up with using unique_ptr for the resource which gets stored in a map. The actual key to the map will be implemented as a enum elsewhere so I can index into the cache to get what is needed. There are 4 methods. 2 load_resource methods and 2 get_resource methods there is no way to remove a resource at this point as I am not sure I need it yet for this game at least.
One load_resource takes care of the basic loadFromFile. sf::Shader as a extra param and so can sf::Texture so the overloaded load_resource takes care of that. get_resource just returns the resource and there is a overloaded version to be called in case the cache is a const.

Here is the main.cpp file which I used for my functional test as well so you can see it in use.#include #include "ResourceCache.h"enum TextureID{ Background};int main(){ sf::RenderWindow window(sf::VideoMode(250, 187), "SFML Works!"); ResourceCache TextureCache; TextureCache.load_resource(TextureID::Background, "./Debug/background.png"); sf::Texture bkg = TextureCache.get_resource(TextureID::Background); sf::Sprite bkg_sprite(bkg); while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) window.close(); } window.clear(); window.draw(bkg_sprite); window.display(); } return 0;}
Like stated this is my first foray back into C++ so feel free to let me know if you see anything obviously wrong with the ResourceCache class. Much appreciated in advance.

Until Next Time.

## I <3 GDNet

Hello everyone I have another version control post in the works. It will be similar to the last one however slightly different and more academic in nature. I am currently taking a Advanced Composition class in school and I need to write an expository (informative) essay. I chose to do it on why a software developer should use version control and the ramifications of not using it when developing software. I am sure you guys will really enjoy reading it. But that is not why I am blogging today.

The reason I am blogging today is to say how much I love gamedev.net. I first came to gamedev.net back in 2004 as a young aspiring game developer. After a hiatus I came back under a new user id because I totally forgot what my last one was and email address changed so on and so forth. I had my ups and downs here pissing some people off because of my sometimes sarcastic replies I have a tendency to make. They technically are not but come off that way because from time to time I get irritated with how lazy people are and don't do their proper research before asking questions. We have all had those moments. Either way I have learned so much about development from this site and I have given back the same learnings to some others that this site pretty much became a second home for me.

Through out these years I learned so much about myself from this site and this site shaped me so much as a developer. Out of all the lessons I learned from GDNet the largest lesson I learned was that game development is not for me. Sure I can make games but that does not interest me anymore I guess I outgrew the childhood fantasy and found my real niche in the software community of developing software to make tasks easier and more intuitive. I also learned I have a passion for Information System Security as well (my current degree). All of this is because GDNet helped shape my identity over the years.

At this point in time I have a burning desire for GDNet to be more then Game Development centric. I mean I rarely ever talk about game development anymore it is all about Version Control, my progress learning Obj-C and cocoa and other software related topics. This community is a great community I just wish it was more Software centric covering the basis of both game development and normal software development.

Either way Home is Home and I

## Taking High Level Programming for Granted

Recently there have been some posts around about people considering using C over C++ for god knows what reasons they have. As per usual the forum crowd advises them to stay away from C and just learn C++. This is great in theory because over all despite the insane complexity of C++ it is a much safer language to use then C. C is a very elegant language because of it's simplicity. It is a very tiny language that is extremely cross platform (more then C++) and has a very straight forward and tiny standard library. This makes C very easy to learn but at the same time makes C very difficult to master. This is because you have to do a lot of things by hand in C because there is no standard library equivalent or particular language features that cover all bases. C++ is safer in a lot of situations because of type safety. C++ keeps track of the type of everything where C actually discards all type information at compile time.

With that little blurb aside I personally feel a lot of programmers should learn C. Not as a first language but at some point I think they should learn it. This is because it allows you to understand how the high level features of modern day high level languages work and people take these things for granted now a days. Today there are not that many programmers that actually understand what templates are doing for them and what disadvantages/advantages they have. The same goes for objects. A lot of programmers fail to understand how objects work internally. This information can make you a much better programmer over all.

Over the last few years I have spent a lot of time in C compared to C++ or other high level languages. This is not only to understand the internals of high level features I have used in the past but because I am preparing for a up coming project I am designing. This project almost has to be done in C for portability, performance, and interoperability reasons. This project not only will be targeted towards the Linux desktop but possibly embedded devices as well. So today I am going to show something that C++ gives you that C does not and how to get the same functionality in C anyway. Then I will explain why the C version is more efficient then the C++ version but at the same time not as safe because of programmer error potential. We will keep the example simple instead of making a Generic Stack we are going to make a Generic Swap function and for simplicities sake I am going to keep the two examples as close as possible.

C++ gives us a feature known as templates. Templates are a powerful meta programming feature that will actually generate code for us based of the the type of data it receives. They can do more then just this but this is a very common use. The main downfall of this particular method of creating swap is that if you pass in over 50 different types to swap during the course of the application you are actually generating over 50 different functions that have to be added by the compiler. So with that said here is a generic swap function in C++ using templates.

[source lang="cpp"]
template
void swap(T &v1, T &v2)
{
T temp;
temp = v1;
v1 = v2;
v2 = temp;
}
[/source]

There are 2 specific features to C++ we are using here. First we are using templates to generalize the type we are swapping and lastly we are using references so that we are actually swapping the variables passed in. This basically means we take in any type of variable and then we swap the address those variables hold. When this is compiled for each different version of swap we call C++ will generate a type specific function for us.

Now we need to make the equivalent of this function in C. The first thing to note is C does not have templates and C does not have the concept of references and it does not retain type information after compile time. So with some C trickery and clever assumptions based of the specs we can achieve the same result. There are other ways to do this but I am going to do it the 100% portable way this is both ANSI and POSIX compliant standards wise. Here is the code and the explanation of why I can do what I am doing will be explained afterwards.

[source lang="cpp"]
void swap(void *vp1, void *vp2, int size)
{
char *buffer = (char *)malloc(size * sizeof(char));
assert(buffer != NULL);
memcpy(buffer, vp1, size);
memcpy(vp1, vp2, size);
memcpy(vp2, buffer, size);
free(buffer);
}
[/source]

Ok so there is a lot there. First a void ptr is a generic pointer we can do this because pointers are always 4 bytes in size so the compiler does not care what is in them because we are just pointing to the storage location. Since we also don't know how big the data being pointed to is we also need to pass in the size. Now we need to find a replacement for our temp variable we used in C++. We don't know what type is stored in our void pointer we need to figure out what to store and calculate how big of a space in storage we need. We don't care what is stored we just want to hold that bit pattern. Because we know in C that a char is only 1 byte we can use that to our advantage to do the pointer arithmetic necessary to calculate the size of our storage. So we will dynamically allocate an array of char types to store our bit pattern. We will also do an assertion to make sure that we are not null before we attempt to copy data into this location. The assertion will bail if we have no space allocated. Next we need to use memcpy this will copy our bit patterns around for us. Lastly we need to make sure we free our temp storage location.
The main advantage of this is the application does not generate a new function for each different type we call through it. This uses the same assembly no matter what we pass into it. This efficiency does come with a price. If swap is not called properly we don't know what we will get back. Also because we are using void pointers the compiler will not complain it actually suppresses what compiler checking we do have. Also you must keep in mind that if the 2 types being swapped are actually different say a double and an int or int and a char* we enter the realm of undefined behavior and have no idea what will happen.

When calling swap with 2 ints you would call it as

swap(&val1, &val2, sizeof(int));

If you are swapping 2 character strings you need to call it as

swap(&val1, &val2, sizeof(char *));

With the character strings you still need to pass the address and you need to pass the size of the pointer to that address range.
This is important because a character string or char * is actually a pointer to an array of characters so you need to make sure you are pointing to the address of that
array of characters.

With all that said you can see how the C++ makes things like this very easy at a price of generating duplicate instructions. With the C you can see of a very efficient way to do the same thing with its own set of drawbacks on the caller side. It is very similar to what the C++ would do internally behind the scenes the only difference is they are passing through hidden type information so that they can generate exact type casting so you retain your type safety. This is a great and simple demonstration of what we take for granted when we use the various high level features of different programming languages. So next time you use these features stop and say thank you to the designers because without their efforts your features would not exist and you would have to do pointer arithmetic on a daily basis.

Last note if you read this and you still are thinking of using C over C++ the decision is ultimately up to you. Personally I love C it is a very elegant and clean language and I really enjoy using it, however, ask yourself if it is the right tool for the job because in C you have to reinvent the wheel constantly to achieve the functionality that newer languages give you almost for free.

## Some internal insite

As of late I have been having some debates with friends of mine about games/game development in general. One things that always comes up in these kinds of debates with my friends is how I am a masochist. They say I am a masochist for using C++ and enjoying looking at things from the system level.

I always tell them ever since I was little I have had a hunger for knowing how things work internally at that level.

That above statement has really got me doing some self reflection. I don't really post on here much about progress on games and what not for one reason. I never really make much progress. It is not because I don't do anything or don't understand how to make a game. Instead I always get tied up in my main interest. The underlying subsystems. I will say ok here is my game idea. Net you know it the game idea is thrown out the window and I am using it as a test bed for new rendering theories and component structures, physics tests and the like. Overall I would have to state I really don't care about making the next greatest game. I enjoy tinkering down at the low level game subsystem level.

You know all those little components that game programmers use to make their games. Render systems, physics systems, ai systems. These low level details are really what I enjoy about game programming.

I would consider myself one of the few people who would enjoy myself more if I was writing graphics engines, and physics engines. Maybe even scripting systems. The stuff that people are always looking into some game engine to do for them because they want to get their game done and could care less about how things work internally.

So I have come to a conclusion maybe I should focus my time on these things I enjoy rather then forcing myself into writing a game. Instead maybe my purpose is to make it easier for others to write games.

I would love to hear peoples opinions on this.

## Some More Progress.

As I said in my last entry it has been a long time since I touched C#. So as I was doing the port of the D3DApp framework for the DirectX 10 Luna Book, I realized quite quickly that I was trying to write C++ in C#. Not going to work. So I took a dive into the SlimDX sample MiniTri to get a general quick refresher on how a C# programmer does things. This sample + the MSDN helped a lot on giving me a nice refresher.

The code is not fully finished yet. I still need to get the font display coded and the GameTimer coded, but none the less I got a fully functional Direct3D 10 window running. The window is cleared to blue and I tacked in the functionality to turn on and off VSync. I hate when the video card transistors scream at high frame rates.

There are two things I learned from sitting down to do this. One it is really a excellent way to reinforce the learning curve of the massive DirectX API. You can't just sit there and copy the code or look at the code and port it. The best way I found to go about things is the read the chapter then implement it on my own in a C# way. The advantage is you actually learn the API not how to copy code and you can get a nice clean framework to use compared to what the author provides.
The second thing I learned is probably the biggest one. Why was a torturing my self with C++ all these years. C# is a very clean and powerful language and just looking at the code you can tell what it does. I will say the code I put together is not perfect yet or finalized in anyway but it is indeed a lot cleaner then the authors C++ code. The main reason I can see that this is so would be the removal of Macros and Preprocessor directives. Not to mention the exclusion of header files.

Now again keep in mind this is not finalized yet still needs some tweaking. Plus some more implementation but here is what I got so far.

using System;
using System.Drawing;
using System.Windows.Forms;
using SlimDX;
using D3D10 = SlimDX.Direct3D10;
using DXGI = SlimDX.DXGI;
using SlimDX.Windows;

namespace InitDirect3D
{
class D3DApp
{
private RenderForm m_Window;
private D3D10.Device m_D3DDevice;
private DXGI.SwapChain m_SwapChain;
private D3D10.RenderTargetView m_RenderTargetView;
private D3D10.DepthStencilView m_DepthStencilView;
private D3D10.Texture2D m_DepthStencilBuffer;
private int m_VSync;

public D3DApp()
{
m_Window = null;
m_D3DDevice = null;
m_SwapChain = null;
m_RenderTargetView = null;
m_DepthStencilView = null;
m_DepthStencilBuffer = null;
m_VSync = 0;
}

~D3DApp()
{
m_RenderTargetView.Dispose();
m_DepthStencilView.Dispose();
m_DepthStencilBuffer.Dispose();
m_D3DDevice.Dispose();
m_SwapChain.Dispose();
}

public void Initialize(string windowCaption)
{
m_Window = new RenderForm(windowCaption);

// Setup the SwapChain and Device
DXGI.SwapChainDescription swapDesc = new DXGI.SwapChainDescription()
{
BufferCount = 1,
ModeDescription = new DXGI.ModeDescription(m_Window.ClientSize.Width, m_Window.ClientSize.Height,
new Rational(60, 1), DXGI.Format.R8G8B8A8_UNorm),
IsWindowed = true,
OutputHandle = m_Window.Handle,
SampleDescription = new DXGI.SampleDescription(1, 0),
Usage = DXGI.Usage.RenderTargetOutput,
Flags = DXGI.SwapChainFlags.None,
};

D3D10.Device.CreateWithSwapChain(null, D3D10.DriverType.Hardware, D3D10.DeviceCreationFlags.Debug,
swapDesc, out m_D3DDevice, out m_SwapChain);

this.OnResize();

// Disable Alt+Enter FullScreen
DXGI.Factory factory = m_SwapChain.GetParent();
factory.SetWindowAssociation(m_Window.Handle, DXGI.WindowAssociationFlags.IgnoreAll);

m_Window.Resize += new EventHandler(m_Window_Resize);
m_Window.KeyDown += new KeyEventHandler(m_Window_KeyDown);
}

void m_Window_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.V)
{
if (m_VSync == 0)
{
m_VSync = 1;
}
else
{
m_VSync = 0;
}
}
}

void m_Window_Resize(object sender, EventArgs e)
{
this.OnResize();
}

public void Run()
{
MessagePump.Run(m_Window, () =>
{
DrawScene();
m_SwapChain.Present(m_VSync, DXGI.PresentFlags.None);
});
}

private void OnResize()
{
if (m_RenderTargetView != null)
{
m_RenderTargetView.Dispose();
}

if (m_DepthStencilView != null)
{
m_DepthStencilView.Dispose();
}

if (m_DepthStencilBuffer != null)
{
m_DepthStencilBuffer.Dispose();
}

// Setup the RenderTargetView and DepthStencilBuffer/View
D3D10.Texture2D backbuffer = D3D10.Texture2D.FromSwapChain3D10.Texture2D>(m_SwapChain, 0);
m_RenderTargetView = new D3D10.RenderTargetView(m_D3DDevice, backbuffer);
backbuffer.Dispose();

D3D10.Texture2DDescription depthStencilDesc = new D3D10.Texture2DDescription()
{
Width = m_Window.ClientSize.Width,
Height = m_Window.ClientSize.Height,
MipLevels = 1,
ArraySize = 1,
Format = DXGI.Format.D24_UNorm_S8_UInt,
SampleDescription = new DXGI.SampleDescription(1, 0),
Usage = D3D10.ResourceUsage.Default,
BindFlags = D3D10.BindFlags.DepthStencil,
CpuAccessFlags = D3D10.CpuAccessFlags.None,
OptionFlags = D3D10.ResourceOptionFlags.None
};

m_DepthStencilBuffer = new D3D10.Texture2D(m_D3DDevice, depthStencilDesc);
m_DepthStencilView = new D3D10.DepthStencilView(m_D3DDevice, m_DepthStencilBuffer);

// Bind views to pipeline
m_D3DDevice.OutputMerger.SetTargets(m_DepthStencilView, m_RenderTargetView);

// Set the viewport transform.
D3D10.Viewport vp = new D3D10.Viewport(0, 0, m_Window.ClientSize.Width, m_Window.ClientSize.Height, 0.0f, 1.0f);
m_D3DDevice.Rasterizer.SetViewports(vp);
}

{
}

public virtual void DrawScene()
{
m_D3DDevice.ClearRenderTargetView(m_RenderTargetView, new Color4(1.0f, 0.0f, 0.0f, 1.0f));
m_D3DDevice.ClearDepthStencilView(m_DepthStencilView, D3D10.DepthStencilClearFlags.Depth | D3D10.DepthStencilClearFlags.Stencil, 1.0f, 0);
}
}
}

## Just got my new toy in the mail

Hey guys it has been a while since my last post. So I would first like to give a few little updates to what I have been upto.

First and foremost my attempts to get back into game development was a total fail. It just did not work out. I was starting then I lost interest quickly and proceeded to get slamed into the dirt by massive ammounts of school work. On the bright side I am only 3 1/2 classes from graduation woo. After all these years of slugging it away at a pointless job it feels good to be almost to my goal of correcting my past mistakes of dropping out of college.

Now onto more goodies. I have always loved electronics such fun to make electricity do cool things and it is even a very good experience to become a much better developer. Having to deal with everything at such a low level it really brings to light some skills that can even help developers create better software at the high level. It is amazing what high level languages sacrifice often for ease of use and it is also amazing how universities do not teach there students the low level stuff really anymore.

So I have been looking into building a interesting robotics project well not exactly robotics but more of a drone project. This is a aspect of engineering I really enjoy because it is a tough project with lots of room to learn and also a larger project that can grow overtime. The issue with a lot of the simpler electronics projects is that they have small room for growth. After some design I realized I am going to need lots of power for this project so it is time for me to leave the world of PIC and AVR and move to ARM Cortex-M. The overall reasoning behind this is that you need some decent processing power to handle all the math needed for the flight controller and the smaller chips have a very hard time with this.

The board I chose is quite powerful for a development board.
Cortex-M4 processor (has hardware FPU)
Contains a mulit axis accelerometer
Contains a Mag sensor for reading magnetic fields of the earth

These few features are awesome because both sensors are needed for accurate flight and maximum stability adjustments.

The board is made by STM as well as the chip and has a built in programmer/debugger making life a lot cheaper then buying external debugging hardware. Super powerful dev package for only $10 can't go wrong. Here is a link to the site for the board if you are interested... http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF254044 Here is also a picture of the beast if you choose not to visit the link above... [sharedmedia=gallery:images:4957] Now that this is all said and done I need to test various IDE's to see what I like. Right now I am testing out CooCox on windows which is free. Seems rather solid despite being a really stripped down version of eclipse as in missing the good features. Eclipse is another option but would have to be run on linux due to the need for make and some other unix tools to function properly without having to run through massive windows GNU loopholes to get it working on windows. Commercial IDE's are not an option because for some reason the Embedded world things$4000 for an IDE is normal.

I will have some more updates on my learning in the future until then have fun coding.

## On IDE's and Editors

The development environment predicament has been a on going thing with developers for years. Constant arguments over the smallest things such as programming languages, version control tools, even the great editor wars. I find it quite intriguing how much developers really like to argue over petty things as it can be quite amusing to read many of the baseless arguments. For me personally choosing many of these items has never been difficult except for one the editing environment. That is what this entry is about trying to make sense of it all.

When I develop code I want to be productive. I think this is the case for everyone. Through the years the one thing I noticed is that the IDE or Editor you are using can have a huge effect on productivity. Not in the sense of tasks being difficult but in the sense of not interrupting the stream of thought you are trying to put into code. For me personally one of the worst things ever is to be working on a algorithm and realize you made a mistake 10 lines up and having to go back and fix it then go back and start working again. Each environment out there be it a IDE or Editor has specific features to help combat this for the most part I would think but do not hold me to it.

The IDE is the modern editor of the day. It contains quick ways to refactor large blocks of code, code completion through syntax analysis and parsing, integrates all the tools you need, and the best of all graphical debugging representations of what you are working on. There is more then just this but a solid sampling of features. The key word here is Integrated everything is there and often works with very little configuration. In my experience however the biggest downfall of the IDE is the editor. When you make that critical mistake you need to stop typing, grab the mouse, and then fix your mistake then go back to working again. The other issue is the fact that many of these features often may not have some sort of quick keybinding causing you to have to go through the menu systems with the mouse yet again. Sure the most commonly used features you have keybindings for and I am sure you have them memorized but it is the odd things that are less common that you happen to use more often then others that hurts. One such example could be the selection of text. You usually have 2 options either the mouse to select the block of code or to use shift+arrow key. This is awkward.

The Editor front you have dumb editors and smart editors. Most use old smart editors like Emacs or Vim. These lack many of the IDE fancy features and if they do have a plugin for it odds are it is not as good. The one place they excel however is editing text. When editing text even the novice with very little experience can really reap benefits. For example I have been experimenting with Emacs for a few days now and man I feel productive editing text. Moving around my characters, words, lines, sentences and rapid selection is just awesome. Want to select a line of code 10 lines up from the cursor is easy... C-u 10 C-p, C-Space C-e then DEL or if you want to cut it C-u 10 C-p, C-k. I think one of the most powerful features here is setting the "mark". You can set a mark set with C-Space C-Space then move and make your edit then use C-u C-Space to jump immediately back to where you previously were. I think the overall benefit of these features is to minimize the amount of thought interruption you have when you need to jump and make a edit. No need to grab the mouse and move the cursor.

I am not sure what I appreciate more when I am writing code. Massive Integration with some powerful features or just a great editor environment that minimizes interruption. Could code completion and refactoring really make you more productive enough to sacrifice the power you get from some of these smart text editors. I find myself making lots of small edits in code rather then massive refactors so something like Emacs makes me personally feel really productive. So it comes down to is a sacrifice for a editor worth graphical debugging tools. I have no idea either way with embedded development you are often looking at hex and binary values as well as assembly code all the time so no GUI debugger really makes it look much better.

So my ultimate question is why can't we have a IDE with a amazingly powerful editor? The best of both worlds without it being a hacked plugin that does not really work like the editor it is trying to emulate in the IDE.

Even after writing this out I still do not know what direction to go. Was hoping the post would clear my mind a bit and help me logically put out what I appreciate in a editor. I guess the issue is I appreciate the features both offer and I want both but nothing gives me both. I am not sure I have the time or energy to develop a new IDE from scratch that works how I want it to work. Eclipse is a huge mess and I doubt I can write a new editor component for it to emulate say Emacs. Ultimately all I want is a environment that understands my code and has a really powerful editor to minimize my line of thought breakage and nothing does exactly that.

What is your take on this leave it in the comments I enjoy reading what other people think and what their experiences are like with odd topics like this. Oh and no flame wars :D

## On the hunt

So I am on the hunt for some music and sound effects files. It is kind of tough to find the right stuff that is free. I could probably use some stuff from my CD collection but if I decide to let some people play Orbis that is a bad idea. The worst part is XACTS limitations for needing to use wav files only. Damn you XNAGS.

## Some Updates on whats going on

Hey Everyone,

Not many people read my journal as much as they did in the past when I was heavily into game dev but it really does not matter. For one I very seldom even post anymore. The reasoning behind this is I have greatly drifted from game development and focus more on embedded stuff.

Right now I have been very busy actually finishing up my degree WOOOOO!!!!!. The stress is building up as the work load ever increases but I know all this hard work I have been doing will pay off. For those who did not know I am getting a BS in Information Systems Security and so far while working 48 hrs/week at my dead end job, working on hobby electronics, enjoying my firearm shooting hobby, and school I have been able to stay on the dean's list. *pat pat* I am really getting excited as this is a huge step for me.

I really do not blog much like I have stated. I have tried to do my own external blog but I always seem to not have the time hopefully one day I can get one going regularly again as I really do like writing.

In the name of my firearm hobby I am adding a new weapon to my collection. Currently I have a Springfield 1911 Range Officer edition .45 cal. I will be adding within the next few days (Can't wait for it to arrive longest 7 days of my life) a WW2 Russian Mosin Nagant bolt action rifle. This rifle shoots a 7.62x54R cartridge. Very powerful round which can easily punch right through cinder block. The bullet itself is a .30 cal right with the 308 and 30-06. The R means it is a rimmed cartridge the 54 basically dictates the cartridge size if I remember correctly. One of these rounds packs more of a wallop then a AK-47 round which is a 7.62x39. The 7.62x54R was designed as a long range round optimized for velocity which increases the accuracy and distance. This round is very accurate from 300 - 500 meters and can easily hit a human body sized target out towards 1000 meters. The Mosin was not just a infantry rifle for the longest time it was also the Russian sniper rifle of choice until the Dragonov was developed. So excited can't wait. I will be sure to post some pics when I get it.

As for hobby electronics I will be posting some more info on this project here as well hopefully. I am currently building what I call an audio trigger system. Essentially the micro controller waits for an audio pulse and uses this pulse to trigger an action. In my case the first project using this small subproject will be a audio triggered stopwatch. Then after this the trigger subsystem will also move to an audio visualizer project.
This project really stretches my electronics knowledge as there were some interesting hiccups I have had to design around. The code is simple the circuits are the hard part for a guy like me. Because of this project I am learning and actually understanding what is going on. The design of this project needs some preparation for a post so it may be a little while and quite long. Hope to get that together soonish.

Feels good to write again cya guys around.

## The Mosin Nagant is here

As I promised the Mosin Nagant has arrived. The Mosin I have received is 1942 Izhevsk 91/30. I think it would be best to give some background before the pictures.

The Mosin Nagant was originally designed by the Russians in 1891. The approximate pronunciation of Mosin Nagant is (Moseen Nahgahn) due to the Russians emphasizing vowels over consonants. Over the years they made some modifications to the rifle the most obvious modification was the switch from a Hex to a Round receiver to produce more accuracy. My particular year is a very interesting year for the Russians. In 1942 the Russians were in some very heated and significant battles to protect their homeland from the unstoppable German war machine. One such example was Stalingrad which everyone here should even know about. This meant the Russians were in a tight bind and really needed to get more weaponry out to the soviet soldiers so often the refurb process in the arsenals was quick and half assed so to speak in order to the the rifle out on the field. In 1942 the Mosin Nagant was still a mainstay weapon for the Russians due to their lack of a efficient Assault Rifle. This meant they suffered in medium range combat as their only other weapons were really the PPSH sub machine gun and some shovels and grenades.

The Mosin Nagant was a top notch rifle and very rugged. Accuracy was a key point in designing the Model 91/30 and other models as the sport a whopping 28 3/4" barrel or larger in some early models. They were designed and sited in to use the Bayonet all the time as it was Soviet doctrine to never remove the Bayonet. Hand picked the most accurate 91/30's were retrofitted with a bent bolt and often a PU scope or some other model scope for the snipers. The 91/30 was used as the Russian sniper rifle all the way up to the cold war when they designed the Dragonov sniper rifle based off the AK-47. Even during the post war time up to and including the cold war Mosin Nagant's were still in use and manufactured but in a Carbine form known as the M44. Numerous other countries also used the Mosin as many of them were part of the Soviet Block at some point or another including Poland, Hungaria, Finnland, and Bulgaria. Many other countries outside the Block used them as well including China, and the North Vietcong. Even today there have been reports of terrorist forces in Iraq, and Afghanistan are using Mosin Nagant rifles.

As stated above the rifle was designed for accuracy. The 7.62x54R was designed as a high velocity cartridge. To give some perspective with some Russian Surplus ammunition ballistic test using 148gr LPS ammunition which is a Light Ball ammo with a steel core instead of led. The muzzle velocity (this is as the bullet leaves the barrel aka 0 yards) sits around 2800 feet per second+. The impact force under 50 yards sits around 2800 foot lbs per sq inch. With the right configuration of load this rifle and push over 3000 feet per second. For those who do not know velocity and twist ratio really decide the accuracy of the rifle from a ballistic perspective. These rifles can easily hit out to 1000 meters if needed.

Ok now more about my rifle. My rifle was manufactured in 1942 by the Izhevsk arsenal in Soviet Russia. This is a wartime rifle in a wartime stock meaning the stock was not replaced post war. The rifle has been refinished by a Soviet Arsenal even though it appears that the refinishing stamps are missing, however, this is normal they forgot this stuff all the time. The rifle is also known as all matching numbers. This means the serial numbers on all the parts match which is good. I am 99% sure the rifle was force matched which is well known for military surplus as the fonts look slightly different on the stamps. There are no lineouts on the old serial numbers they were probably totally ground off and then re-stamped. There is lots of black paint on the rifle as well which was common to hide the rushed bluing jobs and light pitting. One thing you will also notice is a amazing stock repair job done by the Russians on the front of the stock. When it was done I do not know but it really adds to the unique character and history of the rifle.

The best part of this rifle is the fact that it is one heck of a good shooter. Had her down the range and it still functions great. The trigger does take some getting use to I estimate the trigger pull is around 8 - 9 lbs possibly 10 lbs. I would estimate the rifle weighs in at about 12 - 13 lbs or so.

As promised here are some pictures. Due to there being some 18 pictures or so I will just post the link to the album and you can check out a piece of history. http://s752.photobucket.com/user/blewisjr86/media/DSC_0001_zpsfbd2b09e.jpg.html?sort=9&o=0

## Web site mock up complete.

So I am in the process of starting up a small indy game company. It will start as a one man operation pritty much and the plan is to release the games for free. Just a little something to occupy some time really. Who knows maybe it will take off and get bigger. But not worried about that. So through some research I realized that now a days a lot more goes into a website then XHTML/CSS and PHP. So I broke out the rusty Gimp skills and put together a entire web site mock up. This is the result of many hours of work I would estimate about 7 hours of work with research time included. I wanted to get this layout just right so I was tweaking stuff constantly. The next step will be to splice up the site into small images and then use those with XHTML/CSS via image replacement to build the functional site. I will also be using PHP to deliver database driven news.

I would like to know your opinions on the mock up. I am a big fan of constructive criticism. Click the thumbnail to make the mock up bigger.

## Hello from my new desktop.

Hello new GDNet. First off I must say I really love the look and feel of the new website just phenomenal. Despite the small hiccup where somehow during the migration my password got corrupted the staff did a wonderful job in getting me the information I needed to get up and running again on the site in record time. Excellent support guys.

Now on to the real reason for the post. I am saying hello from my brand spanking new iMac. It takes some getting use to but I am in love. The computer is fast, responsive, well integrated, and extremely powerful all in one. Not to mention it feels great to have the power of a *nix kernel + tools without the really nasty support issues and continuity/integration issues of the open source Linux system. Granted I was able to do wonders with a Linux system but I just got sick of the crappy support and things getting broken all the time with kernel updates and what not. So I decided it is time to make the switch to a Mac. Boy I am so glad my $1200 was well spent I would have been pissed if I hated the system. So what is in this beastly computer. Keep in mind I did not by the best iMac on the market so the video card is not the top of the line but I could not justify spending the extra$300 for the kind of development/other purposes I use my desktop for. I am a console gamer so my PS3 handles that for me.

So the specs.
21.5" Screen with speakers mic and webcam built in.
Mac OSX 10.6.6
Intel Core i3 3.06 ghz
ATI 4670 256 mb
4Gb of 1333 mhz ddr3
500Gb serial ata hd
8x Superdrive + sd card reader
Bluetooth wireless keybaord
and a Magic mouse Bluetooth wireless.

So my first impressions is the integration with the hardware is slick. For the specs the machine is a total speed demon. The construction quality is superb I am really impressed with the care taken to make sure everything is top notch materials aka aluminum and glass instead of plastic. The clarity and brightness of the monitor is top notch as well. The os ui is easy to navigate and does so without taking away the power house *nix features and gives easy access to those as well. My favorite so far is the Magic mouse. This mouse is the most well designed / innovative things I have ever used. First it is very aerodynamic but at the same time it remains comfortable and reduces wrist stress. Second it is constructed out of aluminum and the top of it is glass. Great responsiveness from the mouse with great precision. My favorite feature is the lack of a scroll wheel and only having one button. The mouse is multitouch capable. This allow for 1 button to actually work as both right and left click by recognizing which finger is touching the mouse at the click time. Sliding the finger down the mouse allows for scrolling and you can even flick fast it hit the end or beginning of a list or web page. Flicking two fingers left or right allows for back or forward in your web browser just fantastic. You may think the mouse might go flying but it does not move at all thanks to the nice weight to the mouse not to heavy not to light just right. Hold down control and move your finger like you are scrolling and you zoom in and out of the desktop from pointer origin. Very nice for accessibility or doing web video screen casts. The keyboard is nice as well. Very comfortable. I was using a microsoft ergonomic keyboard however, this keyboard is just as stress free. They got just the right angle and the key placement is excellent. The keys don't take much effort to respond to input so it is great for touch typing like I do. It also give you accessibility to all the features of the iMac/OSX like ejecting a cd, expose, brightness, volume, hidden widget dock and media keys.

Software installation is a breeze and initial setup is amazingly simple. Can't wait to give the TimeMachine backup cloud a spin to back up all my documents and such as well. Will let you know how that works out.

Conclusion if you are on the fence of buying a Mac or sticking with windows the answer I can give you is if you play a lot of games and like to constantly upgrade you hardware to stay cutting edge use windows and build your PC I have done that. If you want a amazing stable computer experience without any hiccups and don't mind not having the best video card on the market go with a Mac you won't be disappointed not to mention you get all this great and amazing software that you will never see on a PC. I will say the software for Mac computers is just phenomenally well designed and works like you expect it to with very few bugs. I hit a few bugs with the Safari web browser so I am using Firefox atm but it is not Safari's fault I blame it on bad web coding from my online universities software. I am sure in time those bugs will go away especially with the impressive power of the Safari beta getting ready for HTML 5. The decision is yours either way you will be happy as for me I think I am now officially addicted. I was skeptical at first but now I see why they say once you go Mac you never go back.

## Just a ponder

Currently I am pondering just learning DX right off the bat or to start out with SDL do some 2d and then jump to DX. Right now it seems SDL and 2d might be a good start off.

## Closures and Python 2.7

Wow Hello again GDNet it has been quite a while since I last actually logged into the site. As for what I have been up to; well I have been drowning in school work and honing my development skills. Lately I have mainly been using Python and experimenting with the Python Flask micro web framework. I will say it has really been a joy getting away from the world of C/C++ for a change. So why am I back here after I have left my good bye a while ago. Here is the thing I actually miss this site I lurk on it almost every day anyway so why not. I am going to be starting up a new project game related so stay tuned.

Now for the reason for this blog entry. As I stated I have really been honing my programming skills as of late and dealing with some odd languages mostly in the functional paradigm. One thing about functional languages is that you don't have OOP so you need to find alternate ways to create somewhat of a similar effect and it turns out Closures are just that. Many people ask why not just use OOP then. Well the issue really arises because of the way most books typically teach OOP which leads to very sloppy inheritance and can cause deep hierarchies. This issue with this is it makes your code a maintenance nightmare. The other with the way most books teach OOP is they create a notion of taxonomies which leads to people creating Classes that should have never been classes to begin with. Note I am not saying OOP is evil I am saying the way OOP is often taught is evil. On another note OOP can lead to issues with parallelism where the state of the object becomes out of sync when multiple threads are involved and closures solve this problem quite well.

[Edit Thank you TheUnbeliever]

So what is a closure. Most definitions of what a closure is uses odd jargon like lexical structure and referencing environment and such. The definitions are not very clear unless you have a strong functional programming background so here is a more clean definition that I stumbled across.
A closure is a block of code that meets 3 particular criteria...
1. It can be passed around as a value
2. Can be executed on demand by anyone who has this value
3. It can refer to variables from the context in which it was created in (lexical scope, referencing environment)

So why are these useful... For one they allow you to maintain state between calls much like an object, very useful for creating callback, can be used to hide utility function in the function providing a cleaner api and they can even be used to create many programming constructs such as loops. These constructs are very useful over all and can really simplify to code you write and need to maintain in large complex systems.

Python has had support for closures since version 2.2, however, there are a few issues. Issueless support comes in Python 3.x. The issue in Python 2.7 is a Python Scoping issue that forces the closed over variable to be read only.

Here is an example of a closure in implemented in Python with the exact issue of Scoping...

def counter(start_pt):
def inc():
start_pt += 1
return start_pt
return inc

if __name__ == '__main__':
func = counter(1)
for i in range(10):
print(func())

So what does the code do it is simple it counts up 10 numbers from an arbitrary start point. So what is the issue well the issue is with pythons scope this actually generates an error the exact error is UnboundLocalError: local variable 'start_pt' referenced before assignment. This is the same issue the author of the post was having and it is because of the way python defines the scope of a variable. Basically python determines the scope from the innermost first assignment it finds which means when we increment start_pt we are accessing a variable with no initial value yet because python has the scope confused and forces the variable to be read only.

Python 3.x solves this scope problem by implementing a new statement called nonlocal here is how it looks...

def counter(start_pt):
def inc():
nonlocal start_pt
start_pt += 1
return start_pt
return inc

if __name__ == '__main__':
func = counter(1)
for i in range(10):
print(func())

The output of this code will be as expected 2 3 4 5 6 7 8 9 10 11

But again this is only in Python 3.x what if we can't use Python 3.x because we need support for API's that are not Python 3.x compatible yet. We want to use Closures but also want to avoid the scope issue. There are a few solutions to this problem. Lets go through 2 of them one which seems kind of hacky and other which is less hacky but not a true closure but instead just mimics the closure concept. Here is the first which is a true closure that uses a Python mutable list to work around the Scope issue.

def counter(start_pt):
c = [0]
c[0] = start_pt
def inc():
c[0] += 1
return c[0]
return inc

if __name__ == '__main__':
func = counter(1)
for i in range(10):
print(func())

Basically what we do is create a new variable that is a 1 element mutable list and place our start_pt in this location. We can't use a standard variable c that is not a list because c becomes read only inside the inner function which results in the same issue as before giving us the same error as before so using a mutable list works around the issue and we get the expected output of 2 3 4 5 6 7 8 9 10 11. This is kind of sloppy looking so lets look at the not a true closure but mimics a closure alternative. Note I am violating standard Python naming conventions here because we want the user to think they are using a lexical closure so here is the code.

class counter(object):
def __init__(self, start_pt):
self.start_pt = start_pt

def __call__(self):
self.start_pt += 1
return self.start_pt

if __name__ == '__main__':
func = counter(1)
for i in range(10):
print(func())

So here we turn the closure into a mimicked closure by using a class to preserve the state instead of the mutable list.
We also force our class to be executed only as a function by using the __call__ magic method. So here we have a closure but it is not a true closure but actually and object disguised as a closure.

So there you have it we were able to discover 2 ways to work around the Python 2.7 issues with Scoping and still be able to use our non 3.x compatible libraries. Both methods are valid you can choose which one you want to use. Sorry the example is so simplistic but it really is an easy example to get the point across now you can use your favorite language and use the powerful feature of closures the method you choose is up to you or you can be a real man and jump on Python 3.x

## And the fight begins

Nothing much to say to day besides I am fighting with Gimp trying to make some art. I have done about 50 different attempts to make a orb :P. Fun fun fun I suck at art so bad wish me luck.

Edit: Here is the orb I like best so far what do you guys think.

## Learning Objective-C

Well now that I have a iMac I have been working though a Objective-C/Cocoa book to wrap my head around the main language used by Apple Products. My initial impressions of the language was WTF why can't they just use C++ like other platforms. As I go though the book however, my opinions have been changing. For those that don't know Objective-C is basically a layer on top of the C compiler to introduce object oriented programming. You say why C++ does that. Yes C++ does that but not in the way Objective-C is. Objective-C is what I like to call a compiled static dynamic language hybrid. One of the most powerful features of Objective-C is the capability to modify code on the fly with code right down to the basic objects that are at Cocoa's core. Ruby programmers would know this as monkey patching. First a word of warning Objective-C is worthless on other platforms besides apple platforms because the reason objective-c is so powerful is because of the Cocoa framework that apple provides. Without Cocoa Objective-C is just another C + Objects language.

Now the most confusing thing for me with OC at the moment is the syntax. When you have an object you call its methods with the bracket syntax. For example...

OBJFoo* foo = [[OBJFoo alloc] init];
[foo sayHello];
[foo release];

The basic gist is [ ] in OC methods are called messages go figure damn IT types love their fancy words.

So lets say foo has a property call helloText. We can set this text using the set message and we can get the text using the get message.

OBJFoo* foo = [[OBJFoo alloc] init];
[foo setGreeting:@"Hello Foo"];
NSLog(@"%@", [foo greeting]);
[foo release];

With the new version of objective-c you can now use dot syntax to get at the accessor methods by saying foo.greeting = @"Hello Foo"; and foo.greeting to get the message.

This just adds to the confusion in my opinion. Just when I was understanding that everything in objective is pretty much a message and got use to reading the bracket syntax they throw this dot syntax at me. Yes I understand dot syntax but you can't use dot syntax for messages in general only accessors aka properties. So I have personally started converting all the code in the book to use brackets because for me it is easier to understand objective-c code with the brackets. Take this for instance...
Say we are using this window object inside of a class only so we prefix with self to make more sense.

NSWindow* myWindow = [[NSWindow alloc] init];
NSButton* myButton = [[NSButton alloc] init];
[[[self myWindow] contentView] addSubview:myButton]; // this is more understandable then
// this

The reason I find it more readable is because
get my instance of the myWindow object and then get its contentView now add the my button to our array of subviews.

the dot syntax
is harder to understand what it is doing unless you 100% understand that the dot syntax is only used for properties and or instance variables.
yea the dot syntax makes the code look a bit cleaner but at the same time it is easy to glance at it and forget what is going on especially if you are not familiar with the underpinnings of objective-c. I think apple should have let this one out for consistencies sake.

Despite my syntax hiccups I am really starting to like the language overall as a whole. It is very well designed especially because of the amazing Cocoa framework.
I understand I did not go into detail on a lot of stuff because in all honesty I am just starting to get over the few hurdles the language throw's at me. But rest assured you will see more. My first project in the coming future is going to be a RSS reader. I understand that this is a game dev site but who cares it will be a interesting write up.

## Project Preparations

Well a friend and I are in the mist of starting a new project for the summer and maybe many summers after. So in the process I am learning how to write DLL's with C++. Right now I am sticking to learning static linked DLL's because hopefully we will need nothing other than that. If the time arises tho we will make it Dynamically Linked. Currently in the process of learning I have run across a problem. Every thing is compiling fine with the dll and test app. However with the test app the exe is never getting created. I am in the process of figuring out why this is happening. But I am not quite shure. Maybe it is a issue with the lib being linked. However I don't think this is the case because The Microsoft compiler should complain about a issue like that. Darn you Visual C++ 2005 express edition.

## Yes I be a contemplater

Ok after much thought about what I want to do game development wise my final decision is to use Java and JOGL. I made this decision for a few reasons.

1. Ease of cross platform distrobution via Web start.
2. I am extreamily more fluent in Java then any other language basically because it was one of my first languages and I studied it in college.
3. I already have books for reference on Java and OpenGL incase I need to look something up.

It is amazing what contemplation can do especially with a goal in mind.

## Wow Long Time

Holy crap has it been a long time since I posted here. I have been so tied up with school and work that I kind of just fell of the face of the earth
being totally swamped with no real time to do much of anything.

I just recently due to school got back into doing some programming. Partially because of the nature of the class and me being as lazy as I could possibly be just not wanting to go through all the repeditive steps.

Right now I am taking a statistics class and calculating all of the probability stuff can get very very long and repedative to find out the various different answers. For instance when finding the binomial probability of a range of numbers in a set you might have to calculated 12 different binomial probabilities and then add them together so you can then caluculate the complement of that probability to find the other side of the range of numbers. It is just way too repedative in my liking.

The advantage of this is it really re-kindled my love of the Python language. I just wish the language was a bit more useful for game development sadly. The performance hits are just way too high when you progress onto 3D.

After I finished my homework I decided to do a comparison of the Python and C++ code required for calculating the binomial probability of a number in a set. This is the overall gist of the post because it is really amazing to see the difference in the code of two examples of the same program and it is simple enough to really demonstrate both in a reasonable amount of time. The interesting thing here is from a outside perspective runing both they appear to be run instantaniously with no performance difference at all. So here is the code btw it is indeed a night and day difference in readability and understandability.

Python (2.7.3)

def factorial(n):
if n n = 1
return 1 if n == 1 else n * factorial(n - 1)

def computeBinomialProb(n, p, x):
nCx = (factorial(n) / (factorial(n-x) * factorial(x)))
px = p ** x
q = float(1-p)
qnMinx = q ** (n-x)
return nCx * px * qnMinx

if __name__ == '__main__':
n = float(raw_input("Value of n?:"))
p = float(raw_input("Value of p?:"))
x = float(raw_input("Value of x?:"))
print "result = ", computeBinomialProb(n, p, x)

C++

#include
#include
int factorial(int n)
{
if (n n = 1;
return (n == 1 ? 1 : n * factorial(n - 1));
}

float computeBinomialProb(float n, float p, float x)
{
float nCx = (factorial(n) / (factorial(n - x) * factorial(x)));
float px = pow(p, x);
float q = (1 - p);
float qnMinx = pow(q, (n - x));
return nCx * px * qnMinx;
}

int main()
{
float n = 0.0;
float p = 0.0;
float x = 0.0;
float result = 0.0;
std::cout std::cin >> n;
std::cout std::cin >> p;
std::cout std::cin >> x;
result = computeBinomialProb(float(n), float(p), float(x));
std::cout return 0;
}

Sorry for no syntax highlighting I forget how to do this.
The bigest thing you can notice is that in Python you don't need all the type information which allows for really easy and quick variable declarations which actually slims the code down quite a bit. Another thing to notice is you can prompt and gather information in one go with the Python where in C++ you need to use two different streams to do so. I think the Python is much more readible but the C++ is quite crisp as well.

## The project from insanity

Wow has it really been this long since I posted a journal entry. Man time really flies right by it is just insane. Over the last few months I have been going through the motions of designing a project. The project is rather over ambitious for sure and
99% of the worlds population would probably call me insane. Even as I was going through and laying out the design I realized how insane
I really was but it does not matter I want to work on something long term a huge almost impossible endeavor just because I can. I know I have the
capability to complete said project and at this point it is more figuring out how to approach the project effectively. So lets get into some of the
decisions I have to make to do so after I give a brief layout of what it is I want to do. First and foremost my game is a RPG but not the typical RPG. I don't want to create just another RPG or ARPG to add to the meat grinder.
I want to create a RPG that can evolve and hold longevity without costing a player 1 penny. This project is not about making money or creating a
business it is about creating a community. The key goals of this project all combine around this fact of community and having friends be able to gather together and adventure.

A modular scenario based system (the ability to mod in your own custom adventures in a easy way)
A Turn based Action system
The ability to customize the rule set
The ability to customize various actions in the game (spells, attacks, etc...)
The ability to use premade or custom assets for the scenario's
The ability to play solo or with friends
Open Source/Cross Platform (This project is very ambitious and 100% free + I love open source)
As far as technologies to use I have no clue at the moment. I ruled out Unity/UE4 simply because the do not fit the open source motto even if
they would be great to use they just do not fit the project. I also need something very flexible that will allow me to create the necessary
tools needed to create a good environment for building the custom scenario modules. Since I have a wide variety of applicable programming skills I began evaluation of some potential target technologies. Currently I am evaluating
JME3 which just so happens to be very nice to work with despite some of the quirks and lack of direction in its tooling the core engine itself is
really well done and easy to pick up on. +1 for great documentation. The only thing I really do not like here is the Netbeans based SDK as I find
it very off putting for some reason or another, however, it may be possible to work outside of the sdk and develop some custom tooling to replace
some of the features. The goal is to abstract creators away from needing to actually touch the programming language behind the game and from
having to install the whole engine + sdk to create scenarios. I have also looked at SDL/SFML way back in the past but the new versions for sure are very slick, however, I am not sure I want to go the route of
a 2D game. It for sure would work and it would solve the issue quite quickly of having to work around the JME3 SDK system. This approach could
however remove some people from wanting to help contribute to the project due to the use of C/C++ . Sure there are other bindings but they tend to be quirky and awkward to use because they rarely follow the structure the other languages are known for. Any input on other tech that I did not mention would be much appreciated just leave it in the comments and if you want you can even just
comment to call me insane. Can't think of anything else to type so see you again soon.

## A humble apology and more

[Warning long Entry]

Hello GDNet. I know I am known on this site as the person who can never make up his mind. There are many reasons for this but the main one was previous microsoft anti sentiments. I use to have a rep over the base 1000 on this site for helping numerous people out on their path to game development. Sadly one thing I did that I will always regret bringing to gamedev was expressing my opinion about windows vista based on a /dot article without ever having tried out the operating system myself. The GDNet community was always here to try and help clear up my confusion why would I even do such a thing.

I must say GDNet tought me the bigest lession of my life. Don't express false information based on something you haven't experienced yourself. I am now 22 years old woot and after much reflection I feel I have matured much more thanks to GDNet and I can now return with all microsoft anti sentiments gone.

Why are they gone well when I built my new PC I decided to try it out for myself and I must say it is the best operating system I have ever used distpite some small annoyances. With that said I decided to go back and re-evaluate my decisions on what language to use of the many I know for game development.

I sat back and said what is my favorite language to program in. The first thing that came to my mind was C#. Very elegant and very powerful. So there were a few options for me to choose from SDL.Net/Tao, SlimDX, and of course XNA.
So first thing I decided was should I go cross platform. The answer was a big No. One thing I did realize while I was away was that Linux is going to go nowhere with its additude about everything not open source. Open source is a great concept to help people learn and get involved but it goes horibly wrong when it is a religion. So with THE LESSON I learned from my big mistake here on gamedev I said I don't know enough about XNA to make a decision here. I have heard mixed opinions everywhere and alot of which are negative in nature. I decided to go and find out from the people that know the capabilities of XNA best Microsoft.

So I went to the creators website and asked my questions and had a solid discussion with a XNA MVP, and even 2 XNA users and The ZMan himself stepped in. I learned that XNA is indeed very powerful and not limited really whatsoever besides being bound to DX9c. Yes there are some limitations to the XBOX but the only real major one is no 3rd party dlls allowed with a few exceptions for instance like the XSI dll. I was greated with very open arms and all my questions were answered seriously. So I chose XNA. From the information I gathered without too much detail I learned it is very powerful and quicker to develop with. C++ has always had my head spining with bugs.
------------------

On another note I did some thought on why I never really finished any projects in general. Turns out that I would have one good idea for a game and then I would just snowball it out of control till it became overwhelming. I hear this is a common mistake especially among creative people. With that said I decided to get some help. I learned about Agile development and I am going to use this aproach with the guide of my XNA book and it looks like it will really keep me on track.

------------------

Once again I greatly apologize to all of GDNet for my major misgiving to the community and just want to let you know I am back on track and ready to earn my rep back.

## Book Review: Cocoa and Objective-C Up and Running

Well I just finished my first book on Mac OSX software development. First and foremost I should go into a little bit on why I am in the process of learning Objective-C and what drew me into using this book in the first place. First reason I decided to dive into Objective-C is my new desktop/development platform is a iMac. Secondly the new phone I will be getting once the tax return comes in is a IPhone 4 due to it hitting my carrier Verizon this month. Currently I have a Android phone and I am very very disappointed maybe it has to do with the fact that mine is a samsung not sure. I want to be able to develop applications for both my phone and my desktop computer. To have any potential to sell these applications I need to use the right tool for the job and according to apple this is Objective-C/Cocoa. Now that is out of the way what drew me to this book.....

First when I was looking at the selections of books out there I saw a few very high quality titles. I on the other hand have experience in development in both GUI and games from a hobby perspective and have a solid background in programming concepts. So I did not really want a long drawn out book because I know how to read a APIAPI doc I just want a feel for the language. With a background in C and C++ already this was not too much of a leap for me. This books is short and to the point unlike some others but that can be a flaw now onto the review.

After reading this book I must say this is not a book for beginners. It says it was written for beginners, however, if you have never programmed a line of code in your life this book moves way way to fast. First you need to understand that Objective-C is just a layer on top of C so you are basically using C with some runtime extensions. With this in mind this book covers C in 2 chapters. I learned C from the K&R book so this is ok for me as a nice swift refresher but for a newbie to programming this is just not going to cut it. Next the basics of OOP are covered in just a single chapter. UH..... sorry not for beginners again it took me C + structs, C++, Java, and C#, and Python and a few years of experimental throwaway practice projects to get this concept right. It took me 1 year just to understand why Interfaces in C# were even useful in the first place. Took even a year before polymorphism slapped me in the face. Uh to go on even further the basics of Objective C are again taught in 2 chapters. NOT FOR BEGINNERS can I say it enough. With no experience in programming a newbie to software development won't understand a damn thing and be confused as all hell after the first 4 chapters of the book.

Ok with all this said I still thought this was an amazing book to learn from. First and foremost I was able to breeze through the first 4 chapters and get right into learning the syntax and the way Objective-C works. After 2 chapters of learning the new runtime/language extensions it got me right into the Mac OSX Cocoa API framework kind of like the .Net framework but for Objective-C. This is where the final 4 chapters of the book take place so you can write effective GUI apps for OSX. The last chapter of the book gives some useful pointers and some more pointers to further information to learn more. That is it 11 chapters compared to the typical 30 chapter books out there. Now some people may think this is not a good thing personally I found it refreshing.

The biggest commendation I give to this author in his book is the effective use of the tools apple provides ala XCode and Interface Builder. These tools are amazing and I am so happy the author did not do what a lot of Java books do and force you to use notepad and the command line. Face it people yea Vi and Emacs are great for a quick and dirty file edit but we are in the 21st century now and have better tools use them damn it. It is amazing at how powerful these Mac tools are and if you don't learn them or use them you are stupid and the author even rightly states so. The author does not souly rely on interface builder because if you want to make your app truly fluid like Mac apps tend to be you do have to write custom view boilerplate code and they author definitely goes there. Another thing is the author does something I personally really like first he explains the concepts of the chapter then he puts you into code working on a project. This is great using what you learned helps learning it.

Word of warning there are lots of Text Walls in this book. The author expects you to understand previous concepts so a lot of the projects are code code code with some explanations here and there. If you payed attention and learned the previous content of the book you should be able to easily parse the code and understand what is going on. Personally I like this style because it really makes you think about what the code is doing and not just telling you what it is doing. If you want to get anything out of this book you have to do every example to completion.

The author also uses screenshots in a very effective manner for tool demonstrations to make sure you got it just right. This author really takes his tools to heart and I love that. Like I said earlier he states you are stupid if you don't use the tools apple provides because it makes things so much easier and makes you so much more productive. He goes into how to hook up Actions, Outlets, and Bindings through interface builder and even shows something that made my jaw drop and that is XCodes amazing data modeler for the Core Data framework. The Core Data framework is a persistence framework for cocoa that allows you to save data across sessions and even gives you some juicy free stuff along they way like undo and redo.

Overall I feel this is a amazing book and that I learned a lot of information from it. I definitely think if you are NOT A BEGINNER developer and want to dive into OSX development this book is a great way to hit the ground running. Now I just need to put this stuff to use and start a project. More on that next blog post....