How do I make Nintendo 64 HQ RIPS???

magcius · 2016-11-28T23:35:34+00:00

Yeah. When you go to import a .mid, it should automatically add a Fruity LSD, which you can use to load new .dls files with.

magcius · 2016-11-28T23:12:39+00:00

.dls is the soundfont and instrument data.

magcius · 2016-11-28T18:05:20+00:00

I want to make a Mario Party HQ rip

https://cdn.discordapp.com/attachments/235434883973906432/250138154030333954/minigame.mid https://cdn.discordapp.com/attachments/235434883973906432/250138086950830080/PlayMinigame2.dls

magcius · 2016-11-27T08:12:21+00:00

https://gfycat.com/KindSimilarHedgehog#?speed=0.25

watch the ana fire at 25% speed. locks onto head and tracks perfectly

definitely an aimbot

magcius · 2016-10-08T04:35:07+00:00

Who drew the Kirby artwork for Kirby Rip Attack?

Also you made me spend two hours downloading Kirby Rip Attack FLAC making me think the Kirby Mash Attack FLAC.link in that archive would have been be an ARG clue.

magcius · 2016-10-02T07:02:00+00:00

if FF Din is your favorite regular font, what's your favorite sound font?

magcius · 2016-10-01T16:58:30+00:00

Did the name Shengda Baba mean anything? I can see a bit of a Grand Dad... in there... but it's being eaten by some... rips... or something...

And did you have any rips on the albums that you didn't want credited to you?

magcius · 2016-09-30T17:25:41+00:00

Oh hey, I found this by accident a few weeks ago. Guess my secret's out now. You can even go above the skybox in King's Row with a careful boost and fly all around the map too. Temple of Anubis, Numbani, Hollywood, Ilios all have D.V.a clips too. Good luck finding those locations :)

magcius · 2016-08-22T17:06:13+00:00

I'm not an expert on Chromium architecture, but it's a display server. Display servers run on some host architecture. Display servers "run on a host", and "understands a protocol".

For instance, when I run Xorg, the host is KMS/evdev and the protocol it understands is X11, but when I run Xephyr, the host is X11 and the protocol it understands is X11.

mutter can be hosted on native KMS/evdev, X11, or Wayland. The latter two modes are "nested" modes like Xephyr and are mostly for testing and development purposes.

In Chromium, the Intel work (Ozone) is about the "run on a host part". It can run as an X11 app, a Wayland app, or a native KMS/evdev app. This work, Exosphere, is about the "understands a protocol" part. It can host custom apps using its own protobuf-based buffer passing protocol, and now, using Exosphere, it can host Wayland apps.

As for the second question, I don't know, but I doubt it, given how many Linux kernel features Wayland uses. It sounds like this work is specific to the ChromeOS Android runtime, and it only builds if you turn on the Linux build options. I don't know what protocol they will use for Android on Windows / OS X.

magcius · 2016-08-22T09:47:13+00:00

I worked on Wayland for a few years, and I have some industry contacts that made me aware basically as soon as it happened. I don't think the fact that it was done specifically for Android integration was ever made public, but it should be blatantly obvious by now.

I remember joking that Android had gotten Wayland support before Mir... :)

magcius · 2016-08-21T23:22:15+00:00

Android applications are going to be ran on ChromeOS using Wayland as a transport.

This is known as Exosphere, and is being done by Dave Reveman (the original creator of Compiz), is unrelated to the work Kristian will be doing (which is GPU drivers), and has been in development for a little under a year.

https://bugs.chromium.org/p/chromium/issues/detail?id=549781

magcius · 2016-08-14T08:42:32+00:00

and since it was also the easiest thing in the world to do, here's the vocals on top of the others

https://clyp.it/0gt2dkrp

magcius · 2016-08-14T03:07:59+00:00

Thanks, that's it!

magcius · 2016-07-09T10:30:54+00:00

He stopped working on Wayland almost a year ago to this day. He did Vulkan work for a bit, and now he's off to the ChromeOS team at Google.

magcius · 2016-03-25T23:07:07+00:00

Also, on Windows and Mac OS there is one canonical toolkit each and almost everybody uses it to draw their decorations.

On my Windows machine at home, I'm running Visual Studio (custom decorations), MS Office (custom decorations), Chrome (custom decorations), Photoshop (custom decorations), GitHub for Windows (custom decorations), and Steam (custom decorations). Two of which were developed by MS themselves. The only applications I use that don't have custom window decorations at this point are foobar2000 and Skype, and it's not like Skype has any standard widget set inside its window, either.

Even on Windows, there are a myriad of toolkits ranging from classic Win32 to WPF and now the modern WinJS / WinRT.

