jjd

Members
  • Content count

    1023
  • Joined

  • Last visited

Community Reputation

2140 Excellent

1 Follower

About jjd

  • Rank
    Crossbones+
  1. On Software Patents

    If you want to put it out there for everyone to use, opensource it. A patent is intended to allow someone to publish a novel invention without loosing the opportunity to profit from it. This is in contrast to a trade secret. It does not sound like that is what you want to do.   Talking with a lawyer is a good idea. Understand the options. It sounds like you own the business. Many small companies with IP with patent because it provides legal protection. It is also an asset that makes the company more valuable. It can be used as a bargaining chip during negotiations. I am sure that there are many other legal reasons why patenting something is desirable so best to get an expert opinion.
  2. grepr - 7DFPS 2014

    Very cool! But no download for linux? Really? I am shell shocked ;)
  3. Shooting At Stuff

    In the case when there are two solutions it should be the lowest *positive* value.
  4. Installer for Linux?

    Lets reach a compromise here, /opt ?     Or /usr/local   -Josh
  5. Names for a "Death Star"

    It may not quite fit with what you have in mind, but I have always liked the names that Ian Banks used for ships in the Culture series. Even if they don't quite fit, I am sure you can get some inspriation from them   -Josh
  6. Unique Style of Flow Control

      http://bytes.com/topic/c/answers/219859-do-while-0-macro-substitutions   I think the key reply in that conversation, is     Regarding the while(true){...break} thing, I pretty much agree with what everyone else here has said. It is essentially a poor-mans try-catch block. If you can't use exceptions and you have a lot of shared state (making the encapsulation of the failure prone code into functions undesirable), a structured goto can be a clean way of handling and cleaning up from a failure. I have mostly seen that in the context of hardward initialization (so often it is C anyway). However, I would default to exceptions and encapsulation (functions or classes where appropriate) when working in C++.   -Josh
  7. bbox.js

    Hi, This weekend I had an itch that I needed to scratch. I have sporadically been working on a project that uses SVG and javascript. I kept coming up against two problems: (1) getting a reliable bounding box around an SVG path, and (2) being able to properly align SVG paths with one another. There are other solutions to finding the bounding box of an SVG path. Popular solutions are using the functionality of the SVG API itself, or using the awesome RaphaelJS library. The SVG API is not pleasant to work with and, from what I understand, focuses more on operating at the level of the SVG node itself (what I would consider the root of the scene graph). I am more interested in working with the paths and composing objects from sets of paths. So, for the bounding information this is a little awkward, but it is really the alignment information that is unavailable. In particular, when you have an anchor point on a shape that is not in the middle or at the edges, it gets fiddly. I don't like fiddly. Especially, when I am working with things like Bezier curves that are really quite nice to work with. The information about the inflection points is really useful for what I am doing. RaphaeJS is an awesome library but sometimes you just want to a solution to one particular problem. Since I was not intending to use RaphaelJS for anything else, just importing it to calculate a bounding box seemed wasteful. And finally, I just wanted to solve it! :-) I love this kind of problem so I had a hard time not doing it. The code is free and open and I hope some of you reading this may find it useful. https://github.com/jdowner/bbox.js -Josh
  8. Matrix Inversion using LU Decomposition

      There is a simple, stand-alone implementation in Bullet, which is free for commercial use.   -Josh
  9. Unreal supports Linux

    I was just sharing my experience with you, offering an explanation as to why companies like Epic don't bother with Linux tools: Every console developer I've worked for has used Windows development environments -- even when they're making games for PlayStation or Linux. Then, because all the big commercial game developers use Windows, Epic has no pressure on them to provide a Linux version.   It's catch-22 - everyone develops on Windows, so no one is asking for Linux development tools, so no-one develops on linux, so no one asks for linux tools, so... [[and by 'everyone', I mean console game developers -- obviously yes Linux has many developer-users in other fields]] The thing is, it's not just Epic either -- even if they started providing Linux support (which indies would use), the console guys are still stuck on Windows until Sony, Microsoft, Nintendo, Adobe, Autodesk, etc, etc, etc all also make the change. Unfortunately, the Windows environment has a damn lot of momentum.   On the gaming consumer side: Hopefully SteamOS isn't really that different from other Linux distros, so that SteamOS-compatible games would run on Ubuntu, etc.     I agree. And part of the reason is that even though you may end up doing some work on linux you are almost certainly going to be doing a lot of work on windows too. You are not going to want to have retool for each project you do. I think it is similar to the whole 'why do people keep making games with c++?!?!?!!' Well, it makes sense when most of the toolchain and libraries being used support that technology. Can it change? Of course, and it is. I think it is similar with linux.   Over the years I have moved to exclusively working on linux. I would love to get some lovin from the game industry :) And it is nice to see things moving in that direction, but I do not expect it to happen rapidly for all of the reason Hodgman mentions above.   And, somewhat tangentially, I was blown away by the open sourcing that microsoft has been doing recently. Kudos. Who knows, maybe I will move back to windows one day :)   -Josh
  10. It happens an awful lot more than you might expect. Defensive coding is important, and it often comes at a perceived cost to readability.   I'd honestly be rather alarmed to meet a senior engineer who didn't write their conditions that way, when coding in C++.     And, as with a lot of coding practices, it probably varies depending on the kind of company you keep. I predominantly come across this particular convention from engineers who like to follow simple rules but cannot think about the implications of their design decisions or create a decent interface to save their lives. Do I think this is true of all engineers who follow this rule, no. But I do find it hard to shake the weight of evidence I have come across :)   -Josh