Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 23 Apr 2003
Offline Last Active Jan 30 2015 08:33 AM

#5203401 Bug in vc++ 2014 preview compiler? (std::thread)

Posted by Ryan_001 on 10 January 2015 - 11:27 PM

Why are you creating and destroying threads constantly, that's a bad design. Pool them. Or use std::async to start your cheap jobs, since it will use a thread pool.


While I agree that his method is not optimal, a bug in the standard library is a pretty big deal.  If happened to find a way to reproduce this bug, even if by accident, that's a good thing.  My suggestion would be to try simplifying it.  See if you can remove the networking code.  Get it as small as possible while still being able to reproduce the problem.

#5201836 Bug in MSVS 2012?

Posted by Ryan_001 on 04 January 2015 - 07:45 PM

Well one thing I notice is you've got the same header guard on both files.  This might cause some of this as well.  It might only be loading one of the files, which ever one is parsed first.  The other, while included, isn't bringing in any data, since the header guard would already exist and it would ignore whatever is in the ifndef block.


Try making the header guards more unique.


Since the files seem to be in different directories, try something like GUI_SPRITE_H and RENDER_SPRITE_H.


Or just use #pragma once

#5200078 Getting Rid of "char*"

Posted by Ryan_001 on 26 December 2014 - 09:27 AM

I personally would use a stack-based allocator.  That way I could use it with string, vector, pretty much any container within reason.

#5200044 Getting Rid of "char*"

Posted by Ryan_001 on 26 December 2014 - 06:09 AM

Use an abstract base class:

class MyStringBase {
   virtual const char* GetAsChar () const = 0;
   virtual void SomeOtherFunction () = 0;

template <uint32_t Size> class MyString : MyStringBase {
   virtual const char* GetAsChar () const { return data; }
   // ect...

Or rework your functions to take a template parameter:

template <typename T> void PrintString (T&& s) {

template <uint32_t S> void PringString2 (const MyString<S>& s) {

#5188702 C++ header inclusion question

Posted by Ryan_001 on 23 October 2014 - 01:54 AM


I think #2 should actually read: "Only include headers in headers if you can't get away with forward declarations"


Hence the "Sometimes you'll need to deviate from these rules, but in the rare occasion that you do, you'll know."  It's very rare that you can't get away with forward declarations.



Short of putting all headers in one huge header file, how can #2 be accomplished?  Not trying to be a wiseguy - I'm not well-versed in C++ and would honestly like to know.


As madhed mentioned above, forward declarations.  If header 2 contains a "Foo" class that you need to reference in header 1, just declare class foo; at the top of header 1.  If cpp file 1 includes header 1 AND header 2, the linker will take care of it.



Its quite common to #include headers in header files.  Manual creation of forward declarations is gonna lead to lots of subtle errors as you now have your dependencies spread across many files.  Just use #pragma once at the top of every header file, include it where needed, and you won't have issues.  As far as #pragma once being non-portable, I know of no remotely modern C++ compiler that doesn't support it (http://en.wikipedia.org/wiki/Pragma_once#Portability).

#5184885 Is upper division Linear Algebra a good idea or necessary?

Posted by Ryan_001 on 03 October 2014 - 10:28 PM

I found multi-vector calculus to be far more useful than one would initially imagine.  I like linear algebra, but the later stuff tended to be (as you mentioned) more proofs and less applicable to games.

#5175373 So... C++14 is done :O

Posted by Ryan_001 on 21 August 2014 - 06:23 PM

In my humble opinion...
I wish that they'd clean-up the standard library.  I understand that some of the standard lib needs to be vendor specific.  Threads, mutexs, files, memory management, OS specifics, ect... they need to be vendor supplied.  But things like iterators, containers, algorithms, ect...  They really should be just be standard C++ code supplied by the committee.  Call the vendor supplied section of the standard library the 'core library' or 'vendor library', then call the rest the 'extended library' or just 'standard library', whatever...  That way new additions/ideas can be made to the library much faster/cleaner.  Also simply having a 'standard implementation' would really make learning the language a lot easier.
Now I know the counter argument to that is that by specifying 'what' and not 'how' in theory library writers can give a better implementation.  My feeling is that if the committee can't write clean, efficient, proper C++ code, how they hell are we supposed to be able to?  If the committee can't write a simple vector implementation, then they need to get back to the drawing board and figure out why they cannot, rather than just pass the buck onto the vendors.
I mean the whole reason Boost in its current form exists (and I love Boost) is simply because its the standard library that C++ needs.

#5175286 Font Rendering

Posted by Ryan_001 on 21 August 2014 - 08:58 AM

Ya I guess it does, when I have some time I will.  Really quickly the steps to use it would be...


1) Create a Font object like:

TTF::Font font("fonts/Nexa-Light.otf");

The Font object has all the font data, like bounding rects, kerning info, headers, code point to glyph index conversion, ect...


2) Create a triangulator:

TTF::TriangulatorI triangulator;

Currently there are 3.  Each triangulator will have different outputs.  TriangulatorI uses the GPU gems 3 vector rendering (ie. requires a pixel shader).  TriangulatorII on the other hand is just a standard mesh (no special pixel shader required) but requires you to supply a function to specify how to subdivide the curves.


3) Create a Mesh object to store the glyph:

TTF::MeshSmall mesh;

Mesh small is useful for most fonts, but its theoretically possible that some glyphs might be too large (have too many vertices) to be stored in a MeshSmall object, in which case you can use a MeshLarge object.  There's almost no difference from a user standpoint, a MeshLarge just uses a less compact storage.


4) Triangulate the glyph:

