When is multi screen support coming?
I want to put my preview window on another monitor. Idc how much work it takes, do it. I want it.
Be superior to piskel yo, multi screen support. Do it.
Hi @Forrest_Lowe, actually the “do it” thing doesn’t work for developers. Even more, it works in the reverse direction: the more “do it” I hear, the less I want to work on it.
Well that would be valid if I wasn’t also a developer. I am a strong believer in listening to my audience, if you don’t believe in that then why charge for your product? Because you’re gonna make allot more sales going FTU if you don’t give a shit what people think.
The feature can be implemented after doing the full switch to our back-end + Skia (removing Allegro library completely, which is still active on Aseprite v1.2.9 on Linux). You can see the ongoing efforts along all these years to implement this feature here: https://github.com/aseprite/aseprite/issues/139 It’s not related to “I don’t give a shit about the users”, it’s that it required years of work to be able to implement the feature and just in this year we’ll be able to start working on this.
What I find a little harsh from your side, is the imperative tone to ask for features, sounds like developers are slaves or something like that.
It’s more of a suggestion, I am happy to see that it is indeed being worked on. I do not mean to tell you how to do your job, I only mean to express how I feel the product should continue. I want a feature, and to know that it will be implemented in a couple of years (as it sounds from the way you put it) just makes me joyous.
Side note: I don’t mind being harsh if it means you’re listening. I like to be playful and ask for something in a joking manor “Do it” being the punchline(poor though it may be.) But I don’t care to be talked down to for not being on the project. If you were to start your responses with “That feature is actually already in the works” like you have done now, I would have responded very differently.
Developers everywhere hate attitudes like yours, Forrest. You being one of them isn’t a free pass, it makes us ashamed to share an occupation/hobby with you.
Edit: Just a note, there was an even nastier comment from our friend Forrest that was removed that prompted my response, but my remark still stands.
Just in case for future reference I’ll leave here some comments about this feature and why it’s hard to implement in the current design of Aseprite (but it’s not impossible, but it will take some time):
The original version of Aseprite (ASE, Allegro Sprite Editor) was developed with the Allegro (4) library, which was a library to program games on a MSDOS-style (one thread, sequential logic, without events). Remember that I started developing ASE in 2000~2001. (We still have the modified Allegro version that we used for Aseprite in a separated repository for historical reasons.)
Allegro 4 library never supported multiple windows, so the program UI was never thought to be used in multiple windows of the operating system (that’s is why the ui layer uses only on ui::Manager with one display).
Then we refactored everything to a new layer (laf) instead of using Allegro directly.
Then we switch the back-end of laf to our own implementation using events to handle user input, and using Skia to draw graphics in-memory.
Now the laf library supports multiple windows, but the ui module of Aseprite doesn’t. So now we have to change the ui::Manager impl to handle multiple os::Display, and each ui:Window could be related to a specific os::Display.
Basically this is a refactoring-problem vs. avoid-introducing new bugs, we choose to have a more stable Aseprite version in the short-term instead of adding something that will break everything. The actual bottleneck is the tilemap editor feature, once that is implemented on v1.3-beta, we’ll be able to start adding/refactoring more stuff on the beta version (the stable v1.2 is almost feature freeze and only bug fixes will be released from now on).
Wow, I was googling for this and it turns out it’s been discussed just a few days ago. Well, if someday it’s implemented it will be really welcomed!. These kind of core refactors may be really, really painful. I prefer a single-windowed-bug-free software than a rushed multiwindow disaster. Take your time!
Just my two cents, I would rather have someone like this, than those who doesn’t participate in community. and yes, I also came here because I have multi monitor and would like to see the progress of this feature. Thank you.
@dacap Is there an ETA for this feature? (I’m also a multi monitor user, but I don’t really mind if it’s a pair of years or more, I’m more than happy with the development of Aseprite, it’s just my curiosity asking ^_^)
I totally agree!
I’m not too sure of that, man. Maybe Forrest_Lowe meant no harm with his original post, but sometimes users can create really toxic threads (even unknowingly) by asking for things and answering posts in that way (without caring about good manners and/or upsetting other users). Also, welcome to the community! @macroblitz
1+ to this feature, I’m pretty new to animation and art, pixel or otherwise, but at least to me it seems very important to be able to have the same animation open on multiple stages of the animation and on multiple levels of zoom just to easily get an overview of the different states and how they relate to the part you are drawing. Understand it hasn’t been prioritised given the complexity though.
But instead of just complaining I’ll also come with a possible solution. It’s a bit of a hack but works better than nothing if you really want the second monitor (let me know if anyone has a better hack pls).
With OBS (streaming software) you can easily show different regions of a screen on another screen, so if you just duplicate tiny windows of what you would want on the other monitor, and then just blow up that region on your second screen, you can get more references of what you are currently drawing on your second monitor without taking up that much real estate in the main window.
Second monitor on the left:
To easily crop the windows in OBS hold down ALT while resizing them.
Here is what I do by the way to get around this limitation when using Aseprite until it can be supported.
Honeyview will auto refresh when the open file is changed. It also supports nearest neighbor scaling (“No filter” in the menu). So if you keep exporting the image and have it open in Honeyview, you can get whatever size of preview you want. It can also preview animated images in addition to static images.
What did they say? I’m curious as to how horrible it is. Was it a “you make product so you have to improve the product even if it is at the expense of your own health because I paid for quality and I will get quality” dumbfucks or was it worse? I can’t count the amount of people messaging me weekly about an app I stopped developing years ago.