Jump to content
  • Advertisement

Shaarigan

Member
  • Content count

    484
  • Joined

  • Last visited

  • Days Won

    1

Shaarigan last won the day on July 11

Shaarigan had the most liked content!

Community Reputation

1103 Excellent

5 Followers

About Shaarigan

  • Rank
    Member

Personal Information

  • Role
    Artificial Intelligence
    Programmer
  • Interests
    Art
    Design
    Programming

Social

  • Github
    Shaarigan

Recent Profile Visitors

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

  1. Shaarigan

    Architecture of and engine editor

    You should seperate a plain Editor and whatever Unity is because Unity is a closed system that runs your game inside the Unity Launcher App on whatever platform you start it at. This means Unity loads it's own version of the .NET CLR or whatever "scripting" you used. At the point you are getting your game code touched for the first time, there has happen a lot that you wont even recognize under the hood of the Unity executable. Real Editor Apps like WorldEdit in Warcraft or Starcraft games are standalone tools that consume and produce just content and toggle to "play-mode" by calling the game with certain start arguments to know what map to load. "Compiling" scripts highly depend on the environment you write and tools you expose from your engine. Is it compiled from source you have two possible options to go for; either you give the full source code of the engine so one could compile it with a given compiler or trigger compilation by any editing tool (the Unreal way) or you go for the Unity way and compile source code to some kind of embedded runtime either you wrote for your own language or use something existing like Mono or LUA. Often there is a build pipeline involved in game development that consists of tools called during build like compiler, linker, package creation for your assets, digital signing and verifying especially when building for closed platforms like Playstation or Switch and those pipelines are mostly coded via some kind of build file or code provider (Unreal for example rebuilds it's build tool depending on each project you open in editor to have plugins added specific build-steps in there as C# files). My way of handling this in my engine is to have the Editor App be standalone and general. Certain engines may then add certain plugins to the editor to customize workspace and functions exposed to the user and also to control steps like trigger a new build or run the game inside the editor itself. A general interface exists that plugins have to inherit so both, plugins and host application can communicate to each other
  2. Shaarigan

    Aspiring Engine Developer -Help-

    You should know that reading just books dosent get ya serious with engine development. It is a topic about reading about technologies and learn how to implement them in your environment. It is all about practical experience and even experienced developers don't mean to be experts in engine development. A good book I could recommend is Game Engine Architecture, Second Edition along with any C++ Book you could grab to improve your platform near coding skills because a game engine is an OS API consuming and user API producing ecosystem
  3. The other way would be something like Cheat Engine does, for each game you have to know specific memory regions for health, damage taken and whatever variables are describing the "emotional" state of your character. You can then map to those memory regions for each game and define the values you will listen to and create your own events for. But from what you described above (or didn't described) I don't think mainstream game devs would take your yet unknown and exotic device into account for there games so you could rely on modders only
  4. Shaarigan

    C++ Common Runtime

    You have those problems in C#/.NET too so no unexplored landscapes here In C# I usually do platform detection or abstract interface binding, then load matching classes (some kind of late binding happens in the CLR), so supporting post-precompile postprocessor directives (word of the day, really!) or late-binding (another extended form of what the OS under the hood does with dynamic libraries) should be no problem for the kind of IL language. There is always a way to solve that. Also handling with OpenGL, you will anyways have to bind function pointers to library functions if not stuck at 2.0 immediate mode to get all those new (relative) and fancy extension methods from those versions beyond GL2.0. I think anything needed is a good platform anchored assembly initializer and a library with minimal set of classes and functions to support those basic features .NET has. Maybe worh a thought in my mind if I have space for a new project
  5. Shaarigan

    C++ Common Runtime

    I don't agree with that statement either, C++ is way more than just "squeeze the last bit of performance out of a specific platform". I code C++ for a long way now and didn't need to use those tricks like intrinsics or even inline-assembly when writing games and agem engines for years. This is because code is already being optimized by good compiler backends like LLVM. Best example here is Matrix Math, I wrote matrix 4x4 multiplication in clean C++ without explicitely use of SSE instructions. How to say, performance was bad in MSVC but even beats the intrinsic version in LLVM because LLVM is already clever enougth to detect what I want the code to do and let the code be as optimized as possible. Other points I like to work with C++ way more as with C# for example are totally freedom to do anything with your data and template model. C++ isn't interested in how your data is formatted, have a range of memory in hand use it as byte-Array, integer-Array, struct or whatever isn't limitted while other languages especially CLR complains about storing an Int16 in an Int32. The freedom to manage and waste or don't your memory, the freedom of writing static global functions or fully OOP kind classes and last but not least the way more supported template and preprocessor capabilities. This is what makes C++ unique in my opinion! To get that point clear, I'm not in having run 20 year old software on modern hardware without any tweak or recompilation but this was a theoretical general question about how could this be possible in future development. And yes, I already thought about something like precompilation translated code and about (already described above) to keep those loading time aware. My solution would be whatever modern compiler do after the precompiling step before assembling this into architecture specific code. I don't think that those code will run significant slower than native cross-compiled code for that architecture and one will however need to use preprocessor flags to determine platform specific function calls anyways in cross-platform development so this isn't a real statement against a CR :)
  6. Shaarigan

    AI for large numbers of RTS like units

    In modern gameplay, those tasks are done via Behavior Tree rather than the simple state maschine. I worked on games with very large scale of units that have had to be controlled (500 AI units) for a traffic simulation. Those units each have had driver behavior from simply follow there road, change lanes and taking other ways on cros-roads up to complex traffic behavior and seeking for a parking spot. This was all done using a single behavior tree of actions and conditions. It has certain types of nodes to code your actions with; split nodes to link certain sub-trees together, condition nodes to evaluate what sub-tree to follow and action nodes that map to functions n your gameplay code. If you have several units sharing the same tree, there should be a way so that your BT is a singleton object and each unit manages it's state by it's own. This way you keep your units away from wasting multiple instances of the same tree and just hold the information needed. Make several different trees for different kinds of units or link trees together via conditional actions so you could setup your AI in an additive system from basic actions to more complex ones for certain types of unit.
  7. Shaarigan

    C++ Common Runtime

    Sure, you could drive the multiplatform road and recompile for every architecture but this isn't real portable, it is just writing multiplatform code. You can't compile x64 assembly and hope it runs on ARM too ;) What I mean is a really portable compile once and run everywhere solution. Performance suffering depends in my opinion. If you ship something that is compiled to an instruction set that has to be interpreted again then you're right but shipping as code that could be "finally compiled" to the platform it should run at just now then chances are given that performance is as well or nearly as well as if it was natively compiled for exactly that platform. Again, it depends on the exact implementation of the Common Runtime but doing incremental compile at startup isn't that problem if it could be a system similar to Steam for example where you could run a game even if it wasn't completely finished downloading from steam. So compiling the minimum of code you need to start the program and asynchronously push remaining code into execution memory frequently until anything is loaded correctly could give certain value here. I don't want to build something as this yet but was corious to know about the possibility and if (at perfect circumstances) the system could be realized there would be an audience for that
  8. Depends on audience. I talked to several people on tradefair and busines that ended up in "we could quit the talk here if you don't have anything fancy to show yet" >.< I'm not an artist, I'm engine devloper ...
  9. Keep it simple and build a core library that contains all these interface API code and/or split your code into modules so that each module is responsable for just one single kind of system. This makes it easier to port classes to other platforms as the "public" interface never changes to code setup on that core system while you could work on the core and it dosen't effect the rest of the game. Also don't overcomplicate features and code while writing your system ever think about if you really need just that OS API function or could it be replaced by something self written. Keeping this question in mind gives ya a small set of OS dependent features that are Filesystem Access Threads/Locking Window Management & System Messages Audio Graphics Network Input Accessing the filesystem as same as threads and locking could be done via STL but I decided to go for the hard way and was suprised that those implementations are very small and fast and you could do some tricks in C++ for example that make using your API more convinient. Drough::Thread<byte* (Drough::string)> FileFetcherThread(FileFetcherFunction); FileFetcherThread.Start("Test.txt"); for example is my version of a templated thread. Window Management was really simple too because you need just a few OS function calls to setup a window correctly and have it's visual style, size and position changed took me 4 hours of work until anything worked fine. Audio and Graphics is a little bit more tricky as this depends on the underlaying API, so I decided to skip DirectX support and focus on Vulkan/OpenGL (no need for me to go for Apple platform here), while I wrote my wrappers for GL and Vulkan by myself, there was a Tool I made that grabs the specs from Khronos GitHub and creates interface classes for. There is then just a little OS API code needed to load/bind function pointer to those interface while anything else is then managed by GL/Vulkan itself. The most annying part is Audio because you either need a plugin system or set to just one Audio API on each platform while building your code through code compiler. This maybe the only topic where I would accept to use plugins while in my opinion plugins elsewhere (like in OGRE) are a sign of bad or too general code architecture. Networking took me a while too because there is a difference between Windows and UNIX platforms you need to be aware of while general socket access is similar on Windows, UNIX and Playstation/Nintendo SDK, Windows is using a "wait until something happened" model for asynchronous sockets, while UNIX follows the "wait until nothing happens anymore" model. Last but not least input (if not handled through OS messages that I highly recommend to not use) is a special kind too. Without DirectX I even hadn't access to use DirectInput/XInput so the path to go here was using the HID driver interface (used for accessing USB devices). HID is mostly standard but access is different from platform to platform while you need Windows Driver SDK on Windows, there are some Libraries and also a Kernel Level Driver on UNIX while Playstation/Nintendo handles that through there API directly. Anything else about tooling and build pipeline was already discussed above. Something worth to mention, I wrote my own tooling using C# (because .NET/Mono runs on every platform too) to handle build files
  10. Shaarigan

    When x happens - trigger y? C#

    You create a "man in the middle" that has each sender send its events to and each subscriber register itself, there isn't any knowledge of that event manager that it has to take subscriptions itself or even tell any producer to register at it, thats not it's responsability rather than from all other components in your game. It is more or less simple and effective depending on your games architecture. I always feeled that this is enougth and even better in asynchronous/multithreaded code to have an external event dispatcher. My version is capable of addressing different channels with different types of events and runs a dispatcher as bakround task/thread
  11. Shaarigan

    mugen ps2

    Characters are 3D Meshes that have to be pushed to the graphics chip anyways. To make those characters just open your favorite 3D program and create them, then load them to the graphics chip via VBO (or the PS2 SDK equivalent). You could too create your charcters procedural as there are also functions to assemble the VBO by yourself
  12. Shaarigan

    C++ Common Runtime

    Hey everyone, I was fiddling these days with Raspberry Pi and emulation software to run good old retro games from my childhood and came across the question why there isn't a common runtime for C++ code. I avoid the L (for language) because I know a lot about the .NET CLR and it's general assembly model. The idea for a C++ common runtime is to allow precompiled code to run everywhere, on whatever archcitecture like C# does. Why isn't there something like that so we won't need emulation software for our 20 year old games? To prevent the discussion for platform dependent code and C++ optimizations, those are done by the C# CLR too and STL is also similar to the Framework code so bases are there. What are your thoughts?
  13. I was developing my engine for years from scratch, starting in .Net and C# using OpenGL from this community when I started to study game development at University. Iterations over iterations later learning and testing so it is mine too, my work and I'm currently at a point to say that I love working with that rather more as with Unity or Unreal. I worked in several studios, on a bunch of projects and intensive with Unreal and all foremost Unity reaching a point where I think (and some experienced people from the industry think that too) that those AAA related software is full of features that might be usefull to most people but lack of features we would need to run our games. Fiddling for workarrounds instead of just developing the game is quite annoying. It took nearly 10 years until Unity implemented native multi threading support and async code handling, it is a shame while using Unreal is gambling to support certain platforms (I needed to rewrite asset pipeline for a mobile port in Unreal) I decided a while ago to publish my code on GitHub with same voice in mind that you described above, giving my work of 1 &1/2 year (measured in standard work hours of 9 per day) for free so I wrote an EULA and was fine with publishing for everyone. I decided for a free to use but rev-share for commercial model to value the work and support if needed
  14. Shaarigan

    Compile time type name formatting

    You have seen the example on there GitHub page? struct Foo { int i; }; constexpr ctti::name_t FooName = ctti::detailed_nameof<CTTI_STATIC_VALUE(&Foo::i)>(); int main() { std::cout << FooName.name(); // prints "i" std::cout << FooName.full_name(); // prints "&Foo::i" std::cout << FooName.full_homogeneous_name(); // prints "Foo::i" std::cout << FooName.qualifier(0); // prints "Foo" } I personally prefer the CTTI/RTTI variant of the naming operator as it is more flexible (could be used with pointers that inherit/compose the GetType function) vua __PRETTY_FUNCTION__ trick template<typename T> inline char* N() { static char type[sizeof(SIGNATURE) - SIGNATURE_LEFT - SIGNATURE_RIGHT] = { 0 }; if(!type[0]) { impl::TypeName::Lock(); if(type[0]) { impl::TypeName::Release(); return type; } Drough::memcpy(type, SIGNATURE + SIGNATURE_LEFT, sizeof(SIGNATURE) - SIGNATURE_LEFT - SIGNATURE_RIGHT - 1); impl::TypeName::Release(); } return type; } template <typename T> struct GetTypeName { public: static inline const char* Name() { const char* typeName = FullName(); static byte offset = 0; if(!offset) { impl::TypeName::Lock(); if(offset) { impl::TypeName::Release(); return (typeName + (offset - 1)); } const char* tmp = typeName; for(; *tmp; tmp++) { if(*tmp == ':') offset = static_cast<byte>(tmp - typeName); } if(offset > 0) offset++; offset++; impl::TypeName::Release(); } return (typeName + (offset - 1)); } static inline const char* FullName() { return impl::N<T>(); } };
  15. *bump* Still working hard on the project. There will come a project page (maybe)
  • 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!