# All Activity

1. Past hour

3. ## hex grid

Phil, is this your website? https://philbivens.wordpress.com/phils-resume/
4. ## Game Engine API, smart pointers or not?

No. I don't use threads. If obj A creates obj B and stores a pointer to it.(E.g. to get the position or communicate something else). The because of some player action, obj B is deleted. Now obj A has an invalid pointer. So obviously I want there to be a way for A to check if B exists. E.g. a weak_ptr. Anothrr solution would be a messaging system or a table containing all valid GameObjects(and then check if the pointer is in there), but that's waayyy more work than using a weak_ptr. I'm not a fan of handles as it doesn't play well with oop. I would prefer going the pointer route. So you are saying shared and weak ptr's are ok when needed. And I should use raw ptr when possible?
5. ## Vulkan? OpenGL? What........?

When you say game engine / graphics engine, what functionality exactly do you need? It is probably a pretty low priority for most general purpose engines, as most people don't need 64 bit coordinates, and many of those that think they do can usually get by using a different method (moving origin etc). It's unlikely to be necessary for e.g. character animation / skinning, particle effects... So if you are making a general purpose engine, you would presumably either: Make all 3d math 64 bit and make 99.9% of people pay the cost for something they don't use Support more than 1 precision throughout, which could potentially multiply complexity and bug potential unless done very carefully If it is just CPU side, can't you use your own 64 bit classes, then downsample to 32 bit for rendering? Dave Eberly's classes (https://www.geometrictools.com/) are usually designed to be able to change the bit depth if I remember right. Most of mine are written similar way with templates so it is easy to change whether a float is 32 or 64 bit. Without more information is hard to say more. API wise for multiplatform I bow to other's knowledge, but personally I'd be strongly tempted to use a third party abstraction layer like diligent engine or bgfx if at all possible. As Hodgman says it depends very much on what you mean by multiplatform. There's consoles, and then there's the wild west of OpenGLES on mobiles.
6. ## Game Engine API, smart pointers or not?

My personal preference, be it C, C++, Java, .NET, whatever, is to have functions either return unique ownership (normally a new object, which is then the sole responsibility of the caller), or to return a reference/pointer to something the API still owns and manages. In C++ unique_ptr and raw pointers fulfil that nicely. For function parameters, the same deal where possible, the API either takes ownership, or just uses the reference for a fixed duration, normally the function call itself. Sounds more like a create. I think the problem here is the "deleted at any point". What is able to delete it, why is it? Are you multi-threading the game logic? You definitely don't want an API design where a pointer/reference/etc. gets invalidated by some other thread, maybe before a create/get function even returns. A solution I used with a couple of things was to say my object references must stay valid during a particular update frame (I was essentially storing them in std::vector). This meant any pointer within an update was guaranteed safe, but I had to use unique ID's to track specific things between frames. I think it is important though, even if you do use "shared_ptr" or "handle", or even in languages like Java and .NET, to try and stick to a single ownership model for object lifetime where possible, as it is easier to think through, and even garbage collector languages have things it does poorly (Close/Dispose/etc.) or the possibility of memory leaks (e.g. forgetting to remove things from collections). e.g. in this case you object is probably still "owned" by the scene, and once removed it is marked "dead", removed from the scene collections, any getter fr it returns null, it's not rendered, no physics, no updates, etc. and any remaining references are mostly just a safe way for other objects to see it "is dead" in a safe way. unique_ptr has literally zero cost, shared_ptr you probably want enable_shared_from_this (or traditional intrusive ref counting). You probably regardless want to avoid using heap dynamic allocations for objects. The fastest is generally going to be a vector<T> of values, due to continuous memory, but sometimes that is not practical.
7. Today
8. ## Maker4D - the 3D RPG game maker engine

2019 april 22. -Some graphics bug causing a line on background on some computers were fixed . -Animation code is now more optimized. -The software renderer is optimized. -Fixed a loss of keypress-processing on very low frame/second when running on Linux. -Added new code paths for x86-32 and ARM builds that uses more branching and less FPU instructions. -5% overall speed-up. 40% speed-up on old Cyrix based computers. -More than 50% speed-up in the Android version on ARM CPU-s.
9. ## Game Engine API, smart pointers or not?

