Draw image directly?

[Andy]

I've been working on a project and I'm trying to step it up so it can use multiple APIs.

Is there a way I can draw images directly (based on a rectangle class which is written for the engine)? Obviously I'm not trying to use an image per sprite, but I am trying to render a sprite without using the sf::Sprite class.

I've tried using OpenGL code in conjunction with SFML to draw a sprite, I've been very unsuccessful so far.

I'd post code, but they're just the wrong answers.

Using a class like to following:

Code: [Select]


class RectangleF{
    public:
        RectangleF();
        RectangleF(float _x, float _y, float _w, float _h);
        float x, y, width, height;
        float right();
        float bottom();
};


-thanks for the help in advance[/code]

[Hiura]

Why don't you want to use Sprite?

(btw, there is a solution to use no Dprite but it's kind of stupid so ... I won't tell you unless you have a really strong argument to the question above.)

[Andy]

That's ok, for now I'll just use a single "facilitator" sprite for all my sprites.

The reason I'm avoiding the Sprite class is because I want the engine to be able to use multiple APIs, so using sf::Sprite becomes difficult, since I don't always have use of this class with other APIs.

I just don't want to continually declare another sprite class just for one API and it'll mean more code.

I could continue to try OpenGL in conjunction with SFML until I get it working. I've gotten close, but no cigar.

I think it would be pointless to argue it, so thanks but no thanks.

[Hiura]

I agree, be able to use multiple APIs for an engine is really good. But if you use sf::Image, why not use also sf::Sprite ? I mean, you're already using one thing from SFML so why not use the whole lib ?

Or maybe I miss something ?

PS : «I think it would be pointless to argue it» You're wrong, my question was really a question. Plus, nothing I say is perfect so please come and argue with me!   :twisted:

[Andy]

Ok, I just had to be sure you weren't one of those people (though in a place like this it seems hard). I don't want to be involved in no flame war.

But for the sake of the argument,
I want to draw images directly for these reasons:

Every API I've seen so far seems to have a texture/image/surface class that can be used to blit to the screen, however not every API uses a sprite class.

This engine is setup in two distinct parts the "BackStage" modules and the "ForStage" module, the backstage part may refer to "ForStage" objects in a vague manner (e.g. void *). They are intensionally vague so preprocessors for any backstage object becomes unnecessary. Since the API objects are unmixed and no API-specific objects are used in the backstage, it makes for cleaner code.

The ForStage module uses every object, though this makes "messy" code easy, it limits all the preprocessors and pointer casts to module.

Arguably using vague types can make way to easy segfaults, but I believe this can be prevented with a little bit of labeling.

The ForStage module is used in a way so that no API information needs to be used with the backstage objects. The backstage objects may call any forstage function as necessary.

The ForStage functions takes whatever information is necessary to draw a sprite, string or other. By using references, the weight of these calls can be limited.

Also in the future I may make it so the engine is more plugin based, in hopes that'll be more universal.

[Hiura]

I'm not very experimented with that kind of work. You may look with someone else how to organize your code. But just a note : when I hear void* in C++ code I think "there should be a prettier way to go".

But if you want my opinion :

Spontaneously I would do the following : have two kind of class, backend (kind of private, used for implementation) and front-end (public interface). That's a bit like you said, but no need of void*-thing.

In fact like SFML does for sf::Window. If you look at it you won't find any messy code.

[Andy]

I agree.

I still may have to use a void * just to point to a data structure.
Oh wait, or just do that in the private class.

I thinking how for image works, but what about sprite? A good puzzle me thinks however some things just don't seem to directly correlate. I'm gonna do some more brainstorming, but thanks for the input.

[Hiura]

One idea frm many : a class Texture (frontend) , no big deal here, and for the backend we have some BETexutre which would have a SDL_Surface or a pair of sf::Image/sf::Sprite in the different implementations.

Good luck!

[Andy]

I think I'm seeing what you're doing there!

For instance with the x property.
Appearence in header:

Code: [Select]


class backsprite{
    ...
    float &x();
};

Appearence in module:

Code: [Select]


float &backsprite::x(){
    return sprite.GetPosition().x;
}


Thanks for the helpful advice! [/code]

[Nexus]

Regarding encapsulation, your member function x() is as useless as the public variable you had before.

Since you return a reference to non-const, the user can access the attribute and change it in any way he wants, without informing the class about these modifications. Besides, you are bound to this fixed implementation, for instance you can't switch from float to double without changing the method signature. Apart from all this, your code isn't even valid C++, as it implicitly removes const-qualifications.

Real data hiding means to separate the implementation from the interface. One way to achieve this is to provide get and set functions with separated read/write access.

[Andy]

Thank you for pointing that out, I'm still a C++ newbie.
[edit]
I'll get standards help elsewhere (as this is not the appropriate place).
That statement realize far behind I am still.
Google hasn't been nice about find information on the standard, however I remain hopeful I'll find something.