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 - eXpl0it3r

Pages: 1 ... 617 618 [619] 620 621 ... 719
9271
General / Re: AW: How do I diagnose why SFML runs slowly?
« on: November 02, 2012, 10:57:11 pm »
Graphics driver? What other should I try? The open source drivers are pretty crappy in games as far as I know. The AMD graphics driver I have installed is through Ubuntu's package manager.
It doesn't matter where you get the driver from, if it doesn't support your chipset well... Also don't make assumption without testing them, specially if the alternative doesn't work.
Being on a Linux system requires some experimentation, so don't hesitate whenever you need to test things. ;)

Dunno, how do I know that?
You could've just looked on their website...

9272
General / AW: How do I diagnose why SFML runs slowly?
« on: November 02, 2012, 09:40:24 pm »
Try a different driver...
Is the installed game also OpenGL based?

9273
General / Re: Accepting User Input, and Gui/library recommendations?
« on: November 01, 2012, 10:59:00 pm »
Is there any written tutorial about creating own widgets(or about anything except hello world really..)?
but some tutorials would be nice. :P
SFGUI comes with quite a few examples, that possibly show every single widget in use. Should be quite easy to extract the information from those with the help of the doxygen documentation.

9274
Ah, thank you! I just got the latest nightly and tested with that, and I still see the same problem.
And what font did you use?
It works perfectly fine on my end...

9275
General / Re: Accepting User Input, and Gui/library recommendations?
« on: November 01, 2012, 03:57:14 pm »
I can try to create my own mini window and take a crash course on the win32 library functions to try to figure out how to implement and read from a basic text box. Or I can try to find some sort of Library such as Qt or WxWidgets, and use some of their build in functions for it.
Like I said if possible I would like to have the box within the window itself, and not another separate popup window.
Using an GUI library like MFC, Qt or WxWidget won't give you the possibility to have GUI elements on top of the OpenGL/SFML rendering (afaik), thus you can't really use those.
The 'easiest' thing would be to use the OS specific 'message boxes' (or Qt's equivalent), but this would then be a 'pop-up' window, which you don't want.
So this leaves you with the SFML/OpenGL GUIs, like SFGUI (gets my recommendation), TGUI or basically anything that can implement an OpenGL renderer (e.g. GWEN or CEGUI).
Good luck! :)

9276
General discussions / Re: Unofficial Nightly Builds
« on: November 01, 2012, 03:49:00 pm »
Updated the following builds:
  • Visual C++ 10 32bit
  • Visual C++ 10 64bit
  • Visual C++ 11 32bit
  • Visual C++ 11 64bit
  • MinGW TDM GCC 4.7.1 32bit
  • MinGW-w64 rubenvb GCC 4.7.2 32bit

Thanks to the external library fix there shouldn't be problems anymore regarding static runtime library linkage with all Visual C++ and the MinGW 32bit builds.
For the MinGW 64bit builds I'll have to investigate a bit more. If you really need MinGW 64bit builds use the previous ones, but be aware that you can run into problems when linking statically...

9277
Graphics / Re: sf::Text appearing with an odd offset
« on: October 31, 2012, 08:35:16 pm »
You should've probably also searched on the issue tracker: #216

9278
Well the default font is depreciated and already removed in newer versions of SFML, but as you said it's most probably no the source.

I'd kind of guess that you're doing something wrong since I haven't heard of such a problem yet, thus you should provide a complete and minimal example that reproduces the problem. ;)

9279
Window / Re: Mouse Get Position Issue
« on: October 31, 2012, 03:04:14 pm »
Important to note is I did adjust the y coord because I am using openGL, but even still they are both messed up.
You're doing somewhere something wrong, most probably when you assume that you 'just' adjust the y coordinate with OpenGL directly, but without any code, we can't help you at all. I mean what do you expect us to do, when we have no clue at all what you're doing?
How do you check things at breakpoint? How do you ensure that the two checks happen at the same time?