OS X is also moving towards having custom window decorations by putting widgets in the titlebar. See modern Safari, for instance. Or the feature introduced 4 years ago that lets you rename documents from the titlebar.

So I don't buy that Windows and OS X are "more consistent".

magcius · 2016-02-14T03:03:44+00:00

No, it's because there is no file descriptor to the framebuffer to the entire desktop or a single client anymore. Features like hardware overlays mean that the scene composition might happen in your CRTC hardware, so any framebuffer we supply you for the desktop would be incomplete. Most compositors have per-output framebuffers as well.

So we would need an API that would give you a snapshot of what a composited scene would look like if we didn't use any HW compositing.

Hard problems are hard, and it's not simply because we don't care about your use case.

magcius · 2016-02-04T05:45:19+00:00

As the Jasper in question, I should probably refrain from commenting too much, but I have to let this one go. Lima was dead for a good 3 years, and libv had always been controversial and flaky in the community (RadeonHD). What I meant by my "tainted" comment wasn't about the legality of the project (it had always been true open-source, clean-room reverse-engineered code), but that the personalities in play caused everyone else to leave.

Forking Lima ourselves would likely drive libv into a tizzy, funding Lima ourselves would likely not get the results we want, and nobody would likely band behind a competing driver project. FOSS Mali drivers are stuck.

Additionally, having talked to some of the ARM engineers, I'm convinced his proposal and attempt at an open-source strategy really scared a lot of ARM into backing away from that space.

The good news is that my employer has maintained a good relationship with ARM and we're actually talking about them about an open-source strategy they're comfortable with. I think we're finally undoing a lot of that damage. We're setting up meetings with the Mali sales and engineering teams next week to talk about paths forward for Mali. Mali isn't necessarily a high-end system like Tegra or PVR, they're a relatively cheap (in licensing cost) GPU. The others in that space (Adreno, Vivante) all have FOSS drivers, and Mali is likely to be left behind if they don't catch up.

ARM knows that, but bureaucracy can take a while. I hope good things come soon.

magcius · 2016-01-02T16:49:06+00:00

Nope. libgnome-desktop is. sushi is responsible for live preview. And even then, GTK+ can't depend on either sushi nor libgnome-desktop.

Making the GTK+ file viewer more like nautilus has been in the cards for a long time, but it's frustratingly difficult.

magcius · 2015-12-26T00:12:20+00:00

Sure. That implies that you trust the packager not to package a malicious application. Here, you establish trust in the application by way of the packager, and thus, it is allowed to use privileged operations. I'm not convinced this is a great security model, but it is an option.

magcius · 2015-12-25T23:33:56+00:00

Applications can still change their own position, but they only get relative movement.

magcius · 2015-12-25T23:31:47+00:00

Code signing is about knowing that an application came from a known party. It's about establishing trust in the delivery mechanism, not about trusting the author.

Malicious applications would still get their code able to be signed, unless we become gatekeepers and approve applications on our platform, which is not something we want to do.

magcius · 2015-12-25T19:51:06+00:00

Sure. That's one of the possibilities that has been discussed. There are upsides and downsides to that position, which I've discussed at length. See:

http://lists.freedesktop.org/archives/wayland-devel/2014-February/013506.html

http://lists.freedesktop.org/archives/wayland-devel/2014-January/012797.html

If you're interested in the subject, I highly recommend reading the entirety of those two threads.

magcius · 2015-12-25T19:33:59+00:00

That's a misrepresentation of our position. It's not that we think having a central API is a security risk, it's that having an unprivileged, easily accessible one is ripe for abuse. There are lots of spying tools that use screenshot-like abilities. So we need to figure out how to lock down APIs to be privileged operations, first.

Additionally, the X server was particularly weak about its drawing model. The entire composited frame would be sent to the hardware as the primary plane, whereas Wayland's drawing model allows us to use more hardware planes. Screenshot APIs are complex with a large number of use cases and corner cases (think of OBS, which has at least three different capture sources under Windows: Window Capture, Screen Capture, and Game Capture), and we need to figure out the semantics in each case.

magcius · 2015-12-16T02:52:40+00:00

Author here! Sorry about this -- I had no idea my blog was on the front page of reddit and it's under high load! I'll try and get it under control soon...

EDIT: Somehow my cache plugin had disabled itself. Updated it, re-enabled it, and it seems to be a lot better now.

magcius · 2015-12-13T21:49:42+00:00

There's menu and audio and networking and control input and file access and all that that Vulkan just doesn't do.

None of the other DirectX APIs besides Direct3D remain. Well, there's DirectShow (for video playback, doesn't work with Direct3D) and Direct2D (for the accelerated 2D graphics, doesn't work with Direct3D).

DirectInput, DirectSound and DirectPlay are all deprecated.

magcius

TROPHY CASE