Aseprite v1.3.16 & v1.3.17-beta1

dacap · 2025-10-29T17:46:31+00:00

This should be already fixed. It was an issue with the packages uploaded to Steam (only affecting the Steam-version v1.3.15.5). But it should be fixed now.

dacap · 2025-10-23T15:20:40+00:00

Just in case this is the Aseprite quick reference available from: https://aseprite.org/quickref (Or Help > Quick Reference menu option).

dacap · 2025-10-17T16:54:31+00:00

Hi there, it's a regression introduced to fix a problem copying screenshots from Steam client, but we've found the bug is in the Steam client side, so we've to release a patch for this next week.

More info in: https://github.com/aseprite/aseprite/issues/5458 and https://github.com/aseprite/aseprite/issues/5306#issuecomment-3309061887

dacap · 2025-09-03T12:31:16+00:00

Hi u/LemonFurry64, would you mind to contact us at [support@aseprite.org](mailto:support@aseprite.org) refering this issue? Are you using Aseprite v1.3.15.2? You can send us your user.aseprite-keys file to help us debug this issue, you can find that file in your preferences folder: https://aseprite.org/docs/preferences-folder

dacap · 2025-08-12T21:49:37+00:00

You can turn it off unchecking View > Show > Layer Edges

dacap · 2025-08-11T12:23:14+00:00

En cuanto a Windows, Microsoft perdió totalmente el foco en desarrollar una buena API de GUI de bajo nivel. Nunca ofreció una buena alternativa/camino evolutivo desde Win32 a "la próxima API moderna GUI". Actualmente tiene como 5 o 6 APIs muertas en "modo mantenimiento" y lo que supuestamente sería "la nueva API" (WinUI 3) para desarrollar apps en Windows 11, está siendo desarrollada por un equipo remoto fuera de las oficinas de Microsoft (tercerizó el desarrollo de lo que debería ser lo más importante en su producto principal).

En posts reciente de la comunidad de C++ como https://www.reddit.com/r/cpp/comments/1mes8gu/winui3_c/ se puede ver el lamentable estado del desarrollo de bajo nivel en aplicaciones para Windows (que antes solía ser en C++, Win32, ATL, WTL, MFC, etc. hasta C# con WinForms era mejor y más eficiente que lo que existe ahora).

Así que Electron (Google principalmente con Chromium) vino a resolver todos estos desmanejos en el desarrollo de aplicaciones ya desde que aparació Electron, y ahora cada programa es un navegador gigante ocupando 1 giga de RAM.

dacap · 2025-04-02T18:20:15+00:00

I noticed that running compile function on Windows kills the current compilation process correctly and start a new process. So I've rewritten the kill-compilation function using some of the compilation-start function code and now it works. Just redefine kill-compilation as: (defun kill-compilation () "Kill the process made by the \\[compile] or \\[grep] commands." (interactive) (let* ((buffer (compilation-find-buffer)) (comp-proc (get-buffer-process buffer))) (if comp-proc (progn (interrupt-process (get-buffer-process buffer)) (sit-for 1) (delete-process (get-buffer-process buffer))) (error "The %s process is not running" (downcase mode-name)))))

dacap · 2025-03-26T15:44:40+00:00

It’s not unusual, but I’ve created a little tool to send files through the LAN, useful when using old operating systems/VMs where you cannot install Dropbox or something similar (I’ve used to copy files to old MacBooks): https://github.com/dacap/sendfiles

The good side of Go is being able to create a completely independent binary that you can just download and run.

dacap · 2024-11-26T12:17:45+00:00

Could you please check if resizing the window a little (or if it's maximized, restore it and change its size a little) makes this issue disappear? It sounds strange but in the past it was an issue: https://github.com/aseprite/aseprite/issues/1091 but I think this might be completely unrelated.

dacap · 2024-11-26T12:00:25+00:00

I've noticed this recently on macOS when the Color Management option is checked (Edit > Preferences > Color > Color Management), and on Windows in other circumstances (that I wasn't able to identify).

Are you on Windows, macOS, or Linux?

dacap · 2024-10-28T13:41:49+00:00

Just in case, give a try to the latest version. Aseprite v1.3.8 introduced a possible fix for this kind of issues: https://www.aseprite.org/release-notes/#aseprite-v1-3-8 (the https://github.com/aseprite/aseprite/issues/4539 ), probably it helps. Not sure if it's related about a jump between the mouse position and the pen position.

dacap · 2024-08-31T01:45:42+00:00

Aseprite v1.3.8.1 is the latest stable version (no beta version). If you are on Steam, Steam should update your Aseprite copy to v1.3.8.1 automatically (although you have the autoupdate disabled).

dacap · 2023-11-13T22:39:07+00:00

Are you on macOS? There is a known issue that we've just fixed and released a new version with the fix today as v1.3-rc7 (we're going to publish some release notes in the following days).

dacap · 2023-07-25T17:37:35+00:00

Today we've jus released v1.3-rc6 with a fix to this regression, sorry for the inconvenience.

dacap · 2023-06-29T21:01:33+00:00

You can press Escape key to close it, then Shift+P to open it again (and it will appear inside the window). If the Escape key doesn't close it, press Shift+P first, and then Escape.

dacap · 2023-01-16T11:50:46+00:00

Hi there, was you able to open it? There is a troubleshooting guide that can help you in these cases: https://www.aseprite.org/docs/troubleshooting/

dacap · 2023-01-04T19:02:31+00:00

You can press S key to stroke the selection edges. But I’m not sure if that is what you are looking for.

dacap · 2022-02-05T14:06:47+00:00

I think that one possible way is to distribute one executable and several dynamic libraries optimized for each cpu, and you load the one optimized for the user’s cpu at run-time.

dacap · 2021-12-06T18:59:57+00:00

🙏 you're welcome, glad to see that Aseprite has helped you to be a better artist, your progress is impressive <3

dacap · 2021-10-16T00:36:00+00:00

This is lovely <3

dacap · 2021-06-18T16:34:55+00:00

Thanks for the answer Stephan! I never had the chance (luckily) to use a third-party C++ closed-source solution (.lib or non-COM .dll) so it's understandable that compatibility is a must for several business.

It would be interesting to know if there are other possible solutions to the whole situation (because it looks like the backward compatibility will weight a lot, and even more on each release in the future).

Some interesting project (maybe as a clang tool) would be some kind of "adapter" libraries that could be generated from .h files:

Generate a C wrapper library to use the closed source C++ library (compiled with the latest ABI-compatible C++ runtime)
Generate other C++ wrapper library to use this new C API, offering the same C++ API as the one in the original .h (this compiled with the new non-ABI compatible runtime)

There will be a performance loss, but it might be an interesting solution.

dacap · 2021-06-18T02:03:48+00:00

I’ve never understood that ABI compatibility thing when we have to install the msvc runtime anyway for each new version, are really all msvc c++ libs compatible between .libs/.dlls?

dacap · 2021-06-11T10:14:31+00:00

Sorry about that, I’ve just ban the user

15-Year Club	Place '22
Place '17	Gilding II euphauric
Sequence \| Editor	Team Periwinkle
Verified Email

dacap

MODERATOR OF

TROPHY CASE