BBeck's Profile User Rating: *****

Reputation: 560 Enlightened
Active Posts:
1,263 (1.53 per day)
24-April 12
Profile Views:
Last Active:
User is offline Today, 09:39 AM

Previous Fields

OS Preference:
Favorite Browser:
Internet Explorer
Favorite Processor:
Favorite Gaming Platform:
Your Car:
Who Cares
Dream Kudos:
Expert In:
Game Programming, XNA

Latest Visitors

Icon   BBeck is experimenting in his gaming lab. Don't be alarmed if something explodes.

Posts I've Made

  1. In Topic: Porting XNA to C++/OpenGL, where might the tough spots be?

    Posted 28 Jul 2014

    Oh. Incidentally, if you're wanting your project to be multi-platform, I'm thinking you should probably skip DX, which is going to present another problem. The reason I say that is that DX is very tightly integrated with Windows and MS products. I mean there's SharpDX out there. I think that's written in OpenGL to give the functionality of DX in a multi-platform environment. I haven't used it, so I'm not sure.

    But DX is bound very tightly to MS products and is not remotely portable outside of that. That's the primary reason everyone uses OpenGL which will run in Windows environments as well as other environments. But there's a pretty big difference between OpenGL and DX.

    I worked in OpenGL for a very short while a very long time ago. So, I don't know a whole lot about OpenGL. But I have heard that it does nothing but graphics. Technically, that's all that DirectX does too. But DirectX has some other things like the XNA math library and XInput for reading input devices like the Xbox 360 controller. And there's also very tightly integrated libraries for XACT and other audio. In a Windows environment, you may be forced to use some of these libraries even with OpenGL even though they are "considered" to be part of DirectX.

    Anyway, OpenGL should be able to run in Windows and give you the cross-platform compatibility you want. But XNA was built on DX9 and so you're getting even further away from what's going on behind the scenes in XNA. Although, for that matter it was built on DX9 and not DX11 which are night and day different. So, maybe you're having to do things substantially different in DX11 too. But you'll need several libraries for handling sound and input and other stuff that you may be able to get for Windows and are cross-platform compatible to work with OpenGL. It's just likely to be very different from DX. But DX would probably be redundant.

    I would imagine that if you want it to be cross-platform compatible it should be done in OpenGL with libraries to work with OpenGL and forget about DX. You may still have to use DX libraries for things like the Xbox 360 controller and XACT audio though.
  2. In Topic: Porting XNA to C++/OpenGL, where might the tough spots be?

    Posted 28 Jul 2014

    If you are dropping .Net, which you probably should if you're making this for C++ because otherwise you're doing it in managed C++ CLR code, I'm skeptical about how much of the code will be similar to MonoGame's code. I haven't looked at their code under the hood, but it might be a really good place to start. I've heard their code is built on Mono which is a port of .Net to be multi-platform. But it couldn't hurt to look at their code for your project. Worse comes to worse it doesn't help, but you haven't lost anything. But I would think, the more help you can get the better.

    I'm not sure exactly what it is about the Content Pipeline in XNA that makes it so hard to implement. You might contact the MonoGame people directly and ask them. It doesn't sound like your project overlaps with theirs' too terribly much and they might be very willing to share with you. I haven't met them, so I don't know, but I suspect as much.

    If I had to make some guesses about why the Content Pipeline in XNA is so difficult it would be this. First of all, it's built to handle many different types of files for different purposes, extract the relevant data, throw away the garbage data, and compile that data into a common/standard format that is streamlines to be as efficient as possible known as the .XNB file (XNA binary).

    File types that XNA knows how to natively read.
    • Autodesk .FBX - model files including non-model data
    • DirectX effect(HLSL) .fx files
    • Fonts in the .spritefont file format
    • Bitmaps .bmp
    • Microsoft's proprietary texture file format .dds
    • Texture .dib
    • Texture .hdr
    • JPeg textures .jpg
    • Texture .pfm
    • Texture .png
    • Texture .ppm
    • Targa image files .tga
    • Microsoft's deprecated proprietary model format .X
    • Microsoft XACT audio project files .xap
    • XML .xml

    I see at least one file format missing from this list but I got this list from the MS website. XNA also will do full motion .wmv files and I think it will do animated GIFs .gif too.

    There are two sides to the Content Pipeline: the importers and the processors. For every one of these files, in C++ and DX/OpenGL, you have to build an importer that reads the file. That means you have to be an expert in every one of these file formats. Understanding a single one of them can be a major undertaking. I don't fully understand the .bmp format but I believe it's one of the most simple. I can't imagine digging into the JPeg format and trying to understand how to compress and uncompress images in JPeg.

    The .fbx format is one I actually have attempted to decode for C++. Turns out how it works is a big secret. Autodesk owns it and they don't want anyone to know how it works. The proper way to deal with that is to download Autodesk's library, learn their library, and use their library to work with .fbx files. But I found very quickly that the .fbx format is NOT a model format like we use it for in XNA. It's a modeling program's format. In other words it's designed to store basically all the data you would have in a Maya, 3D Studio Max, or Blender file including lights, cameras, 100's of models all with dozens of materials each with multiple HLSL/GLSL/CS shaders UV maps, skinning data, animation data for multiple animations on multiple models, etc. 98% of what the file format is capable of storing is not stuff XNA or really any other environment is setup to use. In other words, the file is 98% garbage (from our perspective as game programmers anyway; artists who use these programs for non-game programming purposes such as making movies would disagree), which is part of the reason that you want to extract the relevant data and compile that data to a .XNB or other streamlined format. And you have to spend all the time learning Autodesk's .fbx library system which I spent a week on and gave up and decided to design my own file format because starting from scratch would be easier then learning the .fbx library. I'm sure it can be done, but just learning this library is no easy task and it's really the best way to write code that loads data from the .fbx format.

    The Blender team has been trying to actually decode the .fbx file format itself and you might get some info from them if you try that. They've done a pretty good job of it in their .fbx exporter, but it's not the way Autodesk would prefer you do it and it's a "best guess" at how the .fbx file format actually works.

    This is just one of the many file formats XNA reads and reading it is a nightmare. I'm sure you can do it if you have a little determination, but it will take a little effort.

    And not only do you have to write an importer that will read the file and bring it's data in where you can work with the data, you also have to write a processor that will have an in memory object to store and use that data and export and import a streamlined version of that data in a format like .XNB.

    Furthermore, what makes duplicating .XNA's Content Pipeline difficult is that XNA is designed to have the Content Pipeline be extensible, so that programmers can write their own custom importers and processors. And you would have to make it so that that works the same way that XNA's does to truly duplicate it.

    I've found that learning to write your own importers and processors for XNA is not an easy task, but then again a big part of that is understanding the file formats that you are attempting to process on top of learning how XNA expects you to extend the Content Pipeline.

    So, yes, it probably mostly does "just take resources and recompile them" (not to mention deal with those resources in memory and provide classes for that data to be accessed. But that's kind of like saying "All you have to do to get to the moon is get on a rocket." :-) It may be true, but it's a bit of an understatement of the difficulty involved.

    The DirectX Toolkit is "supposed" to give us some of XNA's functionality. I haven't downloaded it or used it, but it seems to me that it's not at all the same as using XNA. Likewise with the DirectX Texture Processing Library. I don't know if any of this will prove truly helpful.

    Anyway, I don't want to steer you away from the project. It sounds like a pretty cool project and I'm looking forward to seeing the end result. I feel kind of like game programmers need something like this.

    I "was" working on trying to put together a tutorial for XNA programmers going into DirectX 11 and trying to make that jump as easy as possible. So, in my example code I duplicate some of the XNA ways of doing things. For example, I have inherited Update(gameTime) and Draw(gameTime) methods that would look very familiar to any XNA programmer.

    So, I definitely think something to help ease XNA programmers into the world of DX and C++ game programming would be a big plus.
  3. In Topic: Porting XNA to C++/OpenGL, where might the tough spots be?

    Posted 27 Jul 2014

    So are you trying to re-invent MonoGame where you have a C# framework that replaces XNA, or are you trying to build a class library in DX that basically offers the same functionality as XNA but in C++?

    In C++, you lose the .Net CLR. And I don't know if you really want it back. C++ and DX kind of have their own way of dealing with things. For example, STL largely replaces a lot of the common functionality from .Net such as Lists. I figure it's best to go with the flow and just accept that C++ is different, not to mention unmanaged.

    There's a tremendous amount of stuff in XNA and it's probably easy to forget that. One of the biggest hurdles seems to be the Content pipeline as the MonoGame folks have apparently had a hard time with that. And content in general is pretty rough.

    DX doesn't know what a texture is really. It certainly doesn't know what a model is. There are several file formats XNA knows how to read that DX just has no clue on. You can get some of this functionality back through various libraries but it may be better to build your own. Making a model class as robust as XNA's would be quite a task. Maybe that would be the biggest task yielding the best payoff. But even XNA's Sprite class has a tremendous amount of functionality in it. I think just replicating that would be quite an accomplishment.

    One problem you may run into, especially in OpenGL, is rendering full motion video. MonoGame has this problem. The .wmv file format that is used in XNA would not work in their environment. I'm not sure if that applies to DX, but it almost certainly will apply to OpenGL. MonoGame uses Ogg/Vorbis instead. This assumes you're doing a full port of course. I mean, this is maybe one of the least used features of XNA.

    Also, XNA never implemented skinned animation. They had some tutorials on implementing it yourself by extending the content pipeline, but it wasn't built into XNA. I think that skinned animation is pretty much mandatory and should probably be a higher priority then something like full motion video for cut scenes and whatnot.
  4. In Topic: what part collided in pygame?

    Posted 26 Jul 2014

    Maybe what you want is pixel collision. I think this link covers pixel collision in PyGame.

    If you are trying to make different pieces of a sprite collide with something then you need to use separate colliders and/or treat it as more then one sprite with each having it's own collider. Off the top of my head, I can't think of an example where you would want one part of a sprite to have a different collision then another part of the same sprite.
  5. In Topic: Update multiple tables in one query

    Posted 24 Jul 2014

    For full disclosure, I might also mention that there was a time way back when when I was the one writing the rogue code. I did some really ugly things to the database as an application developer way back in the day before I became a DBA. ;-)

    It's a totally different way of thinking between database programming and most other programming and a lot of developers don't realize that. I certainly didn't until I switched roles.

