E.X.P.L.O.R. in development now! Cool Developer Stuff

Pages: 1 3 4 5 ...6 ...7 8

Split Screen - May 2, 2015

After much work, controller input and client server communication has been drastically improved, and with that, support for split screen!

Categories: Development

Tech Demo 3 - January 2, 2013

This showcases a few, but not all, new features. Including menu flow. Being that I haven’t done any menu flow in a home-made game since Huckleberry’s Adventure. This was pretty big for me.

Categories: Development

Fixed Function Pipeline Gone - February 16, 2012

Over the past few months I have been weeding out the fixed function pipeline. Last month all that remained in the FFP was rendering fonts and 2D images. I have now written shaders to handle that type of drawing and the FFP has been completely replaced by the Programmable Pipeline. This is a great improvement because it does away with the need to worry about quite a few render states (such as lighting). It also means that all drawing is done in the same way, so there is less need for branching in the rendering code.

Categories: Development

OpenAL Dropped - December 10, 2011

One thing that I haven’t been happy with was the audio system in the game. Originally I had decided to use OpenAL. In part because I thought it was going to be as big as OpenGL (not that OpenGL is that big, but it least it is still somewhat backed by NVIDIA and AMD). I also thought it would be more portable. I realize now it’s not. I’m fairly certain there is no PS3 support for OpenAL and I think the 360 support is limited. The PC version is really bad as it is. So I cut out the OpenAL support and rewrote the audio engine in XAudio2. This seemed to be Microsoft’s preferred audio platform for PC and 360.

I’ll tell you this. After dealing with it for two days I’m already very happy with it, and already have about 90% of the functionality in the Emergence engine that I had with the OpenAL engine. By tomorrow it will have exceeded it. XAudio2 actually get’s you closer to the hardware (actually, lack of hardware, since all the mixing is done in software), but it get’s you closer to the software to have more control over it, with easy control over every channel. Further since it is just just software, buffers are literally chunks of memory, I mean direct memory. You allocate memory, that’s your buffer, none of this weird creation of buffers and what-not. You have memory, you have a buffer, and you can feed that buffer to as many voices as you want.

Overall I’m a lot happier with XAudio2. I didn’t even know it existed until yesterday, to be perfectly honest. I actually opened up the DirectX documentation because I thought I needed to refresh my memory on DirectSound, and I was like, What’s this? XAudio2, never heard of it. Well I quickly discovered what it was and how to use it. Really the fundamentals aren’t that different from any other software or hardware mixer, but the implementation seems to be quite good. Plus it is 360 and PC. From a developer standpoint, and some of my colleagues agree, hardware mixing is dead. Processors are so powerful that you can easily get any kind of audio effects that you want. And at this point we have so much memory that special audio effects can be pre-recorded anyway. Still, I’m sure that someone out there is going to argue that hardware will always be better. Well I respond by saying this. A quad core processor has enough cores to take care of any hardware argument. Software runs on hardware, after all.

Categories: Development

Code Rewrites - November 24, 2011

I have mentioned that until I can really start getting content into the game there isn’t that much to do with the game engine. Really to make a game with it, most of the programming necessary would be to write AI and scripting. Without designers and artists there isn’t much AI to program, so I haven’t been doing much with the game engine as of recent.

I did go ahead and rewrite a lot of the code. Well, not completely rewrote it, but I’m trying to make many of the modules within the game more independent of each other, and more object oriented.

Get this, I have a string class for the game, which is used for basic string manipulation, it was depending on the file class, which is used for opening and closing files, which in turn was dependent on the string class. I’m working hard to get rid of all such dependencies.

The other independence I worked on is with the Renderer. I would very much like to have the Renderer 100% independent from all Emergence tech except for the IRenderer interface. Currently it is still dependent upon global variables for it’s internal settings (such as screen width, height, etc). My ultimate goal is to have it so that the Renderer could be contained in a separate DLL, kind of the way Unreal technology did things. That way I could create new renderers of different types (DX11, for instance), and even more importantly, port the renderer to other platforms. The D3D renderer that I’ve currently implemented is dependent upon Windows, so I’m trying to abstract it as much as possible. It won’t be hard to port to the 360 renderer, and as for Playstation, I really have no idea, since I haven’t dealt with PS3 rendering tech at all.

Categories: Development

1 3 4 5 ...6 ...7 8


This blog chronicles the development of the Emergence Game engine. The Emergence Game Engine will be a fully functional 3D game engine with support for the latest technologies in video game development. This blog features the remarks of the lead programmer, Blaine Myers, as he comments on the struggles and joys of developing a 3D game engine.


Recent Posts

  XML Feeds

CMS + user community

Rough Concept Skin by Beem SoftwareMultiple blogs solution