Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - FRex

Pages: 1 ... 116 117 [118] 119 120 ... 124
1756
General / Re: Smooth scrolling large textures
« on: September 06, 2012, 01:07:27 am »
I'm not sure but the position of sprite might be trunc'd if it's texture is not smooth. So with these numbers all you're doing is move by 2 pixels then 3, then 2, then 3, so on, so forth.
Quote
1, This is just an experiment,
2, Even with vertex arrays, I believe I need to use render-to-texture,
3, The problem that I can't do smooth scrolling with large textures is not related to the way the tiles are rendered, since the tile map is just one large texture,
4, I haven't figured out how to use vertex arrays yet,
5, As far as I know, older graphics cards don't support them,
6, The Nintendo Entertainment System certainly had no vertex array support, yet it was capable of smooth scrolling tile-based maps 
1. that's quite alright,
2. that's also alright but the late trend of work-around-to-render-more-than-you-really-can is quite peculiar,
4. So instead of asking you try and work around by asking about something else ;D
5. in the end, every sprite, text, whatever, will attempt to use draw(vertices,count,primitive,states) or vertex array(which then uses the long draw method too), so if it doesn't support vertices, it doesn't support sfml
6. Just.. :)

1757
General / Re: Smooth scrolling large textures
« on: September 06, 2012, 12:43:28 am »
Since I don't have your classes I can't even run the code.  :)
Did you try:
layer1.setSmooth(true);
Also, why use rendertexture if you're redrawing everything every frame anyway?
For tilemaps you should proably go with vertex arrays.

1758
General / Re: Why doesn't my fullscreen window display?
« on: September 06, 2012, 12:21:03 am »
What do you mean by using fullscreen command?!
Also, show us the example you used and how were you resizing the image.
Just saying
App.create(sf::VideoMode(1440, 900, 32), "CRAPS", sf::Style::Fullscreen);
simply won't do.
TBH I don't know what you did but nothing will ever resize automagically on itself, ever.

1759
SFML projects / Re: Eduard Engine 0.0.1
« on: September 05, 2012, 08:12:17 pm »
Here's ee's debug draw, slightly modified and commented, it's kind of quick and dirty, it's a debug tool after all, I hope I didn't make a mistake somewhere, it assumes you flipped the Y axis to match SFML's convention:
class EEDebugDraw3 : public b2Draw
{
private:
        sf::RenderTarget * m_target;
        //inliners for colour and point conversions
        inline sf::Color EEColor(const b2Color& gCol)
        {
                return sf::Color(static_cast<sf::Uint8>(255*gCol.r),
                                                static_cast<sf::Uint8>(255*gCol.g),
                                                static_cast<sf::Uint8>(255*gCol.b));
        }
        inline sf::Vector2f EEVector(const b2Vec2& gVec){return sf::Vector2f(gVec.x*pixmeters,gVec.y*pixmeters);}
        const float pixmeters,radegrees;//constants for point and degree conversions
public:
        EEDebugDraw3(void);
        virtual ~EEDebugDraw3(void){};
        void LinkTarget(sf::RenderTarget& gtarget);
        virtual void DrawPolygon(const b2Vec2* vertices, int32 vertexCount, const b2Color& color);
        virtual void DrawSolidPolygon(const b2Vec2* vertices, int32 vertexCount, const b2Color& color);
        virtual void DrawCircle(const b2Vec2& center, float32 radius, const b2Color& color);
        virtual void DrawSolidCircle(const b2Vec2& center, float32 radius, const b2Vec2& axis, const b2Color& color);
        virtual void DrawSegment(const b2Vec2& p1, const b2Vec2& p2, const b2Color& color);
        virtual void DrawTransform(const b2Transform &xf){};
};
#include "EEDebugDraw3.h"
EEDebugDraw3::EEDebugDraw3(void):
pixmeters(32.f),//arbitrary value dependant on the program needs
radegrees(57.2957795f),//degrees per radian,a physical constant
m_target(0x0)
{
        AppendFlags(static_cast<uint32>(~0));//set all drawing bits to 1(not all 32 are relevant but it's ok)
}
void EEDebugDraw3::LinkTarget(sf::RenderTarget& gtarget)
{
        m_target=&gtarget;
}
void EEDebugDraw3::DrawPolygon(const b2Vec2* vertices, int32 vertexCount, const b2Color& color)
{
        sf::ConvexShape shape;
        shape.setOutlineColor(EEColor(color));
        shape.setOutlineThickness(1);
        shape.setFillColor(sf::Color::Transparent);
        shape.setPointCount(vertexCount);
        for(int i=0;i<vertexCount;++i)
        {shape.setPoint(i,EEVector(vertices[i]));}
        m_target->draw(shape);
}
void EEDebugDraw3::DrawSolidPolygon(const b2Vec2* vertices, int32 vertexCount, const b2Color& color)
{
        sf::ConvexShape shape;
        shape.setFillColor(EEColor(color));
        shape.setPointCount(vertexCount);
        for(int i=0;i<vertexCount;++i)
        {shape.setPoint(i,EEVector(vertices[i]));}
        m_target->draw(shape);
}
void EEDebugDraw3::DrawCircle(const b2Vec2& center, float32 radius, const b2Color& color)
{
        sf::CircleShape shape;
        shape.setOutlineColor(EEColor(color));
        shape.setOutlineThickness(1);
        shape.setFillColor(sf::Color::Transparent);
        shape.setRadius(radius*pixmeters);
        shape.setOrigin(sf::Vector2f(radius*pixmeters,radius*pixmeters));//set origin to middle or position setter below would not work correctly
        shape.setPosition(EEVector(center));
        m_target->draw(shape);
}
void EEDebugDraw3::DrawSolidCircle(const b2Vec2& center, float32 radius, const b2Vec2& axis, const b2Color& color)
{
        sf::CircleShape shape;
        shape.setFillColor(EEColor(color));
        shape.setRadius(radius*pixmeters);
        shape.setOrigin(sf::Vector2f(radius*pixmeters,radius*pixmeters));
        shape.setPosition(EEVector(center));
        m_target->draw(shape);
}
void EEDebugDraw3::DrawSegment(const b2Vec2& p1, const b2Vec2& p2, const b2Color& color)
{
        sf::Vertex line[2];//const sized c styled array, safe enough in here
        line[0].color=EEColor(color);
        line[0].position=EEVector(p1);
        line[1].color=EEColor(color);
        line[1].position=EEVector(p2);
        m_target->draw(line,2,sf::Lines);
}
Example:
{
        sf::RenderWindow App(sf::VideoMode(500,500),"Bug Draw");//window setup
        App.setFramerateLimit(60);//important because steps are linked to fps for this example,
        //construction and linkage to window
        EEDebugDraw3 debugdraw;
        debugdraw.LinkTarget(App);
        //construction and linkage to debug draw
        b2World world(b2Vec2(0.f,9.8f));
        world.SetDebugDraw(&debugdraw);
        //sample body
        b2BodyDef bdef;
        bdef.type=b2_dynamicBody;
        b2FixtureDef fdef;
        b2PolygonShape sha;
        sha.SetAsBox(1.f,1.f);
        fdef.shape=&sha;
        bdef.position=b2Vec2(4.f,0.f);
        world.CreateBody(&bdef)->CreateFixture(&fdef);

        while(1)
        {
                App.clear();
                world.Step(1.f/60.f,8,3);
                world.DrawDebugData();
                App.display();
        }
}

