Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Aug 2000
Offline Last Active Aug 17 2016 04:05 AM

#5300484 Opengl: is gltexcoord1d() deprecated?

Posted by on 13 July 2016 - 02:27 AM

Put glTexCoord inside glBegin/glEnd and before glVertex.

That should not really be the problem, glTexCoord can be called at any time since it just modifies state. glVertex* is only allowed to be called inside glBegin/glEnd.

That said, glTexCoord is just severely, extremely deprecated. You could try to fix it. Try glTexCoord2f instead of glTexCoord1d since that was much more used even back then and maybe the emulation for the very uncommon functions got broken in a driver update. I highly doubt that though. It's far more likely your program relied on undefined behavior of OpenGL and the behavior changed in newer drivers.
It's also possible that whatever you are using to create the OpenGL context requests a context without the deprecated functions.

Personally, I would not bother to fix it. The old deprecated functionality of OpenGL is very useless. Both from a performance point of view as well as from a learning point of view. The way you would do these things now is just very different.

#5300360 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 05:24 AM

You really need to show more code. You probably also need to scale back. A lot.

I can think of no end of things you are probably doing wrong and strongly suspect your initial code was already badly broken (or leaking memory) only undefined behavior was working in your favour.

We are not going to get anywhere with tiny fragments of code though and definitely not with you trying to summarize what you are doing.

#5300356 Draw a text

Posted by on 12 July 2016 - 05:11 AM

They render (or assist in preparing to render) text into some form of image buffer which you then can upload to a texture and use in a suitable way for your scene. Either by using them to render your objects or in some kind UI overlay.

#5300351 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 04:44 AM

You allocate a new object dynamically, then you add a pointer to it to the vector and then you delete the object. The pointer in the vector then points to something which no longer exists and anything you do with it is undefined behavior.

I have the strong suspicion you are trying far too much with too many holes in your knowledge.

#5300333 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 02:45 AM

A better option would be instead of storing Asset in the vector you store Asset* (or std::shared_ptr<Asset>) and return those.

I'm not happy with that. Unless the sharing of ownership is explicitly desired (and in my experience it usually is not) you should not use shared_ptr. Store unique_ptr in the vector and return the raw pointers. If that is a problem (because Assets might get deleted) then you should fix your messed up ownership semantics first instead of trying to work around it with foolishly shared ownership.

#5300325 Draw a text

Posted by on 12 July 2016 - 02:03 AM

HarfBuzz with cairo is one way to go. HarfBuzz will shape the text with a very high quality, including ligatures. For purely English texts with most fonts it is likely to be completely overkill though. Just the FreeType text rendering functions will probably be good enough. That still leaves significant parts of the layout work in your hands though. I have also heard good things of Pango but never used it myself.

#5300318 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 01:29 AM

This increasingly feels a bit like an XY problem. Maybe it would be a better idea to talk about what you are trying to accomplish instead of trying to ask how to do it with a vector. For example, I'm worried you might not realize how expensive it can be to modify a vector depending on what your usage pattern is and what exactly Asset is.

#5300314 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 01:01 AM

Iterators going out of scope and iterators being invalidated are completely different concepts.

Edit: Iterators become invalid (regardless of whether or not an instance of said iterator currently exists) when a container needs to do modifications which change the layout in memory for some or all elements.

In case of a vector, anything that forces a reallocation of the vector will invalidate all iterators (for example a push_back when the vector has no more capacity remaining). It can also invalidate some iterators, for example an erase will invalidate iterators to the removed element and all behind it, including the end-iterator.

#5300311 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 12:33 AM

Since you are working with a vector the potential issues are not just related to sorting or deleting. Whenever the container invalidates its iterators all pointers you have become invalid as well. See the documentation under "Iterator invalidation".

Additionally, when you swap with another vector your pointers will point to assets in the other vector.

#5300307 Getting address of an item in a std::vector

Posted by on 12 July 2016 - 12:23 AM

Asset* asset_address(int id)
   auto it = std::find_if(vectorAsset.begin(), vectorAsset.end(), [=] (const Asset& asset) { return asset.get_id() == id; });
   if (it != vectorAsset.end())
      return &(*it);
      return nullptr;

#5300140 sort list

Posted by on 11 July 2016 - 06:49 AM

List and vector seem unbelievable stupid to me as they don't even have a usable sort function. I need to have sorted by color and have them displayed on top.
The colored regions seem to come from not shown images by the sort function.

That shows your lack of experience in C++ as well as the principles of object oriented design. std::list and std::vector are about storing a sequence of data using different constraints. Sorting the content is not part of their job description 'container'.

Algorithms operate on containers. They don't care about the exact type of container (although compile time polymorphism allows them to use specific optimizations for specific container types). std::sort can sort an std::vector. It can sort an std::deque. It can also sort my custom container (provided the iterators to my container allow random access) without me doing anything else.

Any problems you still seem to have are solely on your side. From a long experience of reading your threads I know you unfortunately seem to have a habit of posting incomplete code, incomplete descriptions and not really listening to the people trying to help you. std::sort on vectors works. It works fine in my hobby projects, it works fine in my professional code.

#5300017 Calling a function in a derived class from a template

Posted by on 10 July 2016 - 01:03 PM


template <typename T> class Field
	template <typename Functor> void Iterate(Functor f)
		for (unsigned int n=0; n<10; n++)
			f(m_Data[n] /* or whatever seems reasonable */);
	T m_Data[10];
That's a lot more C++ instead of doing some kind of inheritance hierarchy and the compiler has a lot of practice optimizing it. Even better would be something like this:
template <typename T> class Field
	T* begin() { return &m_Data[0]; }
	T* end() { return begin() + 10; }

	T m_Data[10];
Now it works with all those standard library algorithms, including ranged for. You might need a few additional typedefs as well, but the real question is, why don't you use std::array which already does what you try and more.

#5299760 Does Object Pooling with a Vector in C++ have problems with memory?

Posted by on 08 July 2016 - 05:30 AM

bad advise

All in all that is pretty bad advise (especially since this is For Beginners). Using a vector the way you advise removes all advantages of vector while forcing you to work around its shortcomings. Especially if you want to do your own buckets using vector of all things makes absolutely no sense. Besides, std::deque already does all of that for your.

Interweaving the free list within the pool is of course possible but definitely not something you should suggest to a beginner. Unless you know your types are always trivially constructible and destructible you also need to take over lifetime management. If you need to do that, the standard library containers are already out for backing storage.

#5299482 GL Synchronization between process

Posted by on 07 July 2016 - 02:53 AM

Nope. I only mentioned the thread signaling in combination with the glFinish.
You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.
EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.

That is irrelevant though because the OP specified in #3 that they need the information between different processes, not just threads in the same process.

#5299155 class array to list

Posted by on 05 July 2016 - 07:42 AM

Again, your constructor does not do what you think it does. This has nothing to do with classes, this is the basics of value assignment in C++ (or even C).