Messages

1

Graphics / Looking for a better design for drawing sprites in order.

« on: April 23, 2010, 09:06:40 pm »

Here are the results of multimap vs multiset (using same test case as above)

Here are the results so far (in ticks):
10,000 loops

10 sprites  
[map] average: 234
234
234
234

[set] average : 254
312
234
218

100 sprites
[map] average : 2755
2844
2734
2688

[set] average : 2668
2047
2500
3459

1000 sprites
[map] average : 34,568
34,813
34,297
34,594

[set] average : 32,291
32,390
32,375
32,109

10000
multimap) 388,969

multiset) 388,563


Its pretty damn close.

2

Graphics / Looking for a better design for drawing sprites in order.

« on: April 23, 2010, 08:24:05 pm »

Running with differing amount of drawables.  

This is my test scenario (worst case)
Adding sprites 1 by 1.
Drawing through.
Removing 1 by 1 using the find/lookup methods.

Here are the results so far (in ticks):
10,000 loops
a) map + vector + list
b) multiset

10 sprites
a) 343
b) 188

100 sprites
a) 3797
b) 2047

1000
a) 326,219
b) 26,812

(retested 1000 sprites)
a) 392,266
b) 26,406

10000
a) -
b) -

I'll write one up using multimap in a second.

3

Graphics / Looking for a better design for drawing sprites in order.

« on: April 23, 2010, 11:01:47 am »

For anyone still reading.

I wrote up another method of storing drawables by using std::multiset and compared it with my original.

It's approximately 2x faster.
Using the list, vector, and map = ~37 seconds
Using multiset = ~20 seconds

I'm going to stick with multiset.

4

Graphics / Looking for a better design for drawing sprites in order.

« on: April 22, 2010, 08:24:23 am »

I agree.  Objects are only added and removed if their visibility or levels have changed.  Which is not a common occurrence in the middle of a non-game state.

I am wondering if there are any implementation designs that are an improvement over mine as it is costly to remove drawables from the list.   All drawables on the list are used as the key and the list iterators used as the value within an std::map to facilitate searching drawables for removal.

This requires 2 calls to map (find, and erase) and 3rd call to list (erase).

5

Graphics / Looking for a better design for drawing sprites in order.

« on: April 21, 2010, 11:02:20 pm »

The problem is, code execution order does not guarantee sprites will be drawn in order without some sort of method to track their levels, sort the sprites, and then drawing them.

What are your ways of doing this?

My method:
If the drawables need to be rendered they are added to a draw vector (only happens when set view == true, not every frame)
At the end of each frame, drawables on vector are sorted (std::sort), then merged with an in-order drawables list.
Then the list is iterated through executing windows::draw()

By the end, the draw list contains all the drawables rendered last frame in order, removing the need to continually adding, sorting sprites every frame.


If a drawable is no longer visible, it is removed from the list.
I use a map to do this rather than iterate through the list looking for the drawable.

6

Graphics / [solved]Strange 'Artifacts' produced by RenderImage

« on: April 18, 2010, 09:27:11 pm »

Correct me if I'm wrong but it sounds like ashen is trying to build layers of sprites on top of each other like a naked character, then clothes, then weapon (built on top of the previous sprite to create the final image).  

Is this correct?

7

Graphics / sf::string [1.6] is there a built in way to find height?

« on: April 14, 2010, 09:06:27 pm »

Ok, so this is the design, let me know if an improvement can be made:

//Iterate 1 -> 255
   // find the glyph with greatest height

//= Get String Size / Font CharacterSize * glyph height

8

Graphics / sf::string [1.6] is there a built in way to find height?

« on: April 14, 2010, 01:28:53 am »

What I am looking for is a means to finding the height where it includes the tail parts of symbols like q,p,g, etc.  The only way I can see doing that is to push all possible symbols onto the string and getting it from the rect.  Which doesn't sound like the right way to go about it.

Is there a simpler way?

9

Graphics / [solved]sf::events::TextEvent question

« on: April 14, 2010, 01:15:11 am »

Thanks!

10

Graphics / [solved]sf::events::TextEvent question

« on: April 13, 2010, 12:49:44 am »

Defined within TextEvent is Uint32 Unicode.

Is there an std type that can natively support the that type in the form of a string?  I'm currently using std::wstring, but warnings are making me cast to wchar_t when saving the event data to the wstring.  Or is wstring the best option?

I just want to make sure I'm not accidently casting away valid data.

11

Graphics / Question about sf::string 1.6

« on: April 11, 2010, 09:46:23 pm »

Opps, meant string.  Thanks for the timely responses.

12

Graphics / Question about sf::string 1.6

« on: April 11, 2010, 09:09:51 pm »

Firstly, I'd like to say, sfml is quite good.  I was using HGE and decided to make the switch last week and haven't had a single regret.

I have a few questions though.
Is there a way to modify the colors of individual characters within a sf::string?

Is there a trivial method to retrieve the widest character of font set at a specific size?

And lastly a trivial method of allowing me to edit strings?  Such as insert and remove characters? (otherwise, I'd have to use a std::list<char> to do it).

Thanks in advance.