|
 Yeah that's the same ray tracer from a while ago. I needed a few more impressively sounding features to put on the resume bullet point list, so added a KD tree based accelerator. Works correctly but not actually much faster than the naïve approach  Probably partially because the scenes are pretty small, but I'm also not traversing the tree in the most optimal way.Coincidentally it's written in C++. I wouldn't that argue it's easier or faster to develop than C#, but it rarely gets in the way, and memory management is definitely not something I regularly have to think about. RAII just takes care of it unless I'm manually allocating a bunch of space for the framebuffer or something, but even then I's easy to immediately write a corresponding free/delete. My main complaints would probably be the lack of modules, bizarre error messages, and next to useless IntelliSense. mobby_6kl fucked around with this message at 16:39 on Feb 23, 2014 |
#
?
Feb 23, 2014 16:37
|
|
|
|
| # ? May 26, 2024 13:21 |
|
|
Rottbott posted:Nope - I preferred C# at one point but eventually changed my mind. Partly for templates, and partly for destructors/smart pointers and usable value semantics. The only things I miss from C# are the superior standard library and LINQ.
|
|
#
?
Feb 24, 2014 02:34
|
|
|
Orzo posted:Valid point, but what about the superior IDE? You don't miss that? Don't forget about resharper, its a godsend for programming c#.
|
|
#
?
Feb 24, 2014 21:05
|
|
|
I've been working on a little bit of a Spelunky clone. The solution/room generation didn't really warrant any pictures, but now I have buggy ladders! I'm also going to start up a proper blog soon to post more progress on this and possibly other projects, but for now I have setup a wordpress (Here) until I have time to setup a proper site. 
|
|
#
?
Feb 25, 2014 05:56
|
|
|
Orzo posted:Valid point, but what about the superior IDE? You don't miss that? While I agree that C# is superior, Visual Assist is so loving good at making Visual Studio work with C++ that I'd say it's drat near required for anyone doing C++.
|
|
#
?
Feb 25, 2014 06:45
|
|
|
I'm redesigning my application's UI to be more user-friendly. It's a tall order, because the application is a pretty technical utility (detecting duplicate files). I'm using the Nimbus look and feel for the sake of cross-platform compatibility. I edited some free icons that I found in GIS to use as placeholders until I get a chance to design my own.
|
|
#
?
Feb 25, 2014 14:28
|
|
|
Internet Janitor posted:Playing with hexagons. Congratulations on making it to BoingBoing!
|
|
#
?
Feb 25, 2014 23:27
|
|
|
Trabisnikof: uh, link? I wrote my code from scratch but the animation is pretty similar to some looped gifs I'd seen on the internet, so you might have run into a gif made by somebody else. Internet Janitor fucked around with this message at 23:38 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 23:34
|
|
|
Internet Janitor posted:Trabisnikof: uh, link? http://dvdp.tumblr.com/post/55124353196/130711 Looks neigh identical, just flipped sideways (better looped gif I guess). Maybe someone is derivative of another, but I saw this blog linked from boingboing and (mistakenly?) thought it was you. Edit: 
|
|
#
?
Feb 25, 2014 23:46
|
|
|
Nah man that guy's must be the original; I just wrote a program to generate similar animations.
|
|
#
?
Feb 25, 2014 23:49
|
|
|
Internet Janitor posted:Nah man that guy's must be the original; I just wrote a program to generate similar animations. Well, that blog will have lots of fodder for you to try and replicate, some very cool animations.
|
|
#
?
Feb 25, 2014 23:51
|
|
|
Internet Janitor posted:Nah man that guy's must be the original; I just wrote a program to generate similar animations. It's pretty likely too that this one will inspire me somehow to update my portfolio site. I only got an afternoon's worth of time to play with the Javascript port of Processing a few months ago, but it's fun and I'd love to come back to it and whip up something along the lines of (but different, of course) what you have there. All I have right now are just plain old linearly-pulsating bubbles and color rotation.
|
|
#
?
Feb 26, 2014 19:00
|
|
|
 Me and Scaevolous spent the past 2 dayish working on a way to ASCIIify the twitch plays pokemon stream (and to maybe start scraping it and make an api out of it) Works using redis pubsub, some websockets, and liberal use of opencv and ffmpeg http://pokemon.boner.io/ for live ascii pokemon fun
