• 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.

Anthony Serrano

Members
  • Content count

    479
  • Joined

  • Last visited

Community Reputation

3285 Excellent

About Anthony Serrano

  • Rank
    Member
  1. Twitter's "Photos" tab is exclusively still images. Videos, including animated gifs, appear under "Videos".
  2. The fundamental issue is just that real-world coloration doesn't work like that.   CMYK (and RGB, and most other color spaces for that matter) are perceptual abstractions - they take advantage of of the trichromatic nature of human color perception to reduce any perceivable color to a mixture of three primaries. But because of their fundamentally perception-based nature, they do a poor job of actually modelling the interactions of pigments and lights sources. But in reality, coloration is determined by a material's visible light absorption spectrum, which is a continuous spectrum across the entire range of visible light. The result of this is that there are many different absorption spectra that will produce the same visual color. And so two pigments that appear to be the same color can mix differently with other pigments. For example, you can produce a pale yellow pigment that mildly absorbs all blue light, and another that strongly absorbs certain frequencies of blue light, and even though the two look the same, they will produce different colors when mixed with other pigments (and the two pigments will also look different under colored lighting). tl;dr if you want to properly simulate color mixing you need to model a fuller representation of their absorption spectra.
  3. OpenGL

    Yes, you should. To go into a bit more detail on this.  In general when providing a recommendation to somebody who is just starting out learning 3D APIs and who also wishes to go fully cross-platform with their very first project, I advise: don't.  It's too much to deal with at one time; you're going to have your hands full learning a 3D API on a single platform as-is, without the additional complexity of wanting to be fully cross-platform too.  Focus on learning one thing at a time, learn it well, and build on previous knowledge for subsequent projects; save the cross-platform aspirations for the second or third project, in other words.     It's also worth mentioning that there's a lot more to being cross-platform than just using the right graphics API.
  4. This may come as a shock, but most modern games have even more input latency than you think, often around 100 ms (i.e. roughly 6 frames at 60 fps) owing to several factors including interpolation delay and swap chain length. Even fighting games, which generally have very precise, sometimes frame-specific timing mechanics, typically have at least 70 ms of latency.
  5. People aren't really THAT precise with their inputs. No one is even going to notice if a button hold is occasionally detected as lasting a frame too long or too short unless your target frame rate is too low to begin with. And if frames consistently take longer than expected, you have bigger problems to worry about than precise input timing.
  6. Surprising that no one yet has mentioned the biggest cost of interpolating between the previous and current states for rendering: it adds an extra update step worth of latency to the game, which when combined with the latency due to double- or triple-buffering, monitor latency, and input latency might not be acceptable to your players, especially if your update rate is low to begin with.
  7. OpenGL

    For what it's worth, basically any current "mid-range" GPU should have no trouble running a 360-esque game at 1080p 60 fps - even my 5-year-old mid-range GPU (a Radeon 7850) can do that.   After all, the previous-gen consoles are over a decade old at this point, and they weren't cutting-edge even when they came out.
  8.   I'd say the modern equivalent would be even higher, probably more like $150M to $200M - it was a huge team with a long development time even by the standards of the day, more like a Terminator 2 or a GTA V than you're average AAA game.
  9.     You mean Chrono Trigger?   No, that is nowhere near enough.  Looking it over, that game was about 2 years in development with about 70 people based on their credits. That's about 140 work years, or about $16M in salary.     You can probably hire someone to make an extremely simple game that follows the same style of Chrono Trigger. $20K will give you about 2 months of professional work, or about 5-10 months of amateur work. That won't get you very far, but it could make something that vaguely reminds you of Chrono Trigger.     Although it's worth mentioning that many of those developers weren't working on Chrono Trigger for the entirety of it's development - at least half the development team is credited on at least one other Square game that was in development at the same time, which includes Final Fantasy 6 (which has 35 shared credits with Chrono Trigger just by itself), Live A Live, Front Mission, and Seiken Densetsu 3.
  10. Well yes, there are some games from that era that used some of their tile RAM as a low-resolution, limited color-depth frame buffer which I left out for the sake of simplicity.   This includes games that just use it in a limited manner for special effects (like in The Legend of Zelda: A Link to the Past on the SNES, which renders the Triforce and maiden crystals at run-time using 3D models), as well as some that use it for main gameplay, like Zero Tolerance (Genesis) or Wolfenstein 3D (SNES). The latter type also often run at lower frame rates because the consoles don't have sufficient VRAM bandwidth to support that at 60 fps, assuming the CPU itself is not the bottleneck.
  11.   i'm coming up with 0.005109375 pix / frame^2   9.81 m/s^2 / 32  pix / m = 0.3065625 pix / sec^2   0.3065625 pix / sec^2 / 60 frames / sec = 0.005109375  pix / frame^2.   however, pix/sec^2 / FPS != pix / frame ^2 as i recall.  its not truly a linear relation as i recall. but linear is often an acceptable estimate.   pix/sec^2 / FPS = pix*frames/secs^3 ?  no, that's not right...  been too long since i did this stuff.   hmm, hitting intellectual thicket here,  anyone have a machete handy?   given an acceleration of A per sec, what the equivalent accel per 60th of a second? i think its an integration...      You've got math errors too. Dimensional analysis is your friend.   m/s2 divided by pix/m produces a result in m2/s2pix - division by x is equivalent to multiplication by 1/x, so (m/s2)/(pix/m) is equivalent to (m/s2)*(m/pix). You want to multiply acceleration in m/s2 by the pix/m conversion.   Similarly, pix/s2 divided by frames/s produces a result in pix/(s*frame), which needs to by divided by frames/s again to produce an acceleration in pix/frame2.
  12. You have a math error. 9.81 m/s2 at 32 pixels/m and 60 frames/s is 0.0872 pixels/frame2, not 5.232.   Pay attention to the units - acceleration is in units of distance over time squared, which means that if there is a time unit conversion you have to apply it twice.   Please note that there is a very good chance that you'll find this corrected gravity too "floaty" - there's a reason most 2D games actually use gravity significantly stronger than Earth's.
  13. The first thing to keep in mind is that most older consoles don't "render" graphics, which is to say that they don't have frame buffers that they write image data into before displaying it. Instead, they process graphics data based on the settings of the control registers to generate the video signal scan-line by scan-line in real time. This is why they have strict graphical limitations on things like the number of background layers or the number of sprites displayable on a single scan-line. However this also means that on these consoles, drawing time is basically irrelevant. (Some early consoles, like the Atari 2600, don't have any kind of video memory, and the graphics are controlled entirely by display register settings. Games on those systems have to constantly adjust those settings from scan-line to scan-line during the active display portion of the frame.)   The end result of this is that almost all games on pre-3D consoles run at the display's refresh rate (60 Hz in Japan/North America/Brazil, 50 Hz in Europe/Australia) - with slowdown if there's a lot to process - though there are exceptions.   In the console world, it's not until the rise of 3D (N64, PS1) that it becomes commonplace for games to not run at 60 Hz - starting with these consoles, render time is also a factor in frame rate. Many games, in the interest of graphical fidelity, start allocating larger chunks of time to rendering, and as a result most games run at 30 Hz or even 20 Hz (especially common on N64 games), dropping even lower under heavy graphical load. However there are exceptions here too. For example, F-Zero X on the N64 runs at 60 Hz - and note the visual sacrifices they had to make to maintain that frame rate - and almost all 2D games of that era, like Castlevania: Symphony of the Night, also run at 60 Hz.
  14.   This is the real answer right here. That is an integer divide, and putting it in parentheses causes it to be evaluated in full before evaluating the rest of the expression.   To get it to work as intended you need to remove the parentheses, turning int rowStart = mappedResource.RowPitch*(row/sizeof(float)); into int rowStart = mappedResource.RowPitch*row/sizeof(float);
  15.   Being shut down is the LEAST of the risks  - you face serious damage to your future. Worst-case scenario is a massive court judgement that may consume all your real-life assets, taint your credit rating, and cast a shadow over future job opportunities. Again, to be clear, having your game shut down is the BEST-case scenario.   And making it clear that you don't own the copyright doesn't help at all - that's a tacit admission of guilt re: copyright infringement that makes it EVEN HARDER to defend yourself in court.   Stay safe out there - under NO CIRCUMSTANCES should you make use of someone else's IP without explicit permission.