Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jan 2009
Offline Last Active May 20 2016 02:42 AM

Posts I've Made

In Topic: A* A star vs huge levels

20 April 2016 - 04:27 PM

For nav mesh generation, it can definitely be automated, but it's indeed not trivial. I work on a substantially large open world game where the nav meshes were generated procedurally. 


You may want to look into recast / detour, an open source pathfinding framework that can also generate navmeshes from an arbitrary collision mesh.


In Topic: SpriteFont render Umlaute

26 March 2016 - 04:43 PM

I think I got it.


Your input is indeed ISO-8859-1, in which ü is 252 (or 0xfe). This also corresponds to the unicode codes for those characters, so that's supposed to work as input for the TTF_RenderGlyph_Blended function that you use to render the glyphs and give you the right glyph (according to the docs it is expecting a unicode character code as input: https://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf.html#SEC54 )


But since character 252 ends up being the exponent 3 character and since you expect ü to be 129, then it seems that the font that you're using is designed to map characters according to extended ascii (an old thing called codepage 437, http://www.theasciicode.com.ar/ , https://en.wikipedia.org/wiki/Code_page_437 ), in which 252 is the exponent 3 character and where ü is 129.


So... I think it might be the font. Try grabbing another TTF font to see if it fixes the issue.

In Topic: SpriteFont render Umlaute

26 March 2016 - 10:55 AM

It returns 1...


What I have to do now? :D


Well, you need to debug then. Verify that you generate your font texture properly, verify that you get to the right position in your font texture according to the input character code, make sure that the input character code makes sense (if you get 1 with the test above it is probably ISO-8859-1 in which case ü should have the code 0xfc according to http://www.fileformat.info/info/charset/ISO-8859-1/list.htm).


If you only have the issue with characters > 127 then you likely still have a signed/unsigned issue involving a char somewhere.

In Topic: SpriteFont render Umlaute

26 March 2016 - 07:00 AM

Try this:


std::string test( "é" );

cout << test.size() << endl;


If it displays 2, then the string is very likely encoded in UTF-8. If it displays 1, then it's probably ISO-8859-1.


But if you want to know if there's a 100% sure fire way to programmatically know the encoding of a string you're given, there's none. If it's a string literal, you have to make an assumption about what the compiler will give you. If you read it from a text file, you have to make sure of the encoding the file was saved as.


This is why in some text formats such as XML, there is a header that explicitly indicates the encoding. (for instance <?xml version="1.0" encoding="ISO-8859-1"?>)

In Topic: SVN vs Perforce

26 March 2016 - 06:41 AM

One of the reasons perforce can scale to huge projects is that you can define rules to automatically "forget" the content of older versions of certain types of files. For instance, you can have it store only the last 4 versions of png files.


This allows to use it to store absolutely all of the assets of even a huge game, such as a large open world game, at the expense that the history gets truncated. But in those cases keeping the entire history is not feasible anyways.


I don't know if subversion have this feature nowadays.