Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1587 Excellent

About snake5

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. snake5

    SGScript 1.4.0 has been released!

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

    SGScript 1.4.0 has been released!

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

    Favor Small Components in Unity

    The post is obnoxiously one-sided. I can easily see the counterarguments to this idea: Increased number of memory allocations leads to reduced performance. Amount of glue code increases due to everything being separated, which in turn also reduces perfomance and increases the complexity/unreadability of the code. The amount of files to deal with while editing any object is increased. Any one-off behavioral changes for certain object types require yet another file to store the derived component, thus splitting the code for special objects for many files, making editing more complicated. Because of this, I am highly skeptical of the claim that "your entire project is easier to manage and the complexity of the project can be manageable again". Also, I see no "before" and insufficient "after" (where's the glue code?) code examples to illustrate your point and help with the credibility of your claims. There is no data (and I highly doubt there will be) that could prove your point. This is fine for a blog/forum post, not for an article.
  10. snake5

    Lerp vs fastLerp

    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.
  11. 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).
  12. 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.
  13. 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.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!