In this case text is a std::string.  Now you can do whatever you want with the glyph (add it to a vertex buffer perhaps).
5) Optionally get the kerning:
TTF::vec2s t = font.GetKerning(CodePoint(text[i]),CodePoint(text[i+1]));

Kerning is the distance between one glyph and the next.


#5174976 Something between bilinear and bicubic interpolation?

Posted by Ryan_001 on 20 August 2014 - 05:57 AM


I personally prefer Bezier (it doesn't overshoot, hits each control point exactly, and look absolutely gorgeous).


How does that work? The cubic bezier on Wikipedia does not hit each control point, only the outer two - but then it's also 2D intead of 1D:




Can this be calculated in a way similar to bicubic interpolation? I couldn't find anything.


THanks a lot!



You may be right...  I implemented it all years ago, so TBH I can't find my source material.  The code I use for interpolation has served me very well over the years, but perhaps I was mistaken and I thought I was using a bezier spline when in fact I was using another type.  Or perhaps it actually doesn't hit every control point exactly.  Clearly I'll have to take another look at it.


Perhaps I was thinking of Catmull-Rom splines when I said they hit every control point exactly and don't overshoot.  And when I said Bezier spline I probably meant BSpline.

#5174676 So... C++14 is done :O

Posted by Ryan_001 on 19 August 2014 - 05:08 AM

I find many of the C++11 features 'tacked' on and very hackish as is, so I'm actually dreading C++14 a bit.

#5171324 Something between bilinear and bicubic interpolation?

Posted by Ryan_001 on 03 August 2014 - 06:12 PM

Yes and no.
What you essentially have there is value noise.  With value noise you can get approximately smooth by using a smoothstep function http://en.wikipedia.org/wiki/Smoothstep and that will look a little less blocky but boundaries will still be visible.  In order for value noise to be smooth across boundaries points on both sides are needed.  So to look like the bicubic version you will need 4 points for a 1D signal, 16 for a 2D or 64 for a 3D signal.  I personally prefer Bezier (it doesn't overshoot, hits each control point exactly, and look absolutely gorgeous) or Catmull-Rom interpolation over Bicubic.
The other common option is gradient noise.  You can get smoother results with less points.  Perlin and Simplex noise are 2 common examples.
I personally prefer value noise, as it is less prone to obvious patterns, and tend to look more interesting; but for real-time applications gradient noise is often the way to go due to being so much faster to compute.


*edit: I think I made a mistake there unsure.png  

#5169569 Font Rendering

Posted by Ryan_001 on 27 July 2014 - 01:24 PM

A while ago I wrote for my own uses a font loading/rendering helper library.  I posted it on sourceforge because a few people in other forums expressed interest.  There's been alot of talk lately on font rendering in games, so I thought I'd post a link in case anyone is interested.




Unlike most font rendering libraries, this doesn't use or produce a texture/sprite sheet.  Rather it triangulates the characters into an actual mesh.  There are a couple different choices of triangulators, one that produces very compact representations that uses the technique described here: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html.  There are a few others as well.


Its worked well for myself and from what I understand a few others.  If any bugs are found I'm happy to fix them.

#5164917 Game Design: The Illusion of Choice

Posted by Ryan_001 on 05 July 2014 - 12:43 PM

Meaningful choice is referring to choices that will affect the outcome of the game/encounter/whatever.  A skin change often has little if any effect on the game, where-as a stat change often has a significant effect on the outcome.  Granted there are many counter-examples (in LOL Annie's frostfire skin for example makes the 'stun stack' very difficult to see).


I personally dislike the idea behind 'illusion of choice', but I can see where it can be useful for fueling monetary transactions without affecting balance or gameplay (ie. staying away from the P2W side of microtransactions).

#5148421 C++ std::move() vs std::memcpy()

Posted by Ryan_001 on 20 April 2014 - 05:02 PM

Actually, my link does list all the important information. As the notes say:



Objects of trivially-copyable types are the only C++ objects that may be safely copied with std::memcpy or serialized to/from binary files with std::ofstream::write()/std::ifstream::read(). In general, a trivially copyable type is any type for which the underlying bytes can be copied to an array of char or unsigned char and into a new object of the same type, and the resulting object would have the same value as the original.


The properties listed above that cover the possible reasons you have already sliced into a bit in a formal way.


A) I'm talking about std::move() vs std::memcpy(), not copying.  What you've posted covers copies, not moves.

B) I want to know WHY is shouldn't be done.

#5146755 Using C++

Posted by Ryan_001 on 13 April 2014 - 01:33 PM

Think of console programming like a king-fu master telling you to hit a bowl of water again and again.  It seems silly to you at the time, and ever so boring.  You want to be making engines and games with cool graphics, and here you are wasting your time with yet another console tutorial.  Yet there is good reason the master has given you those instructions...



Programming is essentially all problem solving. You have a problem and you break it into smaller problems. You break the problem down enough until you have something you can Google. Then you put all of the pieces together and you have a program. Then the program doesn't work and you have to figure out why. That is programming.

hehe... so true ;)