NOGDUS $1670.00 has been donated to NOGDUS!
September 21, 2017, 03:46:07 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Wishlist/Useful Extensions  (Read 4416 times)
0 Members and 1 Guest are viewing this topic.
Cycl0ne
Guest
« on: April 23, 2011, 03:40:18 PM »

Ok, here I would like to post all things I notice, which could be "nice" to have (extensions, nothing completely new):

Sprite Class:
- SetBitmap() should be extended with the following methods:
virtual void SetBitmap(const Resource_BitmapStrip& bitmapStrip, bool visable);
virtual void SetBitmap(const Resource_BitmapStrip& bitmapStrip, bool visable, float x, float y, float priority);
virtual void SetBitmap(const Resource_BitmapStrip& bitmapStrip, bool visable, float x, float y, float priority, float origin_x, float origin_y);

Would make code easier to read, when you could set alot of variables in the initialisation phase.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #1 on: April 24, 2011, 02:35:14 AM »

Yeah, those seems like a useful addition, thanks Smiley

However, I probably wouldn't add them as member functions, but instead as non-member helper functions - in fact, in the future I'll probably try and pull functions out of the classes when possible, to keep the classes more well-defined, containing only the basic functionality, with a set of helper functions to make them more convenient to use.

So I would add them as non-member functions like this:
Code:
void SetBitmap( Sprite& sprite, const Resource_BitmapStrip& bitmapStrip, bool visable );
void SetBitmap( Sprite& sprite, const Resource_BitmapStrip& bitmapStrip, bool visable, float x, float y, float priority );
void SetBitmap( Sprite& sprite, const Resource_BitmapStrip& bitmapStrip, bool visable, float x, float y, float priority, float origin_x, float origin_y );

To be called like this:
Code:
SetBitmap( mySprite, "MyBitmap.pix", true );
SetBitmap( mySprite, "MyBitmap.pix", true, 10, 10, 5 );
SetBitmap( mySprite, "MyBitmap.pix", true, 10, 10, 5, 16, 16 );




Actually, good old Scott Meyers explains the "why" of it better: http://drdobbs.com/article/print?articleId=184401197


And stack overflow has a bit of a discussion about it: http://stackoverflow.com/questions/332460/non-member-non-friend-function-syntax

But yes, a good addition it would definitely be - I'd love to hear more suggestions like this, as it will just help to improve the engine as a whole.
Logged
Cycl0ne
Guest
« Reply #2 on: April 24, 2011, 04:23:37 AM »

Another Extensions:

Optimisation Code:
- Something one could activate to do some performance checking. Timers/Cpu/Memory usage. (sorta performance class)

For the "Platform Part":
- perhaps some functions to get memory, cpu speed, harddisk size.. something that could be important for the game to run.
Logged
Cycl0ne
Guest
« Reply #3 on: April 24, 2011, 04:32:58 AM »

Ohh and while we are at it:

how about BOOST? www.boost.org

Two things which are really usefull:
no_copy Class
Smart Pointers

Perhaps there are more in this, which could be useful.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #4 on: April 24, 2011, 05:31:11 AM »

Optimisation Code:
- Something one could activate to do some performance checking. Timers/Cpu/Memory usage. (sorta performance class)
Yes, this could be quite useful - So far, I've just used AMD CodeAnalyst for performance profiling, but sometimes it can be useful to mark up sections of the code. I already have support for performance timers in Platform, so could build something on top of that. Good one :-)

For the "Platform Part":
- perhaps some functions to get memory, cpu speed, harddisk size.. something that could be important for the game to run.

This would also be nice - for completeness, if nothing else Smiley  Can you think of any other parameters that would be useful (and make sense across platforms) than the ones already mentioned? Also, it's worth nothing that values which are very platform specifice, one can always grab directly in the game code, using the specific platforms API and some custom #ifdefs
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #5 on: April 24, 2011, 06:02:17 AM »

how about BOOST? www.boost.org

Sorry, but for this one I have to flat out disagree - there's no way I'll ever put that awful bloated mess anywhere near my precious little Pixie  Grin  I've really gone out of my way to reduce dependencies as much as possible - I'm not even using STL, and only a couple of carefully chosen third-party libraries, mostly for file formats.

In my opinion, using STL and BOOST is a sure way to get poor performance and code which is hard to work with under pressure. No thanks!   Cheesy


That being said, there might well be *concepts* from STL/BOOST which can be worth looking at.


