Renzatic

Moar woods! This time, I went with a painterly style to see how it'd look. There was a lot of work done in Photo for this one.

It should. The M1 is the same CPU architecture, and it's running on the same OS. There shouldn't be any compatibility issues.

Touched it up a bit more to give it something of a sketchy, painterly look. I think I'm done with this one. Time to start my next project.

Ah, my elementary school years. Fond memories.

There is one guy, who's name totally escapes me at the moment, that I've seen post both here and Blenderartists. ..so there's probably a couple.

Well, since I'm back on Windows using AP again, I guess I can show off my stuff here once more. Especially since I did a lot of touching up in Photo on this shot. ...man. I didn't realize how much I missed their gradient tool until now. This is something of a remake of an earlier picture I made a couple years back. One of the first thing I did with vectors. Now it's 3D, and snazzy fresh.

...strange the forum never notified me about getting a reply to this thread. Yeah, I expect (and hope) that the iPad version will keep it's touch-centric UI. I've used the desktop version of AP on a tablet, and it was a fairly janky experience. I'm mostly curious about the feature set. There's really no reason for developers to offer up a truncated mobile version of their apps anymore. The only question is whether they'll take advantage of the power on offer.

Now that the iPad is effectively a Macbook Pro 13" in a tablet form factor, are you all planning on taking advantage of this newfound power? Will the iPad version match 1:1 with its desktop counterpart? For example, I remember reading awhile back how you're planning on bringing 3D support to Affinity Photo/Designer. That'd be an absolute killer feature to have on the iPad, and it'd practically seal the deal on me buying one. So...whatchall plannin'?

There are situations where text rendering can look decent on Windows. The modern features of the OS do tend to look better than their Win32 equivalents, like Settings, Edge (which may inherit Chromium's font renderer, not sure), UWP apps, etc. But there are more than a few occasions where you run into older programs, and get blasted by those thin, rainbow bordered fonts that just look...janky. No matter how many times I try to adjust Cleartype, that slight colored haze always manages to keep lurking about, especially on darker themes. It doesn't help that Segoe UI, which is EVERYWHERE in Windows, is a fairly thin and spidery font. Something medium weighted would help things out tremendously.

Thing is, you get excellent font rendering out of the box with Ubuntu, which has roughly the same hardware and software constraints as Windows. It's just something that Windows has always been weak on. Though to be fair to Microsoft, it's not like they can make too many sweeping changes to the OS like Apple can. If they change too much too quickly, they risk an angry mob of people marching on Redmond.

In general, Window's font rendering is just godawful. You can tweak it to some extent, but it's never really good.

It's definitely a snazzy upgrade. Haven't had any problems so far.

Now I might have to buy it out of pure respect for the skillz on display.

Wow. People still do that? That's impressive.

It ran perfectly. I decided to give it a roll here in Windows, and there's no difference in look or performance whatsoever. One of the reasons why I'd assume it runs so well in Wine is because it looks like it's leveraging oldschool Windows APIs, not really pushing the box in any way as far as GPU and interface niceties are concerned. Meanwhile, the Affinity suite leans on the more modern standards, which Wine doesn't support nearly so well. It makes for a great experience when you can use it, but sorta sucks when those nice features keep you from hopping OSes.

From what I can find, it's looks like a program that's geared more towards general Linux usage than a specific OS. It might've been a problem back when, but things are more than likely better today.

What program was it?

I have access to them on Steam, and they install instantly there. Thing is, I hate having to open Steam every time I want to launch a program. There's always someone there who starts spamming me with messages every time I open it up.

If it ran on Redhat, it should've run on Fedora, since it's effectively tomorrow's version thereof. The only time I actually had any trouble installing an app was with those two programs I mentioned above. Substance Painter and Designer are targeted towards Redhat/CentOS users, and thus only comes in .rpm files. Pop, being Debian based, can't install .rpm files natively, so I had to convert them to .debs. Was it a pain in the ass? Oh, yes. Even though things are considerably more user friendly than they've ever been in Linux land, there are still occasions where you have to get down and dirty with the nerdy to get something working. But I was able to get it work, and it performed fine afterwards.

You have Substance Painter and Designer on Linux, both of which are Adobe apps. The problem with Linux isn't that it's small, rather that it's very specific. If you're working with code or 3D applications, you have tons of users with all the support you'd ever need. Graphics design? Well, that's more of a question mark.

It's not an issue of reliability, so much as ease of use. All Linux software will run on all Linux distros. Appimages are just the no fuss, no muss approach to it.

Like I said, it's a rare problem these days. Something you only clash against occasionally. In the 3ish months it's been since I slapped Pop OS on my machine, I've only seen it happen once, and that was from someone playing around with their own homemade complied version of an application, and wasn't too familiar with Linux norms.

Yeah, but you do run into similar situations even on Windows, when you find yourself having to update to a later version of, say, .net. The only difference there is that Windows does a better job of making that upgrade process automagical, while Linux just tells you that you need a later version of the library, and leaves you to find out how to do it. Like I said, it's mostly an academic argument, because at the end of the day, it isn't any more difficult for developers to implement, and doing so doesn't make the app any slower or less efficient. Literally the only difference is that your raw tar.gz version which only includes the binaries is 120 meg, while the appimage is 135 meg.

That's true of Linux as well, provided you have that library installed. The biggest strength and greatest weakness of Linux is that it's wide open. You have all these different distributions with different standards and upgrade schedules. Ubuntu, which updates every 6 months, may not have the latest version of Library X installed, while Arch, with it's rolling release schedule, gets it as soon as it's available. While it doesn't happen nearly so often as it once did, there are occasions when you run into a program that's been compiled against the latest version of Library X, which your distro may not have installed as standard yet. It's fairly simple to get around, because all you have to do is run to your package manager, and update to the latest version (provided it's there, which it usually is from my experiences). Though it's still a pain in the butt, because it's a bit of extra unnecessary overhead you have to deal with. Flatpaks and appimages take away that potential pain in the butt, because they include all the libraries along with the binaries. What you're arguing is basically a Linux purist standpoint, that all libraries SHOULD be handled exclusively by the OS. In the end, the only thing you're losing out on is having to deal with slightly larger app install footprints, so it's mostly an academic argument.

How are appimages 3rd party kludge? Linux addressed it's problem with conflicting libraries in much the same way the other OSes have with snaps and flatpaks, and appimages simply the process even more by making your apps a single, self contained executable you don't even need to install.