|
|
#
?
Feb 27, 2014 00:09
|
|
|
I think I crashed it from linking it on twitter maybe, sorry  FastEdit: I really liked it though! The way it gets the text perfectly is neat, and the health bars in battle look cool when represented by numbers as a fraction of a bar.
|
|
#
?
Feb 27, 2014 01:44
|
|
|
Jewel posted:I think I crashed it from linking it on twitter maybe, sorry its cool we're watching it, gonna have to recode some things so this is a good test!
|
|
#
?
Feb 27, 2014 01:46
|
|
|
 Kind of boring I know. I'm just running 5 instances of x264/ffmpeg to see how much I can squeeze down ~5T of 4K-10bit footage. But look at all those squiggly lines!
|
|
#
?
Feb 27, 2014 21:27
|
|
|
Squiggly lines are great. But why don't you have any colors?
|
|
#
?
Feb 27, 2014 21:58
|
|
|
NFX posted:Squiggly lines are great. But why don't you have any colors? Oh I was just futzing around with the color.
|
|
#
?
Feb 27, 2014 22:05
|
|
|
 General text layout routines, speech bubbles with tails. The UI toolkit for my new game is comin' together. edit: And just in case anybody needs a variable-width pixel font, feel free to use mine: 
|
|
#
?
Feb 27, 2014 22:46
|
|
|
I got bored and thought "how hard could writing an interactive fiction engine be in Python?" and a day or two later I've got something basic working, more or less. Only supports a few verbs so far, LOOK, TAKE, DROP, PUT, USE, INVENTORY, N/S/W/E. 
|
|
#
?
Feb 28, 2014 07:08
|
|
|
I'm bored at work today: http://cloud.mecheye.net/Random/steam.html
|
|
#
?
Feb 28, 2014 21:17
|
|
|
 I'm cleaning up the code base for my PSN Windows Phone 8 client, Foulplay. While I was doing that, I figured I could take those libraries and make a Windows 8 version with it. The UI is no where near done, and I'm still working on my entities and managers, but it's getting there. Also, I know it's ugly. I'm a programmer, not a designer  .
