• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Fs02

How do you manage two vector from two different api's(Box2D and SFML)

9 posts in this topic

Hi, i'm using box2d and sfml and i have two different vector here (b2vec2 and sf::Vector2f).

 

I'm trying to combine two vector type in my game classes, what i've done now is making my own game vector utility whit all basic vector operation and casting ability to b2vec2 and sf::Vector2f and it's to far from efficient since i no longer able to pass the vector by pointer or refference and must pass it using value which expensive operation.

 

i'm also thinking about make b2vec2 as my global vector for game objects and create a converter for convert it to sfml if it needed sometime.

 

any advice or example's on how you manage this ?

 

thanks smile.png

1

Share this post


Link to post
Share on other sites

If you need to keep all vector classes intact, then the safest way is to roll your own vector class and write conversion functions. Usually this is not the case. It'd also add conversion overhead.

 

If the classes share the same members (eg, x, y, z) and overloads, you can get away with writing global copy functions and just using them directly (one type at a time and on a per-component basis if you need to use them interchangeably). I'd advise against this, however, as it'll create a mess.

 

As a matter of speed and clarity, for instance idTech uses macro-based vector operators, which automatically resolve into inline code and are inherently faster. You could adopt the same approach. Eg:

 

vec2d v0, v1, v2;

 

v2 = v0 * v1;

 

becomes:

 

#define VecMult2D(a, b, res) (res[0] = (a[0]) * (b[0]), res[1] = (a[1]) * (b[1]))

 

VecMult2D(v0, v1, v2);

 

You'd no longer be dependent on member functions and your "vector class" would degenerate into a simple POD. Furthermore, you could mix vec2dA and vec2dB if both of them provide a bracket operator overload. Eg:

 

vec2dA v0;

vec2dB v1;

myvec2d v2;

 

VecMult2D(v0, v1, v2);

 

Not that this would be a good idea. The biggest problem with this is likely converting code from operator-oriented form into macro-oriented form, which can and will be a true hassle.

 

A third and most likely simplest option would be to rename one to the other or both to your own. Once again, if the operator overloads and members are the same, the conversion is actually pretty simple in most IDE-s: use Replace All (usually Ctrl+H or Ctrl+Shift+H) and rename one class name to the other (or, again, both to your own class). If you have differences in member names, then the conversion can be a real PITA, though.

 

A fourth and most efficient way is to use some form of refactoring. I don't know what native refactoring capabilities are like in IDE-s, but VisualAssist X (can be pricey, but is well worth the investment if you have the money) excels in stuff like this.

 

There is no automatic way to handle this.

Edited by irreversible
0

Share this post


Link to post
Share on other sites
Both Box2D and SFML are open source. Recompile one of them to use the other's vector.

Or, depending on how the two vectors are laid out, maybe it might be possible to cast them? I don't know whether that's safe or not, I typically avoid all except polymorphism casts and int casts, so my casting knowledge isn't great.
They both just have x and y floats and that's it (besides the functions). Can a reference to one be safely cast to a reference to the other?

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Vector2.php
http://www.learn-cocos2d.com/api-ref/2.0/Box2D/html/structb2_vec2.html Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites

For 2 element vectors its probably not that big of a performance problem to copy 2 floats compared to copying a pointer thats same size or twice the size of a float. If you actually use the floats at some point they need to get read anyway.

I would just pick one of the vector types that feels more comfortable to use or where you estimate less conversions would be needed if you need to call one of those librarys more often. Later if its really too slow you can always profile and see if you need to improve this or something else.

0

Share this post


Link to post
Share on other sites

I would go with a class implicit conversion operator.  The class would be my own Vector2/3 class.  

 

Or inherit from one of the vectors, and add your own conversion to the other one.  Just be sure you don't create one of your class vectors but then delete it with the base class vector you may get memory leak since it's probably not have a virtual dtor.

0

Share this post


Link to post
Share on other sites

