Irrlicht 1.5.1 released
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Irrlicht 1.5.1 released
Edit: As Niko already blogged, the 1.5.1 release is out now. It's a bugfix release which has only a few things updated. All applications should be able to compile against this new release without modifications. Just make sure that you *do* recompile.
Ok, starting with revision 1815 we have a new SVN branch. The new branch at https://irrlicht.svn.sourceforge.net/sv ... leases/1.5 contains a copy from SVN/trunk and will eventually become the official 1.5 SDK release.
As with the previous releases we want to give you the chance to do some last minute tests and provide some feedback in order to stabilize this release. So please check all your projects with the new engine and post your results (positive as well as negative ones, also benchmarks) in this thread. Please avoid mentioning already known bugs, because we couldn't fix all things in this release (in case you still think it's worth mentioning the bug just post a bug ticket at https://sourceforge.net/tracker2/?atid= ... unc=browse )
The beta test will last for approx. 2-3 weeks, depending on the number of bugs, feedback, and our free time to fix the code. So don't wait too long with your responses We'll provide a binary release of the 1.5 beta in the next days. Until then compile the engine on your own or use the nightly builds (of SVN/trunk, won't be too different for the next time...)
BTW: The SVN branch merging will be changed to 1.4->1.5->trunk, which means that fixes of the 1.4 branch will also go into 1.5 and trunk (after some days at least), while fixes in 1.5 will only go into trunk, but not into the 1.4 branch. trunk will be handled as before!
Ok, starting with revision 1815 we have a new SVN branch. The new branch at https://irrlicht.svn.sourceforge.net/sv ... leases/1.5 contains a copy from SVN/trunk and will eventually become the official 1.5 SDK release.
As with the previous releases we want to give you the chance to do some last minute tests and provide some feedback in order to stabilize this release. So please check all your projects with the new engine and post your results (positive as well as negative ones, also benchmarks) in this thread. Please avoid mentioning already known bugs, because we couldn't fix all things in this release (in case you still think it's worth mentioning the bug just post a bug ticket at https://sourceforge.net/tracker2/?atid= ... unc=browse )
The beta test will last for approx. 2-3 weeks, depending on the number of bugs, feedback, and our free time to fix the code. So don't wait too long with your responses We'll provide a binary release of the 1.5 beta in the next days. Until then compile the engine on your own or use the nightly builds (of SVN/trunk, won't be too different for the next time...)
BTW: The SVN branch merging will be changed to 1.4->1.5->trunk, which means that fixes of the 1.4 branch will also go into 1.5 and trunk (after some days at least), while fixes in 1.5 will only go into trunk, but not into the 1.4 branch. trunk will be handled as before!
Last edited by hybrid on Wed Aug 05, 2009 10:56 am, edited 1 time in total.
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
Excelsior!
Heck, while you're raising bugs, feel free to investigate and upload patches for the existing ones! We're all in this together, like a family, but without the drunken fistfights and barely-legal gropings at weddings.
Speaking for myself, I don't intend to start committing the back catalogue of feature patches to the trunk until 1.5 proper is actually released, so the sooner we flush out the bugs, the sooner we get new features on the trunk.
Heck, while you're raising bugs, feel free to investigate and upload patches for the existing ones! We're all in this together, like a family, but without the drunken fistfights and barely-legal gropings at weddings.
Speaking for myself, I don't intend to start committing the back catalogue of feature patches to the trunk until 1.5 proper is actually released, so the sooner we flush out the bugs, the sooner we get new features on the trunk.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
Jump "BUMP"ing this to mention that as we're focussing on getting bug fixes into 1.5 (and 1.4.3) that the SVN trunk is liable to lag behind a bit. For the moment, it would be great if you could assume that the 1.5 branch is the "trunk", and build and test against that until it's properly cut and released.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Maybe now it would be a good time to check out an old bugfix of mine?
There's a bug when choosing to open an archive which is a folder (CFileSystem::addFolderFileArchive()) because the method that suppose to do it is empty.
I coded that method following the rule of "if ignore case is true just make lower" that other parts of the file system used so the bug the happens in linux is present here too. Except that it works just fine.
Hybrid said back then (when I posted the fix) that he isn't gonna use it because the file system should be recoded/redesigned anyways but it seems nothing had happened since and I guess it would be wise to use this fix until a proper redesign would be.
CFileSystem::addFolderFileArchive() bug fix thread.
P.S
There are a few versions of the patch in this thread, these are bug fixed patches while the last post and the first edited post has the latest version.
There's a bug when choosing to open an archive which is a folder (CFileSystem::addFolderFileArchive()) because the method that suppose to do it is empty.
I coded that method following the rule of "if ignore case is true just make lower" that other parts of the file system used so the bug the happens in linux is present here too. Except that it works just fine.
Hybrid said back then (when I posted the fix) that he isn't gonna use it because the file system should be recoded/redesigned anyways but it seems nothing had happened since and I guess it would be wise to use this fix until a proper redesign would be.
CFileSystem::addFolderFileArchive() bug fix thread.
P.S
There are a few versions of the patch in this thread, these are bug fixed patches while the last post and the first edited post has the latest version.
Switched to the 1.5 release branch (rev 1876) and I'm getting this compiler error for both the Linux debug and release builds:
Using an explicit cast appears to fix it:
Code: Select all
:~/gdev/itubras/deps/irrlicht/source/Irrlicht$ make
g++ -Wall -pipe -g -D_DEBUG -I../../include -Izlib -Ijpeglib -Ilibpng -I/usr/X11R6/include -DIRRLICHT_EXPORTS=1 -c -o CCameraSceneNode.o CCameraSceneNode.cpp
CCameraSceneNode.cpp: In member function ‘virtual void irr::scene::CCameraSceneNode::OnRegisterSceneNode()’:
CCameraSceneNode.cpp:233: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
../../include/irrMath.h:162: note: candidate 1: bool irr::core::equals(irr::f64, irr::f64, irr::f64)
../../include/irrMath.h:168: note: candidate 2: bool irr::core::equals(irr::f32, irr::f32, irr::f32)
make: *** [CCameraSceneNode.o] Error 1
:~/gdev/itubras/deps/irrlicht/source/Irrlicht$ g++ --version
g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Code: Select all
--- CCameraSceneNode.cpp (revision 1876)
+++ CCameraSceneNode.cpp (working copy)
@@ -230,7 +230,7 @@
f32 dp = tgtv.dotProduct(up);
- if ( core::equals ( fabs ( dp ), 1.f ) )
+ if ( core::equals ( (f32) fabs ( dp ), (f32) 1.f ) )
{
up.X += 0.5f;
}
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
Heh, thanks, I've already found that one. It'll be committed soon.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
hi,
I'm trying to compile the dll with mingw/gcc (C::B)...
when I use debug mode with no DX support an include is missing:
Irrlicht.cpp (line 12):it seems this file is part of the dx sdk, so if you don't have the dx sdk installed the file is missed !!!
and I also get the cimpile error from this thread !!!
I'm trying to compile the dll with mingw/gcc (C::B)...
when I use debug mode with no DX support an include is missing:
Irrlicht.cpp (line 12):
Code: Select all
#include <crtdbg.h>
and I also get the cimpile error from this thread !!!
Irrlicht.cpp (line 44):Irrlicht.cpp:44: error: external linkage required for symbol 'irr::core::IdentityMatrix' because of 'dllexport' attribute.
Code: Select all
IRRLICHT_API const matrix4 IdentityMatrix(matrix4::EM4CONST_IDENTITY);
while(!asleep) sheep++;
IrrExtensions:
http://abusoft.g0dsoft.com
try Stendhal a MORPG written in Java
IrrExtensions:
http://abusoft.g0dsoft.com
try Stendhal a MORPG written in Java
Against rev 1921 I have tested all of my apps on win32/Linux in both release and debug modes and they all appear to be working as expected.
I ran into a couple of minor issues with the examples and new regression tests.
Linux
All of the examples build and appear to run fine in "release" mode.
1 - Examples. I'm not sure why, but it looks like the default build for the examples is for "release" mode when the library itself defaults to "debug". Also, in order to build the debug versions of the examples, the make files need to be manually edited vs. controlling the build with NDEBUG like the library uses.
2 - Tests. Patch I'm using to control debug/release build via make:
In release mode I'm seeing this error (happens with/without "-fexpensive-optimizations"):
In debug mode I see this error:
It appears that result images were once being written to "results/" but that is no longer happening.
Switching back and forth between release/debug builds makes me want to submit a 1.6 patch for: irrlicht.lib, irrlicht_d.lib, irrlicht_static.lib, irrlicht_static_d.lib, ...
win32
Test combos: vc8/vc9 projects, debug/release modes, d3d9 & opengl drivers.
1 - Examples.
SplitScreen_vc8.vcproj is missing in BuildAllExamples_v8.sln.
No problems building and all ran fine with the exception of "10.Shaders" using the d3d9 driver and "high level shaders".
2 - Tests. All tests passed, but for vc8 I needed to update the solution "dependencies" and add "..\lib\Win32-VisualStudio" to the project "Additional Library Directories" in order to build.
That's it for now - I don't have any solid benchmarks, other than it "feels" just as good as they day we met... (maybe benchmark info could eventually make its way into the tests). Well done!
I ran into a couple of minor issues with the examples and new regression tests.
Linux
All of the examples build and appear to run fine in "release" mode.
1 - Examples. I'm not sure why, but it looks like the default build for the examples is for "release" mode when the library itself defaults to "debug". Also, in order to build the debug versions of the examples, the make files need to be manually edited vs. controlling the build with NDEBUG like the library uses.
2 - Tests. Patch I'm using to control debug/release build via make:
Code: Select all
Index: tests/Makefile
===================================================================
--- tests/Makefile (revision 1921)
+++ tests/Makefile (working copy)
@@ -4,7 +4,12 @@
CPPFLAGS = -I../include -I/usr/X11R6/include -pipe
# CXXFLAGS += -Wall -O3
+CXXFLAGS = -Wall -pipe
+ifndef NDEBUG
CXXFLAGS += -g -D_DEBUG
+else
+CXXFLAGS += -fexpensive-optimizations -O3
+endif
ifeq ($(HOSTTYPE), x86_64)
LIBSELECT=64
Code: Select all
ERROR: vector2d 0.7071067811865476, 0.7071067811865476 != vector2d 0.7071068137884140, 0.7071068137884140
tests: testVector2d.cpp:19: bool compareVectors(const irr::core::vector2d<T>&, const irr::core::vector2d<T>&) [with T = double]: Assertion `compare == with' failed.
Aborted
Code: Select all
Starting test 'guiDisabledMenu'
Irrlicht Engine version 1.5.beta
Linux 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686
Creating X window...
Visual chosen: : 39
Using renderer: OpenGL 2.1.2
GeForce 6800 GT/PCI/SSE2/3DNOW!: NVIDIA Corporation
OpenGL driver version is 1.2 or better.
GLSL version: 1.3
Image match: 0.000000%
******** Test failure ********
Test 'guiDisabledMenu' failed
******** Test failure ********
Switching back and forth between release/debug builds makes me want to submit a 1.6 patch for: irrlicht.lib, irrlicht_d.lib, irrlicht_static.lib, irrlicht_static_d.lib, ...
win32
Test combos: vc8/vc9 projects, debug/release modes, d3d9 & opengl drivers.
1 - Examples.
SplitScreen_vc8.vcproj is missing in BuildAllExamples_v8.sln.
No problems building and all ran fine with the exception of "10.Shaders" using the d3d9 driver and "high level shaders".
Code: Select all
Please select the driver you want for this example:
(a) Direct3D 9.0c
(b) Direct3D 8.1
(c) OpenGL 1.5
(d) Software Renderer
(e) Burning's Software Renderer
(f) NullDevice
(otherKey) exit
a
Please press 'y' if you want to use high level shaders.
y
Irrlicht Engine version 1.5.beta
Microsoft Windows XP Professional Service Pack 3 (Build 2600)
Using renderer: Direct3D 9.0
NVIDIA GeForce 6800 Series GPU nv4_disp.dll 6.14.11.7519
HLSL pixel shader compilation failed:
error X3539: ps_1_x is no longer supported; use /Gec in fxc to automatically upg
rade to ps_2_0
error X3539: Alternately, fxc's /LD option allows use of the old compiler DLL
HLSL pixel shader compilation failed:
error X3539: ps_1_x is no longer supported; use /Gec in fxc to automatically upg
rade to ps_2_0
error X3539: Alternately, fxc's /LD option allows use of the old compiler DLL
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\wall.bmp
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_bk.jpg
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_ft.jpg
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_rt.jpg
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_lf.jpg
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_dn.jpg
Loaded texture: c:\gdev\iTubras\deps\irrlicht\media\irrlicht2_up.jpg
That's it for now - I don't have any solid benchmarks, other than it "feels" just as good as they day we met... (maybe benchmark info could eventually make its way into the tests). Well done!