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

snake5

Members
  • Content count

    393
  • Joined

  • Last visited

Community Reputation

1587 Excellent

About snake5

  • Rank
    Member
  1. In under 3 weeks, SGScript bindings for .NET 2.0+ were finished and now it's time to release v1.0.   Only Windows is currently tested and supported (both standalone and running under Unity) but I'll be looking into options to support Linux and macOS as well.   The API is made to look similar to the C API where possible which I hope makes up for the missing documentation.   The binaries for SGS.NET are included in the Windows version of 1.4.1 binaries.   Probably currently the biggest missing thing is not being able to bind arbitrary objects to the engine, only IObject-based ones, the next version will offer more binding options. I'm also not entirely sure how the native library linkage works within other engines/platforms so that's probably another thing to work on in the upcoming version.   Here's a screenshot of SGS.NET running in Unity
  2. Yes, that's pretty much what it is, something between the two. More built-in features than Lua, faster than the default Python implementation.   Those are just the terms of the MIT license. Lua uses the same exact license, by the way. :)   That's interesting, I did not realize this could be off-putting to some. The reason I included it is that there are non-free scripting engines (e.g. SkookumScript) and it seemed like an important thing to mention. Besides, it's nothing original - the About page of the Lua website features a similar section at the bottom.   Anyway, thanks for your input, I'll try to think of a way to improve the text on the website.
  3. Hi, I'm the developer of SGScript and I just wanted to let you know that I've been working on the project all this time, and there have been lots of improvements since my previous post. Today I have released SGScript 1.4.0. Some highlights from the Change Log since 0.9.5: added class syntax added 'defer' keyword (moves statement to end of block, 2+ statements are executed in opposite order) SGSON serialization (JSON-like, with function syntax) added coroutines, thread syntax and API (thread, subthread, sync, race, end_on) added map literal (map{ [5] = true }) symbol (named persistent variable) & coroutine serialization null-coalescing operators (??, ??=) single header implementation Some useful links: Try the language at sgscript.org SGScript on Discord -------------------------------- Now that that's out of the way, I have a question: Seeing as many people these days don't make their own engines, is there any popular small to medium-sized open-source engine that you use for which you'd like to use a scripting language like this one?
  4. It does handle mipmaps. Every mipmap is retrieved separately by dds_seek/dds_read. dds_read_all is only a wrapper that copies everything into one big buffer with a predefined order of items.   Basically whatever texture part you want out of it, you can move the pointer to it using "dds_seek( &info, cubemap_side, mipmap_id )" and then memcpy it using "dds_read( &info, my_buffer )"   What it doesn't handle though, is pitch (row length in bytes). If your target buffer expects different pitch, it will be necessary to use an intermediate buffer in size that can be retrieved using dds_getinfo (size member of dds_image_info output struct). Or write your own reading function (once you have the side/mipmap offset, it shouldn't be that hard).   There actually are multiple DDS formats, one pre-DX10, the other one contains an extra header. It even supports partial cubemaps and all sorts of weird pixel compositions. Nobody needs them (not that I recall, anyway) but it's important to detect these cases to avoid buffer overruns and broken visuals. Sadly, the format isn't quite as simple as one would expect.   Internally I use something even more simple (this is the header, pixel sorting order major->minor is - side, mipmap, depth, height, width): struct TextureInfo /* 12 bytes */ { uint8_t type; /* 2D[1]/CUBE[2]/VOLUME[3] */ uint8_t mipcount; uint16_t width; uint16_t height; uint16_t depth; uint16_t format; /* format ID (rgba8/r5g6b5/dxt1/dxt3/dxt5/..) */ uint16_t flags; /* SRGB[0x01]/HASMIPS[0x02]/LERP[0x04]/CLAMP_X[0x10]/CLAMP_Y[0x20] */ }; struct Texture { char magic[4]; /* STX\0 */ uint32_t datasize; /* size of 'data' */ TextureInfo info; uint8_t data[ datasize ]; };
  5. If you only need minimal parsing (to map byte offsets to cubemap sides/mipmaps for some common color formats), this might help:   https://github.com/snake5/sgs-sdl/blob/master/src/dds.h https://github.com/snake5/sgs-sdl/blob/master/src/dds.c Usage example: https://github.com/snake5/sgs-sdl/blob/master/src/ss3d_engine.c#L745
  6. Just one thing that wasn't mentioned yet: in C++, "public:" / "private:" / "protected:" labels define different blocks of variables. Within these blocks, the order is preserved, however the standard doesn't guarantee that block order will be preserved. I've no idea how often reordering is the case in practice, though simply using structs / making all members of a class public will guarantee that there are no ordering issues.
  7.   Would be nice (and often necessary in the case of deferred rendering) but not important considering all of the other aspects of a game engine. But if you must...   First of all, all of that inheritance stuff is completely unnecessary. Also, shaders will be structured in an entirely different way, and same features will often require different approaches for the rendered images from both renderers to be equal - a basic deferred renderer probably won't have support for multiple materials, for example, so to add that, a "material ID" would have to be stored in the G-buffer (possibly the stencil buffer), and used as a pixel filter for multipass light rendering.   Some simple observations: The forward rendering pipeline requires a "for each item {  render(item,ambient_lighting);  for each light {  render(item,light)  }  }" rendering order or similar The deferred rendering pipeline requires a "for each item {  render(item)  }  for each light {  applyLight(light)  }" rendering order The details vary but the point remains - you need a way to render all of the visible (or just all) items. Also, you need to render polygons that roughly describe the area occupied by the light for deferred shading.   So, you can achieve a lot with just two functions - DrawItems(items) and DrawTriangles(vertices) - used with the appropriate shaders and render targets at the right time. How you choose to call these functions is completely up to you. Might be as simple as RenderForward() and RenderDeferred(), a configuration variable or something else entirely.   Also, to start with simple code, you can just draw a fullscreen quad for each light - it will be slower (a lot slower with many lights) but guarantees effortless accuracy.   There are lots of optimizations/improvements to apply here (item ordering by transparency, depth sorting, global sorting with item span rendering, separate solid/transparent forward rendering passes, Z prepass etc.) but I'll leave those unexplained for now, since they're not really relevant for a school project type engine. You can always ask more questions to Google or in the forum when you're done implementing the basics.
  8.   They have the always_inline attribute, which FORCEINLINE is defined to in UE4 as well (specifically, #define FORCEINLINE inline __attribute__ ((always_inline))).   As for usage, I use it to enable inlining of trivial (single-line) functions in debug builds, to improve performance without sacrificing much of the debuggability.
  9. Depends on the case. With the fast version, lerp(a,b,1) may not return b. Multiplication by 0/1 are generally not lossy operations, addition and subtraction of non-zero numbers can easily be lossy.   So, fast lerp works fine almost everywhere but if you absolutely need lerp(a,b,1) to return b, use the slightly longer version.
  10. That's about right, since it would require some horrible indirection/registration of weak references, and GCs could easily lead to the objects being destroyed at a bad time. One frame, the object works, the next - it's broken. Hard to debug. Lua works around the registration issue with weak tables though, as mentioned above. The GC issue still remains, though.   What I've found to work for me (even though I use my own scripting language, SGScript, the concept should still apply to others) is weak objects: make scripting object handles themselves weak.   Every object has interface/data pointers or some equivalent of that: interface defines how the language should deal with it, the data pointer allows linking C++ data to use in bindings. When C++ code decides to drop an object, the C++ part of it is destroyed and the scripting object receives new interface/data pointers (empty interface definition + NULL data), thus unlinking it from its contents. Any access will fail with a descriptive error.   Another option is to refer to objects through named handles only (like "find('player').check_something()"). Should work everywhere but it'll increase code size.   I'm 3-4 years in so I completely agree that it's no small task to create a fully featured scripting language. The payoff is impressive, though there will still be lots of regrets and certain features just out of reach (like low-cost loops, JIT and smart optimizations).   However, creating a basic "command list" style language or defining a basic language like what ant (the build tool) has in XML (or any more acceptable alternative) is quite simple, actually. Judging by your usage description, it may just fit your needs, though expect at least a week of work to get something to run and at least a month of work to fit all your needs (if they're indeed simple).
  11. It looks more like reading from old/uninitialized GPU memory than anything else. Tiles of this size cannot be realistically achieved by bugs in the code, they would require an entirely different (tile-aware) loop. This is more likely to be coming from GPU driver errors or API misuse. For example, not filling all mipmap levels of a mipmapped texture could cause this.
  12. Demo looks impressive.   Single-shadowmap omni lights are a particularly nice feature. Didn't see the "light in front of camera" case so well in the video but it's visible in this screenshot: http://i.imgur.com/qUQTbfm.png   One minor issue though - I noticed that shadowmaps were slightly broken in one specific location - http://i.imgur.com/DDZkFhi.png. Seems like simply a case of depth bias/depth value space mismatch, though I'm not sure how hard it would be to fix in this case.
  13. VIS data in the Quake map format is basically occlusion culling data. Frustum culling is something else entirely. Both methods are useful on their own as well as combined. If you have the data, I don't see a reason not to use it.
  14.   I meant that instead of doing calculations in world space, you'd do calculations in view space.   So, instead of this - "output.worldPos = mul( output.pos, World ); output.pos = mul( output.worldPos, View );" - you'd pass the world*view matrix to the shader and do this - "output.viewPos = mul( output.pos, WorldView );".   It will mean that most (if not all) calculations done will have to be done in view space (all light positions, directions - transformed by view matrix).