Vincent_M

Supporting multiple libraries

I'm in your same boat: trying to provide my own localizable string interface that's platform-independent.

I believe UTF-8 encoding is an encoding format for storing text that would multiple bytes to identify, yet it's meant to be backwards-compatible with ASCII. With that said, that front bit in each byte isn't used in calculating it's UNICODE value. Instead, it's used as a flag to determine if the next byte of data's back 7 bits are used to describe the localized character's unique value. These values, once calculated into normalized 32-bit (unsigned?) UNICODE encoding. Then, you'd have a bitmapped font that would represent each glyph in the font on the image by a 32-bit (again, unsigned?) value equal to the what would match up to your localized text's normalized UNICODE values.

I think that's in line with what Hodgman was saying above. With that being said, you'd want to store your text that you'd display onscreen in UTF-8 encoding, and use a library to read those UTF-8 strings, such as utf8proc, to convert it into a string of normalized UNICODE characters that'd you'd use as look-up values in your localized bitmapped font when rendering text to the screen.

Since we're storing text in UTF-8 and XML parsers typically expect its text to be stored as UTF-8 text, I store my strings in an XML schema like so:

 Hello! Hola!  New Game Nuevo Juego

I'd like to point out that my XML code doesn't appear here^ Looks like it was edited out :/

 

Then, in my code, I'd have a LocalizedPackage that'd load up an XML file of localized text, typically for an entire menu or for cut-scene dialog that would contain a collection of localized strings described by my LocalizedSting class. LocalizedPackage reads the XML file, and for each element in the XML, it create a LocalizedString instance. LocalizedString would then create an instance of LocalizedText that'd it hold for each element found. It'd read each element, use the 2-character code to determine which language it falls under, and label that LocalizedText with that language. the XML parser would read in the text, and tell it as UTF-8 string and convert it to normalized, an array/vector/list of unsigned long's.


Then, you'd do something like this in your code:

fontString->SetText(localizedPackage->GetString("greeting_string"));

LocalizedPackage contains would keep track of the game's current language with this variable:

// in .h
static int currentLanguage;

// in .cpp
int LocalizedPackage::currentLanguage = LANGUAGE_ENGLISH; // set default language to English

 

LocalizedPackage would return the correct language's normalized UNICODE string that my FontString class would know how to interpret. Of course, if you wanted to provide localized text in a specific language regardless of the engine's current language, you could always do this:

fontString->SetText(localizedPackage->GetString("greeting_string", LANGUAGE_SPANISH));

You would want to provide lots of error-checking so that GetString() returns NULL if something's invalid, and have SetText() check if it's receiving non-NULL data...


I don't have this completely implemented yet, but I hope this gives you ideas!


EDIT: LocalizedPackage could be expanded to also load more than just localized text --images, sounds, music, etc.

I wondered this same thing in high school when I was working on the PSP homebrew games. You should look into BSD Sockets --they're native to UNIX/Linux, but also used in Windows (using the Winsock API that comes with the Windows SDK). Every platform I've ever come across supports the socket API.

 

As far as I'm concerned, this is an awesome guide on how socket programming works:

http://beej.us/guide/bgnet/output/print/bgnet_A4.pdf

 

It gives a great introduction to the TCP and UDP protocols, how data is transferred over a network and gives you an idea on how network programming works at the low-level. Lots of error checking is involved, but learning this will make you a networking digital Jedi.

 

There's this other library I've seen in a few projects, notably Cube, called enet. It's built on top of the socket API, so I would look into that as well once you're familiar with Beej's guide above.

Set a small goal, or have one set it for you. How much programming experience do you have?

 

Have you played any text-based games before (I count Pokemon).

 

EDIT: And by small goal, I mean something to design within an afternoon or something.

So, you'd like the literally have the camera move in the direction the camera is facing, even along the Y-axis? For example, if you're looking 45 degrees up, you'd like the camera to move up the Y-axis?

 

If this is the case, then you would want to add this line to your MovableObject::moveForward() method:

m_position.y += sin(m_rotation.x) * distance;

 

Keep in mind, that sin() and cos() give you the normalized components of a vector along the unit circle. Using sin() and cos() with x and z will give you a direction vector with the length of 1 because it's normalized. When you add m_position.y into the mix, you're actually making the direction vector longer than 1 unit (before you scale it by distance).

 

