SuperG

Members
  • Content count

    82
  • Joined

  • Last visited

Community Reputation

1300 Excellent

About SuperG

  • Rank
    Member

Personal Information

  • Interests
    Design
    Programming
  1. How to learn from Quake source code

    Want to learn C++ to but. Problem I have with these old engines are. its legacy C & C++ Modern C++ gets Functional features. The C++ I would go for is at least from C++14 to 17 OpenGL has modern replacement Vulkan. And those very old engine are made for old single core Hardware. Modern CPU can do a lot of threads. Why is John Carmack so interrested in Functional programming?
  2. That true, and a toy project is not good proof. But the point is to solve that isue of bad use of caches and CPU prefetching. Is fall back prety fast to OOP or braking DOD rulez. the point is to move on into advance solution. In DOD it might be done differently. Posibly counter intuitive. But probaly doable. First thing in mind. keep DoD pure. EntityID Key. Take out use of pointers make Entity and components moveable in the array. that gives many way to sort and move to other systems Position used bij few Systems one pure of position PODs other POD including position and orientation other POD inc. position and velocity. That a direction to pioneer into. Reusing and sorting Component if entity start moving the positionPod and movable is put in pod incl position and velocity in other system for these PODs i think this is normalizing tabels by having multiple tables without gaps. excistance based programing. It also means iets system act like booleaan no check for Null. As no pointers. That direction solution could be viable.
  3. Lot of asumption. And conclusion based on? OOP did already a fine job! DOD failed? But I mis a lot. Wat is the prime goal of licencable engine for the masses. That lots of indie dev. Is fully implemented productive content pipeline. Not as part of the engine. But where the engine is crusial part off. The editor is it most important feature of Unreal or Unity engine. Well somewhere there is a time the game industry went from hardcoded to scripted. It a long time ago. But wenn Epic went for Artist productivity by script engine avoiding lot of recompiling , the trade of is huge , but the gain in production time to. If performance was everything then Microsoft Flightsimulator was not the last game made in Asembler.And when giving DODECS a datadriven feature. And choose a scripting engine. Use more Data oriented way . Might be no Lua. As for ECS vs OOP sound like a lion vs dog. But it should be kat vs dog and do I need lion or not? So to me ECS is a solution to specific problems and need. More pattern. DOD is more counterpart of OOP. Then this opinion "ECS DOD sucks because first adventure with DOD has worse performce then OOP?" OOP does so well because of this. Programmer with 10 years oop experience has lot of oop solution in head for pletora of problems. Modern Core have logic to mask effect of jumping around in memory. Where in- ordercores get much bigger hit. ESC is patern solution for some specific problem. Where DOD paradigm solution that fit group of problem best. So what is better OOP or DOD, but wenn you have not that 10+ years experience in DOD way of large pack of solution for that paradigm. Then the flaw in ECS DOD is not that solution choice , but lack in experience. John Carmac experiment with Functional programming. But to make case if it better or suitable for making games he need to port a full game over as proof of. He didn't have the time as busy he is. Like A Doom port. Might be on his bucket list. There are other pet test that show poor performance for ECS and DOD. Even very small games wich do not need ECS. Like order of pong clones. but if you use DOD for optimisation sake. it is as mention before to design the data layout to fit the memory acces paterns in where the CPU cores and mem prefetcher likes it a lot. The problem here that this a advanced part of DOD where experience matter a lot. It could be a beginning DOD programmer like me and most, choose layout a dozen time failing by choose a dead end , where experience dev the attemps need 5. As a example. depending on game complexity there might be need of high experience level. The major problem of ECSDOD is the high OOP experience in the gane industry. Where triple A senior programmers and there engine tream know how to tackle complex problem the OOP way. The problem there is that to get te most out of CPU the need for advanced solution to get the most out of many core CPU. Which is paradigm wich scales well on many core CPU. T-machine RDBM link is not that weird. There it is the norm to have many core and multy CPU database serving. It not easy task either and also there is need of high experience level to solve any and specific problems. Where game is weird data base with Complex and big with very large items. As with John Carmack and Bruce Lee. There need of proof for any theory. But that the problem. You need a master to proof of a martial art style. You need game studio with triple A project who hire DOD and RDBM experts as Senior and lead programmers and architecture designers. With a game of substatial scope. Why is John Carmack so interrested in making games with pure functional paradigm? Why is C++17 still including the more Functional paradigm to it. If you want to make a big scope game and push the tech. Then you need this first optimisation of effectively use of many cores in near infinite way. A paradigm that is many core friendly. Not only in save multithreading but performance schaling to. That the chicken egg problem. I don't expect a ECS DOD triple A titel any time soon. It big problem and it isn't sure if it is posible. But there is no proof if or not OOP<DOD. I have read T-machine blog to. But my prime reference for DOD is DOD online book by Richard Fabian. So in that mentioned Example of caching solution template. In DOD you layout the data to mimic that. Not easy task. Much more advance problem not seen in very basic ESC solutions. But in pure DOD ESC you use existance based programming, each component type array is in it selve a boolean no Null check. no pointers. So sorting and moving components . In database terms it called normalisation of tables. The problem with experimenting with DOD is that big urge to fall back to your well know experience of the OOP way to solve isues. DOD have it own pattern and antipaterns. But experienced programmer in that field are rare in the game industry. At least experimenting means to be open for other paradigm. But it isn't clear that some pattern are the same while for the one a good patern might be a anty patrn in the other. So OOP might be mixable. Possibly more at layer level. And thirdparty libs you have to interface. There for also that huge resistance to other solutions. in Game code complete Book 3th/4th edition. Example of big resistance to refactor to more Component oriented architecture for Sims.
  4. I have the same problem. I notice this. If follow John Carmack , yes his step from C to C++ is very old one. His newer adventures also years old back is with Haskel. So that Funcional programming with pure Functional languages. in these day there is still C but C++ is C++ C++98 C++11 C++14 and C++17 so the long livaty of C++ is it legacy support and it still evolving. D is the language is the one wich drops legacy i Notice hard defending of OOP. But I also Discovered the combination Functional Reactive programming. Because CPU get many more cores so side effect less , lockless programming and much easy way of archieve that with paradigm that support it from it core. Without being guru to tackle that major problem of concurrent and parallel programming. In paradigm wich seams to come from the single core time. John Carmack interrest in Functional programming has to mean something. What is the relation of functional with DOD
  5. There are much more reasons for ECS then performance. In that case Hardware is important and the most obvious thing about current hardware is many core CPU so Multithreading in efficient way. AMD is comming out with friendlier priced 8cores with SMT. So 8cores could become the new 4 thread limit. So utilising future CPU and wat mainstream wil become is supporting beyond 10 threads? Those other reasons depend largly on what type of game you gonna make and if ECS is solution that support specific features best. ECS in the DOD way offers this. If you game have high numbers of entitys. If you have lot of different types of entities. If you can assemble types in runtime. If you want to procedural generate types with different mix of components. If you want to change entitys runtime. A bad case for ECS is 1 on 1 counter sniper game with complex balistics. A good case is game like Arma where few units spam bullits with 2K to 10K Rounds per minute from gatling gun. Mounted on armored units air units attack heli in large scale warfare. A even better fit would be space game where there are no fix classes but design units in game with procedural but can also load design in or designing ships is part of core game. ECS for game like Pong or tetris clone. Then ECS might be huge overkill solution. My idea of space game is like as with cars naval ship. In Century of carse there are a lot of types spread over years in the few hundres so procedural need. Naval most ships have a specific design and there are only few build of the sane type and bigger the more uniek they are. Also lot of diversity. I expect the counter part of T- ford to bugaty Venyon in space. But also naval counter pars of century of torpedoboats and nimitz class carriers. Many types of bombere fighters frigates of centuries of space Warfare. Often you don't rely on ECS but my case i might need it badly.
  6. UML diagrams for video games

    The way I understand it. UML is a standard. And it explains it self rather very well. The L wich stand for " Language" It purpouse it to communicate Modeling. If both participant know UML then they communicate the model to each other. If only one ore none knows UML but uses there own way of expressing model. Sketches. Then they need to explane what it means to the Other. Me thinks in specific branches like game development and small teams The use of it is often not needed. But in large corporation with huge teams and lot of junior programmers its good thing to speak the same language and know the same modeling language. In software where there is lot of change and no clear target as in games. But in large scale bussness software where there is legacy stuf from decades no drastical changes. But if new employer come in they can read the UML and see the bigger picture or that part of the package or module. Two fictional examples. Mostly in UML example they come from bussness side. Like bank where your department team design the ATM software for specific new ATM model. In this case the use cases are clear also as it done before for older ATM models . In your team are two new employers. If corporation uses UML and the new team members knows UML . Communicating the job can be started right on. Indie dev team of 5 experimenting with new idea going for prototyping a few ideas How do you usecase gameplay and fun. Where most are self tought programmers and there dev experience are of one man to less then 7 teams . No UML. Sketches wil do. My experience as first impression of somebody else software base. A DX11 example bundle and framework. Then I compile that frame work of other dev from internet as DX11 example bundle . You see long list of project which depend on other projects in that list where some project are end app tech sample demos using the framework project. Mixed in that long list. With in each project there is huge list of .H and Cpp files where there is no insight of dependancies. In my own very little pet project it not a problem one project and a short list of files. My own project are so small I don't need UML. I am alone so for Communicating with myself. Make sense after 6 month I have no clue what I did. If my project got bigger. It would be nice.
  7. Multithreaded renderengine is not the same as a multithreaden game engine. To me it means the render system or component and render backend is that multithreaded or not. DX11 supports multithreaded with defered contex , but the result of that , it doesn't yield much Gains. With Mantle and DX12 and Vulkan is it possible to use eficently multithreading for rendering and ACE Asynchonoc compute engine For rendering compute and kopy Engines That means if your game load and GPU settings are CPU bound. Like a huge amount of drawcalls. And with these new efficient low overhead API it factor 10 x or so more drawcalls are possible compared to the old API. So to me it seams do you want to render multithreaded and go wild with drawcalls then you need DX12 or Vulkan. Where the game engine often already is multithreaded and there is also the same isue you can do it easy way with low or limited gains , or better advanced ways where you can gain a lot. Multithreading game engine is is something differrent then multithreaded rendering. The last is specific the new API and the whole engine is complex topic to not only multithread tread save but also do it efficently so to scale well on more cores. But also beyond 4 cores. But the render component is part of the larger full engine so there architecture need to fit very well so they are strongly related. So I would read into DX12 multithreading. Don't know yet if my DX12 book dives deep into that matter.
  8. X- series I have a lot of fun with . But not Rebirth which is very different . The problem with Egosoft is small budged complex game production . A production that don't fit within budged . Bad decision to try go for consoles . Where unfinished rushedout games are blocked . So there 1.0 releases are Alfa sold as Release games . Where 2,x are Beta . Depending on mod community to fix thing to finish gameplay mechanics and making it feature conpleet . Because at that time there wasn't anything big in the genre . They where the only one I thank them for supporting the genre . Now the genre got mild revival . They did some thing right compared to current big ones . And that staying away from MMO . Biggest problem is A cumbersome GUI that not fully implented and a hog to handle the farious gameplay the game offer . Yes they did have carriers but with no GUI and gameplay workt out for it . There where mod to ease the pain. So because my interrest in game development I get strong impression that these complex games depend highly on strong AI and GUI development . As one person can not manage a whole nation doing work of milions and babysit milions .
  9.    As Norman Barrows stated. It depends on the game. The example there don't need it. Entity is just a ID is used in the Data Oriented Design. The value of that and its features used in pure form might be noticed in much bigger game. The way it noticed is if you got a lot of something. If entity need to change component on run time. Move components in memory. Make new entity by combining components even in run time. I think it would be noticable the benefit if your making a game. With the scope of. A Space tactical stratigic game , where game is about * In game design ship types . By player content driven game. Not just data driven but beyonpd that. * in game tweak components stats . Bigger ship can have bigger guns. * build fleets . * And watch the AI fight it out or act like armada Admiral player vs player etc. * if you got carriers with dozen types of Fighters etc. It makes Entity in numbers very large. * drone frigates it can make entities insane. Launched 300 or so in a X series game. * Missile frigates. Missile barage like Egosoft Xseries Then a more pure form of ECS the DOD way make sense. There are a lot of games from small to big there is not a lot of something and no need to mutate objects. So it make no sense to go with ID for Entity. But there are game concept where it have great value.
  10. Correctness as in contex as thread save. Avoiding deadlocks or share data that depend on order it prosces from few treads. If it save it correct as no deadlock crash or corrupted data, but not parrallel as if you trow a tradfic light on place where many lanes garther. My guess is to use parralism to the max the software solution needs to be designed with parralism in mind not only thread save. Making computation as non dependant and avoid shared data. Avoiding deadlock by design and critical section stuf.
  11. OOP and DOD

    Yes it is confusing for beginning programmer like me. But this is how I see it. By my observations and readed articles about it. OOP is way to handle growing complexity as software base grows larger. It a way to split software enginering over many Programmer. Tackle large scale software engenering. I think. It is learned in software enginering education so it where beginners start to come in touch with it. As I did not have that education OOP is as vague to me as DOD. But I am into C++. As for games they say start smal like a phong clone or space invader. Then with a language where easy'er to start in and full supporting OOP. Make little game that runs everywhere even in browser. Like java. Or C#. They say DOD is about optimisation but its more. It is also about hardware knowledge and build a solution that fits hardware at best for a very performance and tech pushing software problem. That last is crusial part that makes DOD relevant or not. As the best example of this case is. Where you have high need to push the hardware. And the hardware is very sensitive for OOP misbehavior. And you problem there is lot of thing to compute. So first you need to know if you need DOD. 1 ) A platform exclusive means you can focus on optimise and learn the platform and it architecture in deep detail. 2 ) A platform that much more sensitive to OOP waist of bad memory acces pattern where compare to common used CPU 3 ) a software solution that need to get the most out of it. 1 ) A console Exclusive! 2 ) A in order cpu with lack of big caches but predicable cache latency, a excotic beast the Cell CPU of the PS3 is. 3. ) a PS3 triple A game exclusive. But not exclusive there are exception, like for crossplatform titles to get PS3 up to level of other platform might need to invest in PS3 port team with same need to delf deep in it architecture. Studio with dedicated game engine team. Can do this to. That why some of the pro DoD article come from developrs who worked on PS3 exclusives or advance port, like a very hardware demanding cross platform title to utilise PS3 to it fullest. Like DicE Thus DOD is about high performance computing and hardware knowledge to take full advantage of it. It where advanced software enginering, meets hardware architecture knowledge. As a next step beyond a advances and experience software engineer. Who need to be expert in architecture to. This means that for console release exclusive, this expertise of platform is starting to grows with each production.The next big title 2 of the same dev they get more knowledge get even more out of it. So sequel 2 on the same platform looks much better. This keeps growing to where the 4 th big title get even more out of the platform because of the growing platform architecture knowledge and game show this leap in understanding of the platform. And then nextgen comes. These DOD guru need to learn a new platform and it architecture again. Where small titles running on whatever platform it undoable for smal team to figure out multi platform Or don't have the resources or the game is not that demanding. As for PC you have this wild configurations posiblities. From game related articles DOD seams to fit ECS very good. The reason that DOD ECS examples can perform worse then OOP because it tested in small tech demo example where there often is no deep knowledge of the platform tested on. Often these programmers have high OOP skill but DOD is new . Where platform often can handle small scale OOP bad behavior because CPU it designed to handle most common software by having large caches, out of order cores and advanced branch prediction units. And the DOD solution uses probaly the wrong data structure. Or the array size is to small or the mix OOP with DOD where OOP works as anti DOD Patern. Also those who sucesfuly utilised DOD on PS3 CELL. Also uses thos SPE units all 7 minus reserverd ones. So comparing DOD singlethreaded solution to a OOP single threaded solution is not the real practical gain. As hardware architecture for DOD is crusial so is multicore CPU use for them. Also a unused iGPU on APU is wasted architecture compute power usable with C++ AMP OpenCL or DirectX compute . Most DOD examples are ECS based and uses often a OOP mix. So first you need to have a game idea that is so demanding that you need those 8 cores . Know the hardware as deep as posible. Which bit limited on PC platform. But C++ is also for managing memory. So to me Java for DOD is step back. It best to delf first deeply in the theory, then follow programmers that just start using DOD and draw hard conclusions, often fallback on OOP very fast. Thus DOD mixing it with OOP. And DOD turn out bad. So have bad experience with it. A good start is Richard Fabian online DOD book. As it hint to DoD solution for OOP solutions, that important if you know the OOP way but Running into a wall with DOD. My guess is its big advance topic and that online book explains it deeplier then any one does to my knowledge. So what do the expert here think about that online DOD book.
  12. Unlimted speed & memory No need for optimisation, auto or compiler wil do. The highest level of language wil do. So you can talk to the computer in human native languages . And feed it with full mathematic writing. Using the full formulas for every finegrain computation. With very fine delta time of 1 millie sec for physics computing . For each NPC AI & AL can be implemented in most full & complex way. Even rendering optical sensing for AI and run analistic computation on that for every AI NPC. So to 3D sound. Game worlds and all it objects and entity are photorealistic and full interactive. With full material atributed in volumetric way. Like also material based destructable.
  13. Some say early optimisation is a bad thing. But it could be mostly true but not that black and white, more be a 20 to 80 rule that there is lot grey area. Some post upward it mentiond that ECS is multithreaded friendly . Multithreaded is a optimisation for scaling and higher scope games that got and wil be more important as utilising modern cores. While quad is mainstream now we going beyond 8 plus hyperthteading. It isn't about thread save only, but also effecient parralel computing. ESC using more pure Data oriented design support that much better. As efficent parrallel computing relies on software architecture and method paradigm used. While OOP and ECS and DOD are mixable. But some benefits of DOD could be destroyed by mix it with OOP. It could be that some ECS architectures perform bad because of that. For small games where scaling and heavy multithreading is not needed its no isue . That my observation by reading a lot on ECS. And are interrested to in ECS scaling and use for big scope games.
  14. Game Engine Architecture: what's after that?

    The advice is valid and I have the same isue. But if the goal is to build a engine for your games. The advice is to make a game and engine wil show up after iterations and refactoring to reusable architecture with split of framework to engine and the game specific part. That make sense! But instead of Game to show of your engine. I think that needed for large engine team who there engine is the licencable product need a game that show of the game engine. You get a full game which feel like tech demo but is full game. IDsoft first games of each IDtech engine. That make sense! But we are beginners. Not big engine building studio or team. It doesn't have to be a full game. But a short basic barebone short core feature showing tech demo. Like short minimal feature playable game. That means your first version of your first playable tech demo. You need only the most needed features to get this first minimalistic game running and full playable. That means it will very light on content. Using simplistic asset done by engine programmer. No need for content production pipeline. Because that get hard needed when you go for full game and need lot of assets and levels etc. Choose if simple MPlay like splitscreen. Or NPC not both at ones. Add one feature per iteration. Or shooting NPC which are light on AI. Like astriods for space shooter. Zero AI needed. Go for pure procedural first so the need for artist is low . That the plan I go for. Also often these example source code do work. But if not debugging and get working is big learning experience. Also what I did is rip a depricated math lib out and put the current in. Go from 32 bit build to make it 64bit build. And I drop the 32 bit. I got both books. But they are bridge to far. But shows what is the end road and it a lot of features big and small. So long road to go. Like they both mention memory management. Like my old dev PC is a memory limited platform. Not for the first 100 iterations for a demo. It got 8GB with old quadcore from AMD. It not the sinclair ZX81 where you bound by extreem low amout of memory. And for the first low number of simplistic dummy asset a big enough memory waisting memory pool wil work. For now. And Reusing objects. How ever at some point where you get to make a full game the asset needs wil grow and memory footprint grow and then more advance memory management is needed. Also where you come at point to release a demo, having memory management keeping using to much might make your target audience smaller. But then again its tech demo. I would priortise features from the minimal game demo and add and refactor for the next feature that make the most sense like depend on existing implementiation of features. A good example are astriods. No AI as they are not NPC and no Mplay needed. To make it chalanging there can be a lot and moving fast. At some point there comes a enemy space craft but not before static mines. Then defence satelites. For FPS shooter Classical zombie. No need for advance AI. But before that to avoid animation, some low tech robot like man size big vacuum cleaner but with a weapon. After the 250 next feature itteration the demo have nice feature pack so does the engine . In my case I go first for the most abstract and feature poor minimalistic abstract space shooter tech demo, that could grow to big genre merger and stil be in demo low asset state. And sticking with procedural content.
  15. Unity Structuring a Simple 2D Engine

    Simple game might have a very limited number of features. So a very basic game engine with at least those few features will do.