Jump to content
  • Advertisement

capn_midnight

Member
  • Content count

    15309
  • Joined

  • Last visited

Community Reputation

1708 Excellent

About capn_midnight

  • Rank
    GDNet+

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Recognize these faces as my tweeps, but the BGs have been changed. Also, I think they screwed up their targeting. https://t.co/qDRDQsptHO
  2. My wife watches this show "Once Upon a Time". I find the only relatable characters are the recurring villains.
  3. This database app vendor I have to deal with doesn't provide a public API. Or so they think. They forgot about SendInput.
  4. RT @JulianHiggins: The eternal civil war - procrastination vs. motivation. https://t.co/LWncuQnSQq
  5. I had forgotten how pedantic Java was. I had gotten to live--for a short while--in blissful ignorance, that which is so rarely recapturable.
  6. In this video, I demonstrate using the Primrose text editor to live-edit the world around me. [color=rgb(0,0,238)][/color]
  7. If you'd like to see the (kind of crappy) video of me #livecoding #WebVR #VR #WebGL #JavaScript you can get it here: https://t.co/Ybze6FAPrb
  8. capn_midnight

    The Good, The Bad and The WebGL-y

    >> ThreeJS caught my attention because it allowed games to be built directly into a browser with no need for plugins. While great in theory, there was a huge learning curve and 3JS, in its current state, is the toy of elite coders and is pretty much inaccessible for someone wanting to implement simple WebGL into their current online presence.    I forget sometimes how far I've come.   In terms of libraries, Three.JS helps you *avoid* having to write a lot of particularly difficult code. It has a very useful scene graph implementation, and really does some great work for turning WebGL's procedural madness into a much more manageable object-oriented style. For the most part, the design is very straight forward and consistent, though admitted the documentation is lacking, or worse, in some cases it's out of date.   I personally find using something like Unity more difficult than using Three.JS. When it comes to using a GUI system to design a game, I'm a noob. But I've been programming for over 15 years.
  9. capn_midnight

    VR Lessons Learned So Far

    @jefferytitan: I don't think the 75fps framerate target that Carmack talks about is strictly necessary, but it definitely needs to be at least 60fps. But what is surprising is that scenes don't need to be extremely detailed to achieve presence. I would say it's better to achieve high framerate than to achieve high polygon count, high res textures, etc. We used to play 3D games that were nothing more than billboarded sprites and were fine with it. Something like that would still work in VR, as long as the framerate and interactions were smooth.    On avatars, I've been using a model of a fat, cartoon bear that I threw together with a simple running animation. The arms are not rigged to my Leap Motion yet, but you mostly can't see the arms. Having a body and feet to see, though, has been nice. I like it, at least. YMMV.   However, with the Leap, I've noticed that it absolutely *is* necessary to have a fully rigged hand model. Simple spheres for each of the knuckles works fine, but a single sphere for the entire hand is not good enough. However, I'm having some network performance issues with the Smartphone HMD sync in Psychologist.js, so I might have to degrade the visual in that case (i.e. transmit only the hand's location and not all of the individual finger joints).   But without direct, kinematic sync with body motion, it's best to show nothing. I've found any sort of user-oriented movement that was not triggered by the user's actual movement to be the most likely to cause motion sickness. This is where I refer to presence being a double-edged sword. If you haven't achieved presence, the user (or rather, me) still feels like they are looking at a screen and non-didactic movement isn't disorienting. When you get the user feeling like they are in the scene, they need to be in complete control of what is attributed to them.   So in short, if you do use some sort of fake hand model, I'd try to keep it abstract. Show the model of the tool held in the hand but do not show the hand itself, and keep movement to a minimum.      @cozzie: I have the Samsung Galaxy Note 3 for doing the Smartphone-style HMDs, and a cardboard box that I built myself for holding it, with a strap I cribbed from a pair if head-wearable magnifying lenses (but not the lenses, I bought lenses specifically on Amazon.com). It's not Google Cardboard, because Google Cardboard was announced the day I ordered the lenses.   I also just acquired an Oculus Rift DK2. I spent a little time last night and most of this morning getting it to work with Psychologist.js (okay, I officially hate that name now, it's too long). It's up and running now, but requires specially development builds of Chromium or Firefox. 
  10. I've written a little bit about this project for a little while, and I've finally decided on a name. Psychologist.js is a framework for rapidly prototyping virtual reality applications using standard HTML5 technologies. It keeps you sane while bending your mind. You can view a demo of the framework in action here. You can access the repository on Github here. Features: Google Cardboard compatible: use your smartphone as a head-mounted display, Multiplayer: share the experience and collaborate in cyberspace, Leap Motion support: control objects with natural movement, Game pad support: create fast-action games, Speech recognition: hands free interactions, Peer-2-peer input sharing: use devices connected to your PC with your Google Cardboard, 3D Audio: create fully immersive environments, App Cache support: save bandwidth, Blender-based workflow: no proprietary tools to learn, Cross-platform: works in Mozilla Firefox and Google Chrome on Windows, Linux, and Android, Oculus Rift support (coming soon): the cutting edge of head-mounted display technology.
  11. capn_midnight

    HTML5 audio for games made easy

    You're welcome!
  12. capn_midnight

    HTML5 audio for games made easy

    Very nice, but you shouldn't use <progress> elements like that. You should be using <meter>.
  13. capn_midnight

    HTML5 audio for games made easy

    That's a good idea. And yes, with Web Audio, it shouldn't be difficult.   My goal with this was to just get a bare minimum of useful audio together. The Web Audio API is extensive, but for throwing together quick demos, 80% of it is unnecessary. This JS file is for that 20% use case, wherein the <audio> tag is completely useless.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!