Jump to content


hellhound_01

Member Since 15 Nov 2008
Offline Last Active Jan 02 2013 02:20 PM
-----

Topics I've Started

jsoncpp integration on linux fails

02 January 2013 - 02:25 PM

I'm trying to integrate jsoncpp to my project linux support. My platform is a 32-bit xubuntu with gcc version 4.7.2. I tried to use the debian package, also a build from latest jsoncpp sources, both results in same issue.

I used CMake for my builds. The jsoncpp includes and library are found successfully. But when I add the includes to my CMake includes (The jsoncpp headers are included with cmake command INCLUDE_DIRECTORIES), the build of my empty brConfig class (which has only one #include<string> in line 51) fails with the following error:

[100%] Building CXX object CMakeFiles/brCore.dir/src/brConfig.cpp.o
In file included from /usr/include/c++/4.7/i686-linux-gnu/bits/c++config.h:414:0,
from /usr/include/c++/4.7/string:40, from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/include/brCore/brConfig.h:51,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/src/brConfig.cpp:25:
/usr/include/c++/4.7/i686-linux-gnu/bits/os_defines.h:45:19: Fehler: fehlender binärer Operator vor Token
»(« In file included from /usr/include/c++/4.7/cwchar:46:0, from /usr/include/c++/4.7/bits/postypes.h:42,
from /usr/include/c++/4.7/bits/char_traits.h:42, from /usr/include/c++/4.7/string:42,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/include/brCore/brConfig.h:51,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/src/brConfig.cpp:25: /usr/include/wchar.h:75:43:
Fehler: fehlender binärer Operator vor Token »(« In file included from /usr/include/sched.h:43:0,
from /usr/include/pthread.h:25, from /usr/include/c++/4.7/i686-linux-gnu/bits/gthr-default.h:41,
from /usr/include/c++/4.7/i686-linux-gnu/bits/gthr.h:150, from /usr/include/c++/4.7/ext/atomicity.h:34,
from /usr/include/c++/4.7/bits/basic_string.h:41, from /usr/include/c++/4.7/string:54,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/include/brCore/brConfig.h:51,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/src/brConfig.cpp:25:
/usr/include/i386-linux-gnu/bits/sched.h:133:20: Fehler: fehlender binärer Operator vor Token »(« /usr/include/i386-linux-gnu/bits/sched.h:171:20:
Fehler: fehlender binärer Operator vor Token »(« In file included from /usr/include/c++/4.7/cwchar:46:0,
from /usr/include/c++/4.7/bits/postypes.h:42, from /usr/include/c++/4.7/bits/char_traits.h:42, from /usr/include/c++/4.7/string:42,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/include/brCore/brConfig.h:51,
from /home/hellhound/Repository/binrevengine/modules/brCore/trunk/src/brConfig.cpp:25:
/usr/include/wchar.h:104:1: Fehler: »__BEGIN_NAMESPACE_C99« bezeichnet keinen Typ /usr/include/wchar.h:107:1:
Fehler: »__END_NAMESPACE_C99« bezeichnet keinen Typ /usr/include/wchar.h:135:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:149:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:153:39:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:157:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:161:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:164:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:165:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:194:56:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:195:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:235:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:237:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:254:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:264:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:275:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:281:32:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:284:45:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:285:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:323:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:327:51:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:332:6:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:335:65:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:336:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:354:31:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:358:29:
Fehler: »mbstate_t« bezeichnet keinen Typ /usr/include/wchar.h:358:46:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:364:10:
Fehler: »mbstate_t« wurde nicht deklariert /usr/include/wchar.h:364:26:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:368:10:
Fehler: »mbstate_t« wurde nicht deklariert /usr/include/wchar.h:368:38:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:372:4:
Fehler: »mbstate_t« wurde nicht deklariert /usr/include/wchar.h:372:32:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:374:9:
Fehler: »mbstate_t« wurde nicht deklariert /usr/include/wchar.h:374:37:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:375:1:
Fehler: »__END_NAMESPACE_STD« bezeichnet keinen Typ /usr/include/wchar.h:413:5:
Fehler: »mbstate_t« wurde nicht deklariert /usr/include/wchar.h:413:33:
Fehler: expected initializer before »__THROW« /usr/include/wchar.h:414:1:
Fehler: »__gthrw_pthread_cond_wait« kann nicht als Funktion verwendet werden
/usr/include/c++/4.7/i686-linux-gnu/bits/gthr-default.h:
In Funktion »int __gthread_cond_timedwait(__gthread_cond_t*, __gthread_mutex_t*, const __gthread_time_t*)«:
/usr/include/c++/4.7/i686-linux-gnu/bits/gthr-default.h:886:74: Fehler: »__gthrw_pthread_cond_timedwait«
kann nicht als Funktion verwendet werden /usr/include/c++/4.7/i686-linux-gnu/bits/gthr-default.h:
In Funktion »int __gthread_cond_destroy(__gthread_cond_t*)«: /usr/include/c++/4.7/i686-linux-gnu/bits/gthr-default.h:907:48:
Fehler: »__gthrw_pthread_cond_destroy« kann nicht als Funktion verwendet werden make[2]:
*** [CMakeFiles/brCore.dir/src/brConfig.cpp.o] Fehler 1 make[1]:
*** [CMakeFiles/brCore.dir/all] Fehler 2 make: *** [all] Fehler 2

It seems to me that the issue is invoked by the std::string include.
Here is my simple class:

#ifndef BINREV_CONFIG_H__
#define BINREV_CONFIG_H__

#include <string>	  // compile fails here if I add JSON includes to CMAKE

namespace binrev{
namespace brCore{

class CORE_LIBRARY_API brConfig
{
   public:
	 brConfig();	
	 virtual ~brConfig();

};
}//ns-brCore
}//ns-binrev
#endif //BINREV_CONFIG_H__


I could build and compile my sources successfully on windows platform using MSYS/MinGW with GCC 4.5.0 and
MSVC 2010. Any idea what is going wrong?

Fast DX texture pixel color conversion?

15 November 2012 - 09:07 PM

I've an image loaded in 32 bit rgba format. But DirectX9 requires an argb texture format. What is the best way to convert my image data to this format?

I've tried to use D3DFMT_A8R8G8B8 directly, but in this case my color values are changed and my texture appears blue. If I use D3DFMT_A8B8G8R8 instead,
I get in trouble because the returned surface format is D3DFM_A8R8G8B8 instead of my requested format. So I've to iterate over each pixel and bring it to the
correct pixel format. But this is a huge bottleneck on large images and not usable.

How would you handle this missmatch? Is there a faster way to convert those pixel colors?

Texture artifacts after texture switch.

07 November 2012 - 08:05 AM

I've written a sprite batcher, which uses a VBO to render multiple sprites in multiple batch calls. This batcher is designed to batch different sprites based on differend texture resources. If I add a Sprite with a new texture, different to the actual texture which is related by actually geometry values in VBO, I render the actual VBO with the actual texture. When rendering is complete I remove the old, batched geometry and replace the actual texture with the new one. Until next texture switch or final render call the batching restarts.

This works fine with different sprites if I render only one sprite for each texture. But if I try to render multiple sprites referencing the same texture, any additional batched sprite has texture artifacts. In the alpha area of those sprites content of the other textures is rendered:

http://s7.directuplo...bdmiwxo_jpg.htm

As you can see I render three different sprites (shelf, knight, barrel). Anything is fine. If a add a second barrel sprite, this sprite texture (and also for any additional barrel) has render artifacts. If I add next an additional shelf texture, only this additional shelf sprite shows the render artifacts, the barrels are rendered correctly.

This is strange and I have no idea what could be wrong.

First I thought there could be a problem with the zBuffer. By this reason I've set glDepthMask to false and also set glDisable(GL_DEPTH_TEST) before rendering those sprites. But this takes no effekt.

Any idea what could be wrong?

Best way for perfect pixel collision detection?

31 October 2012 - 11:00 AM

Actually I try to implement a pixel perfect collision (PPC) detection for 2D sprites. For "normal" sprites anything is working perfectly. But how should I handle scaled and rotated sprites?

PPC is expensive, so I try to find an optimized solution to perform PPC. What is the best way I should go? Should I read the actual pixel data from pixel buffer and compare those or should I approximate the scaled values against the origin image data?

Actually I use this approximation attempt to check point based collisions,
but this works not realy good with scaled sprites:

bool brSprite::intersect(float x, float y)
{
	// first check if bounding rect collides with point positions
	bool collision = this->contains(x, y);
  
	// perform pixel perfect collision if required
	if(collision && m_usePPC)
	{
      /* Substract actual rectangle position from point position value to
	   reduce intersection point to image dimensions in range: [0,width]
	   and [0,height].
	  
	   Please take note that we also have to regard the region x,y
	   position values to determine correct image position in atlas
	   textures and a scaling of the sprite.
		*/
		int pos_x = (int)((x - m_x)+m_region.getX()/m_scale.m_fX);
		int pos_y = (int)((y - m_y)+m_region.getY()/m_scale.m_fY);
	
		if(pos_x<m_width && pos_y<m_height){

			// define alpha compareable
			int alpha = 0;
			if(m_ppcTolerance>0){
				alpha = (255 * m_ppcTolerance)/100;
			}

			// perform pixel perfect collision check
			brColor color = m_region.getImage()->getPixelColor(pos_x,pos_y);
			if(color.getAlpha()>alpha){
				collision = true;
			}
	  else{
		collision = false;
	  }
		}	
	}  
	return collision;
}

Any Ideas?

Issues using comparator on std::map

26 August 2012 - 12:58 PM

I try to implement my own comparator for a std::map to use a complex object as key value. I kow i could overwrite the less operator in my complex object, but I've decided to be more flexible, to use a comparator struct object instead. So I could perform different comparsions if required. I followed the instructions at this link: http://stackoverflow...map-with-struct

Here is my comparator, which is a protected member of my class, which holds the map:

struct Comparator : public std::binary_function<brCore::brConfigSet, brCore::brConfigSet, bool>
	{
		bool operator()(brCore::brConfigSet const & left, brCore::brConfigSet const& right) const
		{
			// comparison logic goes here
			return true;
		}
	 };

And here is my map declaration:

 typedef std::map<brCore::brConfigSet, boost::shared_ptr<brFont>, Comparator> Fonts_t;

The code compiles, but when I perform a find operation after I've added the first element to map, the find execution crashes with the hint that the less operator is missed.
But why? If I understand this article correctly the less operator isn't required to be more flexible ... Thanks for any help.