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

Lichtso

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

118 Neutral

About Lichtso

  • Rank
    Member

Personal Information

  1. Thanks,   well it supports collada for 3D models (which I usually export from Blender). I forgot to mention the formats. I added them in the first post.   You can make a terrain using a array of ascii numbers or a gray scale image as heightmap. The documentation is unfinished but you can take a look at the "Resources" folder that is delivered with the download and contains some examples.
  2. Oh, jup fixed that. Sometimes the server infrastructure crashes and I don't know why (yet).   Also I'm not quite sure if the ubuntu package works as I never tested it on another computer. Would be nice when someone would verify it.
  3. Hi,   as some of you might already know I've been developing a game engine for the last two years. Today I decided to open the beta phase so that the world could take a look and give me some advise and tips.   Platforms: Mac OS 10.8+ Ubuntu 12.04 Windows 7+ Programming language: C++ 11 Languages: English, German Licence: WIP, but I plan to write a free to use (also for commercial use) closed source license   Using libraries: Bullet Physics 2.91 WebKit JSC for scripting in JS / ECMA-Script OpenGL 3.2 OpenAL and Vorbis / Ogg SDL2 Formats: Images / Textures: Png, Jpeg, WebP Audio: Ogg 3D-Models: Collada (.dae) Terrain: float array or image as heightmap Objects and scene: Xml Features: Deferred lighting Dynamic shadows and reflections: Mirrors and water Glass refraction Material mapping Bump-, normal- and parallax occlusion mapping Animation of terrain, particles, textures and skeletons is possible Full user interactive physics and scriptable world Post effect shaders: Edge smooth / antialiasing Depth of field / fog Screen space ambient occlusion Links: Download Trailer I and Trailer II WIP documentation: On Github     All comments are welcome!
  4. Mathematically you are correct, but the terminology is wrong. There is a difference between Bézier curves and B-splines (both 2D). And their higher dimensional counterparts Bézier surfaces and NURBS (both 3D). A B-spline is made of multiple weighted bezier curves, broadly speaking.   But the equations you have there seem like they belong to a Bézier surface not a B-Spline surface (or NURBS). Their derivatives can be calculated with different approaches. I think using De Casteljau's algorithm is a easy one. For example, exactly calculating the derivative in the direction of u: float s = 1.0-u, t = 1.0-v; Vector3 points[4]; for(unsigned int i = 0; i < 4; i ++) { unsigned int i4 = i+4, i8 = i+8; Vector3 a = controlPoints[i ]*t+controlPoints[i4]*v, b = controlPoints[i4]*t+controlPoints[i8]*v, c = controlPoints[i8]*t+controlPoints[i+12]*v, d = a*v+b*t, e = b*v+c*t; points[i] = d*v+e*t; } points[0] = points[0]*s+points[1]*u; points[1] = points[1]*s+points[2]*u; points[2] = points[2]*s+points[3]*u; points[0] = points[0]*s+points[1]*u; points[1] = points[1]*s+points[2]*u; return (points[1]-points[0])*3; for the other derivative you would have to swap u and v and flip the order of the control points.   I'm preoccupied in this topic for a while now because I'm trying to write a Bézier surface raytracing algorithm. What are you planing to use them for?
  5. Well, the developers of Microsoft thought that it would be best practice when they wouldn't follow the standards exactly but put some unnecessary "language features" in the header files of their libraries so that no compiler, which is conforming to standards (like GCC or Clang) could link against it.   http://msdn.microsoft.com/en-us/library/xey702bw.aspx http://en.wikipedia.org/wiki/C%2B%2B/CX   Sadly I never found a nice way to avoid C++/CX on Windows 8 so far and writing a DLL as a wrapper around WinRT just to have it in normal C++ isn't really what I was looking for. But maybe you could give me a hint to a solution...   I might be a bit sarcastic, but I think they did it on purpose to protect their beloved platform Windows from "evil intruders" and people like me, who think they could get around the MSVS compiler.
  6. Well, that depends on the compiler you are using. http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ As you can see, GCC and Clang are the leading ones, MSVS has still big gaps to fill ...     You are right, it is not impossible and I managed to implement it in the end. But have you ever tried to combine deferred lighting and transparency?     I didn't know of "DSSDO" before. Learning never stops. I just implemented my own type of SSAO also using normal buffer and depth buffer, so I guess it is similar to DSSDO.
  7.   The engine has no Windows support so far, because MSVS doesn't even support c++11 and I'm already using c++14 features … I tried some cross compilers, GCC and Clang for Windows but as long as you don't use MSVS you can't link against the system libraries, so it didn't work so far.       Sorted them ascending from simple/less amount of work to hard/took long to implement: Localization: Support for different languages is a nice feature and really simple to code. Material Mapping: Only one texture lookup in the shader, no problem Using C++ 11 features: At the time I started this project I had no idea of c++11 only programmed c++03 so far, but it was intuitive and I learned quickly how to use all the new features of the language. Port from Mac OS 10.8 to Ubuntu 12.04: There are people out there who think that porting modern c++ code is nearly impossible and yes it is true, when it comes to Windows. But as long as you only want unix support, there is absolutely no problem. I installed a Ubuntu on an extern hard drive and put LLVM 3.4 and GIT on it, cloned my GIT-repository, built the make file and it worked. I just had to fix some system unique things like the path to the safe games … well, of course I had the advantage of using only cross platform libraries, right from the beginning, so it went like It went like clockwork. Depth of Field / Fog and Edge Smooth / Antialiasing are all simple post processing shaders using the depth buffer. Texture Animation: A time uniform in each shader has to be in sync with the physics engines time. Deformable Terrain: Needs vertex buffer objects and vertex array objects, OpenGL 3.2 "features" … Logarithmic Depth Buffer: The math about it were the hardest part. Bump/Normal Mapping and Glass Refraction: Calculating the tangent and bitangent needs a geometry shader and is the hardest part about it. Particle Systems on GPU: Transformation feedback is also a OpenGL 3.2 feature and are hard to debug GUI and Text: There is no text or GUI rendering in OpenGL. You have to use another library or do it your self. I used SDL_ttf for the text and did the GUI my self, not difficult but lots of work Dynamic Shadows: Calculating and applying the shadow maps for all types of light sources took me (too) long Dynamic Reflections (Mirrors and Water): The math behind all types of reflections and the frustum clipping of the mirrored world were the worst part about it, using frame buffers and texture projection was fairly simple Skeletal Animation: Parsing a COLLADA, calculating the bone poses and implementing the shaders correctly is difficult Parallax Occlusion Mapping: Raytracing, Whoo! Keeping the performance and nice visual results is nearly impossible, but I'm okay with that trade off now Screen Space Ambient Occlusion: The same as above. Optimizing the performance while keeping the visual results is really difficult Deferred Lighting: Well, using something advanced as deferred shading/lighting means inventing your own graphics pipeline and together with maintaining all other graphics features and transparency it is a real pain in the ass and therefore drove me crazy.
  8.     Of course I know OGRE, Irrlicht and all those rendering engines. But I wanted to make my own one to get a better understanding of computer graphics and best compatibility with the rest of the engine.
  9. I started developing my (newest) game engine "Olypsum" in February 2011.   This is the list of features so far: C++ 11 Mac OS 10.8 and Ubuntu 12.04 Localization Deferred Lighting Dynamic Shadows Bump/Normal Mapping Glass Refraction Material Mapping Parallax Occlusion Mapping Screen Space Ambient Occlusion Depth of Field / Fog Logarithmic Depth Buffer Edge Smooth / Antialiasing Dynamic Reflections Mirrors and Water Texture Animation Particle Systems Deformable Terrain Skeletal Animation Libraries which I used: OpenGL 3.2 OpenCL 1.1 OpenAL 2.1 Bullet Physics Googles V8 SDL2, SDL2_ttf, SDL2_image libogg, libvorbis netLink Tools which I used: Clang, LLVM 3.4 XCode 5 GIT   and I wrote it alone.
  10. Well the idea of using a library for binary serialization is that the debugging is as simple as if the format its self would be human readable. For example my implementation has a method stringify() which generates a human readable representation if needed for debugging.   Just to make clear that I didn't invent MsgPack, its an open format. You can click "Try!" at the website and compare it to the human readable format JSON. In my case it compressed up to 66% with a average around 33%.   The thing is that a SocketManager is not necessary just a simplification to manage multiple sockets at once. But it is a good idea to add some sugar here. I reformed the examples from: std::shared_ptr<netLink::Socket> socket(new netLink::Socket()); socketManager.sockets.insert(socket); to //std::shared_ptr<netLink::Socket> socket = socketManager.generateSocket(); auto socket = socketManager.generateSocket(); Is this what you meant?     The listen() call can be blocking or non blocking, it depends on the sockets (they are non blocking by default) and if a time to wait is given. So I don't see any problem integrating it into a main event loop. It is the same in my own game engine.   I also tried GCC but it got behind in terms of C++11 support so I switched to Clang and LLVM. This only my personal opinion, but I think LLVM is the future and it will surpass all other compilers and byte codes.
  11. Why did I decide to use MsgPack?   Compared to std::stringstream: * All std::streams are just passing through bytes, they don't really serialize or deserialize data structures * You would have to make your own encoding based on ASCII chars and that isn't space efficient   Compared to Google Protocol Buffers: * Define message formats in a .proto file. * Use the protocol buffer compiler. (Not needed with MsgPack) * Use a C++ API to write and read messages. (There's no getting around it)   Compared to Apache Thrift: * It supports more container types, but less primitive types than MsgPack * Write a Thrift IDL file and use the code generator. (Not needed with MsgPack)   Compared to boost::serialization: * It is just a personal preference of mine but I don't like Boost. It is just redundant because we already have the std::lib. * I don't overlook the documentation. But it seems to have similar features compared to MsgPack.   All in all, what makes MsgPack unique? * It is like the widespread JSON, but binary. * Data and types are encapsulated: e.g. You don't have to worry how a number is stored, the serializer decides to use (u)int8/16/32/64 or float32/64. * The data flow is controllable. You can feed to deserializer with small pieces of data and will get the results immediately without having to wait until an entire packet is deserialized.     What about sockets and connectivity?   Compared to unix sockets, Enet, SDL_net and ZeroMQ: * They are plain C, no OOP, just ugly function calls with to many parameters or structures.   Compared to boost::asio: * Well again: It is boost and I consequently avoid it.   Compared to RakNet: * It is not open source and has a commercial license. * But it is especially made for games.   Compared to ClanLib: * It is more like a entire game engine, not just a networking library. * It doesn't seem to have as many features as my library has, for example: UDP multicast and broadcast are missing.   All in all, what makes my netLink unique? * It is OOP, easy to use, light-weight and you don't have to care about stuff like select() or blocking. * You can use it with std::streams for I/O or call the base functionality directly (multiple abstraction layers). * It supports IPv4 and the coming IPv6. * It is written in C++11 and LLVM compiled, so it is more efficient than older versions.  
  12. Hi,   I'm developing my own game engine for some time now and wanted to add multiplayer/network support. Therefore I was looking around the web for a c++ (11) library which suites my needs for a game engine and not for a browser. I wanted a lightweight library without the big overhead of HTTP, XML/DOM-parser or even Boost. But such a thing didn't seem to exist, so I decided to write my own one:   netLink which can be found under zlib licence on Github. It supports IPv4/IPv6 UDP/TCP sockets, a manager to handle multiple connections and MsgPack, which is a JSON like binary format. I can now transmit small packets (like position updates or chat messages) over those sockets using the MsgPack encoding.   My questions: Do you have a use case for such a library and were you looking for something like this too? Is there something important missing (except the windows support) ? Or do you have good experiences with other libraries and when yes, which ones and why?
  13. Thanks for your answers. They helped me a lot.   Well, I think I will stick to rational cubic bezier patches, because I can implement a Bounding volume hierarchy built from the convex hull of the control points to accelerate the raytracing, which wouldn't be possible that easy when I would use NURBS. Also I can see no "real" advantage of NURBS except form the modeling, but that shouldn't be a problem since I can convert models of NURBS to bezier patches.       If I got it right, than the continuity at the edge between to patches should be given when the three neighbor control points are forming two lines of equal length. So that shouldn't be that complicated to compute and even if I don't solve this problem, I can still convert NURBS models to bezier patches.   So I will start with the bezier patches and then try which method (numerical, approximation, dividing or maybe a mixture of those) is the fastest for my raytracing application.
  14. Hi, I'm currently working on a raytracing rendering engine for a research project. Since raytracing doesn't need triangle meshes I thought about using curves like NURBS or rational bezier patches. My question is: What do you think is better suiting for this purpose?   I have only worked with bezier curves before and just read a few papers and wiki articles about NURBS. Therefore I have some other questions about them:   1. Is there anything only a NURBS can form and a set of rational bezier patches can not? I read some thing like: It is possible to convert a NURBS into a set of rational bezier patches and vice versa too, but I'm not sure about it.   2. What exactly is the knot vector of a NURBS and what is it needed for? A set of rational bezier patches just needs the control points and their weights and a NURBS needs control points, weights and the knot vector. Isn't that redundant data?   3. Are calculations (finding a point, derivative or normal) of a NURBS more time expensive or complex than the ones of bezier patches?   4. NURBS seem to end before actually reaching the first / last control point, bezier curves reach the first and last control point in every case. That is a bit confusing but seems to be natural. Any explanation here?
  15. Hi, the solution in my game engine is the following: [CODE] struct Bone { Matrix4 staticMat; unsigned int jointIndex; std::string name; std::vector<Bone*> children; }; struct Skeleton { Bone* rootBone; std::map<std::string, Bone*> bones; }; struct BonePose { Matrix4 poseMat, dynamicMat; }; class SkeletonPose { public: std::map<std::string, BonePose*> bonePoses; SkeletonPose(Skeleton* skeleton); ~SkeletonPose(); void calculateBonePose(Bone* bone, Bone* parentBone); void calculateDisplayMatrix(Bone* bone, Bone* parentBone, Matrix4* mats); }; void SkeletonPose::calculateBonePose(Bone* bone, Bone* parentBone) { BonePose* bonePose = bonePoses[bone->name]; bonePose->dynamicMat.setIdentity(); if(parentBone) { bonePose->dynamicMat = bonePose->poseMat; bonePose->dynamicMat.translate(bone->staticMat.pos-parentBone->staticMat.pos); bonePose->dynamicMat *= bonePoses[parentBone->name]->dynamicMat; }else{ //Is root bone bonePose->dynamicMat = bonePose->poseMat; bonePose->dynamicMat.translate(bone->staticMat.pos); } for(unsigned int i = 0; i < bone->children.size(); i ++) calculateBonePose(bone->children[i], bone); } void SkeletonPose::calculateDisplayMatrix(Bone* bone, Bone* parentBone, Matrix4* mats) { Matrix4 mat; mat.setIdentity(); mat.translate(bone->staticMat.pos*-1); mats[bone->jointIndex] = mat * bonePoses[bone->name]->dynamicMat; for(unsigned int i = 0; i < bone->children.size(); i ++) calculateDisplayMatrix(bone->children[i], bone, mats); } //Draw Frame //Calculate the hierarchical transformations of the skeleton skeletonPose->calculateBonePose(humanModel->skeleton->rootBone, NULL); //Calculate the matrices used in the shader Matrix4* mats = new Matrix4[skeleton->bones.size()]; skeletonPose->calculateDisplayMatrix(skeleton->rootBone, NULL, mats); currentShaderProgram->setUniformMatrix4("jointMats", mats, skeleton->bones.size()); delete [] mats; for(unsigned int i = 0; i < meshes.size(); i ++) meshes[i]->draw(); [/CODE] I hope you can understand my code [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img].