Activity for Zenju
-
Zenju posted a comment on ticket #606
following issue might be related: actual: if (std::count(pkStream.begin(), pkStream.end(), ' ') == 2 && std::all_of(pkStream.begin(), pkStream.end(), [](const char c) { return isDigit(c) || c == ' '; })) return L"SSH-1 public key"; expected: if (std::count(pkStream.begin(), pkStream.end(), ' ') == 2 && std::all_of(pkStream.begin(), pkStream.end(), [](const char c) { return isDigit(c) || c == ' '; })) return L"SSH-1 public key";
-
Curly braces prevent indentation (in lambda)
-
Issue is fixed in the latest version from 2026-02-13! Ticket can be closed.
-
It works! :) the raw string literals are preserved, and no regressions when applying Astyle to my whole codebase. I'll be using this version onwards. Thank you! PS: The VS 2022 x64/Static configuration fails to build. IMHO it could be removed entirely if unmaintained, since the effect is apparently like "Release" but with "Multi-threaded (/MT)"
-
The two examples above are "complete" meaning, pasting each of them into a new cpp file and formatting keeps them unchanged (with the Astyle config from above), rather than fixing the broken switch and lambda layouts. This was tested with your latest version from Jan 30th, freshly compiled from gitlab. For some reason the presence of the raw string literals is responsible for the layout corruption. When deleting them, both the lambda and switch lay out correctly.
-
The two examples above are "complete" meaning, pasting each of them into a new cpp file and formatting keeps them unchanged (with the Astyle config from above), rather than fixing the broken switch and lambda layouts. This was tested with your latests version from Jan 30th, freshly compiled from gitlab. For some reason the presence of the raw string literals is responsible for the layout corruption. When deleting them, both the lambda and switch lay out correctly.
-
The raw string literals seem to be preserved now, unfortunately there are regressions: For example the layout of the switch statement in the following test sample is broken (using same astyle config as above): std::string test() { return std::string(R"( <tr> <td>)") + R"(</td> <td><span style="font-weight: 600;">)" + R"(</span></td> )"; } void generateLogFileName(const ProcessSummary& summary) { const std::wstring failStatus = [&] { switch (summary.result) { case TaskResult::success: break; case...
-
I've released ScalerTest version 1.2 which uses the config from the last GUI session for the command line mode.
-
I have pushed a fix for the first problem (pointer reference). It works correctly now, thanks! The second you can inmprove with --squeeze-ws. But only int will be recognized as a type, this is a limitation of the current parser. Hopfully this function can be restored again at some time. I've been relying on it a lot in Astyle 3.1 to normalize third-party codebases, especially all the function signatures.
-
There seems to be a more general issue: Astyle keeps the following code unchanged: void test(int* test) { wxWindow * const win = nullptr; int* const win = nullptr; std::vector<std::pair<int, int>> * const win = nullptr; } expected: void test(int* test) { wxWindow* const win = nullptr; int* const win = nullptr; std::vector<std::pair<int, int>>* const win = nullptr; }
-
Perfect, the issue has been fixed!
-
I just realized there is "--keep-one-line-statements", and it works for switches, too!! Ticket can be closed! :)
-
Sorry, this should have been filed under "Feature Requests", not "Bugs".
-
My Astyle config used: --style=allman --suffix=none --keep-one-line-blocks --align-pointer=type --min-conditional-indent=0 --max-continuation-indent=80 --indent-switches --indent-col1-comments --indent-preproc-block --indent-preproc-define --pad-header --pad-comma --formatted --lineend=linux --indent-preproc-block --convert-tabs --preserve-ws
-
Preserve one-liners in switch
-
Unexpected change of raw string literal
-
There is also the opposite case: AStyle produces: auto test() { return { .ai_flags = AI_ADDRCONFIG | AI_PASSIVE }; } while the expected result is: auto test() { return { .ai_flags = AI_ADDRCONFIG | AI_PASSIVE }; }
-
Unwanted indentation after >>>
-
Unwanted space between *&
-
Wrong indendation when returning struct
-
The ticked can be closed! Apparently the latest changes to https://sourceforge.net/p/astyle/bugs/585/ fixed this one as well! Thanks!
-
Thank you! :) Ticket can be closed.
-
Thinking about it, the expected result is probably better this one: template <typename... Ts> struct is_proxy_type_list<ProxyTypeList<Ts...>> : std::true_type {}; template <typename T> struct GenerateTypeList { private: using proxy = typename std::conditional<is_proxy_type_list<T>::value, T, ProxyTypeList<T>>::type; }; But with your latest changes, the current code produces: template <typename T> struct GenerateTypeList { private: using proxy = typename std::conditional<is_proxy_type_list<T>::value,...
-
The ticked can be closed! Apparently the latest changes to https://sourceforge.net/p/astyle/bugs/585/ fixed this one as well! Thanks!
-
Awesome! I seem to have run out of any more of these issues :D The ticket can probably be closed.
-
-
This issue should be fixed! See https://sourceforge.net/p/astyle/bugs/585/
-
astyle 3.6.8 (git 2025-03-17): unexpected linebreak for inherited class
-
Alas, one problematic "switch" remains: struct TreeView { bool operator()(const TreeLine& lhs, const TreeLine& rhs) { switch (lhs.type) { case NodeType::root: return true; case NodeType::folder: { const auto* folderL = nullptr; if (!folderL) return false; return true; } case NodeType::files: break; } assert(false); return false; } };
-
The issue seems to be fixed!
-
Here's a probably related issue with function "missingIndent()": void test(const std::vector<std::pair<int, int>>& workload) { } class NativeFileSystem { public: Zstring missingIndent() const { return isNullFileSystem() ? Zstring{} : rootPath_; } };
-
This is a major improvement! Most issues are gone, but not the following: class GdriveFileState { public: std::optional<std::vector<int>> tryGetBufferedFolderContent() { return {}; } struct FileStateDelta { FileStateDelta() {} private: int test = 0; }; };
-
Unfortunately this example doesn't work yet: namespace { struct SshDeviceId { }; class SftpSessionManager { public: class SshSessionShared { public: SshSessionShared() : session_(0) {} int session_; }; } } should be namespace { struct SshDeviceId { }; class SftpSessionManager { public: class SshSessionShared { public: SshSessionShared() : session_(0) {} int session_; }; } }
-
astyle 3.6.8 (git 2025-03-14): incorrect function-scope class indentation
-
astyle 3.6.8 (git 2025-03-14): incorrect using indentation
-
This is probably the same error: (full repro when inside .cpp file) namespace fff { struct FileAttributes { }; SyncDirection getEffectiveSyncDir(SyncOperation syncOp) { switch (syncOp) { case SO_CREATE_LEFT: case SO_DELETE_LEFT: case SO_OVERWRITE_LEFT: case SO_RENAME_LEFT: case SO_MOVE_LEFT_FROM: case SO_MOVE_LEFT_TO: return SyncDirection::left; case SO_DO_NOTHING: case SO_EQUAL: case SO_UNRESOLVED_CONFLICT: break; } return SyncDirection::none; } }
-
astyle 3.6.8 (git 2025-03-14): incorrect switch indentation
-
It works! :)
-
It works! :) BTW thanks for supporting all these different build environments: I downloaded the latest Astyle code from git, opened the vs2022 solution, just compiled: executable built, no errors! My mind is a bit blown by how great this works and how easys it is. I didn't even have to read any documentation, or fiddle with compiler options. It' s like when you're used to torture, but then you're unexpectedly offered a spa...
-
AStyle 3.6.7: wrong indentation of multi-line string concat
-
AStyle 3.6.7: wrong indentation of multi-line assignment
-
AStyle 3.6.7: class modifiers indentation
-
Preserve function argument whitespace
-
HqMame is pretty dead(1) at this point. It is based on the last Mame version that supported the GDI graphics renderer, which was very unfortunately dropped by Mame. In order to update to a newer version, one of the other renderers like Direct3D would have to integrate xBRZ. Last time I looked this seemed like a horrendously complex and tedious endeavour. 1) It's not really dead, but working fine as ever with all the games I cared about at the time :>
-
HqMame is pretty dead(1) at this point. It is based on the last Mame version that supported the GDI graphics renderer. In order to update to a newer version, one of the other renderers like Direct3D would have to integrate xBRZ. Last time I looked this seemed like a horrendously complex and tedious endeavour. 1) It's not really dead, but working fine as ever with all the games I cared about at the time :>
-
HqMame is pretty dead(1) at this point. It is based on the last Mame version that supported the GDI graphics renderer. In order to update to a newer version, one of the other renderers like Direct3D would have to integrate xBRZ. Last time I looked this seemed like a horrendously complex and tedious endevous. 1) It's not really dead, but working fine as ever with all the games I cared about at the time :>
-
This is almost certainly a quality of implementation issue with VisualboyAdvance. xBRZ is about N times faster than other filters like HQX, where N is the number of CPU cores. I suspect VisualboyAdvance didn't properly implement multithreading and/or partial screen updates.
-
This is almost certainly a quality of implementation issue with VisualboyAdvance. xBRZ is about N times faster than other filters like HQX, where N is the number of CPU cores. I suspect VisualboyAdvance didn't properly implement multithreading.
-
This is almost certainly a quality of implemenation issue with VisualboyAdvance. xBRZ is about N times faster than other filters like HQX, where N is the number of CPU cores. I suspect VisualboyAdvance didn't properly implement multithreading.
-
I haven't released 1.9 yet.
-
While perfectly useable, the idea with my xBRZ implementations is mainly to demonstrate a proof of concept to dismiss excuses of project maintainers like "too much work, too difficult, not possible". But in the long run each project would have to decide for itself if it wants to integrate xBRZ. Personally I don't see why not, because all those projects support HQx, which is in all respects inferior to xBRZ. So the best approach to get an updated xBRZ would be to directly ask the maintainers of MAME...
-
The file name is correct, it's a 32-bit executable.
-
Fine with me!
-
I think I forgot! :D Just updated the latest source code (which is still ScummVM 2.0) to use the FFS task scheduler. The build now requires an additional file, thread.cpp, which is part of FreeFileSync. Caveat: I haven't tested the code! I couldn't even compile it, since ScummVM apparently doesn't support Unicode on Windows. On macOS/Linux this shouldn't be a problem. You just have to make sure that thread.cpp (and its dependencies e.g. sys_error.cpp, ect.) are compiled and linked against ScummV...
-
I think I forgot! :D Just updated the latest source code (which is still ScummVM 2.0) to use the FFS task scheduler. The build now requires an additional file, thread.cpp, which is part of FreeFileSync. Caveat: I haven't tested the code! I couldn't even compile them, since ScummVM apparently doesn't even support Unicode on Windows. On macOS/Linux this shouldn't be a problem. You just have to make sure that thread.cpp (and its dependencies e.g. sys_error.cpp, ect.) are compiled and linked against...
-
You're not offending at all. I'm just busy with different things, that's all.
-
Funny how small open source devs seem to care more about licenses than the "big guys" (cough Nintendo cough) https://twitter.com/lunasorcery/status/1242569546038460416
-
I find license minutiae a very boring topic, so I just chose GPLv3 and am planning to stick with it.
-
Indeed for pixels outside the input image, the xBRZ algorithm just assumes duplicates of the border, while looking as far as 2 pixels beyond. For images having an alpha channel a better solution is to just treat these outside pixels as transparent. A full-blown set of new parameters just to handle the border behavior seems a bit overkill. In the RGB case (= emulator use), the current behavior (duplication) is fine, for ARGB images, transparent outside pixels are a better default. I've implemented...
-
Reminds me of (SCNR) ;) https://theoatmeal.com/comics/exposure
-
Reminds me of (SCNR) ;)
-
Reminds me of (SCNR) ;)
-
Ideally: don't :> (and try to get along with GPLv3)
-
1) yes 2) computationally expensive, but not too difficult. The result might not be suitable for real-time use, though. 3) not likely. I don't see any demand. Probably 95% of xBRZ use cases are already covered with 2xBRZ - 6xBRZ.
-
1) yes 2) computationally expensive, but not too difficult. The result might not be suitable for real-time use, though. 3) not likely. I don't see any demand. Probably 95% of xBRZ use cases is already covered with 2xBRZ - 6xBRZ.
-
1) yes 2) considerable 3) not likely. I don't see any demand. Probably 95% of xBRZ use cases is already covered with 2xBRZ - 6xBRZ.
-
I don't understand what you mean with "out-of-bounds border". Perhaps you're having an image that has both an alpha channel and a mask color? I don't see anything in Theory.png that would indicate that the outer pixels are not part of the image.
-
I don't understand what you mean with "out-of-bounds border". Perhaps you're having an image that has both an alpha channel and a mask color? I don't see anything in Theory.png that would indicate that the other pixels are not part of the image.
-
ppl.h only exists on Visual Studio on Windows and is used for task scheduling. But it's easy (for me) to use the task scheduler from FreeFileSync, which would be portable to all OSs. I'll see to include it when I update to ScummVm 2.0
-
ppl.h only exists on Visual Studio on Windows and is used for task scheduling. But it's easy (for me) to use the task scheduler (from FreeFileSync), which would be portable to all OSs. I'll see to include it when I update to ScummVm 2.0
-
put the following inside a CMD file
-
To scale all PNG files in the current directory, put the following inside a CMD file and run it: for /R . %%F in (*.png) do ScalerTest.exe -6xBRZ "%%F" "%%~nF.6xBRZ.png"
-
I have my doubts about the code-quality of these xBRZ shader hacks, at least what I've seen didn't look very pretty. I'd wish they didn't use the name "xBRZ" without any extra annotation indicating they're not official. A proper xBRZ integration into MAME would require adapting the Direct3D renderer, which looks relatively complex, thous like a very time-consuming endeavour.
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
Would it be possible to have an update to the version you provide with OpenGL+xBRZ? Not sure when I have some free time to do that. It's great to see however that there seems to be some consideration to include it into the official ScummVM. IMHO xBRZ completely superseeds HQx (both technically and aesthetically), so I'm not sure why projects like DosBox or others have so much trouble deciding whether they want to include it or not. complication with non-Windows platforms. Could anything be done about...
-
By "not adding" it.
-
Latest Visual Studio 2017
-
I'm actually not quite sure where I got Hindi.nsh from, but it's basically this version: https://github.com/angryip/ipscan/blob/master/ext/win-installer/NSISPortable/App/NSIS/Contrib/Language%20files/Hindi.nsh
-
Fix translation files: Romanian.nsh, TradChinese.nsh
-
If there were any issues regarding the handling of the alpha channel, the ScalerTest tool would show them as well.
-
If the issue cannot be reproduced with the Scaler Testing Tool, http://sourceforge.net/projects/xbrz/files/ScalerTest.zip, then it's not xBRZ that's causing the artifacts.
-
If the issue cannot be reproduced with the Scaler Testing Tool (http://sourceforge.net/projects/xbrz/files/ScalerTest.zip), then it's not xBRZ that's causing the artifacts.
-
The xBRZ integration only affects a few DOSBox source files. To use it with the latest...
-
xBRZ can already be (and should be) used in parallel as is. No need for a rewrit...
-
The scaler is pretty much complete and has achieved its goals quite well I would...
-
I don't have influence on xBRZ or save states being integrated into the official...
-
I don't have influence on xBRZ or save states being integrated into the official...
-
I don't have influence on xBRZ or save states being integrated into the official...
-
PS: the makensis.exe error codes should be documented so that batch scripting can...
-
failed finalize should be considered error
-
WinVer.nsh incorrect Server check
-
This can be solved via ordinary batch scripting, look for the "for /r" command
-
You could have tried "ScalerTest.exe -h", "ScalerTest.exe /?" or the like :)
-
Okay, I've added command line support.
-
Probably not in the near future... MAME 0.172 introduced a few fundamental changes:...
1 >
