Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Oct 2007
Offline Last Active Yesterday, 11:39 PM

Posts I've Made

In Topic: Multi thread rendering engine

18 September 2016 - 04:11 AM

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.

In Topic: Space Simulation Game Design (Finding The Fun)

07 July 2016 - 11:57 PM

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 .

In Topic: Component based architecture .... for game!

14 June 2016 - 05:40 AM

>>  It's how often you combine these things into game objects like ships, or cars, and make new ones with tweaks etc.  [/size]
that's what i call defining a new "entity type". IE a new kind of "game object".   some games must do this often and have many people who must be able to do it with various skill sets, and some games do not. like most things it depends on the work to be done, and the size and skills of the team.[/size]
IE if you were going to bang out pong, pacman, galaga, space invaders, or missile command, etc. by yourself on weekend just for fun, you wouldn't bother with ECS.[/size]


Personally, I like the Unity approach. You get most of the benefits of components without the unnecessary trouble that complete decoupling causes. None of the games I've worked on that shipped - or the ones that were cancelled! - used the "entity is just an ID" mantra because it buys you little but costs you a lot in terms of code clarity and predictability. Some of the people above will disagree, obviously.

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.

In Topic: when to use concurrency in video games

13 May 2016 - 11:28 PM

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.

In Topic: OOP and DOD

27 April 2016 - 06:20 AM

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.