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 ... 118 119 [120] 121 122 123
1786
System / Re: Questions and problems with sf::thread
« on: September 01, 2012, 11:07:24 pm »
Would it be feasible to merge your tiles into vertex arrays of quads?
(ie : you don't ever move, rotate, scale them, they use one or very few sf::textures for their graphics)

1787
Feature requests / Re: sf::Drawable
« on: September 01, 2012, 11:03:35 pm »
Just wanting to point out that 1.6 did it this way (and it discouraged from inheriting drawable if you don't need transforms) so it's more like downgrade request.  ;) Not a snowball's chance in hell..

1788
System / Re: Questions and problems with sf::thread
« on: September 01, 2012, 10:57:48 pm »
I mean if the things you draw are all from one texture/no texture? And how many tiles do you draw per call?

1789
System / Re: Questions and problems with sf::thread
« on: September 01, 2012, 10:38:33 pm »
Do you have only one huge texture for tileset? Maybe try making a class that takes window reference and then draws chunks of map(each chunk being class object containing small vertex array) that fall in view, it's substantially easier when there is only one texture.

1790
Window / Github Keyboard.hpp mistake
« on: September 01, 2012, 09:57:26 pm »
Comment of line 144 in Keyboard.hpp at github says   "///< The F8 key" while it should say "///< The F9 key"  :D

1792
Object 1 bottom=150
Object 2 top=600
if (bottom1 < top2)
        return true;
Use rect's intersect method.

1793
General / Re: Problem with "Manage different screens in a game"
« on: August 30, 2012, 10:43:48 pm »
setbackgroundcolor is from 1.3 which is ancient by now.
I'm digging through code and seeing mistakes already: loading image and font in run method, should be moved to c-tor. Actually this method just looks weird, the flow gets stuck in infinite while(Running) untill switch to other screen happens.
I'm not really sure, the way I do it is push the screens onto a stack and call run and render of the top one and the screens can request a pop(request as in, not pop themselves because that would cause the flow to return to function of object that got destroyed, but tell the wrapper around stack to do a pop next loop).

1794
Graphics / Re: sf::Rect questions
« on: August 30, 2012, 10:31:33 pm »
There are no floats involved in int=int/int, whatever is after decimal point gets cut off, there is no step in between with floats.

1795
Graphics / Re: sf::Rect questions
« on: August 30, 2012, 05:58:50 pm »
Dividing int by int returns trunced int, and even if it didn't then saving a float to int would trunc it(with a warning from some compilers about implicit trunc).
Quote
but I don't know how they work in SFML yet
They hold vertices, and the primitive type that these vertices are supposed to take, that's all.

1796
Graphics / Re: sf::Rect questions
« on: August 30, 2012, 05:41:05 pm »
Fill once for future setTile calls of it:
void Tileset::setTile(int tileNum)
{
                if(subRect.size()==0)
                {
        for(int h = 0; h < numTilesY; h++)
        {
                for(int w = 0; w < numTilesX; w++)
                {
                        rect.left = w * tileWidth;
                        rect.top = h * tileHeight;
                        rect.width = tileWidth;
                        rect.height = tileHeight;
                        subRect.push_back(rect);
                }
        }
                }
        this->setTextureRect(subRect[tileNum]);
}
Using local variables:
void Tileset::setTile(int tileNum)
{
        std::vector <sf::Rect<int>> subRect;
        for(int h = 0; h < numTilesY; h++)
        {
                for(int w = 0; w < numTilesX; w++)
                {
                                                sf::Rect <int> rect;
                        rect.left = w * tileWidth;
                        rect.top = h * tileHeight;
                        rect.width = tileWidth;
                        rect.height = tileHeight;
                        subRect.push_back(rect);
                }
        }
        this->setTextureRect(subRect[tileNum]);
}//all memory used by subRect gets released by its dtor
There is like bilion problems here: using sprites(classes derieved from it = even worse) for tiles is bad, you should use vertexarray instead. Why make entire array of all possible rects and not compute the tile rect directly like that(there might be error here, I wrote it very hastily):
void Tileset::setTile(int tileNum)
{
        int x=tileNum%numTilesX;
        int y=tileNum/numTilesX;
        sf::Rect<int> rect;
        rect.left=x*tileWidth;
        rect.top=y*tileHeight;
        rect.width=tileWidth;
        rect.height=tileHeight;
        this->setTextureRect(rect);
}
 

1797
General / Re: Need help understanding how this code works.
« on: August 30, 2012, 03:51:24 pm »
It wasn't sarcastic, <own class name>_HPP is extremely unique and in all caps like all macros should be.

1798
General / Re: Need help understanding how this code works.
« on: August 30, 2012, 03:40:29 pm »
CLASS_HPP seems like an extremely unique name written in all caps.

1799
Graphics / Re: sf::Rect questions
« on: August 30, 2012, 02:46:18 pm »
What are you doing and trying to achieve? Is tileset derieved from sprite? If it is, sprite copies the rect for itself and updates it's 4 vertices everytime rect changes. Why do you fill and destroy all tiles every call to setTile instead of making your vector local variable or filling it only once?

1800
General / Re: Need help understanding how this code works.
« on: August 30, 2012, 12:45:59 pm »
It's NOT needed. It's not at all significant, macros are not code, it's preprocessor - it works in text, not code, the _INCLUDED can make it more intuitive, it could be whatever but should be in ALL CAPS, long and unique(for safety).
http://www.stroustrup.com/bs_faq2.html#macro - read this to understand why macros are evil and should have extremely unique names.
Quote
Conventions such as having macros (and only macros) in ALLCAPS helps, but there is no language-level protection against macros. (...) Macros operate on a program as a stream of characters before the compiler proper sees it

Pages: 1 ... 118 119 [120] 121 122 123