The latest SVN bugs thread

[Nadro]

Finally a texture handling in a shader callback is fixed. Both int and float interfaces works properly for this task.

[hybrid]

Ah, nice that this worked as I hoped. Did you try the DX version to see whether the error is reproducibly removed this way? Maybe we should also start to add tests to the regression suite to make sure that all these things won't reappear.

[Nadro]

Yep, I checked DX version too. When variable is a sampler, binding is skipped, so an errors dissapeared when we'll try bind a texture in DX.

I like an idea with test suite it will be very usefull for future changes in an engine, so I agree with You that we should do it.

[hendu]

Wouldn't that last change break int arrays? "uniform int arr[10]"?

Trunk now forces GL_INT to 1, even if a larger count is passed.

[Nadro]

Thanks for a report. Fixed now. I also added an interface for bool variables. Under the hood a bool is like an int for OGL and D3D, but for beginners users a bool interface for bool variables should be more intuitive and thats why I added it.

[CuteAlien]

@greenya: compile warnings fixed in svn trunk r4232 and compile tests added.

[user-r3]

Hm, probably a problem with 64-bit. I think casting to u32 (or int) is wrong there for pointer-arithmetic. Should probably be casted to unsigned long.

I just wanted to test it, but found while doing so another problem - the file-open dialog no longer works (at least on Linux) as it's no longer possible to change the path (and so I couldn't open the dds now quick for a test). Guess I will look on that problem first. But too late today already as I have to work tomorow, so will have to wait until weekend.

I know this post is quite old, but I am wondering whether this is still the case...

After moving my project to my new computer I thought "why not use the latest irrLicht SVN" so I downloaded and compiled it and I got the latest versions of all other libraries I'm using.

One of them is irrBullet. In it's initialization it crashes, so I debugged it and got the following output:

#0 634A05C9 irr::gui::CGUIFileOpenDialog::CGUIFileOpenDialog() ([PATH REMOVED]Irrlicht.dll:??)
#1 63496BE9 irr::gui::CGUIEnvironment::addFileOpenDialog() ([PATH REMOVED]Irrlicht.dll:??)
#2 0043BADB irrBulletWorld::irrBulletWorld(this=0x4f579e8, Device=0x1344de0, useGImpact=true, useDebugDrawer=false) ([PATH REMOVED]vector2d.h:27)
#3 00436585 createIrrBulletWorld(device=0x1344de0, useGImpact=true, useDebugDrawer=false) ([PATH REMOVED]irrbullet.cpp:11)
#4 0040BC59 CGlobal::initGame(this=0x1344660) ([PATH REMOVED].cpp:161)
#5 00435206 main(argc=1, argv=0x13441f8) ([PATH REMOVED]main.cpp:11)

I am especially interested in this part:

#0 634A05C9 irr::gui::CGUIFileOpenDialog::CGUIFileOpenDialog() ([PATH REMOVED]Irrlicht.dll:??)

How can I possibly fix this for me? (I am quite in trouble, because this is important for me to go on programming...)

Thanks anyway!

[CuteAlien]

Problems don't sound related. I'm not on Linux right now, but I think the problem with paths was just something that got fixed again immediately. Don't really know what the problem is - could there be some version mixup? For example if you link to shared libraries then the old lib might still be around. Or maybe your include path still points to old headers.

[user-r3]

Thanks for your answer!

I am not on Linux too, I am on Win7 64bit (didn't know this was Linux related, sorry)

But thanks for pointing out version mixups, I did now recompile irrBullet with irrlicht SVN and even though I'm still getting errors compiling, they are not irrLicht related and so I think you solved my problem

[Randajad]

Bug in latest svn:
IGUIEditBox supports Ctrl+V combination, but not Shift+Insert.

[CuteAlien]

That's neither a bug (simply a feature not implemented, we probably also don't support other CUA stuff) nor is it specific to svn. If I get next time to reworking the edit-box (it has still a lot of other stuff that should be changed) I'll think of it.

[Randajad]

Thanks very much for reply anyway.

[greenya]

Hi.
I have 2 small issues.

#1
------------------------------------------------------------------------------------------------------------

I was looking into video::SExposedVideoData comments (which give documentation after all), it has typos in definition of D3D9 struct:

Code: Select all

            //! Pointer to the IDirect3D9 interface
            IDirect3D9* D3D9;
 
            //! Pointer to the IDirect3D9 interface
            IDirect3DDevice9* D3DDev9;

The second comment should state "IDirect3DDevice9".
Same for D3D8 struct.

#2
-----------------------------------------------------------------------------------------------------------

And the second quick question: is there any ability to get rendering window HWND which was created by Irrlicht internally when we use software renderer? I ask this, because video::SExposedVideoData has union structs for D3D8, D3D9 and OpenGL, each has HWnd -- so for hardware accelerated rendering devices we can get HWND. But for software -- we cant, since the struct video::SExposedVideoData is not valid for them (this is said in documentation to it).

from doc:

Note that this structure does not contain any valid data, if you are using the software or the null device.

P.S.:
i don't know is this a bug (well it cannot be bug, since doc says - so it works as intended, but i believe this small functionality missing).
IrrlichtDevice has some nice methods to work with the window, i suggest to added method void* getWindowId() which should work with any video driver.

[Randajad]

irrTypes.h:115

Code: Select all

#ifdef _IRR_WINDOWS_API_
//! Defines for s{w,n}printf because these methods do not match the ISO C
//! standard on Windows platforms, but it does on all others.
//! These should be int snprintf(char *str, size_t size, const char *format, ...);
//! and int swprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format, ...);
#if defined(_MSC_VER) && _MSC_VER > 1310 && !defined (_WIN32_WCE)
#define swprintf swprintf_s
#define snprintf sprintf_s
#else
#define swprintf _snwprintf
#define snprintf _snprintf
#endif

Please, remove these defines. It's your opinion and do not define it. Make IRR_SNPRINTF or like this. I can't compile my project with boost on windows without undefing it out.

[CuteAlien]

@greenya: #1 fixed now. Don't know anything about #2 right now.

@Randajad: Hm, doing this now will likely break a few user applications as the define has been in there nearly from the start to my knowledge. Not sure why this fails with boost now, but I used boost last 2-3 years ago so probably something was changed in the meantime. And I can't really disagree with you that redefining c-functions in public library headers sounds like a bad idea.

I would be fine with changing it (IRR_SNPRINTF, irr_snprintf or snprintf_irr?), but I hope Hybrid also gives some feedback on this first.