1760
General / Re: Why doesn't my fullscreen window display?
« on: September 05, 2012, 11:04:13 am »
There's an overload that takes a vector 2i and a view, the 1 argument version uses window's current view.

1761
SFML projects / Re: Eduard Engine 0.0.1
« on: September 05, 2012, 11:02:03 am »
Quote
it sounds like a missing sf::Texture::setSmooth(true), no ?

That makes lines appear non-stop.
Quote
Mixing the two isn't so hard, but mixing them well is not so easy...
I have no idea really. I could post my old debug draw class, it's self explanatory, but so is (imo) everything.

1762
SFML projects / Re: Eduard Engine 0.0.1
« on: September 05, 2012, 02:07:15 am »
I use tiledmap class with chunks of 512x512(size is controlled by a constant in one of headers and 512 seemed like a good compromise between amount of draw calls and uneccesarry tiles getting rendered off view), engine renders only one that fall within current view, but I guess that has nothing to do with the problem. The lines actually come from sfml but I don't really mind. There is a position on my todo list 'wrap render window so that view get trunced to pixel perfect rendering' but I'm too lazy, it's like 20 lines of code, I might do it soon-ish.  :P

Quote
We're still missing a nice tutorial on how to glue SFML and Box2D together, so if you got some time...
I have like 6 months of c++, 1 year of extremely weak c(no free store, no string.h, no nothing) and 1,5 years of total programming background (delphi, borlands vcl) and almost no education except net and a bad, bad course (not even a book).
I used box2d for 2 monnths, sfml 2.0 for 2 months and sfml in total for 5 months maybe.
Do you still want me to write a tutorial. ;) (but I might)
However the old debug drawing class could work outside the box if I didn't delete it.(I checked, it's still there  :P)