|
|
#
?
Mar 2, 2014 17:56
|
|
|
Now, I realize that this doesn't look very exciting: ... but, it turns out that it is actually pretty important. The BeagleBone Black has two versions of the Linux kernel that it currently uses: 3.8 and 3.13. 3.8 is the one that has been around a while and is the one shipped on the BBB when you buy it. 3.13 is under development and only used by the folks on the cutting edge of the kernel development. 3.8 has flaky USB (especially when it comes to hotplugging USB devices) and lacks support for the SGX driver (for hardware-accelerated OpenGL ES). But, 3.8 supports the dynamic loading of device tree overlays. Overlay loading allows you to plug in interface cape boards and have the kernel find them and automatically load the proper drivers, mux the pins, etc. If you are doing custom interfacing, you can also load your own overlays from user space at runtime. For the majority of BBB users, dynamic overlay loading is far more important than the other issues, since you can plug in different LCDs and interface boards without having to rebuild the kernel over and over. 3.13 has solid USB and SGX support. It does not, however, have overlay loading. Want to use a particular cape board? Then you have to build the device tree with the exact configuration that you want to use. Developing custom hardware? Better get used to rebuilding your kernel over and over. This is the single major thing holding back 3.13 from becoming the mainline kernel for the BBB. As an extension of that, it is also the main thing keeping people from having easy access to OpenGL support. So where does that screenshot come in? I started looking at this problem to see how I might be able to move the overlay and capebus manager support from 3.8 to 3.13. That screenshot shows my preliminary port of the capebus and overlay running in the 3.13 kernel. It still doesn't work on the backend (pins aren't being muxed properly, though the proper kernel drivers in the overlay are being started), but it is properly querying the i2c EEPROMs on the cape boards and loading the proper device tree overlay fragments, which is pretty drat awesome. That screenshot shows that the i2c bus was examined, the four expansion cape EEPROMs were looked for (and not found), and the built-in eMMC and HDMI capes were discovered. This work involves hacking on three different kernel drivers: the AT24 EEPROM driver (drivers/misc/eeprom), the OpenFirmware device tree driver (drivers/of), and adding the Capebus manager driver (drivers/misc/cape). The i2c kernel interface has changed between 3.8 and 3.13, so there was some rework involved in the 3.8 capemgr driver code.
|
|
#
?
Mar 2, 2014 19:24
|
|
|
That's pretty cool. I've really got to set some time aside to build a 3.13 image, as I still have not got around to using the SGX drivers. I found it so frustrating that the clusterfuck surrounding the SGX drivers and device tree overlays was not handled in a better way by TI. It really hamstrings the platform getting traction. Anyway, I am glad to see that you're working on it.
|
|
#
?
Mar 2, 2014 20:50
|
|
|
Contains Acetone fucked around with this message at 17:35 on Jun 24, 2020 |
|
#
?
Mar 3, 2014 06:57
|
|
|
Internet Janitor posted:more fun variations. let me input music into that  hendersa posted:... but, it turns out that it is actually pretty important. The BeagleBone Black has two versions of the Linux kernel that it currently uses: 3.8 and 3.13. 3.8 is the one that has been around a while and is the one shipped on the BBB when you buy it. 3.13 is under development and only used by the folks on the cutting edge of the kernel development. 3.8 has flaky USB (especially when it comes to hotplugging USB devices) and lacks support for the SGX driver (for hardware-accelerated OpenGL ES). But, 3.8 supports the dynamic loading of device tree overlays. Overlay loading allows you to plug in interface cape boards and have the kernel find them and automatically load the proper drivers, mux the pins, etc. If you are doing custom interfacing, you can also load your own overlays from user space at runtime. For the majority of BBB users, dynamic overlay loading is far more important than the other issues, since you can plug in different LCDs and interface boards without having to rebuild the kernel over and over. 3.8 has CCF stuff in it, right? I'm working on some Zynq BSP stuff where I've found an unfortunate amount of things I have to reconcile between the original vendor kernel and the latest mainline, including renaming of various device-tree attributes, various architectural changes (like implementation(s) of CCF), etc. Rebuilding a device-tree isn't too bad though, you can just use dtc for it and then specify the appropriate file on the kernel bootargs; certainly not user-friendly though.
|
|
#
?
Mar 3, 2014 07:51
|
|
|
Contains Acetone posted:Playing around with the GalaxyZoo dataset that's up on Kaggle.com: ML features for galaxies look like electron shells. 
|
|
#
?
Mar 3, 2014 15:55
|
|
|
movax posted:3.8 has CCF stuff in it, right? I'm working on some Zynq BSP stuff where I've found an unfortunate amount of things I have to reconcile between the original vendor kernel and the latest mainline, including renaming of various device-tree attributes, various architectural changes (like implementation(s) of CCF), etc. The common clock stuff is in 3.8, which is actually one of the reasons that TI didn't add SGX support to that version. SGX was originally working in the 3.2 kernel (the one used for the original BeagleBone), and TI balked at porting it to 3.8 because of things like CCF. They made a decision internally to make the "next TI supported" kernel for the BBB be 3.12/3.13, so they ported the SGX stuff directly into those trees while making the needed i2c and CCF changes. 3.8 support was thrown in the ditch, and the community resources have been picking up the slack. Things should be much better once the whole platform moves to 3.13, since we'll have TI support behind us again. Device tree changes aren't too big of a deal if your platform is somewhat static. For the BBB, BeagleBoard.org wants to give users the option to plug whatever standard capes in that they like and they "just work", since BB.org's view on things is that a community that has a solid working example to start from is much more effective in bootstrapping new hobbyists that want to get their hands dirty with the platform. Getting your hands dirty with rebuilding new DTs with dtc isn't a big deal to someone experienced, but to someone who just wants their new $50 LCD cape to work, it is frustrating to mess with a lot of things he doesn't understand just to get something that is supposed to work to actually work. I still get many mails from people that are trying to get Android working on the BBB who get caught up on having bad HDMI cables, writing bzip2'd images to microSD cards without decompressing them first, etc. You have to realize that knowing how dtc works and being able to write device tree nodes really does put you up there in the top 1% in terms of technical know-how in the BBB community. I think that the Raspberry-Pi community really sucked up most of the Linux embedded hobbyist talent, so the BBB community is somewhat left in the lurch.
|
|
#
?
Mar 3, 2014 18:41
|
|
|
hendersa posted:The common clock stuff is in 3.8, which is actually one of the reasons that TI didn't add SGX support to that version. SGX was originally working in the 3.2 kernel (the one used for the original BeagleBone), and TI balked at porting it to 3.8 because of things like CCF. They made a decision internally to make the "next TI supported" kernel for the BBB be 3.12/3.13, so they ported the SGX stuff directly into those trees while making the needed i2c and CCF changes. 3.8 support was thrown in the ditch, and the community resources have been picking up the slack. Things should be much better once the whole platform moves to 3.13, since we'll have TI support behind us again. Ah, I feel your pain there w.r.t to 3.8 and jumping up to 3.12/3.13. I think a resource a lot of folks look over when doing kernel hacking is LWN; usually you can pull up the discussion and get some good insight into why design/architectural changes are being made, instead of being confused looking at LXR and wondering why certain files disappeared between versions, or certain structures changed. I forgot all about BeagleBone and the capes; that does kind of run in sharp contrast to device-tree, doesn't it? How exactly does your capebus-manager solve the problem? Do you define a generic entry in the device-tree that's the starting address of a given peripheral (that may or may not be present) and then the capebus manager does some more resource allocation work? I'm not super-familiar with the BBB, I keep forgetting it's not a Zynq/Cyclone V, and there aren't things hiding behind AXI ports; it's got a finite amount of peripherals with fixed I/O addresses. Contains Acetone posted:Playing around with the GalaxyZoo dataset that's up on Kaggle.com: This is pretty neat, have you played with doing stuff with asteroid zoo / processing to find asteroids from given datasets?
|
|
#
?
Mar 3, 2014 23:37
|
|
|
Contains Acetone fucked around with this message at 17:36 on Jun 24, 2020 |
|
#
?
Mar 4, 2014 03:45
|
|
|
movax posted:I forgot all about BeagleBone and the capes; that does kind of run in sharp contrast to device-tree, doesn't it? How exactly does your capebus-manager solve the problem? Do you define a generic entry in the device-tree that's the starting address of a given peripheral (that may or may not be present) and then the capebus manager does some more resource allocation work? Well, kinda sorta. The BeagleBone kernels have patches to the device tree code in the kernel to enable overlays. The general idea is that there are some aspects of the system that will remain static, but you want the flexibility to dynamically add new nodes to the DT at runtime. Examples of the static bits are the drivers used to control the built in hardware (say, the DA830 driver for the built-in RTC) and the locations of MMIO registers of the SoC. You configure these various pieces, mux the processor pins to handle these items, and then mark those pins as in-use ("off-limits"). In this regard the device tree is static. Overlays come in by allowing for additional nodes to be added to the device tree at runtime. The DT uses a hierarchical structure of nodes (it is a tree, after all), so it is a matter of locking the DT with a lock, pulling the tree out of memory and turning it back into nodes, inserting the new nodes, pushing the new tree back into memory, unlocking the tree, and then "starting" the new nodes. Unloading of overlays is implemented, but most drivers can't handle it, so it is rarely used. So really, detecting new capes loading their overlays from the filesystem (or from overlays statically compiled into the kernel), and then adding them into the DT is runtime patching of the DT. The overlays have a special marker symbol in them ("__overlay__") in each "fragment" that tells dtc to prepare the fragment to be added into the DT. Each fragment has a target specified in it to state where its nodes should be inserted into the DT ("target=<&dest_node>;"). As an example, the built-in HDMI cape's overlay contains four fragments: one that specifies pinmuxing, one that specifies the framebuffer driver, one that specifies the I2S audio format (between the SoC McASP and the HDMI framer chip), and one that specifies the ALSA driver for the HDMI framer chip audio. If the built-in HDMI is disabled, none of these nodes are added into the DT. If the cape is enabled, the Cape Manager will load the overlay for HDMI and dynamically patch the DT. 
|
|
#
?
Mar 4, 2014 17:04
|
|
|
I had a play and learnt a bit about the html5 canvas. For some reason I wanted to draw a Gameboy. It's been fairly tedious, but I'm enjoying myself. I'll probably keep going and work on all the little details, maybe animate the screen with something, who knows.
|
|
#
?
Mar 6, 2014 11:52
|
|
|
Are you just fiddling with canvas, or are you trying to build something? I'd do the Gameboy frame as SVG (SVG elements are easier to work with and can fire events) and the screen as canvas. That is, unless you're just learning canvas in which case that looks like a fun exercise. 
|
|
#
?
Mar 6, 2014 19:26
|
|
|
So... hacking on the Linux kernel. It can be a bit complex when you are digging through a subsystem that you didn't write, so I tried to do some static analysis on it to get the "big picture" of how the code works: Ick. The function call graphs that I generated are actually a big help, since they make it much clearer as to where additional functionality should "plug in" to the existing code. GraphViz is really helpful for this sort of thing, and I highly recommend it for your "quick and dirty" graph generation needs. I also just received a copy of the German translation of an article that I wrote on malware analysis:  I can only hope that that material makes more sense in German than it does in the original English.
|
|
#
?
Mar 6, 2014 19:58
|
|
|
glompix posted:Are you just fiddling with canvas, or are you trying to build something? I'd do the Gameboy frame as SVG (SVG elements are easier to work with and can fire events) and the screen as canvas. That is, unless you're just learning canvas in which case that looks like a fun exercise. I have no goal in mind, the sole purpose is to just play with canvas. Honestly, if I just wanted the end result (a vector image or something) I probably could do it in a tiny fraction of the time by drawing it in Inkscape. Hell, I'm not even sure why I'm learning canvas to be honest. I don't even know how it's going to be useful to me. It's not like it's Python or Bash, that knowledge basically solves all my problems. 
|
|
#
?
Mar 6, 2014 23:24
|
|
|
hendersa posted:So... hacking on the Linux kernel. It can be a bit complex when you are digging through a subsystem that you didn't write, so I tried to do some static analysis on it to get the "big picture" of how the code works: That is probably a better way than scribbling on a notepad whilst browsing through LXR. The OpenFirmware sub-system doesn't seem too bad though.
|
|
#
?
Mar 7, 2014 00:17
|
|
|
Xik posted:I have no goal in mind, the sole purpose is to just play with canvas. Honestly, if I just wanted the end result (a vector image or something) I probably could do it in a tiny fraction of the time by drawing it in Inkscape. Hell, I'm not even sure why I'm learning canvas to be honest. I don't even know how it's going to be useful to me. It's not like it's Python or Bash, that knowledge basically solves all my problems. "It's fun". Nothing wrong with that.
|
|
#
?
Mar 7, 2014 02:07
|
|
|
Now in pure CSS: http://cloud.mecheye.net/Random/gb.html Because it was fun.
|
|
#
?
Mar 7, 2014 03:02
|
|
|
Suspicious Dish posted:Now in pure CSS: http://cloud.mecheye.net/Random/gb.html Broken in Safari. Looks like display: inline-block isn't getting applied properly on the divs. 
|
|
#
?
Mar 7, 2014 22:53
|
|
|
|
| # ? May 26, 2024 13:21 |
|
|
Just needs the webkit prefix. EDIT: I was playing around with this for a little bit last night. 
Sinestro fucked around with this message at 23:01 on Mar 7, 2014 |
|
#
?
Mar 7, 2014 22:59
|
|
