Jump to content
Double Fine Action Forums

Vincent Pelletier

DFA Backers
  • Content Count

  • Joined

  • Last visited

About Vincent Pelletier

  • Rank
    Double Action Newbie


  • URL
  1. The camera ! I forgot about checking each camera parameter ! Oooh, and there are those two values that are so far ignored for grim... And they have interesting values for the scenes & angles I mentioned. Wunderbar !
  2. I'm working (from time to time) on residualvm's lighting code (old school OpenGL fixed pipeline), and attenuation (or lack of it) is driving me crazy. Dear remastered edition developer, if you read me, could you give me a hand understanding what's going on in the original code (I'm only able to get software rendering to work with original game, FWIW) ? A few examples: In set "mo", there seems to be no attenuation. This is especially visible when talking with Meche. In set "do", there seems to be no attenuation for the spotlight. In set "tu", there is visible attenuation (very likely quadratic) for the spotlight. In set "al", there seems to be no attenuation for the spotlight. In set "ce", there is visible attenuation (very likely quadratic) for the omnidirectional light "newlight9", at zone entrance from blue casket elevator. How does the game decide to attenuate a light or not ? Is it applied to all lights in a given scene ? Regards, Vincent
  3. In a similar vein, the helicopter-style cloud fans seem wrong. Like, one 90° pair of blades are always in front, and the other pair always behind them.
  4. Would it be possible to get the "concatenated" experience when part 2 is out ? Like, an add-on to the first game, which fires up instead of first part's credits roll ? To keep the moving parts down between a stand-along install of part 2 (and reducing room for bugs), each part may have its own saves, and inventory may not been carried over from part 1 to part 2... It's about the feeling of continuing the story instead of having to look for where the second part is installed. The menu art may be even different based on the latest played episode (a bit like how HalfLife 2's menu background scene changes) if you plan to have different art for it (I think just slapping "2" somewhere in the menu is not the sexiest option, so you probably planned for different art). As for my feelings on the decision on splitting things up: I backed a DoubleFine story told with DoubleFine art. You can have it come out in 6 out-of-order episodes if you want (as long as Jar-Jar is in none of them). Heck, you can even have me buy half of them, I've already gotten more than my contribution's worth. I've paid for Psychonauts thrice already[1], so I could as well buy 3 different games/parts next time. [1] Once on steam to get the game. Once on Humble Bundle to get it DRM-free. Once more on Humble Bundle to get the DRM-free native Linux version. Please don't release a digital collector's edition. Wait, no, please do !
  5. My thoughts, too ! (...and already answered) Also: Yay for from-start GNU/Linux support announce. Please, take my money !
  6. Video: [Marius talking] Me: Hey, I understood that ! It's english ! Any fansub (even in english) ? Joking aside: the rest not impossible to understand, but working daily in english with co-workers natively speaking japanese, polish, portuguese, bulgarian, german, chinese and spanish co-workers (my mother language being french), I didn't expect to have to really concentrate to understand spoken (american) english.
  7. I, for one, don't give a damn about 64bits builds - although I use 64bit linux on many machines. I don't think spending time to get 64bits binaries has much value over using the same time to get, say, a few extra puzzles in the game. Or more polished 32bits version (one which doesn't crash in 4 years when some library decides to change some undocumented behaviour). If 32 bits environment is hard to set up, blame your distro. If you are so tight in disk space to care about the whopping 100MB-ballpark the 32bits counterpart of libraries take, you should probably consider moving to a new hard disk. There are really only two fields where 64bits becomes essential: high performances making good use of the extra registers, and high non-pointer memory usage (>2GB). I think DFA fits in neither (of course, it needs to run decently... but I can't imagine a 2d game really needing extra registers to make a difference). Take a look at Debian's popularity contest results: there are recently just as many i386 as amd64 submissions (first graph, "submissions per architecture", mind the logarithmic scale). Heck, I would even welcome using wine to run DFA, as long as it was written with wine compatibility in mind (OpenGL, checking if the game runs fine there) and maybe some fixes get contributed to wine. I would get a working DFA and better-working other windows apps. The only reason I see to not use wine would be from developer point of view: I'm not sure I would enjoy tracking down a crash when I have an extra layer to trace through. Native binaries + gdb + valgrind should be more debug-friendly (disclaimer: no developer-side experience in working with wine, although I use it often and contribute to it occasionally). What really matters for Linux as a market audience is that people decide to pay for something when Linux is a supported environment. This says nothing about how binaries look like nor their dependencies.
  8. +1 for M.C. Escher-esque world. Also, this. Thinking of the Guatemala occurrence (buildings getting sucked in the ground). But it might only be scary when it's real, seeing it in a game (or movie, etc) might have a lot less effect.
  9. Same here for SD, and a tiny bit of stuttering on fullscreen HD, but I attribute this to nouveau (libre driver for nvidia cards). Yay for HTML5 & Theora ! lover>
  10. Offtopic: Oooh, what do you work on? I'm an on-and-off contributor to Neverball and a few other bits and pieces. The projects I contribute to are mostly off-topic, besides a handful of commits to residualvm because I just needed to play Grim again and a WoW add-on (because written in lua). See my ohloh page if still interested (I see there are a few missing projects an not-linked aliases, I should update ohloh more often).
  11. Yes, depending on how much you care to do so. Easiest is to compile to byte code, though there are good Lua decompilers. You can then take that byte code and package it into a custom format or a zip, though that's more obfuscation. You can encrypt said package and hide the key somewhere in your executable, though a truly determined attacker could probably find that key with enough searching. I'm curious about the motivation to hide code... I know it's the case for grim and EMI (which also use lua), but I don't really get why it is so. In my understanding, it describes the storyline and interactions with it - which looks trivial enough to not be in the "trade secret" ballpark. Also, still in my understanding, it should not contain anything of value to another project (different puzzle, story line, ...). It's certainly more like in the "spoiler" ballpark, but then people poking in game resources should not be afraid of them. Disclaimer: working full-time on free (libre) software, without such level of engine/script distinction.
  12. Woops, looks like my post wasn't in the right place, and got overlooked:
  • Create New...