The best thing to do is find your direction vector, normalize, then multiply by distance like so:

void MovableObject::moveForward(float distance)
{
	Vector3 direction;
	direction.x = -sin(m_rotation.y);
	direction.y =  sin(m_rotation.x);
	direction.z =  cos(m_rotation.y);
	direction.Normalize();

	// add the direction, scaled by distance, to the current position
	m_position += direction * distance;
}

 

Depending on your coordinate system, you may want to change direction.x to +cosf() and direction.z to -sinf(). You'd also want to scale your "distance" float by the elapsed time between frames in your update loop if it's not already so it moves smoothly regardless of framerate.

@mightypigeon: Did you build that using .NET with C# or VB? When I was working in C++ and DirectX, I'd build mine using the winapi C classes, which is gross Win32 stuff from the 90's... Designing .NET applications are a breeze, but getting my C++ engine built on top of OpenGL to interact with .NET hasn't ever worked out for me yet.

 

EDIT: Woah, I asked before I looked up wxWidgets. You sir, answered by question before I even knew haha

So, are you just looking to generate new random numbers every different time? What language and what OS are you using?

 

In C, rand() will give you the same results every time based off of how long it takes to initialize the OS (I think), and even that can be OS-dependent (this is coming from a Linux background). You should be able to, however, change those results by seeding.

 

Check out srand(), if you're using C/C++. You can feed it time(NULL), which will gives the elapsed time in seconds since Jan 1st, 1970. In other words, the value changes just about every single time you call time(...), and feed the returned result to srand(), which then generates a new sequence of random values that can be retrieved by calling rand().

 

Here's a link: http://www.cplusplus.com/reference/cstdlib/srand/

 

What I did was call this in my game's initialization code:

srand(time(NULL));

 

 

Just call rand() like your normally do, and things should look differently from there. If you start seeing similar results, try calling that line in a few other places, but don't overuse it --it can be a heavy system call.

I've got to admit that this was the first time I've actually used glGetError() to track stuff down, but once I realized it holds the last error, I kept running it through my initialization code until I found the method that does it. Calling glGetError() after each gl* call is expensive on OES implementations, so if I do that, I'll have to setup a bunch of #ifdef preprocessors so that I can run my builds w/o being bogged down.

 

As far as glDisable(GL_TEXTURE_2D), I've been checking that, but this where I think the issue could lie because I actually don't call commonly used glEnable/glDisable states directly. Instead, I have my own method that holds a synchronization variable to determine whether the state is already enabled before calling glEnable(), and vice-versa. This meant to cull unnecessary calls for OES builds. I think something could be wrong with glBindTexture because I modified one of my wrapper methods recently for that particular call. I'll also have to check glActiveTexture's wrapper function...

 

My models also don't use just textures directly, they use a Material object that is configured to work with the corresponding config of my uber shader built for that model to render. My Material class has some logic when uploading texture types that don't exist across each mesh in my model (uber shaders work at the per-model level for efficiency). So, if some parts of my model uses normal mapping, but others don't, instead of loading two shaders, I just load one with normal mapping, and for materials that don't have normal maps associated with it, it'll send a default 2x2 normal map. If I'm using diffuse maps, then they default meshes without ambient maps to a white texture.

 

These textured vertices aren't lit, however, and I know it's going through the lighting shader too, so I think it's some sort of GL state issues like you've all pointed out.

I've been drawing vector art programmatically, and even provided a simple library to batch render vector shapes. My graphics artists and I would like to import vector art from DCC tools, however. I've done some research, and it looks like the SVG would be a great format for both static and animated vector graphics. Is this correct? I see it's XML-based, so parsing it wouldn't be that tedious.

 

Any thoughts on SVG format?

I was just at gamasutra checking out jobs ads, and I found this article:

http://www.gamasutra.com/blogs/TommyRefenes/20130107/184432/How_do_I_get_started_programming_games.php

Tommy Refenes was the programmer behind Team Meat's Super Meat Boy that got critical acclaim on the XBox LIVE Arcade. He's also featured in Indie Game - The Movie, which I highly recommend you watch that as well for extra motivation.

