Activity for Irrlicht Engine
-
Michael Zeilfelder committed [r6740] on Code
Merging r6725 through r6739 from trunk to ogl-es branch
-
Update our libpng copy in vendor to 1.6.54
-
Merging r6702 through r6737 from branch releases/1.8 to trunk
-
Update libpng to 1.6.54 (from 1.6.37)
-
Update outdated vendorlibs.txt info
-
Fix: Unbind textures in OpenGL which get removed
-
Add COpenGLCoreCacheHandler::getDepthFunc and some const fixes
-
Yeah, nodes don't make mesh copies for the animations. You can make copies and pass them to nodes, but meshes are indeed modified while they get animated. The unmodified base mesh is only encoded in the weights (for skinned meshes) - and those don't change.
-
viwrap posted a comment on ticket #329
damn, does that mean animating a mesh involves acutally applying modifications to the underlying mesh resource?
-
The problem is if you have 2 nodes using the same mesh but different animations. Then one node suddenly has the wrong animation now. The only way we could cache would be having a frame cache which keeps copies of animated meshes around. Which might be a good idea, but a bit more work. Well, with current animation system at least. Note that avoiding double animation if you only gota single instance (or all instances on same frame) is already done for skinned meshes in CSkinnedMesh::animateMesh which...
-
i have to stress that this fix is for CAnimatedMeshSceneNode since I seem to have gotten the class name wrong both on the ticket name and patch filename... it's late.
-
i have to stress that this fix is for CAnimatedMeshSceneNode because I seem to have gotten the class name wrong both on the ticket name and patch filename... it's late.
-
CAnimatedMesh getMeshForCurrentFrame cache patch
-
SConstruct various fixes for Win64 MSVC patch
-
Thanks for the patch. Applied in svn r6733
-
SConstruct fixes for Win64 MSVC (Patch #328)
-
SConstruct various fixes for Win64 MSVC patch
-
Add support for loading jpg files with YCCK format
-
Remove declaration for unimplemented function COctreeTriangleSelector::deleteEmptyNodes
-
ComboBox now marks all mouse-wheel events as handled
-
a CGUITable.cpp bug
-
Closed as like mentioned above it's not reproducible and there was no further feedback.
-
-std=gnu++26 CLMOMeshFileLoader::SObjMtl::operator=(const irr::scene::CLMOMeshFileLoader::SObjMtl&)’ is deprecated [-Wdeprecated-copy]
-
Those should have been fixed in svn 1.8 and svn trunk a while ago already. I just checked again and found some other warnings in 1.8 with newer compilers (fixed now), but that one didn't show up even with gnu++26 (and I think it was already there a few versions earlier). Not updating hc1 for now. Maybe taking another look at that one if I'm ever retired.
-
Avoid compiler warnings with newer compilers (backport from trunk)
-
Jon Daniel created ticket #481
-std=gnu++26 CLMOMeshFileLoader::SObjMtl::operator=(const irr::scene::CLMOMeshFileLoader::SObjMtl&)’ is deprecated [-Wdeprecated-copy]
-
Cleanup: Use some double instead of float constants in places where we work with doubles
-
Cleanup: removing some unnecessary destructors for structs
-
Minor internal string type cleanup
-
string::insert now expects template type instead of always char
-
Merging r6700 through r6723 from trunk to ogl-es branch
-
Add function aabbox3d::getPlanes
-
Comment spelling fix
-
Optimize CSceneCollisionManager::getCollisionPoint with better early out
-
Minor optimization in CTriangleSelector::getTriangles
-
Add default cases to avoid warning C26818: Switch statement does not cover all cases.
-
Add default cases to avoid warning C26818: Switch statement does not cover all cases.
-
Reduce the amount of places where const got removed with c casts
-
const IVertexBuffer::operator[] now returns a const S3DVertex reference
-
Reduce the amount of places where const got removed with c casts
-
Add flag irr::gui::EFF_HOVERED_HANDLES_UNFOCUSED_MOUSE_EVENTS to allow disabling this UI behaviour
-
Allow compiling with -Wformat-overflow=2
-
Cleanup: Remove unnecessary semicolons
-
Fix recently broken character input for some extended key characters on Windows
-
IGUIElement::isMyChild can now also check const IGUIElement* parameter
-
Inquiry Regarding Forking the Irrlicht Engine
-
Marvin M. posted a comment on ticket #164
Since this ticket has been answered. It can be closed (can't see a way to do it by myself).
-
Thank you for your kind answer. I definetely will have a look at nabla
-
The engine is (mostly) under the zlib license, so forking is absolutely allowed. Just check the license file, it 's rather short. Actually there are quite a few forks out there already. For example Luanti (formerly Minetest) use their own fork now. Or the Nabla engine once started out as a fork (originally as build-a-world engine) and has similar targets you mention here, so maybe take a look (it's very advanced and under a lot more development currently than Irrlicht, thought maybe a bit harder...
-
Inquiry Regarding Forking the Irrlicht Engine
-
Fix some input key on Windows by breaking Windows 98 compatibility
-
Add AutoRepeat and Extended flags to SKeyInput to pass on that info on Windows
-
Remove unused union in ply loader
-
The loop is: for ( u32 i = 0 ; i < Rows.size() ; ++i ) So the loop itself checks 'i' already. A second check won't change anything as neither 'Rows' nor 'i' change inside the loop. The second check is a bit more interesting as the expectation is that every Row has an "Items" array which has the same size as "Columns". This also seems to be true to me at first view. But there are more places where it could in theory go wrong (but I didn't see anything right now checking this). You could add for testing...
-
The loop is: for ( u32 i = 0 ; i < Rows.size() ; ++i ) So the loop itself checks 'i' already. A second check won't change anything as neither 'Rows' nor 'i' change inside the loop. The second check is a bit more interesting as the expectation is that very Row has an "Items" array which has the same size as "Columns". This also seems to be true to me at first view, but there are more places where it could in theory go wrong (but I didn't see anything right now checking this). You could add for testing...
-
yybbwc posted a comment on ticket #480
也许吧，我有一个功能，本来点击大概十次左右就会崩溃（这个功能会频繁调用clearRows)，加了if (i < Rows.size() && j < Rows[i].Items.size()) // Check array bounds first这段检查后，点击二十次也不会崩溃了 Perhaps. i have a function that would typically crash after being clicked about ten times (this function frequently calls clearRows). After adding the check if (i < Rows.size() && j < Rows[i].Items.size()) // Check array bounds first, it no longer crashes even after twenty clicks.
-
That crash seems to be inside a non-Irrlicht class (irr::core::ustring16). Not native Irrlicht at least, probably from the Irrlicht-spinoff engine you are working with.
-
That crash seems to be inside a non-Irrlicht class (irr::core::ustring16).
-
a CFileSystem bug
-
Thanks for reporting. Code changed in r6706 in svn trunk Wasn't a real problem as the unitialized variable was only used once in constructor where it was ignored (only used as return result) and afteward stuff was initialized. But cleaner to initialize the variable directly (and it won't trigger static code analysis tools that way anymore).
-
Initialize CFileSystem::FileSystemType earlier to avoid triggering code analysis tools
-
a CGUITable.cpp bug
-
a CFileSystem bug
-
Add option to use parent transformation for absolute transformation of nodes
-
I haven't even found time yet to look at this ... (I spend my spare-time yesterday on the other bug you reported, I'm not doing Irrlicht round-the-clock or even every evening). And nothing is ever simple, especially when you have to make things work for all users insteads of just one application. My first thoughts on a very quick view go like this: - It mixes device abstraction code (Irrlicht device) with gui. Maybe can't be avoided (hard to tell without spending a lot more time on it), but it's...
-
I haven't even found time yet to look at this ... (I spend my spare-time yesterday on the other bug you reported, I'm not doing Irrlicht round-the-clock or even every evening). And nothing is ever simple, especially when you have to make things work for all users insteads of just one application. My first thoughts on a very quick view go like this: - It mixes device abstraction code (Irrlicht device) with gui. Maybe can't be avoided (hard to tell without spending a lot more time on it), but it's...
-
@cutealien 不考虑在windows上支持输入法吗？你看，这代码很短，也很简单 Not planning to support input methods on Windows? Look, the code is short and simple.
-
examples/Demo fullscreen switch X Error
-
Closing now due to lack of feedback
-
a small bug
-
OK, I fixed it in svn trunk r6704 by simply getting rid of the 'long' branch. I see no problem with that. If there ever is I guess someone can complain again. Thanks for the report! Also a tiny plea for future bug reports - in your bug report titles please don't always say something like "it's a tiny bug". Write instead what the bug is about, something like "CFileSystem::createFileList() uses wrong type on 64 bit systems". Otherwise browsing bug-reports becomes a bit confusing ;-)
-
CFileSystem::createFileList() now using intptr_t instead of long for _tfindfirst on MinGW as well
-
Yeah, I got the problem. But your solution changes Visual Studio types as well (for 32-bit) and that always used intptr_t as well for 32-bit, so while it would work (long is enough on 32-bit), it's not exactly nice. So I'm currently wondering if that branch is still needed at all. Because all headers I looked at so far use intptr_t - Microsoft headers anyway, but also the original ones from MinGW as well as the clang headers. So only reason I can think of is that there are some old MinGW headers...
-
我之前出错误，是因为进入了long分支（32位），而我用的是64位，32位整数承载不了64位指针，就这么简单。 所以我的修复措施是在64位windows系统上使用intptr_t I made a mistake earlier because I entered the long branch (32-bit), but I was using 64-bit. A 32-bit integer cannot accommodate a 64-bit pointer—it's as simple as that. So my fix is to use intptr_t on 64-bit Windows systems.
-
Yeah, got it updating later on (did indeed not update for a long time and needed the -Syu) and got clang 20. And realized by now we already used intptr_t for this (I had thought earlier you introduced that, but turns out it's the one place Irrlicht uses this). But what I couldn not figure out is why we ever used long. It says it's because of mingw, but all headers I checked there so far also used intptr_t. Mabye this is something really old, I'll have to try if I can get an old 32-bit system booting...
-
是时候支持输入法了，但考虑到难度，还是只支持windows系统上的输入法吧。 It's time to support input methods, but considering the difficulty, let's just focus on supporting input methods on the Windows system for now. irr::gui::IGUIElement* ele = dev->getGUIEnvironment()->getFocus(); if (!ele || (ele->getType() != irr::gui::EGUIET_EDIT_BOX) || !ele->isEnabled()) { HIMC hIMC = ImmGetContext(hWnd); if (hIMC) { ImmNotifyIME(hIMC, NI_COMPOSITIONSTR, CPS_COMPLETE, 0); ImmReleaseContext(hWnd, hIMC); } ImmAssociateContextEx(hWnd, NULL, 0);...
-
这也太老了吧……你可以用 pacman -Syu来更新pacman的索引。https://www.msys2.org这是初始教程。https://packages.msys2.org/packages/?repo=clang64这是包索引。 This is way too outdated... You can use pacman -Syu to update pacman's package index. https://www.msys2.org is the official beginner's tutorial. https://packages.msys2.org/packages/?repo=clang64 is the package repository index
-
#if defined(_WIN64) intptr_t hFile; #else long hFile; // mingw return type declaration #endif This is my current repair measure.
-
In theory simple... but unfortuantely I'm getting download errors. Maybe I have to re-install my msys2 system completely or something like that. Not sure yet. Also the version it tries to download by default seems to be llvm 14 and not 20.
-
很简单的，你可以用msys2安装。 It's very simple, you can install it using MSYS2.
-
Oh, a runtime error, not a compiler error, interesting. Thanks for the info! I'll try to install Clang on Windows (but might take a few days until I get to it).
-
Irrlicht Engine version 1.9.0 Microsoft Windows 8 or later (Build 9200) Irrlicht context Using renderer: OpenGL 4.6.0 Intel(R) HD Graphics 620: Intel OpenGL driver version is 1.2 or better. GLSL version: 4.6 Resizing window (603 372) ================================================================= ==12936==ERROR: AddressSanitizer: access-violation on unknown address 0x000053 84f4c0 (pc 0x7ffdb191faad bp 0x0015d05e7020 sp 0x0015d05e6600 T0) ==12936==The signal is caused by a WRITE memory access....
-
Can you please copy-paste me the exact error you are getting? And if you use any special compile flags for clang then please add those as well. I'd like to avoid adding intptr_t as Irrlicht otherwise still compiles without c++11 enabled.
-
#if defined(__GNUC__) and defined(__MINGW32__) long hFile; // mingw return type declaration #else intptr_t hFile; #endif 这是我现在的修复措施。 This is my current repair measure.
-
Add check in quaternion::normalize() for broken quaternions
-
Add (vertex) color material option to MaterialViewer
-
sorry，我的修复措施不对…… Sorry, my fix was incorrect...
-
a small bug
-
a small bug
-
Thank you for the report. It's fixed now in r6700 in Irrlicht 1.8 branch and in r6701 in svn trunk.
-
Merging r6686 through r6700 from branch releases/1.8 to trunk
-
Fix CGUIPanel (in GuiEditor) so horizontal scrollbar can get focus
-
a small bug
-
Merging r6688 through r6698 from trunk to ogl-es branch
-
Fix bug in CMeshSceneNode::render when it's called without previous OnRegisterSceneNode call
-
Fix 2 more cases of variable shadowing in CB3DMeshWriter
-
Avoid variable shadowing in CB3DMeshWriter::writeMesh
-
CIndexBuffer now uses explicit calls to it's own functions in constructor
-
Fix spelling in comments
-
No problem supporting both. Right now clang is the only compiler which sets utf-8 as default to my knowledge (and it didn't have a problem with those characters...), so independent of the year it's a bit early to assume all people use this.
1 >
