This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - bb010g
Pages: 1 ... 20 21 [22] 23 24 ... 34
316
« on: May 03, 2014, 07:32:45 pm »
xmobar works pretty well too; it has some built in stuff and can run scripts or one-liners at an interval of your choosing as well as display a changing stdin (normally from your WM).
317
« on: May 03, 2014, 12:55:21 am »
Wow! You have a welcome topic! Have some necro peanuts!   (Maybe necroing your welcome page every few years could become a tradition...)
318
« on: May 03, 2014, 12:14:55 am »
shmibs: What WM is that? It looks like dwm. Juju: Use a mkinitcpio hook, like this: sudo -s or su into your root. Make a file /root/kernel-copy.sh (or whatever): (replace all references to EFI only stuff with proper locations and text, but the basic operations should be fine; the if block is there to make sure my /boot/efi is rw and not r as it tends to mount for no particular reason (I think it's related to being HFS), so you should be able to remove that unless you have cp problems) #!/usr/bin/env bash
while [[ -d "/proc/$PPID" ]]; do
sleep 1
done
if [[ "rw" != "r$(/usr/bin/mount | /usr/bin/grep '/dev/sda4' | /usr/bin/sed 's/.*(r\(.\).*/\1/')" ]]; then
/usr/bin/umount /dev/sda4; /usr/bin/fsck.hfsplus /dev/sda4; /usr/bin/mount /dev/sda4
echo ' -> Remounted /dev/sda4 as rw [kernel-copy]'
fi
/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz.efi
/usr/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img
/usr/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img
echo ' -> Synced kernel with ESP [kernel-copy]'
Make a file /usr/lib/initcpio/install/kernel-copy (fixing as necessary): #!/usr/bin/env bash
build() {
/root/kernel-copy.sh &
}
help() {
cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to my external drive
HELPEOF
}
Again, change as necessary. Mostly taken from the EFISTUB ArchWiki page.
319
« on: May 02, 2014, 10:06:09 am »
I'm thinking a bit of the Windows 7 solitaire with the large suits. It only does one graphic per card and relies upon the number for rand identification.
320
« on: May 02, 2014, 08:13:26 am »
I'm not entirely certain that these giant faces mesh well with the graphics of the rest of cards.
You should try redesigning the normal cards in the face style.
321
« on: May 02, 2014, 01:11:54 am »
FUn fact : the SNES soundchip is a Sony one, did you guess why the GBA doesn't have one? (Hint : PlaySomething contract between Nintendo and Sony has been broken and thus they became "ennemies".)
Nintendo and Sony wanted to make a CD drive for the Nintendo 64, it later been cancelled and Sony went ahead and made their own console with a CD drive, the PlayStation.
Relevant video: PlayStation - Did You Know Gaming? Feat. Caddicarus
322
« on: May 02, 2014, 01:10:21 am »
I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.
What bug? I'm intrigued.
323
« on: May 01, 2014, 05:43:00 am »
Do you have a Prime? I've been presuming you do and can look at it. If not: Almost every drawing command has two variations: a Cartesian and a pixel version. Pixel versions are suffixed with _P; for simplicity's sake they will be dropped as the positions do not matter here. GROBH(G) and GROBW(G) return the height and width of G. BLIT copies a GROB from one buffer to another, but with optional regions and optional alpha color: BLIT([trgtG],[dx1,dy1],[dx2,dy2],srcG,[sx1,sy1],[sx2,sy2],[c]). (Unless otherwise specified, optional GROBs default to G0.) INVERT inverts a region of a specified GROB in place: INVERT([G],[x1,y1],[x2,y2]). If the rotation was in-place, that would make calculations of position hard. I think Tim was thinking of something like that, but I'm not sure. Hence my suggestion of bitmap matrix transforms that can be sent to another GROB. There's a MSDN article on them in the context of DirectX that is pretty useful anywhere: DirectX Factor - 3D Transforms on 2D Bitmaps. It also discusses how 3D or 4D transforms can be used to do fanciness in a 2D or 3D plane if you're careful. It's awesome. It would actually be really cool if we could muck around with up to 4D matrix transforms and just specify optional values for z and w cross-sections, defaulting to 1 or 0, whichever would work better. (I'm getting sleepy and trusting my judgement here less.) Exemplī grātiā: MATTRANS([trgtG],[dx1,dy1],[dx2,dy2],srcG,[sx1,sy1],[sx2,sy2],matrix,[zPlane],[wPlane],[color]). We should be able to convert the 3D matrices from back to 2Ds with a z of 1 with some depth stuff, but the non-affines are worrying me, as they pull from values in the matrix. New idea: what if we could get and set a matrix of RGB values from and to a GROB region, such as GETMAT([G],[x1,y1],[x2,y2]) and SETMAT([G],[x1,y1],[x2,y2]) (with respective _P variants)? Then we could take a bitmap out, transform it, and...wait...array of 2D coordinates doesn't leave space for RGB values...how about returning 3D matrices with the z being the color? /me refers back to the articleSo, how about {GET,SET}MAT([G],[x1,y1],[x2,y2],[dimension]), where dimension defaults to 2 and the output/input is a q×(dimension+1) matrix (with the last part holding color) and q is the number of pixels. That should allow for the offloading of heavy transforms to the matrix functions and allow for easier custom transforms (like 3D→2D flattening). So Tim, when you read this, something to consider. It would allow for some pretty cool stuff. 
324
« on: May 01, 2014, 03:58:17 am »
Ubuntu's not bad for a power user interested in Linux. Unity is decent. While I dislike the advertisement stuff in the new versions, I don't think it deserves as much hate as it gets. If you want more control, pick a lighter-weight distro.
325
« on: May 01, 2014, 03:52:14 am »
PEANUTS!
326
« on: May 01, 2014, 03:50:42 am »
What would be cool as well is if images could be rotated.
The problem with this is how you you then use the rotated image? The coordinates used are always in the upper left corner, so to keep the grob consistent we'd have to change the size in order to not lose information and it seems to me you'd then have difficulty using it since it would be hard to know where to place it..
I didn't really get it. Of course the size would change but you are aware of it since you requested the rotation. Isn't there a function to get the size of GROBs ?
There are—GROBH and GROBW. I think what Tim was thinking was an in-place transform, like INVERT, but I'm not sure. I think going with matrix transforms with a BLIT like syntax would work fine, however.
327
« on: May 01, 2014, 12:09:21 am »
I play Project M and just got a new laptop with an actual graphics card (yay!) (Lenovo IdeaPad Y410p), so I should be able to pop Dolphin on there and play. 
328
« on: April 30, 2014, 11:59:57 pm »
What would be more useful would be a way to apply matrix transforms to a GROB; e.g MATTRANS([trgtG],[dx1,dy1],[dx2,dy2],srcG,[sx1,sy1],[sx2,sy2],matrix,[color]) acting like a mix of BLIT and DIMGROB (with the default color). That would allow for rotations along with flips and more.
329
« on: April 29, 2014, 09:55:55 am »
However you want; you can use a literal, like {1,2,5}, or a function, like seq(2x+1,x,1,10). Any valid list will work.
330
« on: April 29, 2014, 09:51:51 am »
I'm getting the same thing occasionally. Here's my key: a867-ac3c-b40c-8ddc.
Pages: 1 ... 20 21 [22] 23 24 ... 34
|
Show Posts