Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 May 2007
Offline Last Active Today, 10:10 AM

#5181122 Multiples of 16B constant buffer or Microsoft gone mad.

Posted by achild on Yesterday, 03:20 PM

One of the most, if not the most, useful programming skills you will learn is how to learn. I'm not saying you don't know how to learn - I'm saying learning how to learn to use an API (identifying what is important to get started, what is the "functionality that isn't needed most of the time", and so on) or language or piece of hardware is a skill in itself that takes practice and experience.


Understanding that data alignment is a fundamental concept with 3d APIs (or nearly any hardware-related API really) is something you must learn. Now, when you go and try out a new 3d API in the future, you won't blindly dig through 100s of pages of documentation, but instead you will say "ah yes I bet it's this".

#5181066 reading float from binary file (endian problem?)

Posted by achild on Yesterday, 12:42 PM

When writing an entity, you

  1. put a byte for "is it drawable?"
  2. an optional color reference something or other of 2 bytes each
  3. the 9 floats

When reading an entity, you

  1. get a byte for "is it drawable by default?"
  2. get a mandatory 2 bytes for textureLink
  3. the 9 floats

Perhaps you are not writing anything on 2, but are reading that mandatory 2 bytes for textureLink, throwing everything off? Point being... there is some logical discrepancy between your write and read functions, which accounts for the issues you are having.

#5179939 Help improving this desing using C++

Posted by achild on 12 September 2014 - 12:15 PM

Your 3 requirements are counter-intuitive to the end goal, I believe. Why make an object pool in the first place?


Typically it's done to mitigate the various performance issues which can happen with multiple small allocations. Here, you'll find if you do a lot of allocations, your solution may become the bottleneck. RTTI, virtual interfaces, and a map lookup for every single allocation are going to kill you performance-wise except in trivial situations.


So, the big question is - why are you designing this?

#5176670 Welcome your new Visual Arts forum moderator

Posted by achild on 28 August 2014 - 08:02 AM

Nice. Congratulations!

#5158477 Why do large engines use their own string class

Posted by achild on 05 June 2014 - 12:51 PM

It's worth noting that even in this case it needs to be used with care.


If one assigns one CryStringT object to another (ref count is 2) and uses one of them in another thread, passing it along in some data structure or something, it can wreak havoc. It's not unreasonable to be responsible for protecting your own shared data, but the COW code is not thread safe either. I believe in the standard library 2 separate string objects are not supposed to have any hidden surprises like that (though it has been a problem in the past).

#5149517 Do we use pointers in game programming?

Posted by achild on 25 April 2014 - 05:56 PM

More importantly than learning about pointers themselves, IMHO, is that learning them is a great first step to learning about memory. This will be invaluable later on as you gain more experience, especially when it comes to optimization (whether for speed or other types of targets).

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

Posted by achild on 22 April 2014 - 10:27 AM

I'm not sure if someone mentioned this, but a clear difference when your class allocates memory is that std::memcpy will not remove ownership from the original. So when your object dies, it will release the memory, but the object you copied will still hold a pointer to the released memory, causing a crash down the road. std::move, on the other hand, will release ownership from the original object (zeroing pointers, etc) so that it can be destroyed without affecting the state of the target object.


A move affects both the source and the destination, while a copy only affects the destination.





struct Object {
char* data;
Object () : data(new char[10]);
virtual ~Object () { delete[] data; }
is not trivially copyable (you'd have two objects pointing to the same data on the heap), but... is it trivially moveable?  There are no exceptions thrown.  The pointer will move properly with a std::memcpy(), as there will be still only one owner.  As long as the src isn't destructed we don't have a data leak.  Does the hidden v-table pointer get copied properly?  Will something else get mangled?


The pointer will NOT move properly. It gets copied properly. There are now 2 owners, not 1. You said "as long as src isn't destructed" but that's an important detail that highlights a major difference between memcpy and move.

#5134563 C++ Constructors vs. Init() Functions

Posted by achild on 25 February 2014 - 03:45 PM

In C++, constructors are really important for RAII. Note that they are required if you wish to follow the objects-are-never-in-an-invalid-state thought process.


Personally, if I have to have confirmation that "initialization was a success", I'll add an IsInit or IsValid function. These cases are very, very rare in real life situations. Also... once you start using smart pointers it will be silly to explicitly Init after creating the object...

#5131298 Auto update systems - yes or no

Posted by achild on 14 February 2014 - 10:01 AM

Hey everyone. I want to put an auto-update system in some software. The question is, how will others feel about it? Why doesn't all software have this? Chrome seems to auto-update (and disabling it isn't obvious). No one seems to complain. But then other modern software will simply tell you there is an update available and redirect you to their website if you so choose. I suspect there are a variety of opinions out there on this so...


How do you feel about auto-update systems? Intrusive? Convenient? Like/hate/don't care either way? If you dislike them, what do you prefer?


Interested in everyone's thoughts on this.

#5115968 Help me get rid of this goto!

Posted by achild on 10 December 2013 - 01:03 PM

You weren't missing anything. It's just an exercise in refactoring, which is something you simply have to get experience in (like you are right now).

#5115909 Creating a game with Open source/Middleware engines?

Posted by achild on 10 December 2013 - 08:47 AM

It's not only feasible, but highly recommended you use pre-existing solutions (until you find for certain they won't work). These ought to help:




http://content.gpwiki.org/index.php/Game_Content_Resources (pre-made fonts, icons, sound fx, etc)

#5114664 2D Rects collision problems

Posted by achild on 05 December 2013 - 01:14 PM

Google "separating axis theorem".


For rectangles it's very simple.

// Assuming left right top and bottom are not flipped or invalid
if (r1_left < r2_right && r1_right > r2_left && r1_top < r2_bottom && r1_bottom > r2_top) 
    return true;  // Collision
return false;  // No collision

[edit] - I suppose if the edges are equal they would be touching but not necessarily colliding.

#5109568 2D Windows 8.1 game development C++

Posted by achild on 15 November 2013 - 03:01 PM


Other : MonoGame (http://www.monogame.net/)



I'm glad I asked, hadn't heard of that...



Except... the question states C++...

#5098326 Maps or level editors

Posted by achild on 02 October 2013 - 01:20 PM

- For something like pacman you may get away with manual input. Better even to have an external text file of some kind.

- Ideally using a preexisting solution would be best because you can get to work on your game.

- If, for some reason, you can't adapt it to your needs and you can't adapt your needs to it, (or you need in-game level editing) rolling your own will also work but will take at least twice as long as you think it will.


Tiled is fairly well done and pretty popular. There are others if you look around, depending on your needs.

#5098054 [Solved] Crossroad. HGE or SDL?

Posted by achild on 01 October 2013 - 07:44 AM

HGE is more high level and you can make games faster. I'd stick with that if cross platform is not a concern.


When you get into 3d stuff you will need to change but that's okay... HGE is very good at 2d and that's a good reason to stay with it. Once you go 3d, you may consider looking for another high level framework or even one of the engines out there such as UDK, Crysis, or Unity, really, if your interest is in making the games themselves.


People tend to build engines/frameworks on top of SDL versus using it directly. For example someone ported HGE to be cross platform and they built it on top of SDL.