Quote
I guess non programmers wouldn't understand what seems to be great about this, since it's very simplistic but the code behind it, is what counts atm.
I might post the code, I don't think I cussed in comments and they are kind of informative (but few) and explain purpose of class/header and variables and methods are not nammed like 'do_voodoo()' but rather 'GenerateTerrain()' and 'DumpIntoStream(std::ofstream& gstream)'
Also quite good class is the silent hero of the jumping - b2contactlistener derived class, it tells both objects: you collided with this guy and give each others pointer to them, currently all collision going on is between a static wall(that does nothing, ever) player(same) and jump sensor(count touching walls, if greater than 0 then it permits a push upwards('jump')) but all it takes is adding some new type of object to enum ,derieveing a class from interface from eeuserdata and declare virtual methods to react to type in whatever ways.
Oh.. but I'm reluctant because it's probably nooby design and execution.  :-[

1763
SFML projects / Re: Eduard Engine 0.0.1
« on: September 05, 2012, 01:47:07 am »
You better don't go into editor, it lacks any gui, I can only manage with what it has so far because I know the code behind.

1764
SFML projects / Eduard Engine 0.0.1
« on: September 05, 2012, 01:22:25 am »
Just a little something I've been messing around with during last month to brush my c++, SFML, Box2D and interfacing-all-of-them-together-into-easy-to-manage-structure skills.

Download (Wins32 Relase compilation):
https://docs.google.com/open?id=0B8dEkQw1a4WvZERTbmdDMDZoT2c

Choose to download entire .rar(File-download or press Ctrl+S), then unpack and run the exe.
I don't know what will happen if you remove some of resources, I tried to make checks for fstreams but I might have missed a spot.  :)

Corners that have been cut:
-Options and Load Game are placeholders  :(
-Click on these two buttons and background creates a floating text 'Test'  :)
-The menu buttons are plain images  :(
-Only thing that is implemented so far are tiles and terrain
-Tiles are ugly placeholders
-Game and Editor automagically load the testing map
-Algorithm to change editor data into box2d data is not too good but well abstarcted away so if I come up with better one I can convert map with new one using 3 command lines

Controlls:
-Editor is controlled by tilde to toggle console, command lines(full list in Resources/Main/EditorDictionary.txt), mouse for editing and escape and wasdqd for camera, it's better and safer to avoid it for the time being, I might write instruction
-Game is controlled by W S A D keys, press E to toggle Box2D debug draw

SFML part:
-Windowing
-Time control with clocks
-Input, rendering
-Extremely easy Box2d debug draw rendering with vertices
-Not using the default font altho I didn't upgrade to the latest version and still have it  8)

Box2D part:
-Everything physics related ie movement, collision, callbacks(currently only very few, for example the jumping sensor that allows jumping only from top of something solid)

P.S. No, my name's not Eduard.  ;)
P.P.S. I wonder if someone reached this point.  :-\

1765
Graphics / Re: [Solved] SetOrigin function makes the sprite disappear
« on: September 05, 2012, 01:00:31 am »
Quote
The origin of an object defines the center point for all transformations (position, scale, rotation)
Quote
By default, the sprite is positionned/rotated/scaled relatively to its top-left corner, because it is the local point (0, 0). But if we change the origin to be (5, 5), the sprite will be positionned/rotated/scaled around its center instead. And if we set the origin to (10, 10), it will be transformed around its bottom-right corner.

To keep the sf::Transformable class simple, there's only one origin for all the components. You cannot position the sprite relatively to its top-left corner while rotating it around its center, for example.
Seems informative and clear enough to me and easy to confirm through little experimentation.

1766
Graphics / Re: Sprite and Texture errors
« on: September 04, 2012, 08:27:39 pm »
Yeah ;) Also the copy c-tor of texture seems quite heavy so this idea is getting worse by the minute.

1767
Graphics / Re: Sprite and Texture errors
« on: September 04, 2012, 08:21:10 pm »
We were talking about textures in a vector. If vector realocates then sprites that held pointers to it's elements now contain garbage pointers.

1769
Graphics / Re: Sprite and Texture errors
« on: September 04, 2012, 07:53:44 pm »
Quote
OpenGL somehow releases the texture
Don't be cussin like that around me. ;)
void Sprite::draw(RenderTarget& target, RenderStates states) const
{
    if (m_texture)
    {
        states.transform *= getTransform();
        states.texture = m_texture;
        target.draw(m_vertices, 4, Quads, states);
    }
}
But sprite holds pointer to sf texture not anything opengl and draws like that so there is garbage in the space where old texture pointer points to(maybe)?

1770
Graphics / Re: Sprite and Texture errors
« on: September 04, 2012, 07:43:22 pm »
Vectors are guaranteed to lay their contents like c-style arrays did(one after another, so random acess is fast) and they reserve a bit of extra space for few objects when they get constructed but if you add too many they will run out of this extra space and then realocate their content to another chunk of space, bigger than the last to prepare for next push_backs.
You can check how many objects there are with size() and how much more space is ready for next objects with capacity().

Pages: 1 ... 116 117 [118] 119 120 ... 124
anything