• Advertisement

Anthony Serrano

Member
  • Content count

    479
  • Joined

  • Last visited

Community Reputation

3285 Excellent

About Anthony Serrano

  • Rank
    Member
  1. Am i blacklisted on ScreenShotSaturday?

    Twitter's "Photos" tab is exclusively still images. Videos, including animated gifs, appear under "Videos".
  2. cmyk vs real world paint mixing

    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 Cross Platform Graphics APIs

    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. Avoid game state interpolation with fixed time step

    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 Can someone recommend a good "Mid Range" hardware?

    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. Cost of Game Making

      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. Cost of Game Making

        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. The tick rate of old console games

    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 tick rate of old console games

    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. Reading from a floating point texture resource

      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. Question and Tips on creating a game

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