I'm Back... with a Couple of Bug Reports :)

thecaptain

16-12-2007 06:43:14

Hey Guys,

Haven't been around here much recently, but I'll have some more time now, so I'm hoping to get back into the swing of things.

I updated my code to the latest version on SVN earlier today, and I am very impressed! The new rendering system, new widgets, and other changes are great. I also noticed that the whole system is even running much faster than I remember. 8)

But there are a couple immediate bugs that jump out:

1. Mouse Cursor cannot move to the extreme edges of the viewport.
This is probably due to the mouse image being centered now. The mouse active pixel should be the point that is stopped once it reaches the extreme edge of the screen.

2. DirectX Rendering has some issues with the new render system
Take a look at this screenshot:



Notice the mouse cursor, the horizontal trackbar, and the missing text. There seems to be some contamination of images by one an other... I'm not exactly sure what would cause this, but probably some incorrect memory management in DirectX. On OpenGL, it all looks fine.


Otherwise, this progress is great! I'm looking forward to integrating the updated system into our game.

kungfoomasta

18-12-2007 18:07:57

Wow! Sorry thecaptain, I completely missed this thread! :oops:

Issue 1:

I guess we could scan through the image pixel by pixel and find the left-most non transparent pixel, which would be the "active pixel" you speak of.

Issue 2:

Direct X works and looks fine on my system. Is this related to the ATI card issue brought up before? I see the vertical scrollbar is also messed up..

One of the main changes in rendering is that Tuan contributed use of an Index Buffer, in addition to the Vertex Buffer. I wonder if the Index Buffer has some minimum requirements or some sort? You know something is wrong when text appears on some buttons and not on others.. they all use the same code!

thecaptain

18-12-2007 19:11:07

No worries :)

About the mouse, what I mean by active pixel is where the mouse click is actually registered. Typically this is the upper left most pixel in the cursor, but not always. For example, it's in the middle for a text cursor and resizing cursor. You have to already know this for the rest of the code to register mouse clicks, so just use that pixel.

If you move your mouse across the screen in the OS while you're reading this, you'll see that the arrow cursor stops at the top and left edges of the screen, but can go almost off-screen on the right and bottom edges. The reason for this is that the active pixel (where a click would be registered) is the point that has to stay on screen in all cases.

Does this make sense? :wink:

Hmm... that's good to know that DirectX works fine on your system. I'll mess around with a couple of things and see if I can figure some things out for my system as well. I'll also take a look at the index buffers.

kungfoomasta

18-12-2007 19:29:54

Actually I looked into this on winXP Pro, and if you go to control panel and look at the cursor schemes, you will see that the center point of the image is always the active pixel. This is actually really easy to implement, I just expand my bounds by 50% of the cursor texture width. 8)

thecaptain

18-12-2007 21:30:50

Cool!

andy

20-12-2007 11:33:37

I wonder if the directX display issue (which I'm also seeing) is related to the note at the bottom of [b]this[/b] page

Andy

kungfoomasta

20-12-2007 17:27:34

That does seem interesting. However I looked at my vertex declaration, and it seems to follow those rules. :(


void VertexBuffer::_declareVertexStructure()
{
Ogre::VertexDeclaration* vd = mRenderOperation.vertexData->vertexDeclaration;

// Add position - Ogre::Vector3 : 4 bytes per float * 3 floats = 12 bytes

vd->addElement( 0, 0, Ogre::VET_FLOAT3, Ogre::VES_POSITION );

// Add color - Ogre::RGBA : 8 bits per channel (1 byte) * 4 channels = 4 bytes

vd->addElement( 0, Ogre::VertexElement::getTypeSize( Ogre::VET_FLOAT3 ), Ogre::VET_COLOUR, Ogre::VES_DIFFUSE );

// Add texture coordinates - Ogre::Vector2 : 4 bytes per float * 2 floats = 8 bytes

vd->addElement( 0, Ogre::VertexElement::getTypeSize( Ogre::VET_FLOAT3 ) +
Ogre::VertexElement::getTypeSize( Ogre::VET_COLOUR ),
Ogre::VET_FLOAT2, Ogre::VES_TEXTURE_COORDINATES );

/* Our structure representing the Vertices used in the buffer (24 bytes):
struct Vertex
{
Ogre::Vector3 pos;
Ogre::RGBA color;
Ogre::Vector2 uv;
};
*/
}


Vertex:
1. position
5. diffuse color
6. texture coordinates

andy and thecaptain:

What video card are you using?

thecaptain

20-12-2007 20:26:18

I'm using an old Intel integrated graphics Accelerator: Intel(R) 82852/82855 GM/GME Graphics Controller

I've got all the latest drivers and it actually works well with most 3D applications though.

andy

21-12-2007 01:16:45

Mine's an Lenovo/IBM T60 which has as ATI Mobility Radeon X1300

kungfoomasta

23-12-2007 22:33:05

Issue 1 is fixed in SVN.

Issue 2 is much more serious, and I'll have to make a post in the ogre dev forum. No idea what the root cause of this is..

andy

23-12-2007 23:47:31

I think issue #2 might be related to setting the texture between sending quads to the render queue...

I did some testing and reached a point where I have a test program that simply creates 2 images (ie 'mSheet->creatImage..).

If I use the same texture for both images then they display fine. If I use different textures for each image then only the first one displays..

I was going to have a look at how _setTexture works and see if calling that between _render calls made a difference

Cheers
Andy

kungfoomasta

24-12-2007 21:06:21

Interesting. Maybe I'll look at ogre and see how it does its rendering again, I never really figured it out.. :lol:. Maybe there is another way to render objects instead of using the _setTexture and _render methods.