My Information

Member Title:
Here to help.
Age Unknown
Birthday Unknown
Dallas, Texas, US of A, Planet Earth, Sol System, Milky Way Galaxy
Rock music composition and performance, Grunge Music, Bebop (think Thelonios Monk), Swing (think Cab Calloway), Gaming, Astronomy, RPGs, Scuba, Sail Boats, Furniture Building, Cooking, Rocky Patel Cigars, Character Driven Dramas(like HBO's Deadwood), Story Telling (plot writing), Linguistics, Economics, Target Shooting, Electronics (don't know as much as I'd like to), all aspects of 3D game programing including music, physics, modeling, texturing, annimation, probability, AI, lighting, etc., Texas Holdem' Poker, Learning, Dogs, the love of my life (my pit bull), guns (especially 19th century black powder), putting make-up on ogres, etc.
Programming Languages:
C, C++, C#, Visual Basic, Java, Pascal, T-SQL, HTML, FoxPro, ASP.Net(very little), Assembler, Machine Code(conceptually anyway)

Contact Information

Website URL:
Website URL


Page 1 of 1
  1. Photo

    BBeck Icon

    11 Aug 2013 - 04:27
    Generally, yes. :-)
  2. Photo

    aaron1178 Icon

    10 Aug 2013 - 00:42
    You wouldn't happen to get high marks in written exams would you ;)
Page 1 of 1