Two things which are really usefull:
no_copy Class
Smart Pointers

I'm not a big fan of the boost approach of applying concepts like this to the general case - when you do, it is so easy to apply them to cases where one shouldn't, leading to lots of debugging pain.

In the case of the no_copy: Only reason I can see for having a no_copy class, is for singletons. The way I see it: if you don't want multiple instances, make it an explicit singleton; if you do want multiple instances, add proper copy constructor and operator. In Pixie, I already have the Singleton class, which can be used for that purpose. I can't think of a case where I would need a generic "no_copy" class to derive from - but I'm happy to listen if you can think of any?

As for smart pointers: I'm of the opinion that one of the strengths of C++ is the control you have over creation and destruction of objects - you're in full control of how and when this is done. Reference counting (as in smart pointers), is a sure way to hand that control over to a system which won't know what's best for your specific kind of object. All of a sudden, there's no one clear owner of an object - just lots of objects keeping references to it. I think that if one repeatedly find oneself needing smart pointers, ones design is in serious trouble, and one need to re-evaluate things.

In the general case, a pointer should have one clear owner, who is responsible for deleting the object. Other interfaces should be designed with this in mind, with particular care given to cases where ownership is handed owner, as that leads to the most robust code.

There are often particular cases though, when reference counting is great - but I think that for those cases, a more specific and thereby more explicit solution can and should be used, rather than a generic "Smart Pointer" (which will inevitably spread through the code as it is an easy patch to use instead of thinking about ownership). I have one such case in Pixie already - the ResourceManager handles reference counting for Resource_* objects, and will automatically create and destroy them as needed. I definitely think that it is better to add custom reference counting where needed (and ONLY where *needed*) rather than having a generic smart_ptr.

But </rant> aside, it is always possible for anyone using Pixie to include BOOST in their side of the code, if they find its concepts useful. But I can promise that it will never make it into *my* version of Pixie itself  Cool
Logged
Cycl0ne
Guest
« Reply #6 on: April 24, 2011, 12:13:13 PM »

Ok,

perfect. I just wanted to read something like this Smiley So forget Boost. I was just curios, because many games (commercial) use boost and the also promote that many concepts in boost will be in the precessor language of c++ (c++2x?) or how they call it.

Im certainly with your arguments. i was just "blinded" by the amount of games using this (PS3 - Uncharted, The SIMs, many EA games....) it was jsut the habbit: when so many uses this, it could be good. ;-)
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #7 on: April 24, 2011, 12:52:27 PM »

Yeah, I know what you mean  Smiley

However, I'm pretty sure Uncharted is NOT using boost, and I doubt EA use it - in fact, EA doesn't even use STL, but have their own alternative, EASTL, instead
Logged
Cycl0ne
Guest
« Reply #8 on: April 24, 2011, 12:59:22 PM »

Uncharted is using boost. I got my hands on this book:
Game Engine Architecture
http://www.amazon.de/gp/product/1568814135/ref=oss_product

he shows sourcecode (partial) from uncharted 1 and 2 and some othe games from him .. where he uses boost ;-) but forget the book. it is .. hmm nothing "special". It reads like a lecture from university.

And for EA. I got my hand on this Book:
Game Coding Complete

and looking for the source code i stumbled about his forum. In his forum are alot of commercial programmers. And one of them is the Sims Medieval Coder (AI something) and he uses also Boost and STL ;-)
Logged
Cycl0ne
Guest
« Reply #9 on: April 26, 2011, 10:09:28 AM »

Ok,

what about a script language like LUA? As Addon for Pixie?
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #10 on: May 01, 2011, 01:47:53 AM »

I don't think I would put a script language into Pixie - I see that kind of thing as very much a game side system. Just exposing the basic engine systems is not very helpful, as you would then have to implement the entire game in LUA - and why would you do that when you can implement it in a proper language with full debugging capabilities and optimisations? If one were to use a script language, it would be for rapid iteration of certain game systems (like AI/behaviours) or to allow modding of the game without a need for a compiler. But to do that, it would still be necessary to write the main systems in C++, and then expose carefully selected game functions to the script language - or even better, write a custom script system which makes the most sense for your specific game and its needs.

LUA is a nice language, but there's lots of other choices too - so I think it is much better to keep it as a game side addition, rather than adding it into the engine itself.   Cool
Logged
Tags:
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines
.: Theme by Richard Marks :.
Valid XHTML 1.0! Valid CSS!