Jump to content
  • Advertisement

lawnjelly

Member
  • Content Count

    982
  • Joined

  • Last visited

  • Days Won

    25

lawnjelly last won the day on September 20

lawnjelly had the most liked content!

Community Reputation

2008 Excellent

About lawnjelly

  • Rank
    Advanced Member

Personal Information

Social

  • Twitter
    lawnjelly
  • Github
    lawnjelly

Recent Profile Visitors

25743 profile views
  1. This is how unity builds work, and they are awesome (in fact you can have lots of .cpp files, you just include them all from one (or a few) .cpp file which is passed to the compiler, the effect is the same). It can still be a good idea to use a few different modules with unity builds though, so you get most of the benefits from both approaches. Even with unity builds, even though the headers may only be included once, they can still take a while, if you are impatient like myself, so having wrappers can still be a good thing for thirdparty stuff. As a project gets bigger, the link time can get more of an issue, my current preference is to have a bunch of modules and dynamically link them for fast iteration, and statically link for final release. That way if you touch a file in 1 module out of 10, it only needs to link 1/10 of the codebase. I suspect it may be even less than that in terms of linking time (link time might not scale linearly with size of project). As an example I recently experimented making unity builds of Godot, which decreases the full build time: https://github.com/lawnjelly/godot_SCU Unfortunately for everyday developer iteration the link time is more of a rate limiting step because it is all built as one executable. i.e. you touch a file, and it can compile super fast, but still takes 30 seconds linking. With dynamic linking this could be reduced to e.g. a couple of seconds. Your implementation looks quite nice, although really all I was trying to show was an example of wrapping an external library, rather than selection between libraries, perhaps I shouldn't have used windows.h as an example(!). Having the macro in the header file is to ensure that calling the third party library is in the same translation unit. Compilers used to be rubbish at inlining anything that wasn't in a header files, but with link time optimization that is less of an issue now. I still prefer it out of habit (plus link time optimization is SLOOWWW ).
  2. Probably made the mistake of #including windows.h... One of the tricks I use for non-template external libraries / functions that have 'expensive' includes, is to wrap them in your own .h / .cpp file. So you only include your own .h to use the functions rather than the third party. Yours can be clean and fast compiling, even if the external is rubbish. E.g. //my_windows_wrapper.h #pragma once #ifndef QUICK_BUILD #include <windows.h> #endif class WinWrapper { public: #ifdef QUICK_BUILD void some_windows_func(); #else // will get optimized out void some_windows_func() { // call windows some_dodgy_windows_func() } #endif }; //my_windows_wrapper.cpp #include "my_windows_wrapper.h" #ifdef QUICK_BUILD #include <windows.h> void WinWrapper::some_windows_func() { // call windows some_dodgy_windows_func() } #endif Then for final release you can change the QUICK_BUILD define and it will link directly to the third party code. There might be an even better way of doing this. Optimizing compile / link times can be really important in big projects to reduce iteration time, and there's no reason why you can't do it at zero cost for final release builds.
  3. lawnjelly

    DOOM: Skeletal Animations & Dynamic BVHs

    Absolutely awesome, using a ray tracer to do doom! You guys are all on fire!
  4. lawnjelly

    GameDev - Doom Challenge - Part 1

    Like the gun and the level design doodle! Looking forward to seeing it!
  5. lawnjelly

    Doom Game Challenge : þoom

    Looking fantastic Goliath!
  6. lawnjelly

    Doomish - About 70% Done

    Looking awesome!
  7. lawnjelly

    Godot contributions

    I haven't played with the multiplayer side, the docs seem to suggest there is quite a bit of support and there has been quite some activity adding new features for 3.2: https://docs.godotengine.org/en/3.1/tutorials/networking/high_level_multiplayer.html
  8. lawnjelly

    Godot contributions

    Haha no lottery wins! I am no where near any tops of any contributors lists, there are quite a few unsung heroes out there who are working tirelessly every day making commits and bug fixes .. reduz, Calinou, Akien, Chaosus, Groud, clayjohn, KoBeWi, RandomShaper, YeldhamDev, aaronfranke, qarmin, Xrayez, karroffel, fales, iFire, RevoluPowered, bojidar_bg, Mux213, marstaik, jfons, and many more that's just the tip of the iceberg. Myself I'm just looking at problems I personally find 'interesting', and little niches others haven't got the time to investigate. And many of these won't pan out, and aren't part of the core. And I'll probably get back to working on games soon enough. Funnily enough part of what got me working on the rooms / portals module for Godot was the doom challenge. I had thought about doing it in Godot but it didn't support rooms / portals, something I'd been meaning to have a go at implementing. I would like to have had a go at the doom challenge but I've got a lot on in the next month and can't realistically fit it in.
  9. lawnjelly

    Godot contributions

    Some of the regulars will have noticed I've been posting less lately on gamedev. This is because I've been spending a lot more time working on Godot. After making a few games with Godot for the challenges, I had downloaded the source and proceeded to fixing bugs that affected my games. I've now made a few contributions to the engine and spent as much time working on addons / plugins. It has been quite interesting for me because it's my first venture into open source. I've had to learn (the basics!) how to use git, as the project is hosted on github. I've used various source control systems before but git is a bit different, so that was fun. Godot Core & Addons One of the first things anyone wishing to contribute to Godot will learn rather rapidly, is that there is a firm policy of trying to have as many new features as possible as addons (GDScript addons, c++ modules, GDNative c++ binaries), and to only put new features into the core engine if absolutely necessary. This has proved to be a controversial area, because although in theory this is a great plan, in practice it is much easier for developers to get their work available by getting it into the core engine. At present, far fewer users than we would like actively download and use the various addons. Some types of addons require you to be fluent in building c++ to even install. This is a recognised problem among the devs, and hopefully we will be able to come up with some solutions that make it easier to deploy and install non-core modules. Ideally users would be able to just search and click to install an addon from the IDE. This is to some extent possible with GDScript, but not yet available for c++ addons (which are needed for performance reasons in some cases). On the other hand, with the amount of developers keen to make new features, if they were all integrated into the core engine, it would rapidly become a bloated and unmaintainable mess. Of course, psychologically every dev feels that their new feature NEEDS to be in the core engine, no matter how niche. What I have been working on Initially I was mostly fixing bugs in the Android build. As Godot is multiplatform, and has limited manpower (there are only 2 paid fulltime devs!), one of the areas that is lacking is systematic testing. This is totally understandable, but we mainly rely on the issue tracker for people to report bugs and regressions on the different platforms. This seems to work quite well for windows and linux and iOS, but for Android the problem is that there are a million (literally) different combinations of hardware and OS out there, many of which have bugs. Initially the plan was for an OpenGLES 3 renderer that would work on all supported platforms. Unfortunately although many devices report that they support GLES3, in practice the implementations can be very limited and buggy, and it was clear that to cover all the bases Godot needed to produce a GLES 2 backend. This is still rather flakey in places even now, but tends to offer better performance and compatibility than GLES 3, particularly on Android. GLES 2 Skinning One of the first areas I actually made a difference was in identifying and fixing a major skinning bug in GLES 2. I hadn't been able to get any of my games to run on Android, and it was clear there was a major bug which seemed to be crashing Godot whenever skinned characters were used. Which is like, almost every game. Which meant for all intents and purposes, 3d was unusable for mass market on Android. What became apparent is that it is a very slow process to investigate these types of issues on other platforms. Every time you want to run a build on a device, you have to compile export templates (a version of Godot engine for that platform), re-export the project, deploy to the device, and wait for feedback in adb logcat. Not very fast. You need a lot of patience. On top of that I didn't have a clue how Godot engine worked so I resorted to putting a lot of print statements throughout the code to narrow down what was causing the crash. In the end I tracked it down to the bones data not being present for some reason on the device. After further investigation it turned out that the bone data was retained on desktop, but deleted on Android, and only required in certain hardware configurations (if the GPU didn't support float texture). So I figured out a few lines of code to fix this, and it was my first PR. As a result my game that wouldn't work before was now working on my tablet and Android tv box. Great success! Android Keyboard Input Next up, it was apparent that a large percentage of physical keyboards weren't working on android. Certainly none of mine. A bit of debugging and I had this figured out and fixed. (Unfortunately now they are working it has exposed another bug which causes crash when pressing left cursor .. but am sure we will fix it! ) Timing As some of you may know I'm big on game timing, and had previous written an article about it. I resolved to improve the timing in Godot to help resolve the jitter issues many users were encountering. Fixed Timestep Interpolation The problems were occurring because Godot uses a fixed timestep (which is usually good), however if you are using a fixed timestep, under almost all circumstances, you MUST use fixed timestep interpolation to deal with the differences between frame times and tick times. Otherwise you get godawful jitter. Which is what godot currently has by default (unless by chance you match your tick rate to your frame rate). The established solution is to use fixed timestep interpolation. Which is pretty easy for experienced devs to implement, unfortunately it can be a bit daunting for beginners. So I resolved to try and make this easier. On top of that, there was a more serious problem, the timing information necessary to calculation the interpolation fraction wasn't exposed to users. I did some experiments at modifying the base Nodes in the engine to automatically handle interpolation under the hood. They were only partially successful .. it worked but it was not pretty because the engine was not designed with it in mind. Instead I developed a purpose built interpolation node to do this without any coding. For this to work properly I did some investigation into the Godot timing system and worked out how to expose the interpolation fraction. I then made a PR which has been merged which exposes this to the user. Although reduz decided interpolation shouldn't be part of the core engine, he was happy to have the fraction exposed so it was possible in user code / plugins. This is now working great and will be first available in Godot 3.2 which is currently in alpha. On a suggestion from Calinou I then converted my interpolation nodes (3d and 2d) to GDscript so they could be installed as an addon, which is much easier to deploy as it doesn't require compilation for different platforms (users simply copy the addon to their project folder). I am planning to add this to the official addons once 3.2 is released. Semi-Fixed Timestep While I was working with the timing and after discussion with reduz he seemed interested in an eventual move to basing the tick rate on the frame rate of the device. With this in mind I set about expanding the timing code to easily add new stepping models, and added a semi-fixed timestep mode. This is now languishing in amongst some 350 pull requests waiting for review .. I think it will have to wait until Godot 4.0 now, and perhaps until reduz takes another look at the timing code himself as he may want to do it slightly differently (at the moment the vulkan renderer is the priority). I'm not too concerned about this actually, because although semi-fixed is the default timestep in e.g. unreal engine, I really put it in for completeness, and it is not something I'd tend to use in production myself. It is quite useful for beginners though. Delta Smoothing More for my own use I also modified the engine to allow delta smoothing. This is a subtle timing problem that can give jitter, and delta smoothing can be used to help alleviate (though not eliminate) the issues of measured delta not being representative of actual frame delta. I suspect this is something that I would have an uphill battle to get merged into core, so no PR for now and I'll wait until the timing issues have been discussed in future. OS Timing bugs I also spent a good week investigating something I had never encountered before. We had had bug reports of time going backwards, which prompted me to investigate the values we were getting from the OS clocks. It turned out, that under certain circumstances, the MONOTONIC clocks (that were never supposed to go backward), did appear to be going backward. This could lead to incredibly nasty bugs where time was assumed to be going forward (using unsigned ints to store time difference e.g.). After much research I didn't completely sort this out. However I am hoping that it is not currently a problem that occurs in the wild on the current version. When you get down to the level of nanoseconds you have to deal with race conditions and mutexes to prevent something else happening between you measuring the time and reporting it. And time, by its very nature, once you have measured it you have the wrong value. There is a great quote 'Give a man a watch and he'll know the time. Give a man two watches and he'll never know the time!'... Rooms and Portals And so we move onto my current project. Many users have been requesting occlusion culling, and it has been sorely missing from Godot since version 2. It has been on the roadmap for a while but got pushed back because of the need to work on Vulkan. The frustration from some of the users has been palpable. Admittedly it does make the engine almost unusable for certain genres of games like 1st person shooters. So with this in mind, and having written room / portal / PVS systems before (mostly over 15 years ago though!) I decided to have a crack at an interim solution until reduz gets round to it some time during Godot 4.0. I will detail this in a later blog post, and it is still a work in progress but for now here's a link to a video and the project on github: https://github.com/lawnjelly/godot-lportal
  10. I'm just trying to upload some updated versions of one of my challenge entries, but it keeps failing near the end of the upload with 'There was a problem processing the uploaded file. - 200'. I've tried in chrome and firefox. The file is a zip file, 53 megs. Also worth mentioning there are also 4 files there already, I was going to wait until successfully uploaded before deleting the old versions .. in case there is a limit on the number of files or something.
  11. lawnjelly

    Portal occlusion culling help

    Yeah, Godot *cough*, where I've been spending a bit of time contributing lately. There was actually a portal system in the old version 2.1 but there is currently no occlusion culling whatsoever, although it is on the roadmap for version 4.0: https://github.com/godotengine/godot/issues/22048 I did mention doing a temporary version in that thread but it may not be worth it (duplicating the work that reduz will be able to do better integrated with the visual server etc, plus the difficulties of distribution of modifications versus having code in the master branch).
  12. lawnjelly

    Portal occlusion culling help

    Firstly portal rendering is beyond a beginner topic (some major 3d engines don't have occlusion culling!).. But very briefly: Simple portal system, you would split your world into rooms: Room contains objects to render, and a list of portals through which you can see into other rooms. Portals can be contained in more than one room (or have 2 one way portals, one on each side). e.g. Kitchen (contains walls, floor, sink, girlfriend, chain) + Portals (kitchen door, window) Hallway (contains walls, carpet, painting) + Portals (kitchen door, window, living room door) Outside (contains grass, trees) + Portals (hall window, kitchen window) Let's consider a portal being a convex polygon on a single plane. First you need to know which room you are in, let's just pretend you know you are in the kitchen for now. You first draw all the objects in the kitchen, culling to the view frustum. Draw walls, sink, girlfriend, chain Next you go through all the portals leading out of the kitchen, culling to the view frustum (if a portal is behind you for instance, it need not be considered). If the kitchen door is in view, you now add each edge of the kitchen door (portal) as a new clipping plane for your culling routine. Now draw everything in the hallway (the room which that portal joins to) but cull each object if it is behind these clipping planes. Draw walls, carpet (painting culled, outside view of door) Now repeat for any portals in the hallway which you can also see through the kitchen door, maybe a window to the outside. If no more portals are visible through that portal terminate the routine. Draw grass, trees (some culled by the window) This whole thing is recursive in nature. To do all this of course you need to firstly understand data structures and links / references between them, you might for example use a scene graph. You also need to understand the principles of culling and some geometry. You also need to keep track of which room the viewer is in, there are various methods for this .. you could simply take note whenever the player crosses a portal (providing the physics is only allowing movement between rooms via portals).
  13. Probably not, but it is usually quite fun investigating. What you might find (other than the complexity of implementing it) is that the sheer number of sprites you need to store in different orientations is prohibitive in terms of memory use etc. And alpha blending several bone sprites on top of each other (if this is what you are intending) is not free in terms of performance, it could be very bad on mobile for instance, and you might find it is much quicker to just draw the 3d geometry. If you want to look at literature on this sort of thing, imposters is a good search term (it is slightly different but highly related). Another point is that quaternions may not be the best way of storing the orientation for lookup. Depending on your constraints (say you have humanoid characters always standing upright) you might be able to store orientation as e.g. a unit x, y, z direction. Or maybe euler angles or axis angle. These might be easier to do numerical comparisons and allow lookup tables etc.
  14. lawnjelly

    How to become an AAA studio?

    If you mean by AAA studio, you mean be a studio that is able to secure big $$$ to make big budget games, aside from this being incredibly unlikely, and in most cases probably absolutely nothing like what you envisage it to be... Another path (probably more likely) is to work for AAA companies, rise through the ranks to the top jobs, make connections, be in a position to splinter off to form your own group of proven AAA professionals with proven track records of churning out hit games. Then you may be in a position to attract funding. This is probably more likely than making a hugely successful indie game that gives you clout. This path happens quite a lot, but of course it is a sink or swim world, and without a string of hits or reliable income, most of these new companies will not last. From the perspective of investors, one of the things they are looking for is that you have a solid group of experienced industry pros, preferably with some big cheeses that have worked on hugely successful games. Even having made a wildly successful indy game doesn't mean you will have the skills required for big budget AAA stuff, as far as investors are concerned. And if you have a wildly successful indy game and want to self fund AAA stuff, you are probably crazy.
  15. lawnjelly

    Reputation points

    Am in agreement with Gnollrunner. I don't think people want to be mean by a downvote in that circumstance, it's more to reread it and consider how it sounds 'you have to do things like this'. One of the reasons for the success of c++ is that there are many many different ways of approaching the same problems. The language gives you tools, it doesn't force you to work in one particular way. And don't worry we've all made posts which in retrospect could have been worded better. Often times I end up spending 15 mins writing a reply on here, then read it through one final time before posting, and realise I don't know what I'm talking about, and delete it. In a lot of cases, all it takes is to write 'in my experience, it can be a good idea to do blah' or 'in my opinion' to change the tone. Then if someone comes up with something you hadn't thought of, you don't end up digging yourself in a hole.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!