Does this behave the same way?
#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Resize");
    window.setFramerateLimit(60);

    sf::Vector2i mousePos;

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
        }

        mousePos = sf::Mouse::getPosition();
        // Set your break point to the next line and check mousePos there.
        std::cout << mousePos.x << "," << mousePos.y << std::endl;

        window.clear();
        window.display();
    }
}
 

9280
General / Re: Deciding which Container to use for a Manager Class.
« on: October 31, 2012, 11:09:39 am »
Quote from: eXpl0it3r
I can't full agree.
Sure you can.  You noted a possibility that the relative order of elements in the vector may be important...  so did I.
Me not fully agreeing, does not only related to that part.

Quote from: cire
and the relative order of elements in the vector isn't important
The OP was making a blanket statement that deletion from vectors was always expensive, which isn't true.  Considering he was using a vector of pointers, it seemed worth pointing out.
But he's right. Because you shouldn't compare deletion of pointer elements to deletion of data elements, but you have to compare deletion of pointer elements in a vector to deletion of pointer elements in another container.
And if you can't use the swapping trick, the deletion of a vector will take O(n) and for others it might only take O(log n) (heap/tree) or even better O(1) (hash table).

What I do agree on is that vectors are in many cases the best choice. The main advantage that a vector has, is that the data is stored in a continuous memory block and thus iterating over it, will make use of the CPU's cache, which is quite a nice accelerator. ;)
So as we see the use cases of a vector are where you store the actual data in the vector (not just the pointers, since this will give you more of a jumping table) and if you have to iterate a lot over it.
Neither of which are the case for the given problem, so if you actually want to point out things independently from the actual topic, you should make this very clear. ;)

9281
General / AW: Re: Deciding which Container to use for a Manager Class.
« on: October 31, 2012, 09:38:54 am »
A vector or deque should be considered the container of choice until you know that you need the qualities of another container.

Removing something from the middle of a vector can be quite cheap if the element is say, a pointer, and the relative order of elements in the vector isn't important.  Just swap it with the back one and erase the end (or resize if you prefer.)  And, you won't find faster insertion/deletion than at the ass-end of  a vector or either end of a deque.
I can't full agree. Because swapping a to delete mit the back element only works if you're not working with the indices but for managers thos is very likely (you nees to know which resource to return when requested).
So if you can't swap the entries the deletion is essentially O(n) which is slower than the O(1) of a hashtable or the O(log n) of a black-red tree. ;)

9282
Graphics / Re: sf::Text throws an exception
« on: October 31, 2012, 03:29:35 am »
Well I guess the exception itself tells you what the problem is (at least in debug mode it will have a 'descriptive' error).

I can't really tell what exactly causes the (to me unknown) exception, but by questioning the sense of your code I automatically will 'resolve' the problem. I mean the constructor of sf::Text takes either nothing, or a string and a reference to a sf::Font object. So what should the text object do with a temporary font object that only exists in the constructor? There's no sense in such code.
The API has changed and you'll have to go with the change and not try to work around it, thus every sf::Text need a valid sf::Font (okay you can also use the default constructor, for which the sf::Text then doesn't have a a reference to a sf::Font object).

9283
I verified that /MTd and /MDd are the problem. These are the steps I used:
  • Compile FreeType 2.4.10 from source with the /MT flag (use Debug Multithreaded configuration in their .sln)
  • Check out the latest SFML source from GitHub
  • Replace SFML/extlibs/libs-msvc/x86/freetype.lib with the /MT one
  • Compile SFML with CMake option SFML_USE_STATIC_STD_LIBS
  • Link SFML statically to my game (using SFML_STATIC)
Now my game compiles without errors. There are still warnings, but I think those are from libjpeg and libglew.
Well that doesn't confirm anything, it just shows that it works with /MT builds and your specific setup. ;D