EDIT: I just read Simon Forsman's reply above, and his answer for your second question is spot-on. I wouldn't even consider building an engine at the beginning. You're just starting out, and you'll want to start small. An engine implies you have ambitious projects, and you don't want that in the beginning --you goal is just to complete simple projects, and learn your trade. You trade in this case, sounds like programming instead of art, audio, writing, etc. Plus, engine code is meant to be both functional to a degree, flexible for many projects, and easily extensible so you an sub-class which is where you'll want some experience writing complete games before trying. That way, you'll know how to code effectively.

As Simon pointed out, you'll want to write your own code from scratch so you get familiar with the lower-level libraries you'll come into contact with like DirectX, OpenGL/AL, SDL, etc. As you develop code, and complete your projects, you'll start to notice that you're coding the same things over and over again. When you're at that point where you're redundantly doing coding certain routines, you should start learning more about object-oriented programming concepts. Once you've made a few games, you'll notice that you've developed a coding style for your games, and at this point, you're probably copying and pasting entire source files from other projects to serve as a starting point to save you time from re-writing the same stuff from scratch. When you start using really similar code across multiple projects, I'd say that's when it's time to make abstract classes to cut down on coding time, and increase initial functionality of your subclasses. These classes used across projects will be considered the beginning of your game engine

For example, when I first put my menu system together for a specific title, I found that I was re-writing code to do the same things for each type of widget my game-specific menu system did. I created a generic Menu, Screen, and Widget class which literally trimmed of over a thousand lines of code, and made it easier to create different types of widgets (controls like Buttons, Labels, Textboxes, etc) and add it into my game.

This Menu system was used across multiple projects, and so I created an abstract version that had all of the features I'd always need for each project. Then, I'd create a game-specific subclass for each game. Eventually, I created a more abstract interface from the Widget class called CollectionItem. This was my OOP linked-list system, and nearly everything in my engine inherits from it. This engine, btw, is the result of many projects I've worked on in the past (although I've only publicly released one projects so far).

I'm talking in terms of object-oriented programming. If you're not familiar with these concepts yet, learning any object-oriented programming language would get you up and running. I highly recommend C++, and a good book to learn this language would C++ From the Ground Up by Herbert Schmidt. I think helped write part of the C++ standard we use today, and the book seems to cover the concepts well enough, and get to the point.

EDIT2: I would also recommend playing around with a drag and drop editor first like Game Maker: http://www.yoyogames.com/gamemaker/studio. This is where I got my start back in middle school, and it taught me a lot about Game Development just playing around with it. I think it helped me pick up programming because I learned a bit of the logic behind it just playing around with this editor. Honestly, if you're an artist with a technical side, you'd be well-rounded enough to make games on your own with this tool.

I tried building assimp, but I got a build-time error under Xcode 4 since the project was old. Noticed the COLLADA support after reading both of your posts. Very nice!

Thanks!

My MD5Object class (renders an instance of an MD5Model with animation applied to it) also uses 2 animations channels. After watching a documentary on the development of Uncharted 2, I thought about maybe having an STL list of animation channels that could be added or removed at any time, and then have be able to set blender operations between each channel similar to how alpha blending work on fixed-function 3D APIs. Then, I thought about creating a target system where the user has an option of choosing the joint in the model's skeleton to be the root bone for that animation controller. What happens for that animation channels is when the animation is being applied, the first bone to be worked on will be specified "root bone" to the animation channel, NOT the skeleton. What I could do with this is apply my running animation to the first channel, and apply the upper body animation to the second channel where the second channel's animation root bone reference is the next spine bone up from the pelvis since the pelvis is generally the root, which will brand the animation off to all bones.

I think this would work well for the MD5 format due to the way the data is saved. It's actually easier to process animation from scratch than the .x file format was. I still haven't given up on the .x format yet though. The only issue is that bones are calculated twice for the upper body. The data from the first channel is completely thrown out... Of course, I could add in blend modes and the blending factor between animations to give more options in case I wanted to support animation transitions between channels. Right now, I support my animation transitions per channel --each animation channel has a current animation pointer and a "next" animation pointer where the resulting animation between the current and next are determined by a transition factor if the animation is in transition. Otherwise, it just calculates the first animation.