C++Builder with Irrlicht

[SuryIIID]

I think that answer is in zlib.
If all contents in pk3 file is extracted and then chdir("../../xxxx") is used before before getMesh() function all is ok.

Yes, that's what i found today , the bug seems to reside in zlib code.
Moreover it's related to the pk3(zip) file size , if the archive is bigger than
~3 mb(on my computer), the zlib extraction code compiled with BCB doesn't work as expected and GetMesh function fails...
Other than that BCB dll seem to work ok, and it builds the engine with smaller size than the original Irrlicht.dll compiled with VC++ as well as the import library , plus the ability to use a RAD IDE with great database support and literally thousands of open source components to make editors and tools really makes me want to sort all bugs out.

[Guest]

I 've spend whole night to find this tedious problem. This is with char treat related.
If we have some char, there are 0 for end for default. Borland compiler treat this things maybe different.

Well, in File CZipReader.cpp we must add '/0' instead '/'

I'm not sure, whether this will work with another compilers and by this reason use #ifndef

Code: Select all

 #ifndef __BCPLUSPLUS__        //ivo
	while (*p!='/' && p!=entry->zipFileName.c_str())
	{
		--p;
		--lorfn;
	}
 #else
	while (*p!='/0' && p!=entry->zipFileName.c_str())
	{
		--p;
		--lorfn;
	}

 #endif


//in function deletePathFromFilename(core::stringc& filename)
 #ifndef __BCPLUSPLUS__        //ivo
	while (*p!='/' && *p!='\\' && p!=filename.c_str())
		--p;
 #else
	while (*p!='/0' && *p!='\\' && p!=filename.c_str())
		--p;
 #endif

You must recompile Irrlicht.
I use for example some like this:

Code: Select all

device->getFileSystem()->addZipFileArchive("../../media/wq_fort_west.pk3");
scene::IAnimatedMesh* mesh =smgr->getMesh("../../media/wq_fort_west.bsp");
IAnimatedMeshSceneNode * anms = smgr->addAnimatedMeshSceneNode(mesh);

Please keep me informed for another Borland related bugs and issues too

[etcaptor]

Sorry, forgot to login

[etcaptor]

That is not all issue... Still are problems with dir.

[etcaptor]

My results was wrong. Sorry about that.
I made a project to find bug, and found that the reason is related with CZipReader.cpp file.
Function CZipReader::findFile(const c8* simpleFilename) not works for Borland compiler.

If we use

Code: Select all

s32 res = FileList.linear_search(entry)
instead 
s32 res = FileList.binary_search(entry); //test
this function works for BCB.

That is for now. There still are lot of work.
I'll check for comatibility binary_search method and will post final results.

[Ale]

Moreover it's related to the pk3(zip) file size , if the archive is bigger than ~3 mb(on my computer), the zlib extraction code compiled with BCB doesn't work as expected

I am not sure that it is related to the large size of the pk3 file : I made the following simple experiment :
- load with 'addZipFileArchive()' a very small pk3 file, containig ONLY 2 jpg files (grass.jpg + S_S_Barn1_t.jpg)
- load directly with 'smgr->getMesh()' my bsp file (wq_fort_west.bsp)

If i put 'S_S_Barn1_t.jpg' in first position in the pk3 file, both images are rendered
If i put 'grass.jpg' in first position in the pk3 file, only 'grass.jpg' is rendered : All triangles covered with 'S_S_Barn1_t.jpg' are not rendered.

Hope this clue can help to discover where is the problem.
Ale

[etcaptor]

I made many experiments:
1.
-unpack all pk3 contents - missing textures still there
- rename all texturees in small case - somehow resolve problem, when bsp tree is in a root directory instead map

2. At this time I use

s32 res = FileList.linear_search(entry)
instead
s32 res = FileList.binary_search(entry); //test
In Zipreader file /see post above/, compile engine with this change

and move bsp file in root dir of pk3 arhieve.

This trick works for me.

Principally by me problem is involved with use of some operators like << or >>. Borland compiller fills with zero left or right bits, when anoter compillers doing not this. If you examine binary_search function and its calls, maybe will sign, that shift left and shift right operators are used.

