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

phantomus

Members
  • Content count

    258
  • Joined

  • Last visited

Community Reputation

734 Good

About phantomus

  • Rank
    Member

Personal Information

  1. Hi all,   I just released an Android game written in C++ (using SDL2), named "Hatched!". It can be found here: https://play.google.com/store/apps/details?id=com.bik5.hatched   Here's a youtube:  [youtube]https://www.youtube.com/watch?v=sI1yMoj03LU[/youtube]   Hatched is loosely based on "Eggerland", and features ~50 puzzles, most of which are quite intricate, but always compact. The goal is to collect gems, and then reach the exit to the next room. Once the gems have been collected, various traps are activated, making a safe exit a matter of careful planning.   Any feedback would be greatly appreciated!   Jacco Bikker.
  2. Hi all,   I just released an Android game written in C++ (using SDL2), named "Hatched!". It can be found here: https://play.google.com/store/apps/details?id=com.bik5.hatched   Here's a youtube:  [youtube]https://www.youtube.com/watch?v=sI1yMoj03LU[/youtube]   Hatched is loosely based on "Eggerland", and features ~50 puzzles, most of which are quite intricate, but always compact. The goal is to collect gems, and then reach the exit to the next room. Once the gems have been collected, various traps are activated, making a safe exit a matter of careful planning.   Any feedback would be greatly appreciated!   Jacco Bikker.
  3. For those with fast GPUs, here's an executable that renders at full 1280x800 res, instead of the upsampled 640x400: https://mega.co.nz/#!ZwBjWChQ!cgoSi1I-7gLKkBooUHFgmQWClwMocl-qqQ8YeiR2vx8 Note that this requires the original package for the data. Also note that this still uses only one GPU; multi-GPU rendering has been disabled in the demo. Let me know how this runs on your machine. :)
  4.   OpenCL support is highly desirable, and should be available at some point in time. That, or a generic alternative. A CPU tracer is already available (not in the demo); it produces the same output, but a lot slower (it was not built with CPU performance in mind, but with a focus on maintainability).   The post processing (hit F3 in the demo, it's off by default) is just your typical image post processing. The lensflare is pretty accurate; it's based on recent work by Prof. Eisseman of the Delft university. It does a pretty close approximation of physically correct lens flares.
  5.   Filtering is being researched at the moment (not by me though); it is far from trivial in this context. Normally you would do something in screen space, but a path tracer typically doesn't have a single depth per pixel (which is needed to find geometry edges), so that is of limited use. The best solutions so far filter in 'path space' (considering the full set of paths arriving at the camera), but this is compute- and memory intensive.   I would expect filtering to bring a significant improvement to path tracing at some point in time, but right now, it is not yet sufficiently researched.
  6. Hi all,   I posted a demo of the new Arauna2 renderer on ompf2.com: http://ompf2.com/viewtopic.php?f=5&t=1887   A youtube of the demo can be found here: [youtube]http://www.youtube.com/watch?v=Znr1JJLI5uY[/youtube]   A higher quality version of the video can be downloaded as well (warning: large; 850Mb): https://mega.co.nz/#!pgJQUJ4Z!XaJIW0B_BMha39FIk8TsOk2CV2RTw5wRPEpDbrVeNBk   And finally, the demo, which requires a decent CUDA device and 64-bit windows: https://mega.co.nz/#!UphmTTxb!JAfhjCfDa3-zDo3Zy5gD9EArYxlkJKa10XPqZY8sZRs   Arauna2 is an interactive path tracer, which produces images using a random process. As a result, images contain noise, which will fade away as the pixel values approach the 'expected value'. Arauna2 has been optimized to produce decent quality images very quickly, and converges to high quality images in seconds. It is intended for architectural walkthroughs, but something involving games would be even more awesome. As you can see in the demo, we are not there yet, sadly.   I believe Arauna2 is currently the fastest path tracer, but that is of course strongly dependent on requirements. Main limitation is the fixed shading path, which supports the full Phong model, specular, dielectrics, textures, normal mapping and emissive surfaces, as well as every sensible combination of those. Illumination is provided using light emitting surfaces, meshes, point lights, spotlights (including IES profile support) and directional lights.   - Jacco.
  7.   Yeah, sad story I am afraid, tbp disappeared, but he left a vivid community. Sadly we couldn't even salvage the old board. It was such a unique place, with an awesome blend of academics and hobbyists (and people slowly making the transition, like myself). The new board is similar, but tbp was a far better board operator. I wish I knew where he is now, he disappeared.
  8. Hm, I see a lot of familiar stories. Mine, briefly: Got a zx-81 when I was 12, and overjoyed with it. Copied code from books and magazines, learned English that way. Then my grandpa bought me an MSX, which I really enjoyed; coded it on the assembler level. Got a game published as source code in a magazine when I was 16 or so. Then I got an Amiga, played games, no coding... Hated the thing. AMOS did work for me, but only slightly, because it was way too slow. Then I got a PC, and I used it like the MSX: Turbo Pascal with inline assembly, and finally sufficient performance for decent 3D (which I got interested in by a source in an MSX book that did some basic 3D). I spread my code using BBS'es, still no internet... After that: software rasterization, at a very decent level; maybe someone remembers the Alpha engine, and Focus. Then the GPU arrived, which I managed to evade, because I didn't like the 'canned polygons'.. When shaders arrived I got a bit more interested, but in the meantime I discovered ray tracing, and the impossible performance claims made by Ingo Wald (realtime!). After a few years, I got to that level, which was incredibly rewarding; I got there by reading tons and tons of papers. 6 years later, I got my PhD basically on the side, topic was real-time ray tracing for games. Very proud of that. In terms of education: none related; MSX time was books-only (from the library, mostly), PC time was books only too, plus some stuff from BBS'es. Then came the internet, which was amazing: I wrote the portal column for flipcode, and later a similar series on ray tracing. Obviously, I got tons back as well. After that I got my stuff from papers, which currently still is my main source of information. I did most of this in solitude, I think there was only one guy that really thaught me a few things (besides book authors, such as Michael Abrash). Times have changed though: you can now actually get a decent education in games and graphics, which at least allows you to be around people with similar interests. Even if you can't do such a course, you will still be able to meet those people online, which makes a lot of difference. On the other hand, the amount of material to soak up is just incredible, far more than when I started, and I can totally imagine that this is daunting, to say the least. When I got into this, at least it was possible to know 'everything' about graphics (getting close to Abrash, Wald, Fatmap and Fatmap II). Right now, you either pick a niche, or you become a generalist in a narrow field. Now I need to get back to adding spotlights to my path tracer. Graphics programming is such a joy!   - Jacco.
  9.   Oops, that should have been http://ompf2.com/blog.php . Also linked to from the main page.
  10. Hi all,   I am not sure how many of you know about this forum: http://ompf2.com It started as a replacement for the great ompf forum, which focuses on ray tracing, both from an academic point of view and more hobyist oriented. Obviously you are welcome to join this forum to stay updated on the latest and greatest advances in ray tracing, both real-time and off-line. Recently (as in: today ), we added a blog, which will provide daily (hopefully) news from ray tracing land. Url: http://ompf2.com/blog.php   Hope to see you there, - Jacco.   EDIT: fixed url to blog.
  11. An IOTD that I posted yesterday is now on the frontpage, but the image itself is broken (I'm on Chrome). Related to this: It took me an hour to post the IOTD. Based on earlier experiences, I copy-pasted the largest text portions prior to hitting 'preview' or 'save', because in Chrome, both buttons lead to disaster. I had to revert to IE to post, and even then, it took two attempts...
  12. Ah but that CPU doesn't even have SSE2... In that case you can't even compile Arauna yourself; it has tons of hand-written SSE2 code. Sorry about that. Then again, your CPU is ancient, you should be grateful it still works. ;)
  13. Arauna doesn't use a GPU at all. 800x800 @ 30fps would require (depending on the scene) a quadcore processor, ideally an i7. With one of those that performance level is not too hard to reach. Brigade does use the GPU, but it's a path tracer, so you can't speak in terms of fps, it's all about the number of samples per second you can produce. You basically balance resolution, noise and frame rate rather than just resolution and frame rate. Arauna on AMD: That's a problem, sorry about that. I believe the version that was posted here does work.
  14. Check this forum: http://ompf.org/forum . It's all about ray tracing, with an emphasis on real-time. Quite some ompf members lurk on GameDev too btw. Shameless plug: Check my real-time ray tracer, Arauna: http://igad.nhtv.nl/~bikker . The release of a real-time path tracer is imminent, two more weeks. Name is Brigade. Check it out on YouTube: http://www.youtube.com/watch?v=qC2zKIqttzk And here's a video of a game done with Arauna: http://www.youtube.com/watch?v=33yrCV25A14 Greets, Jacco.
  15. Hm, I'm not a C++ expert, so someone will probably correct me, but here we go: If you have only a small recursive function, then you are doing tons of function calls compared to the actual work load. A function call is not 'free': a stack frame is produced, parameters are put on the stack and retrieved inside the function again, and of course there is the jump and return. By creating your own stack, you guarantee that the code doesn't do anything beyond what you intended: you put only the code on the stack that you need, and some variables simply change iteratively (most notably, the current node pointer, in this case). And finally, a recursive function can't be inlined. Depends on the circumstances how bad this is, of course.