As far as my testing goes (dumpbin /all LIBRARY | find /i "msvcr") I have only found a result on the libsndfile-1.dll but nothing in the static libraries, so...

9284
General / Re: Deciding which Container to use for a Manager Class.
« on: October 31, 2012, 03:11:15 am »
That's the reason I said "best" and not best. I understand that these things should be project specific, but I was asking for a general idea of STL container speeds. Most games aren't really going to have 100,000 textures, so I was looking for a container that may be "better" than a vector. By "better" I mean one that would balance adding and removing from a non-terminal point and being able to quickly find a value. Vectors are very fast at iterating from the start to end, but removing something in the middle can be heavy. Consider adding are removing instances nearly every step. (Obviously, there are very few times when this is even a good idea, but I know a vector is not the best container for this scenario.)
Okay this gives us a bit more to work with. :)
Unfortunately this list is missing C++11 containers.
If you want (amortized) constant (O(1)) look up, insertion and deletion then you might want to take a look at std::unordered_map, although it's not guaranteed by the standard (afaik) it will probably mostly get implemented as actual hash table.
std::map on the other hand is often implemented as red-black tree and thus is also quite fast but since things have to get sorted it's 'only' O(log n).
A std::list won't be such a good choice, since the look up, insertion and deletion are in O(n).

For the O-notation see here.
TL;DR: Smaller is better: O(1) < O(log n) < O(n)
And if you got too much time on your hand and are interested in data-structures you can take a look at this. :D

I'm writing the managers to implement the most balanced solution for any generic scenario.
And there I thought you've understood it. ::)
Stop writing stuff for 'any generic scenario' and start writing code that's needed by your game.
Writing a generic game engine isn't really something you should target and it's something that's very rare in the wild, e.g. first there was Quake then there was the quake engine or first there was Half Life and then there was the source engine, etc. ;)

I don't mind implementing auto pointers, it just doesn't seem necessary. What's wrong with:
Object* Instance = new (std::nothrow) Object;
if (Instance != nullptr) {/*do stuff*/}
else
{/*do error stuff*/}
 
Smart pointers not auto pointers (std::auto_ptr is depreciated). ;)
I'm sure it doesn't cover all the possible failures. Like I said read the linked post or at least take a look at this example.

9285
General / Re: Deciding which Container to use for a Manager Class.
« on: October 31, 2012, 02:06:48 am »
I'm looking for the "best" container that balances rapid lookup with quick deletion from a non-terminal end.
Asking for "the best" way is mostly always the wrong question. There simply is no "the best" way. Everything is relative and highly depended on what the code should do and for what it should be laid out. I mean there's a hugh difference between having to handle 100 textures or 100'000 textures, but not only the use case matters but also the integration and location within the project matters.
So to figure out what's "a very good" way of doing things "for your project", it'd probably best to read more on your own on the topic of different containers. ;)

The use of pointers is to avoid copying and such.
Well if you use pointers then the containers to not matter that much, because the containers will essentially just store the pointers and not the actual data. So look up and deletion will often be very similar.

The STL is built to guarantee high performance with the correct use of the containers, thus up to a certain point it doesn't matter that much which one gets used. Also i most cases you should choose the container by it's use case and not by it's 'performance' (otherwise you'd always have to choose a plain array/std::array). So if you want to use indices for your data, then go with a std::vector. If you want to have key->value matching and it should be ordered the go with std::map, if the order doesn't matter then go with std::unordered_map.  If you run into performance issues caused by your manager(s), then you could reconsider the choice.

I know that manual memory management is frowned upon with unique pointers, but it seems unnecessary when the manager deletes everything for you anyway (in its dtor).
I really advise you to reconsider that decision and read a bit more about the actual problem with manual memory management (e.g. read this thread fully).
Keep in mind though that shared_ptr might be more appropriate for 'manager' classes, since you most probably will share the resource rather than transfer the ownership (what unique_ptr does).

Pages: 1 ... 617 618 [619] 620 621 ... 719
anything