Jump to content
  • Advertisement
Sign in to follow this  
ChuckE

architecture of game engine

This topic is 1223 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there!

 

I am currently not developing game engine because I do not have enough knowedge for know. However I'm planning to do it one day. So I want to make some preparations till that time.

 

However I've been wondering about something.

 

Is it possible to implement something like...

Virtual Machine for game engine with unified VRAM and RAM? I mean during its life cycle, game object does not know that it has some data being operated via GPU and some data being operated via CPU & RAM. So basically it means that even for me during game creation or programming I have no need to know that there is GPU and CPU tasks - I simply create object and all required duties is being done my virtual machine.

 

As far as I can understand if it is possible to implement it means that there is a need to create custom set of instructions, which will do GPU and CPU & RAM tasks?

I don't know whether it can be called virtual machine or not. Maybe it's better be called APU emulator. But software emulator of APU - is basically a virtual machine?

 

The talk is simply hypothetical for know. But it would be interesting to create some kind of game engine with its own virtual machine.

 

As a background aka "why do I need this" I'll answer -

I enjoy creating tools and utilities without particular reason. For example due to religious reasons I perform compilation using gcc or g++ (because of the newest c++ standart and its complete or almost complete support there) so I developed for myself .cpp template generator using Python (created simple markup template language) because I got tired of creation files manually. Maybe I'll wrap it into simple WinForms UI and create some kind of IDE for myself.

 

Or for example I am planning to develop source control tool (something like Liquibase but for .cpp files) using Groovy.

 

Or the simpliest CAD to create 1,2, 3 point perspective projections(Don't want to draw it manually neither want to learn some software) and import it to .png (I think I'll use either SharpDX(interested) or Tao Framework(used it years ago) + UI using WinForms+C# is easy to create + import to png is easier to implement that than using c++ I think (though not sure)).

 

It's all about interest and I the idea to implement your own VM is exciting + add your own assembly-like language - what can be better?

Edited by ChuckE

Share this post


Link to post
Share on other sites
Advertisement

Game engines are made in layers that relatively depends of another layers.

 

A graphics module knows what a mathematics module is because they're related.

 

 

 


Is it possible to implement something like...
Virtual Machine for game engine with unified VRAM and RAM? I mean during its life cycle, game object does not know that it has some data being operated via GPU and some data being operated via CPU & RAM. So basically it means that even for me during game creation or programming I have no need to know that there is GPU and CPU tasks - I simply create object and all required duties is being done my virtual machine.

 

Yes. A memory module it's implemented to take care of RAM management, and the graphics module can take care of VRAM management (if VRAM stands for Video Random Acess Memory).

 

 

 


As far as I can understand if it is possible to implement it means that there is a need to create custom set of instructions, which will do GPU and CPU & RAM tasks?
I don't know whether it can be called virtual machine or not. Maybe it's better be called APU emulator. But software emulator of APU - is basically a virtual machine?

 

If you're talking about VRAM being the virtual memory, if we could manage that we'd be doing duplicated wor because the OS already does. A memory manager of a engine operates in a way that can be used in any other related level in the application, allocating objects, providing profiling statistics information, etc, and generally it's worried about the heap and the stack.

 

 

 


It's all about interest and I the idea to implement your own VM is exciting + add your own assembly-like language - what can be better?

 

What you're saying here it's completely unrelated to game architeture. You're trying to implement a virtual machine, but such software it's unrelated to a game engine, and you want to manage virtual memory in a game engine. huh.png

 

I'm not saying that it's not impossible to manage virtual memory in modern architectures, but it's unrelated to a game engine architeture. 

Edited by Irlan

Share this post


Link to post
Share on other sites

What you're saying here it's completely unrelated to game architeture. You're trying to implement a virtual machine, but such software it's unrelated to a game engine, and you want to manage virtual memory in a game engine. huh.png

 

Well....I see. I thought to game engine architecture depends of the hardware it uses. And it's being created with knowledge of hardware it will run.

 

It seems I need to implement something like JVM(more or less) and provide some kind of language, which will allow to develop game. And the game will run inside virtual machine.

Edited by ChuckE

Share this post


Link to post
Share on other sites

It seems I need to implement something like JVM(more or less) and provide some kind of language, which will allow to develop game. And the game will run inside virtual machine.

Unreal works sort of along these lines, as did Quake way back in the day. Unity is obviously based around this approach. Still, I don't recommend doing it in general.

Edited by Promit

Share this post


Link to post
Share on other sites


For example due to religious reasons I perform compilation using gcc or g++

 

Which religion is that?  That might be a religion I can get behind! ;)

Share this post


Link to post
Share on other sites

 


It seems I need to implement something like JVM(more or less) and provide some kind of language, which will allow to develop game. And the game will run inside virtual machine.

Unreal works sort of along these lines, as did Quake way back in the day. Unity is obviously based around this approach. Still, I don't recommend doing it in general.

 

why ?

Share this post


Link to post
Share on other sites

 


For example due to religious reasons I perform compilation using gcc or g++

 

Which religion is that?  That might be a religion I can get behind! ;)

 

Nothing special. I sincerely believe that compiler should support all current language features - because only in that case it will be complete. Thus perfect.

Share this post


Link to post
Share on other sites

Game engines are made in layers that relatively depends of another layers.

 

A graphics module knows what a mathematics module is because they're related.

Well, a graphics module is a pretty vague term. I'd say that the scene manager would know about mathematics. The renderer doesn't really need to do any transformations, as it should be taken care of before hand.

 

To the OP:

A lot of renderers are indeed glorified VMs. Generally the renderer will take in a stream of render commands, which are essentially just opcodes. Implementing an assembly language is a bit excessive IMO.

Share this post


Link to post
Share on other sites

Well, a graphics module is a pretty vague term. I'd say that the scene manager would know about mathematics. The renderer doesn't really need to do any transformations, as it should be taken care of before hand.

 

While you're correct about the graphics module can live without a mathematics module, you're forgeting that a graphics module it's all about bringing the low-level graphics API to our users interface with it.

 

A graphics module should know about the mathematics module to facilitate its interface with the graphics wrapper, and it should be called CXApiWrapper or similar, instead of a renderer because it's not a software-side renderer nor rasterizer. The graphics wrapper it's a interface that needs to be pre-determined before re-building the engine and running the simulation depending of your current platform or some criteria. Example: DirectX® runs faster on Windows, so you should use that instead of OpenGL®—altough both are available. In iOS, we're only limited to OpenGL® ES and it's mandatory to use that.

 

A scene manager it's at the same level of the engine and knows what a graphics module, mathematics, physics, etc. are.

Edited by Irlan

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!