Jump to content

  • Log In with Google      Sign In   
  • Create Account

SuperG

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

Posts I've Made

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.

In Topic: how could unlimited speed and ram simplify game code?

24 March 2016 - 12:30 AM

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.

In Topic: Game Engine design for many-typed many-copied entities

19 March 2016 - 12:09 AM

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.

In Topic: Game Engine Architecture: what's after that?

28 February 2016 - 04:14 AM

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.

PARTNERS