Activity for Irrlicht Engine
-
Michael Zeilfelder committed [r6799] on Code
Fix loading JCS_CMYK/JCS_YCCK jpg's switching red/blue
-
Improve image overflow checks a bit (especially for 32-bit systems)
-
Merging r6795 through r6796 from branch releases/1.8 to trunk
-
Backport [r5827]: IrrlichtDevice::isWindowMinimized no longer returns true when it's maximized on Windows
-
Fix CGUIButton showing wrong pressed image when setImage was called twice with different textures.
-
Merging r6785 through r6793 from branch releases/1.8 to trunk
-
Fix zlib decompression calling inflateEnd twice and returning OK when it failed
-
Add EMIE_LMOUSE_DOUBLE_CLICK and EMIE_LMOUSE_TRIPLE_CLICK support on macOS
-
Update comments about deprecated IImage::lock/unlock
-
Thx, fixed mis-spelling :) And yeah, seems loaders are not consistent. I'm just going to ignore this anyway.
-
Fix spelling in log message
-
Mercury233 posted a comment on ticket #331
I also think that, when retrieving clipboard content, it would be appropriate to introduce a new API or an overload that accepts a caller-provided pointer to a char[] buffer for output, instead of returning the output. BTW, the comments for IImage::lock() and IImage::unlock() should be updated to remove the “Be sure to call unlock()” note, as it has already been clarified in [r5168] that calling unlock() do nothing.
-
Regarding seek(0), this is how it is written in CImageLoaderJPG::isALoadableFileFormat, but I think this usually won’t be an issue in most cases. By the way, in the warning for CIrrDeviceWin32::getGammaRamp, it is written as “setGammaRamp.”
-
Oh I forgot this, it should apply to trunk as well. fix CGUITabControl scroll buttons persist after resize The scroll control buttons remained visible after resizing the tab control larger and fit in viewport. CurrentScrollTabIndex was not reset when needScrollControl() returned false, causing the OR condition to remain true if user had scrolled previously.
-
More patches from my fork
-
I was wrong about using IRRLICHT_API . This would make likely cause memory allocation to cross dll borders. Actually risky functions - this would be the first functions in Irrlicht to return something not reference counted which is allocated with new.
-
Hm, I see now - you got influenced by the other multibyte functions at the end of the string header (I didn't remember those...). Thought those are really multibyte (as in - the format is not specified any futher unlike in this case).
-
About string conversion wrappers in 13: Was there some reason why you create a string for a null pointer instead of just return a null pointer again? I'm considering that one as I'm also using similar wrappers in my projects. Thought I'm going to change it a bit. It should probably be IRRLICHT_API instead of static and implementation beside the other conversion functions. Better to pass the strlen as a second parameter (that way you can pass for example std::wstring or core::stringw which both already...
-
Thank you for merging my patch! Although I am already preparing to migrate to version 1.9, I have found some more issues in version 1.8 that are worth fixing. I will send patches later.
-
Fix compiling on devc++ 4.9.9.2.
-
Fix macOS special keys and Command shortcuts handling.
-
Improve type-cast in PHYSFS_utf8FromUcs2
-
Fix utf-8 parsing.
-
Merging r6773 through r6784 from trunk to ogl-es branch
-
Merging r6768 through r6783 from branch releases/1.8 to trunk
-
OK, no idea what did go wrong. The first missing file suddenly showed up later on server activity log and my second commit had then reversed it. Now reversing again and it should be fine sigh - that was strange.
-
Undo last commit
-
Note: If you update and the last patch is not there... I'm still trying to figure out what's going wrong. I send the patch to sourceforge and at first the change file didn't show up. So I though I forgot it and send again. But now it shows up in old log and in new one - but change still isn't on the server when I download svn (even though I get those versions...). If I look at changes it shows 2 times same change ugh. Never had this, so currently contacting their support and hope they can help.
-
Fix event order when selecting items in a ListBox via keyboard (real patch this time)
-
Patches from my 1.8.5-based fork for upstream contribution
-
I have applied: 1 snprintf and swprintf 2 MY_MAPVK_VSC_TO_VK_EX 4 forced chdir CIrrDeviceMacOSX 5 Xcode project configuration 6 OSX compiling 7 MingGW compiling 8 r5676 backport 9 r6132 backport 10 r6691 backpor 11 CGuiEditbox avoid non-changing keys 12 CGuiEditbox send less EGET_EDITBOX_CHANGED 15 OS X policy 16 bugfix listbox selection update 17 gamma functions 18 CZipReader logging I won't apply: 3 seek(0) because I'm not persuaded so far that this is actually an improvement and suspect it might...
-
Fix event order when selecting items in a ListBox via keyboard
-
Do not send EGET_EDITBOX_CHANGED in CGUIEditbox when no actual character is input
-
Ignore more keys in edit-box that should not trigger character input events
-
burningreggae committed [r6778] on Code
test media
-
29.03.2026 WIP missing -> minor
-
29.03.2026 WIP missing
-
29.03.2026 WIP
-
Fix mismatched GetDC/ReleaseDC usage in CIrrDeviceWin32 gamma ramp functions
-
Add ITexture::SExposedTextureData to allow accessing driver specific texture handles
-
Merging r6741 through r6771 from trunk to ogl-es branch
-
Replace direct includes of gl.h by using COpenGLCommon.h
-
Second try: Fix creating NSMenu with a null bundle name (macOS)
-
Add more colors to the color background in CubeMapping example
-
Updating OpenGL headers
-
Oh strange, thanks for checking! I'll fix it again in the evening.
-
it seems that [r6765] didn't change the code, just changed the changelog.
-
Merging r6766 from branch releases/1.8 to trunk
-
Fix forced chdir behavior in CIrrDeviceMacOSX
-
Fix creating NSMenu with a null bundle name (macOS)
-
Use snprintf_irr instead of sprintf
-
Merging r6762 from branch releases/1.8 to trunk
-
Avoid potential troubles with _IRR_WCHAR_FILESYSTEM in CZipReader error logging
-
Set Activation Policy to Regular on macOS to ensure the application appears in the Dock and has a menu bar
-
Set Activation Policy to Regular on macOS to ensure the application appears in the Dock and has a menu bar
-
CAnimatedMesh getMeshForCurrentFrame cache patch
-
Hm, so trunk passes U__STRICT_ANSI__ in OTHER_CPLUSPLUSFLAGS.
-
https://github.com/mercury233/irrlicht-svn/tree/mercury I manage to build it on GitHub Actions, with some modifications
-
Thanks for testing my changes. I gave it another shot with -U__STRICT_ANSI__ and target 10.13. I wonder if trunk compiles then on your system (I used 10.7 because it's used there)
-
Next try fixing compiling on OSX
-
I forgot to mention that using gnu++11, or adding -U__STRICT_ANSI__ to OTHER_CFLAGS, does allow it to compile successfully. The gnu++14 in my patch is unnecessary.
-
In [r6756], 10.7 won't build: irrlicht-code-r6758-branches-releases-1.8/source/Irrlicht/MacOSX/MacOSX.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.7, but the range of supported deployment target versions is 10.13 to 15.4.99. (in target 'libIrrlicht.a' from project 'MacOSX') And c++11 won't build: irrlicht-code-r6758-branches-releases-1.8/source/Irrlicht/CFileSystem.cpp:27:6: error: Compiling with__STRICT_ANSI__ not supported. g++ does set this when compiling...
-
Fix compiling on MinGW
-
Fix compiling in OSX
-
Try to fix build for MacOSX
-
Fix recent backport of r6691
-
work on warning level
-
Thanks. I've not given up on your original 1.8 patches yet, probably will apply some more there, just got ill last days.
-
Patch series for 1.9
-
- BurningVideo: 0.55
-
- BurningVideo: 0.55
-
Document path functions in coreutil.h a bit more
-
Update documentation for makeColorKeyTexture
-
Merging r6747 through r6748 from branch releases/1.8 to trunk + fix in sXprintf_irr functions
-
Don't redefine snprintf and swprintf from VS2015 on
-
Use MAPVK_VSC_TO_VK_EX when it exists
-
Huh, good argument, didn't even realize that when I wrote that code (was only about speed). But you are right this should be undefined behaviour :-) And yeah, 1.9 not officially released. But likely way more stable than 1.8 as I work with it daily in my job (while I haven't touched 1.8 in a decade except when other people make requests or bugreports).
-
I completely understand that maintaining two branches is overwhelming and that backporting causes merge conflicts. I appreciate the work you've put into this. The main reason I haven't been using 1.9 is that it hasn't been officially released yet. From my point of view, an unreleased version means that there could still be breaking changes, either ones that are already planned or potentially new ones at any time. It may also still contain known issues. If you would prefer, I'm happy to rebase those...
-
Shouldn't have applied the backport patch so fast I guess (did that last night) ;-) I'll update it again. The problem with anything larger is mostly that I don't really want to work on 1.8 anymore. It's done and released. Aside from minor fixed I don't want to touch that branch anymore as there's always the risk of breaking something. And things like backporting are also causing extra work (causing merge conflicts and stuff like that - I spend quite some time on just the 3 patches I did yesterday)....
-
In addition, I have the following patches: 15 Set Activation Policy to Regular on macOS This ensures that the application appears in the Dock and has a menu bar. This used to be the default behavior, but recent versions of Xcode appear to have changed it. 16 Fix event order when selecting items in a ListBox via keyboard Currently, when selecting items using the keyboard, the behavior is inconsistent: if the newly selected item is located below the current item, the EGET_LISTBOX_CHANGED event is triggered...
-
Regarding items 4 and 5, unfortunately I do not use macOS on a daily basis, so I was only able to perform limited testing (I do not even have a machine properly signed in with an Apple account to download Xcode). As for item 14, I would at least recommend applying a basic fix to avoid returning dangling pointers, similar to what has already been done on Linux.
-
Merging r6743 through r6745 from branch releases/1.8 to trunk
-
Backport r6691 from trunk (fix compiling with Unicode/without _IRR_WCHAR_FILESYSTEM)
-
Backport r6132 from trunk (fix MacOS 10.15 only rendering to quarter of window)
-
Backport r5676 from trunk (minor optimization)
-
I hope I'll manage to apply those soon. But will take a while (too many todo's and currently no time). On a quick lunch pause view : 1 make sense. Completely getting rid of it not possible as Irrlicht still needs to run on older compilers (due to it's age Irrlicht is an engine people tend to chose when working on some old system...). 2 also sounds good 3 I kinda get, but not 100% sure yet if a good idea (if people don't pass a file at pos 0 in there it sounds deliberate - like having several images...
-
Sorry, it seems there was a formatting mistake. All items after 14 should actually be part of item 14. Additionally, about the IME support, I plan to submit a separate patch after completing Linux support and conducting sufficient testing.
-
Patches from my 1.8.5-based fork for upstream contribution
-
irr::core::rect::isPointInside no longer considers right-bottom point as inside
-
Minor optimization, don't regenerate mips for cube-map 6 times in example, once does it
-
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...
1 >
