Apple Keyboard Firmware Hack Demonstrated
If I'm not mistaken, doesn't USB have a way for devices to access the host's memory via DMA? If so, does that mean it's possible for a 'hacked' keyboard to use DMA to write an exploit into the host machine's memory?
How To Build a Homebrew PS3 Cluster Supercomputer
Why would you want to use PS3s for a homebrew supercomputing cluster if it means you have to write and optimize code for the SPEs to get benefit out of it? The PS3's linux environment doesn't let you utilize the GPU or all of the built-in SPEs and it doesn't have a lot of RAM available either. It seems like it would be cheaper to build a cluster out of commodity PC parts, and maybe use GPUs+CUDA to get more muscle without having to completely hand-roll your own accelerated computation code (since CUDA is roughly C). I can't imagine that the PS3 would end up cheaper for these purposes, considering it includes a Blu-Ray player along with a bunch of other things you're not going to be using.
DirectX Architect — Consoles as We Know Them Are Gone
That's interesting, but this article is about someone who doesn't work for Microsoft anymore, and hates Intel graphics chips for the same reason any other game developer hates them: They're utter garbage.
I'll enumerate the primary reasons quickly, since I don't expect you to be intimately familiar with the relationship between graphics programmers and graphics driver developers (it's drastically different from Intel's relationship with the X developers):
1) Intel graphics drivers are possibly the most inconsistent drivers on the market. Any given user with a particular Intel chipset might have one of a hundred different driver configurations, as a result of the fact that the chips are bundled with different motherboards which then come with their own driver package... and when you add pre-built machine vendors into the mix the situation is only worse. If their driver quality was extremely high across the board, this wouldn't be an issue, but...
2) Intel graphics drivers have a bad stability track record, at least on Windows. They have a tendency to return invalid/nonsensical error codes from driver calls that shouldn't be able to fail, or to silently fail out inside a driver call instead of returning the error code they're supposed to... resulting in graphics programmers having to special-case handling of individual Intel graphics chipsets (and even driver revisions). In my case, I ended up just having to shut off entire blocks of my hardware-accelerated pipeline on Intel chipsets and replace them with custom software implementations to avoid the incredible hassle involved in coming up with specific fixes. (The wide variety of chipsets and drivers out there meant that for my particular project - an indie game - it was impossible to ensure that I had worked around every bug a user was likely to hit, so I had to just opt out of hardware accel in problem areas entirely).
3) Intel graphics chipsets have sub-par performance across the board, despite marketing claims otherwise. This is mostly problematic for people developing 'cutting-edge' games software, where it creates a 'he-said-she-said' situation with a game developer/publisher claiming that a user's video chipset is insufficient to run a game while Intel claims the complete opposite. (in most cases, Intel is lying.) This is particularly troublesome in areas like support for cutting-edge shader technology, where an Intel chipset may 'support' a feature like Pixel Shader Model 3.0 but implement it in such a way to make it completely unusable. Users don't benefit from this, and neither do developers.
4) Intel graphics chipsets harm the add-on graphics market by discouraging users from picking up a (significantly better) bargain video card from NVidia/ATI for $50 and dropping it into their machine. This hurts everyone because even though that bargain card is significantly better (and most likely more reliable), the user already 'paid' for the integrated chipset on their motherboard, and the documentation that comes with it attempts to make them believe that they don't need a video card. I consider this a dramatic step backward compared to the situation years ago, when integrated graphics chipsets were unheard of and people instead had the option of 'bargain 2d' video cards like Trident or Matrox that would do everything needed for desktop 2D, but also had the option of fairly affordable 3D accelerator cards if they wanted to play games occasionally.
On the bright side, most integrated ATI/NVidia GPUs these days are mature enough to be able to run games acceptably and meet the needs of a typical user. The only thing really holding the market back here, in my opinion, is Intel's insistence on marketing inferior products instead of partnering with ATI or NVidia to please their customers.
Of course, this is unrelated to your point that their Linux/Free Software support is superb, as is their documentation - I'm inclined to agree with you here, but it unfortunately doesn't do much to outweigh their other grievous sins.
JanusFury hasn't submitted any stories.
Good stuff is happening, the file code is pretty much 90% done, and working excellently. I managed to create a complete game in about 4 hours from start to finish, using Fury - you can download it here:
I'm still improving it, but it's already quite fun to play. :)
Of course it's not an RPG, but I'm getting closer and closer to the point where I can make a full-fledged RPG...
File Format Stuff
The new file format code is going well, almost done actually. :) This means better compatibility between versions, and sprites actually being saved with maps. Rejoice!
HAHE ROBBLE ROBBLE XD
I'm so horrible, look at my karma! Almost every post I make here stays at 0 or -1. Oh well. :)
Anyway, Fury2 is still going well... Lots of touchups done to various parts of the engine, latest binary in the usual place.
Still working on the file code, mainly.
Made lots of improvements to the engine, and more on the way. The menu system code is really shaping up, and I added window skin support to the message box and menu components.
I also made some tweaks to the GFX library to improve stability, and added a TileBlit function to do a tiled blit. Good for backgrounds.
I also uploaded a new tech demo, "Windmill", that shows off a number of newer features like parallax scrolling, prerendered layers, and the menu system.
You can grab the latest binary here, and the Windmill demo here.
More Bugs Fixed...
I really don't know where all these bugs are coming from.
Found some more bugs in my old code - a bunch of my other old GDI stuff stopped working, so I rewrote it. Also fixed a bug in the parallax map rendering stuff - no more crashes when the camera scrolls to the top or left of a map ;)
Also, I implemented virtual file support in the rest of the engine objects. Most of them don't save anything, but i'll fix that later ;)
Get the latest binary here.
Heh... somehow I broke my PNG loader. :) No more PNGs until I fix it - The beta will probably crash if you load PNGs. (That includes the sample game).
Edit: Just fixed it, I had to make a small fix in Fury2GE.dll. Turned out to be a bug in my GDI image loader. :) If you downloaded the binary before now, just download it again. :)
Grab the new full binary here.
Recent changes (Or at least the ones I remember):
New VirtualFile class added. (Create them with the F2File function.)
Added VirtualFile load/save support to Sprite and Tileset classes.
Lots of bugfixes. (Still didn't fix the random parallax crash though, working on that one)
Hue Shift filter added to GFX library.
Sprite Scaling added. (Sprite.ScaleLevel)
Sprite Blocking Scaling added (Engine.ScaleBlocking)