So, I was reading an article today which piqued my interest, in some ways disturbingly:
http://m.computerworld.com.au/article/314817/nicta_wins_race_secure_l4
Now, the article sites a grand achievement for a micro-kernel, especially for one focused on security. That is not my problem. The line in the article that says this was a problem for me, however:
"For example, the microkernel is impervious to buffer overflows, a common form of software attack where hackers take control of programs by injecting malicious code."
Now, I know what you may be thinking: yeah, that's great. So what?
Well, I am in many ways appalled that this is still one of the major programming security problems to date, especially since it goes back since programming first started in many ways. So, I did some research to actually see how big a problem this still is.
Turns out, if you look up buffer overflow on Google, Bing, Yahoo, etc, you end up not only getting the Wikipedia definition and status of it, but you also get tons of security firms trying to sell you solutions and training to handle this problem. And the majority of these errors comes from a single aspect of the software: lack of proper boundary checking and the size of data being written to the buffer.
Now, having gone through multiple programming courses, with focuses on Java, C, C++, and many scripting languages, this is horribly surprising that in my recollection, we never once really touched on handling a simple situation such as making sure your buffer is bounded and checked correctly.
So, this got me to thinking: shouldn't there be, at least in pseudo-code somewhere, be some list of programming patterns or such for something like this? Maybe some actual class / object patterns for this, etc?
It turns out there are, but most of them are locked in some obscure text books or completely out of the way or unrelated websites. Such as, there are patterns for a Fixed Size Buffer for Real-time Systems (example here). However, like most of these tidbits of knowledge, they are either obscured to the specific domain in which they belong, making them inaccessible to many programmers and engineers, or they are just described and no actual psuedo-code or structure is given for ideas.
So, I ask my question, why not have some common programming patterns, that everyone can find, interpret, and use?
I personally may start amassing a few of my own I've used quite often and start noting them down here and there. It may be worth someones time, and eventually, it could be compiled for more people to use.
If anyone has any ideas on some good patterns that may match this, shoot me a comment or an email, and I'll make sure to note it. I really think this is something that could be helpful to not just new programmers, but to even older programmers who often have to re-invent the wheel or remember how to do something nifty and elegant, yet simple, that they did before.
Tuesday, August 18, 2009
Thursday, August 6, 2009
Neverwinter Nights 2 Mod - Lands of Neremier
So, I've finally gotten around to working on a mod I've been planning. I originally started the the mod concept when I bought Neverwinter Nights: Platinum Edition. However, it was a while afterward that I finished most of the design planning on my limited schedule, by which time Neverwinter Nights 2 was just around the corner. So, I waited to that I could try the new Electron Toolset. Once I got knee deep in classwork and working co-ops, this got pushed to a back burner project, which I finally started formally yesterday.
So, I've begun working on the areas for the first few areas of the mod, doing some pretty extensive design work on the first areas of the mod where the players start. I will try to post some screenshots of the current areas when I get some time and may make a section of my portfolio on my site dedicated to my Neverwinter Nights 2 mod.
So, I've begun working on the areas for the first few areas of the mod, doing some pretty extensive design work on the first areas of the mod where the players start. I will try to post some screenshots of the current areas when I get some time and may make a section of my portfolio on my site dedicated to my Neverwinter Nights 2 mod.
Sunday, August 2, 2009
New Opportinities - Working on Gaming Articles
So, in the past few weeks, I've been working on a new job I've gotten, which is for a website called FreeMMOGamer. For the site, I've been hired to work on review articles, opinion articles, and anything that comes to mind (with approval of course). Hopefully, in the next few months, I'll have several new articles published here, which will give some of my opinions on current and upcoming MMOs.
For my articles, I'm also thinking of adding a little bit of a developer perspective, to give the articles some new flare and perspective, which will be unique.
We'll see how this goes.
For my articles, I'm also thinking of adding a little bit of a developer perspective, to give the articles some new flare and perspective, which will be unique.
We'll see how this goes.
Thursday, July 23, 2009
IL Framework Generics
So, right now I've been working on the ILGenerics namespace for the framework /What this namespace aims to do is to create a generic implementation of several entities, graphics, resources, states, and actions that are used by various possible entities and actors within a game. These generics can then either be used directly or used as the base classes for other values.
These generics are meant to be the first show of power that the framework has, in that the generics will be some of the most basic types of states, actions, and the like that a system could possibly need. What the namespace will add in general will also be very powerful, giving access to a variety of resources that can aid with making development flow much faster and more fluidly.
I will eventually post the most recent diagrams and documents, which will further explain my reasoning. I need to move the documents to a new host (eventually, probably to a web server I'll rent), which will allow for better configuration management and also allow for all of my work to be hosted from a central repository, rather than on my desktop and backed up on a separate hard drive.
Until later. After these generics are finished, I will finish up the DirectX 9 wrapper classes that allow for the easy creation and extension of DirectX applications, and then will begin on creating my first game with the engine, a proof of concept of how powerful and flexible it can be.
That's it for now.
Oh, also of good note is that I got my personal website up. It can currently be found either at http://www.se.rit.edu/~brb6127 or http://people.rit.edu/brb6127. Feel free to look and investigate my previous work.
These generics are meant to be the first show of power that the framework has, in that the generics will be some of the most basic types of states, actions, and the like that a system could possibly need. What the namespace will add in general will also be very powerful, giving access to a variety of resources that can aid with making development flow much faster and more fluidly.
I will eventually post the most recent diagrams and documents, which will further explain my reasoning. I need to move the documents to a new host (eventually, probably to a web server I'll rent), which will allow for better configuration management and also allow for all of my work to be hosted from a central repository, rather than on my desktop and backed up on a separate hard drive.
Until later. After these generics are finished, I will finish up the DirectX 9 wrapper classes that allow for the easy creation and extension of DirectX applications, and then will begin on creating my first game with the engine, a proof of concept of how powerful and flexible it can be.
That's it for now.
Oh, also of good note is that I got my personal website up. It can currently be found either at http://www.se.rit.edu/~brb6127 or http://people.rit.edu/brb6127. Feel free to look and investigate my previous work.
Thursday, July 16, 2009
IL Framework Progress
Well, yesterday I finished working on the basic IL framework for C++, getting it to compile into both DLLs and Libs for both Debug and Release mode. My next challenge with it is to wrap several of DirectX's files and formats into the framework. This includes but is not limited to:
* Textures (DirectX supported textures)
* Models (.X files for now... may expand later)
* Shaders (HLSL/CG files using ID3DXEffect files and the like)
By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.
* Textures (DirectX supported textures)
* Models (.X files for now... may expand later)
* Shaders (HLSL/CG files using ID3DXEffect files and the like)
By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.
Monday, July 6, 2009
Looking Into Procedural Content
Well, right now I'm working on a project which will create a randomly generated graph, based on some parameters fed into the system. The graph will then be displayed and be editable by users. Next, after the graph is displayed, the system will export the graph into a format for being read.
Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.
Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.
Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.
Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.
Wednesday, June 10, 2009
Development Perspective: Graphics APIs or Graphics Engines?
In this post, I'd like to take a step back from personal projects and happenings and discuss a point of view that was raised in dialogue during a class:
Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"
Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?
Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.
When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.
What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.
What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.
When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.
What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.
Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.
Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.
Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"
Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?
Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.
When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.
What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.
What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.
When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.
What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.
Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.
Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.
Subscribe to:
Posts (Atom)