[ttom]

//------------------------------------------
2. DirectX linking related:

Microsoft lib file is created as COFF library, whereas Borland linker works with OMF library files, so:

- Use COFF to OMF Converter located on C++Builder/bin directory like:

coff2omf.exe d3dx9.lib d3dx9bor.lib

- Change the name of d3dx9.lib original file and the rename d3dx9bor.lib to d3dx9r.lib

- Use Borland Import lib tool located on C++Builder/bin directory like:

/implib.exe/ implib d3dx9.lib d3dx9d.dll

//-------------------------------------------
sorry i can't do it , anyone can help me or tell me where to find the information
[/quote]

[etcaptor]

You must have DXSDK installed. implib.exe and coff2omf.exe are in your CBuilder/bin directory.
You must switch to Command Prompt to use these tools. If I understand right, you are compiled Irrlicht with BCB5 and have problems only with linking?

[ttom]

[C++ Warning] d3dx9core.h(636): W8010 Continuation character \ found in // comment
[C++ Warning] d3dx9core.h(637): W8010 Continuation character \ found in // comment
[C++ Warning] d3dx9core.h(638): W8010 Continuation character \ found in // comment
[C++ Warning] d3dx9core.h(639): W8010 Continuation character \ found in // comment
[C++ Warning] d3dx9core.h(640): W8010 Continuation character \ found in // comment
[C++ Fatal Error] CD3D9ShaderMaterialRenderer.cpp(216): F1013 Error writing output file
////////--------------------
the error message is above
anyone had suggestion

[etcaptor]

"Error writing output file" commonly can be resolved if avoid using of irrlicht namespaces like "using namespace irr;" in header files.
Instead must be used irr:: , irr::scene::, irr::core, irr::video, irr::gui before any irrlicht defined type. ONLY in header files.

I've tryed Irrlicht v.06 with BCB5, but for v7 I use BCB6 and not tryed BCB5.

Well, this weekend will try to publish BCB5 implementation of Irrlicht.

[etcaptor]

I've just compiled Irrlicht v.08 with C++Builder 6. After some test will upload dll and sources. In some souce files are any additions for BCB compatibility. So, these sources must working also with other compilers.

[etcaptor]

About Ale's problem - missing textures. I have this solution:

in file CZipreader:

in function findFile(const c8* simpleFilename)

use

Code: Select all

   
s32 res = FileList.linear_search(entry);//add by etcaptor for BCB right working
instead   
//	s32 res = FileList.binary_search(entry);
 

in function deletePathFromFilename(core::stringc& filename)

use

Code: Select all

    const char* p = filename.c_str() + filename.size(); //add by etcaptor for BCB right working
instead
    //const c8* p = filename.c_str() + filename.size();
 

I've tested this with many pk3 files and have no problems. Maybe is slowly and second part is strange , but works

[etcaptor]

I made Borland C++Builder 6 port of Irrilicht 08. There a dll files and only modified source files are included in rar file
Irr08BCB6.rar

http://etcaptor.f2g.net/Tutorials/Irrli ... 08BCB6.rar

Don't forget to use this before createDevice function:

Code: Select all

#if defined(__BORLANDC__) || defined(__BCPLUSPLUS__)
  _control87((_control87(0, 0) | ~011), MCW_EM);         //float.h
#endif

I'll post mail to Niko, to improve this port and maybe C++Builder support can be included in official Irrlicht release.
If any interest for BCB 5 port please send me mail.

[Ale]

I've tested this with many pk3 files and have no problems. Maybe is slowly and second part is strange , but works

Hello etcaptor
I saw your post yesterday and i had a quick try with Irrlicht 0.8 and BCB6.

You are right, with your modification, all triangles/textures are loaded.
However, it is not only slow : It is VERY VERY slow.
With the same computer and the same pk3 file (my wq_fort_west = 6 Mo in size) the loading time is :
- 10 secondes with the original source (FileList.binary_search)
- 95 secondes with the modified source (FileList.linear_search)

In other words, for the time being, BCB6 is not really usable with large pk3 files.
Thank you anyway for your good work on this issue.
Ale