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

EVIL_ENT

Members
  • Content count

    49
  • Joined

  • Last visited

Community Reputation

276 Neutral

About EVIL_ENT

  • Rank
    Member
  1. The problem with using standard webcams for motion capturing is the huge latency (can also be seen in the video) which makes this mostly useless.
  2. I wrote you some code for that problem using quadratic Bézier curves: http://no.duckdns.org/curve/index.html <!DOCTYPE html> <html><head><meta charset="utf-8"><title>Curve</title></head><body> <canvas id="canvas" width="800" height="800" style="border:1px solid #000000;"></canvas> <script> var ax = 0; var ay = 100; var bx = 500; var by = 200; var cx = 300; var cy = 800; var radius = 200; var canvas = document.getElementById("canvas"); var context = canvas.getContext("2d"); function drawLine(ax, ay, bx, by){ context.beginPath(); context.moveTo(ax, ay); context.lineTo(bx, by); context.stroke(); } function drawCircle(x, y, r){ context.beginPath(); context.arc(x, y, r, 0, 2*Math.PI); context.stroke(); } function drawQuadraticBezierCurve(ax, ay, bx, by, cx, cy){ context.beginPath(); context.moveTo(ax, ay); var n = 100; for (var i = 1; i <= n; i++){ var t = i/n; var s = 1 - t; var x = ax*s*s + 2*bx*s*t + cx*t*t; var y = ay*s*s + 2*by*s*t + cy*t*t; context.lineTo(x, y); } context.stroke(); } function redraw(){ context.clearRect(0, 0, canvas.width, canvas.height); var bax = bx - ax; var bay = by - ay; var bcx = bx - cx; var bcy = by - cy; var ba = Math.sqrt(bax*bax + bay*bay); var bc = Math.sqrt(bcx*bcx + bcy*bcy); bax *= radius/ba; bay *= radius/ba; bcx *= radius/bc; bcy *= radius/bc; context.strokeStyle = "black"; drawLine(ax, ay, bx - bax, by - bay); drawLine(bx - bcx, by - bcy, cx, cy); drawCircle(bx, by, radius); context.strokeStyle = "green"; drawQuadraticBezierCurve(bx - bax, by - bay, bx, by, bx - bcx, by - bcy); } redraw(); window.onmousemove = function(e){ var dx = e.clientX - bx; var dy = e.clientY - by; radius = Math.sqrt(dx*dx + dy*dy); redraw(); } </script> </body></html> Just copy&paste into a *.txt file, rename it to *.html and open in your browser.
  3.   You did not say what you mean with "it". If you mean "How does the smoothstep function work?", the answer can be found on https://en.wikipedia.org/wiki/Smoothstep and https://www.opengl.org/sdk/docs/man/html/smoothstep.xhtml   Or you could create the color gradient with a painting program and load it as a texture. That would allow for more complex gradients with less math operations.
  4. The Samsung Galaxy Tab A seems to have a Qualcomm Adreno 306 GPU. In my experience, pixel fillrate is often the limiting factor, which according to https://gfxbench.com/device.jsp?D=Qualcomm+msm8916_32+%28Adreno+306%2C+development+board%29 is about 458 Mtexels/s or roughly 7.6 Mtexels per frame so it should be possible to touch each pixel about 9 times per frame with a simple fragment shader that does a texture lookup at a resolution of 1024x768 while running at 60 fps. But those are just theoretical numbers, so better benchmark it yourself to make sure they aren't off by too much.
  5. (I am assuming you mean trigonometric functions instead of goniometric functions)   Anyway, the correct answer is: Profile your code and test it yourself. My guess would be that the square root and one trigonometric function might be slightly faster, but I don't know which CPU you are using, so YMMV.   <insert obligatory rant about premature optimization here, blablabla>
  6.   Links are already dead and this post is just 2 days old.
  7. Font files often contain hand-drawn bitmap characters for small font sizes and vector characters for big font sizes. Libraries like FreeType will give you integer offsets and kerning values for those. Having multiple sizes of a font in a texture atlas will make it a little bit bigger, especially for huge fonts, which can be drawn with signed distance fields instead: http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
  8. I wrote a raytracer for a signed distance field of size 256x256x256 in CUDA that could run with 15-60 fps at a resolution of 1920x1080 on a Nvidia Geforce 840M (similar to a Geforce 8800 GTX in floating point performance) with raytraced shadow for one light source and simple phong shading. Terrain could be modified with union/intersect/difference operations in realtime. I used texture memory for that because this way I could use the GPU interpolation units for neighboring distance field voxels which resulted in smooth terrain and way more than 5 fps. So maybe in a few years fast GPUs will be common enough to render worlds this way, but for now I'd raytrace different data structures.
  9.   Floating point math is not associative, so a compiler that reorders instructions without a setting like -ffast-math is not very trustworthy. But anyway, I was recommending OpenCL or CUDA, not HLSL.
  10.   No, IEEE compliance does in fact guarantee "determinism" across different GPUs. See   ftp://ftp.openwatcom.org/pub/devel/docs/ieee-754.pdf   Section 4. Rounding:     Someone else with similar interpretation: http://stackoverflow.com/a/4319151       To quote myself:     As you can see, I was talking about graphics, not simulation, where e.g. one ulp of color difference "most likely" will not matter.
  11. Since you want the same results for sqrt on different GPUs, I assume that what you need this for is not directly related to graphics, since if it was, a small error would most likely not matter.   If that is the case, you should consider OpenCL or CUDA where you can enforce IEEE 754 floating point compliance on recent GPUs.
  12. I really dislike this form of presentation. Would you want to read a text book where you have to open every previous page if you want to read a random page? And you have to push a button for every sentence to appear?
  13. Nice advertisement. Now I really feel like contacting professional translators at ALCONOST who use the right tools during the translation stage and are native speakers in the language being tested. Also did you know that ALCONOST have nine years of experience and excellent translation quality and offer professional translation, localization, and linguistic testing in forty languages? ALCONOST ALCONOST ALCONOST [link link link].
  14. You could also switch the channels of the image in GIMP or Pohotoshop. Probably won't become faster than that.
  15. Here's another lag video. The delay between OS (CyanogenMod) and app seems to be less than in your video. http://www.youtube.com/watch?v=GCXpFMml1AI Code: https://dl.dropboxusercontent.com/u/54747914/share/MainActivity.java App: https://dl.dropboxusercontent.com/u/54747914/share/DelayTest.apk   You mentioned in your video that the second example would not have delay, but imho the black line is still way slower than your finger (and where did the touch position indicator go?). Also this app would be way easier to program with Canvas, because Paint supports antialiasing.   I can't check Stealh Bastard because I don't have the game, but it does not look very prone to delay.