Both Box2D and SFML are open source. Recompile one of them to use the other's vector.

Or, depending on how the two vectors are laid out, maybe it might be possible to cast them? I don't know whether that's safe or not, I typically avoid all except polymorphism casts and int casts, so my casting knowledge isn't great.
They both just have x and y floats and that's it (besides the functions). Can a reference to one be safely cast to a reference to the other?

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Vector2.php
http://www.learn-cocos2d.com/api-ref/2.0/Box2D/html/structb2_vec2.html

 

If they were literally identical, just varying by name, you could get away with casting.  In the real world, no, very bad idea.

0

Share this post


Link to post
Share on other sites

thanks all for your aswers, smile.png

 

 

I would just pick one of the vector types that feels more comfortable to use or where you estimate less conversions would be needed if you need to call one of those librarys more often. Later if its really too slow you can always profile and see if you need to improve this or something else.

i think i will chose this way and try to separate between gameplay object class and graphics class, in my problem i will use b2vec2 more because my game using box2d to program its gameplay and create a converter function for it for sfml related use. well, hope it's the most efficient way

 

 

Both Box2D and SFML are open source. Recompile one of them to use the other's vector.

this a good idea but, it'll be a problem with me since sfml using template to define it's vector and i'm still don't know how to use it. moreover b2vec2 using struct to define it's vector and of course it'll make me confusing

Edited by Fs02
0

Share this post


Link to post
Share on other sites
wintertime's solution is a good one - I was making the mistake of assuming that performance was already a problem.


Both Box2D and SFML are open source. Recompile one of them to use the other's vector.

this a good idea but, it'll be a problem with me since sfml using template to define it's vector and i'm still don't know how to use it. moreover b2vec2 using struct to define it's vector and of course it'll make me confusing


Just use SFML's sf::Vector2f typedef, and it'll work fine. The fact that SFML's vector struct/class is a template doesn't harm anything.

For example, if SFML had a templated struct like this:
template <typename Type>
struct MyStruct
{
    Type x;
    Type y;
};
Then it's really, as the name implies, just a "template" that the actual struct is generated from.

Doing this:
MyStruct<int> myIntStruct;
Tells it to generate a struct, using the template, with 'int' instead of 'Type', like this:
/* template <typename Type> */
struct MyStruct_ForInts 
{
    /* Type */ int x;
    /* Type */ int y;
};

MyStruct_ForInts myIntStruct;
Then they can create a second almost-identical struct, with floats instead:
MyStruct<float> myFloatStruct;
Which creates:
struct MyStruct_ForFloats
{
    float x;
    float y;
};

MyStruct_ForFloats myFloatStruct;
The actual name is generated by the compiler, but MyStruct<float> is the generated "name" of the class type that you, as the programmer, use in your code. So you don't actually use 'MyStruct_ForFloats variableName;', you use 'MyStruct<float> variableName;'

This is just to explain templates - I'd still use wintertime's suggestion. Edited by Servant of the Lord
1

Share this post


Link to post
Share on other sites

wintertime's solution is a good one - I was making the mistake of assuming that performance was already a problem.

yes, i will use it

 

This is just to explain templates

Wow, that was very good explanation,rolleyes.gif 

thanks, really appreciate it smile.png

0

Share this post


Link to post
Share on other sites


Or, depending on how the two vectors are laid out, maybe it might be possible to cast them? I don't know whether that's safe or not, I typically avoid all except polymorphism casts and int casts, so my casting knowledge isn't great.
They both just have x and y floats and that's it (besides the functions). Can a reference to one be safely cast to a reference to the other?

If they were literally identical, just varying by name, you could get away with casting. In the real world, no, very bad idea.
If they're both POD, then under the hood you're basically just casting a pointer to float to a different type of pointer to float, which is valid enough. You can throw in some compile time assertions that the sizes/layouts of the two classes remain identical so that the code will fail to compile should the classes change in the future.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0