• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

legends2k

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

473 Neutral

About legends2k

  • Rank
    Newbie
  1.   Do you really understand the difference between a book and a presentation? That too, an interactive one and why it relates well with transforms? If you'd looked carefully, pressing O while in the presentation gives you the option of seeking randomly too.   Constructive comments, as the site recommends, are much better than rants; try giving objective suggestions upon which we can work together to make the article better.
  2. The shadow itself should be drawn with a circle and not a square. Not only will it be more realistic, it'll also be easier to code this up. Now for the placement:   The two extremes from which the scene can be viewed are Top view i.e. the path of revolution is a perfect circle Front view i.e. the path of revolution is a horizontal straight line If you get the shadow for these two angles right, then the remaining, intermediate angle views may be obtained by interpolating between these extremes. For the top view, the shadow circle will always be on the "far" side of the planet, quite simple. The front view, however, isn't as simple. The planet will be in the horizontal line's midpoint twice, once the shadow circle should be completely invisible (or rather behind the planet), while the other time it should obscure the planet altogether. When it hits the endpoints of the line, it'll be the same as the top view. This will mean changing the z-order of the rendering based on the planet's to or fro movement. While it's doing the first half of the circle, arc1, shadow should be drawn first and when in arc2, the shadow should be drawn second.   Hope these pointers help.
  3. A presentation/tutorial on 2D transforms for programmers and practitioners favouring intuition over mathematical rigour; animations are used to illustrate the effect of every transform explained. Click Here to view presentation. Firefox, Chrome or Opera recommended as they support animations; see Requirements below for details. Press ? while in the presentation for controls and Esc for an overview and quick navigation. Comments and suggestions are welcome. Overview Transformations are a general mathematical concept that is applicable to anyone working in: Computer Graphics Animation Game Programming (2D and 3D) Image Processing Motion Capture UI Design Computer Vision Robotics Aeronautics Parallel Computing Concepts discussed are dimension-indepedant; it's just easier to explain and visualize things in 2D but they're applicable to higher dimensions without loss of generality. Instead of dealing with only elementary transforms (rotate, scale, translate) on points, which most resources do, it also covers: Basic math behind transforms (without matrices) Matrix introduced past the basics since it's just a tool Composite transforms -- concatenation of multiple transforms Anti-commutativity Transforms about an arbitrary origin Active and passive viewpoints of transforms Transformation of coordinate systems Mapping between multiple coordinate systems Hierarchical Transforms Requirements The presentation was hand-crafted using HTML5, CSS3, JavaScript and SVG; so nothing more than a browser is required to view the presentation. Firefox, Chrome or Opera, even if you've an older version, is highly recommended since support for SVG animations isn't that great in other browsers; with browsers like Safari, Edge or IE you will not be able to see these animations -- caveat lector. You can also view the presentation on a mobile or a tablet; the content, without any loss of fidelity, should get resized and fit to given form factor, thanks to vector graphics and CSS3. Touch (tap and swipe left/right) is supported both for navigation and animation control. Animations Transformations are better understood visually than with just dry theory. Hence every transformation workout is accompanied, along with the math, by an animation. Images with a graph sheet background contain animations. Simply click on such an image to cycle through the animation. Every click changes the image's state, animating it into a new figure. When you see the original figure you started with, it denotes the end of all the animation the image contains. If you're using a keyboard to navigate the presentation, clicking the image steals focus from the presentation and sets in on to the image; simply click anywhere outside the image to give the focus back to the presentation. Now press space / -> to continue with the presentation. Solution The solution to problem of mapping the boy space to street space that is posed at the end of the presentation is in map_boy_to_street.md. SVG The demonstrations/interactive animations embedded within the presentation was done in SVG, the XML-based, open standard file format for vector graphics with support for animation. In English, all it has are just instructions like move to, line to, rect, circle, ellipse, etc. in a very readable, XML format and no unintelligible binary data. So a reader (yes, a human one too) can easily read and understand it; a renderer can render it at any resolution without any loss in fidelity. The presentation's first slide has a 3D-transformed background which too is an SVG -- it should show up as something similar to this; a simple check to see how well your browser supports SVGs and CSS3 transforms. It's highly recommended that you fiddle with the SVGs under images directory. SVG format is very similar to PostScript (which also has commands like move to, line to, etc.) and is an excellent Hello World test bed (Short, Self Contained, Correct, Example) for learning transformations or 2D graphics in general. Oh they also have a tag for groupings which may be used to learn hierarchical transformations. An SVG is only more readable than a PS, PDF or XAML. Just open it in a (modern) browser to view it (no, not Edge, it doesn't do 3D CSS3 transforms in SVGs yet :), open it in your favourite text editor, muck around, save and refresh your browser to see the changes immediately; rinse and repeat. Credits Computer Graphics using OpenGL, Francis Hill and Stephen Kelley 3-D Computer Graphics, Samuel R. Buss Essential Math for Games and Interactive Applications, James Van Verth and Lars Bishop 3D Math Primer, Fletcher Dunn and Ian Parberry reveal.js, the presentation framework, generously shared under the MIT licence by Hakim El Hattab MathJax for rendering beautiful math equations on any browser, American Mathematical Society Elementary affine transforms chart shared under CC 3.0, used as first slide background, CM Lee What is or isn't a linear transform, shared under CC 3.0, Ldo Reveal.js on Github pages, Vasko Zdravevski
  4.   I second that.   If you want a slightly more approachable (funny/intuitive) alternative, I suggest: 3D Math Primer by Fletcher Dunn and Ian Parberry   If you want something reference style, more rigorous (harder) with wider array of topics covered, I suggest: Mathematics for 3D Game Programming and Computer Graphics by Eric Leyngel   I've read all three books. Each one is very good in treating some topic or the other. All are excellent in their own right.
  5. An older Wayback machine snapshot had the images. I rsync'd the complete tutorial (12 parts with text and images); made an offline archive stripping off irrelevant parts.   The last two parts has sample code that could be downloaded but I couldn't recover them. Asked the author, he too didn't have backups, but for all the other parts the code is part of the tutorial/image, no a separate downloads, so it isn't much we're missing.   The download link, with the author's permission.
  6. Oh good, because this is exactly what I was thinking when I revisited cross product definition; although handedness decides the direction of the resultant of the cross when it boils down to math, the formulas don't change, numbers are still numbers, the resulting numbers would be the same; it's humans who interpret it based on the coordinate system handedness based on our liking. Yeah, in the reference of one system, when a new one is introduced via mirroring then this test would help. Thanks!
  7. I'm now clear of the part that a model/asset by itself isn't explicitly left or right handed while to see it exactly the way its creator expected it to be seen, we need to interpret in that system. However, I'm reading "Essential Mathematics for Game Programmers", in which there is a statement which goes, "when we've three basis vectors i, j and k, performing scalar triple product like (i x j) . k > 0 then it is right handed while if it's negative it's left handed". What confuses me is, I took 3 vectors say 1i, 3j, 4k and drew them both in a left and right handed system, perform the aforementioned scalar triple product, I always get 12, which is positive, when would this be negative to show that the basis is left handed?
  8.   Agreed. My point is how do you differentiate a LHS model and RHS model, what exactly is different between the two? The reason I'm not able to differentiate is that both models will've just numbers; say in a triangle of vertices v0 (0, 0, 0), v1 (0, 0, 1), v2 (1, 0, 1) where's the handedness encoded/lurking?   Similarly, given three vectors say i (1, 0, 0), j (0, 1, 0), k (0, 0, 1), how do you know if it's left or right handed. In my first post, I'd quoted       But then with the above vectors, considering them as either left or right both pass the test. Then how do I differentiate?