Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Aug 2005
Offline Last Active May 03 2016 10:27 AM

Posts I've Made

In Topic: Create holes in plane dynamically

04 April 2016 - 12:54 PM

Try searching for information about Constructive Solid Geometry.  That lets you do boolean operations of shapes, so you could setup a ground mesh then subtract the spheres from it.  You could also look into voxels, setup a big array of voxels for the terrain, then just start removing the voxels as the user digs.  With voxels, you'd still need to look into some way of calculating the mesh from the voxels though, but there should be a lot of information about that online as well.

In Topic: SpriteFont render Umlaute

04 April 2016 - 08:12 AM

Correct, std::locale::global() sets some global values that std::regex (and other things) will use under the hood.  Since your string seems to get converted into UTF-8 during compile, setting the global locale to a UTF-8 variant means it will do proper handling when doing the regex expressions.  You shouldn't even need to reset to the old value, if you're using UTF-8 then you might as well use it across the board.  Set it and forget it.

In Topic: SpriteFont render Umlaute

01 April 2016 - 03:51 PM

It looks like it's auto converting to utf-8, but doing straight character comparisons.  There's a lot going on under the hood when working with STL and regex and etc, including dealing with locale.  Here's a good example of setting the locale to support utf-8:  http://stackoverflow.com/questions/11254232/do-c11-regular-expressions-work-with-utf-8-strings


char strings typically are simple strings, but utf-8 is a type of encoding.  You can store a utf-8 string in a std:string, but at that point it's really not human readable anymore.  A lot of editors know that the string is utf-8 and auto convert when displaying the value, but if you look at the raw memory then you'll see that it's actually a buffer of utf-8 data under the hood.  That's what's happening with äüöß to Ã¤Ã¼Ã¶ÃŸ, Ã¤Ã¼Ã¶ÃŸ doesn't make any sense when reading, but the values in it are the utf-8 encoded data for äüöß.


EDIT: This is why your solution works, you're extending the regex to check the encoded utf-8 values.  You won't need to do that if you set the locale ala the SO link, or if you switched to using wchar_t types (wregex/wstring).

In Topic: SpriteFont render Umlaute

01 April 2016 - 10:07 AM

Why are you trying to render an umlaute to begin with?  Are you trying to support other languages in general, or just other European languages?  If you're just rendering ASCII, then you might just consider supporting English.  This means you don't need any extended characters and can just use char and std::string normally.  If you're trying to support other languages in general, you should consider switching to unicode instead, then you can use std::wstring and not have to worry about char/byte/etc issues.  With your current implementation this becomes a bit tricky, as you'll probably need to start to page the textures since a single texture wouldn't store all the glyphs that you need.


As for the issue you're seeing, it still looks like you're not even initializing the full set of characters for the ASCII set? You're initializing from 32 to 154, which means you're not initializing the glypth for the umlaute.  In your draw function, since the umlaute is 252, it lies outside your range and you skip it.  You need to initialize a larger character set to properly support the extended characters (either initialize more characters, or map the characters so you can have a specific set without needing junk glyphs in between valid ones).

In Topic: Texture Coord Generation in Shader

31 March 2016 - 04:34 PM

It's possible but would require some additional data passed to the shaders depending on how you want to map things.  The simplest way would be to generate the coordinates in the vertex shader while the vertex are still in object space.  This makes everything centered around the model origin instead of world space, which makes things easier to do.  For some things like a cube, you'd need to know the extents of the mesh before generating the coordinates.  You'll need to know where the minimum/maximum are, as those become 0 and 1.  From there you can project out like a cubemap and generate 2D coordinates for each face of the map based on the vertex position.  The same applies to the different shapes, you're basically assuming a fixed mapping of coordinates over the shape (sphere would use spherical coordinates, cube would use cube mapping (6 2D faces), cylinder would be two faces on the caps plus a single map wrapped around it), then finding where the vertex would hit that shape and using the coordinate at that point.


W00t, phil_t beat me to it and with the proper term that I couldn't, for the life of me, remember.