You could use handles. Instead or refering to objects directly with pointers, you could have a Unique id attached to the game object and then obtain the pointer (everytime when needed and don't cache it anywhere) using that handle. A lot of people are doing this. If you want the pointer approach shared_ptr+weak_ptr could do the thing for you. And if needed you could still keep the raw-pointer version when you don't need to cache the object, in order to reduce ref-counting (if retuning by share_ptr<T>& won't work).
10. ## Game Engine API, smart pointers or not?

Ha! You're here from Reddit I see So you know mostly what I will say.... One thing though........ How can " the newly created object could be deleted at any point". The only way this can happen is because of other threads and if that's the case you could have some race conditions which is another whole can of worms. Now I see why you want to use weak pointers. But first, am I understanding you correctly in that other threads can delete objects you have a pointer to?
11. ## C++ Game Engine API, smart pointers or not?

Hi, I'm writing a game engine, when my API returns a pointer, most of the time it is meant to be used and then discarded right away. But I have some things where it might be useful to store the pointer. E.g. addNewGameObjectToScene. It would create a new object, add it to the scene, and return a pointer. But there is one obvious problem, there is no way to check if the returned pointer is valid. Because the newly created object could be deleted at any point, and then the pointer is invalid and using it would cause crashes. Therefore, to me it would make sense to use smart_pointers to fix that. But have found that not everyone agree's with me on that.(And I personally don't like to use smart pointers in api if I can avoid it) So what do you guys think? If I should use raw pointers, how would I fix the issue, and if I should use smart pointers, will it impact performance or drive people away from using my api? Thanks!
12. ## Large Tilemap Storage

There are different ways to store it, but in a 3D array, the extra dimension would be the map sections. If you have a large map, and you cut that up into, say, 64x64 tile squares (which is your first two dimensions), then you can think of the 3rd dimension as if you picked up all those sections stacked them up, each section has a place in that stack, which is your third dimension. Up to this point, you just have all the sections themselves defined, but not how each section makes up the larger map. What you need is a way of relating those sections in the larger 2D space of the map. One way is another 2D map -- think of it like a tilemap within a tilemap, only the outer tilemap contains map sections. When you draw, the sections might be 1024 pixels apart, and tiles might be 16 pixels apart. You'd find which few sections are on screen, where their corner is, and draw the tiles within it relative to it's corner, then you move over 1024 pixels where the next section is, and then draw it's tiles. Your drawing loop is now nested four levels deep, rather than two. You can have a single 4D array, or a 2D array (the section map) and many smaller 2D arrays (the section tilemaps) -- and you might collect the section tilemaps together as a single (now 3D) array, or not. Now, really, if you want to think about streaming a very large map, is that you don't have to have all the sections in memory. Just the ones that are on-screen and a few nearby so that the player never sees them loading. In that arrangement, you'd not have a 4D array, or even a 3D array of map segments. You'd have a 2D array that's the map of sections, and each of those would be a pointer (or reference) to the small tilemap for that section. You load only the tilemaps for sections nearby, on demand, and you can free the tilemaps of far away sections as needed. If that's not clear, feel free to ask again. But do keep in mind that all this complication might be unnecessary. This streaming sort of set up really only benefits you if tilemap memory use is high, or if loading the entire large map all at once is noticably slow.
13. ## Modular Influence Map System Demonstration Videos

really interesting, Dave! I have always been a fan of influence maps (variants of Flow Field, Distance Maps, etc) in their power for pathing large numbers of agents. You have gone much further and utilized the information in a way which brings about recognizable behaviors without adding an AI system - very impressive. As you hinted, combining these with an AI system would seem to be very powerful and lightweight. Question: Have you found a better (memory or speed) method of storing your influence maps beyond a basic array? Although using the info in an array is exceptionally fast, I am always concerned about the amount of time it takes to re-generate the maps. I have used my own hand-rolled 'brushfire' algo to regenerate partial maps (only the parts that have changed), But these videos of yours seem to show each agent with their own influence maps which are being regenerated with every movement of that agent. Seems like it could get overloaded quickly in scaled up version - am I right? or is the map creation pretty trivial even at scale? I assume there might be one general purpose 'static obstacle' map utilized by all agents for basic pathing, but the threat maps and ally maps are fully dynamic and need to be entirely recreated basically each cycle or so...right? What am I missing in my thoughts here... I will look at your other provided links also to see examples of combining with an AI system to see exactly how you do the 'combining' - I am gathering each AI definition will have the methods of utilizing the available influence map information hardcoded into the AI method itself (though, I guess you could make it data-driven just as easily too - which is something I note you like to do in order to make your software more generalized, powerful and applicable to different situations.
14. ## FSM, BT, HTN, Goap, other

I am both a big fan of DaveMark, and, a fan of GOAP - though it has some severe limitations which Dave points out. I think of GOAP as a 'Dynamic Script Generator' - given a particular Goal, a GOAP routine will search through all possible strings of possible Actions to find the 'best' (as defined by the programmer) one to use in the current situation. There are ALOT of ways to make GOAP more efficient (mostly methods to reduce the exponential search space by pre-filtering possible Actions given the situation). But.... I really like Daves' IAUS system, but I don't think that it is useful multi-turn action sequences, especially at the level that GOAP can do it. But, it might be possible to utilize some sort of hybrid which focuses on the best parts of each - during Combat situations, IAUS is an all-around winner... but when talking about more 'simulation' environments (general townspeople doing townie things), GOAP action plans (Dynamic Scripts) work well because they rarely get 'interrupted' and need re-planning. your thoughts, Dave?
15. ## Large Tilemap Storage

So are you saying that I could use a 3D array to store the map, with the added dimension being the chunk being referred to, and that each chunk has its own cartesian planes?
16. ## Battletech Developer Journal - 03

I love your write ups so far. I thought Piranha Games was the only outfit developing anything from the good ole days of the BT universe. I'll have to pick up Battletech on payday and get some more of my mech fix.
17. ## Zeno Clash 10th Anniversary

Today marks a very special date that is dear to us here at ACE Team; 10 years ago on April 21st we released our debut title to the industry. Zeno Clash launched on Steam and with it we were honored to receive the support from our awesome community and the recognition of the industry that saw something unique in our first offering. We wanted to celebrate this anniversary, so we've produced a commemorative Zeno Clash 10th Anniversary theme, developed by Patricio Meneses, accompanied by an awesome illustration developed by our collaborator; Rodrigo Gonzalez Toledo. You can access the files here or through the following links. We hope you enjoy the materials! Zeno Clash 10th Anniversary illustration developed by ACE Team's collaborator; Rodrigo Gonzalez Toledo. Music on SoundCloud: --- It's been a wonderful journey so far. Thanks to all our supporters and stay tuned for more ACE Team developments this 2019, as we are currently working on multiple exciting new projects!
18. ## Large Tilemap Storage

A 2D array is usually more than sufficient for 2D map storage and iterating through it. As long as you're not falling into any performance anti-patterns (e.g. drawing the entire map instead of just the screen, not walking the layers/cols/rows in memory-order, failing to batch draw calls, etc.) Draw efficiently, iteration is not going to be your bottleneck. Back in the day we were drawing 320x240 screens with ~450 tiles (1 dense layer + 2 sparse layers) using software blitters at 60fps on 66mhz 486s, albeit at 8-bit color. What's often more useful is chunking the whole map into regular sections, either so that you can stream them from disk or just to keep memory use down if it's a concern on your platform -- but that approach ultimately only amounts to a 2D array of map sections, which themselves are 2D arrays of tiles. Even something like a quad-tree is likely over-thinking a 2D game. There's an article floating around about optimizing minecraft-like cube storage, where they looked at various more-complicated storage schemes like RLE arrays and compressed octrees -- the conclusion was that plain old 3D arrays were the winner anyway, and I think Minecraft world sections are (or were) something like 32x32x256. Drawing performance comes from how they generate and optimize draw calls from this simple storage, not coming up with any sort of clever storage.
19. ## Toon Shader Using Unity

This tutorial is published with the permission of Erik Roystan Ross of https://roystan.net. Roystan writes articles about game development using Unity. GameDev.net strongly encourages you to support authors of high quality content, so if you enjoy Toon Shader Using Unity, then please consider becoming a patron. You can view the original article at https://roystan.net/articles/toon-shader.html. Source code at https://github.com/IronWarrior/UnityToonShader. Become a Patron! Interested in posting your articles on GameDev.net? Contact us or submit directly.
20. ## 2D Large Tilemap Storage

Hello - I recently started designing a tile-based game, but I'm not exactly sure what would be the best method for storing my tiles in the map that will be displayed. I understand that most maps are a simple 2D array with each dimension representing the different axes (x, y), but my game has massive quantities of tiles that need to be displayed at once (I don't have an exact number, but I know it will be over 60x30, which is 1800 at once). I'm fairly certain that the aforementioned construct will be too simple and costly for my needs. I'm also looking to delve into simple procedural generation in the future, meaning I want my method of storage to be able to be easily modified/populated. The best analogy of a game I could give for reference is Terraria, since it has both procedural generations and a bunch of tiles. To simplify, my question is basically: What would be an efficient way to store a map with large amounts of tiles (in the thousands), while still allowing the construct to be populated relatively easily? Thanks for any input/help.
21. Yesterday

23. ## WM_LBUTTONDOW/UP events not coming through from touchpad when long pressing

Not sure about the Direct Manipulation API, which bit/interfaces were you looking at specifically? I was under the understanding it was built on the window events, but maybe I understood it wrong. I am surprised raw input didn't report anything, which exactly did you register for? I am sure I recall some stuff specifically about contact points / touch pads. There is also WM_TOUCH, do you get any messages for that?

25. ## C# per pixel displacement mapping with distance functions

Hi everyone, I'm trying to implement the displacement mapping technique by William Donnelly from GPU Gems 2: Chapter 8 for a project. I'm working in XNA/MonoGame and using HLSL for my shaders. The problem I'm having is how to create the distance map and I'm not really understanding how I would go in creating it. I know that Nvidia has released the code for that chapter but the files are in c++ and I'm not familiar with c++ so its been throwing me off on how to recreate it in c#. Any explanation on how I should go about in creating the distance map would be extremely helpful. Thanks for any help or suggestions.

• 17
• 9
• 15
• 60

1. 1
2. 2
3. 3
4. 4
Eck
6
5. 5
• ### Member Statistics

• Total Members
255868
• Most Online
6110