Sign in to follow this  
Geri

OpenGL Hints for my new engine (v3)

Recommended Posts

When i made my graphics engine in 2006, wich i updated since that many and many times to fit the requiretments (however, i always keeped it around 5 year lag with the newest technologies for security reasons) i suspected that i will be able to use it for 6-7 year.

This was a correct suspection from me. My engine was around middle class for a lot of times, and if it begined to fall down to low class, i just added some features to compensate it. My hint was i can do this for 6 year without punishment. This is correct, but now my code reached the level wich is not any more maintainable, i must rewrite it.

However, my current engine will be in use for more, i will not replace it with a new technologoy, its unnecessary.

Of course, i will not to delete everything from the code, there is a lot of code wich will usable in the next version also, but i must thow out its structure, the operating principle, i will change verything at the roots.

Also my new engine must be compatible with my old engine, at function level, for example, my Maker3D should work with the new also. I thing i will write a wrapper interface to keep this.

So now i want to share my plans, the new structure of the engine, and i wait ideas, hints, what you ppls tough about my plan.

If you know some new technology (for example, a new, good looking effect) or you invented something but you cant use it for even, and you suggest and let me to implement it, please share it. It does not matter if its just exist as a never investigated and never implemented data sheet, or just an idea, or you just saw it somewhere, please share it
if you think it is good.


TEXTURE HANDLING:
-------------------------------
My new texture handler will use a new texturing track, what can take the textures to bounch and only load them when its necessary, in buckets, so it can process a lot of it with multithread. Or if the handler gets a flush. My engine alreday had unifyed texture handling, but it was uneffective and slow. The new code will even has the ability to dynamically delete the textures from the RAM, and load them again, if they needed.


MODELL HANDLING:
-------------------------------
Modell handling will be similar to texture handler. But i must redesign this fully to be correspondance with my new structure.


MEMORY HANDLING:
-----------------------------
This was complitely broken in my current engine. I will fix it, there is nothing to say about this. The old code was even optimised with Voodoo3.

KILLING GLOBALS:
----------------------------
There was too much global stuff, so i now will collect everything in monolithic global blocks, i building the levels and the blocks logically:
-main.c (includes)
-lgfx_thread_API.c (my multithreading codes)
-sallang_API.c (everything who does not fit to another place: memcpy_dualcpu, lgfx_atof...)
-filehandle_API.c (crossplatform fopen_lgfx, etc)
-Iinit_API.c (platform init, may 60-70 kbyte)
-Periferia_API.c (keyboard, mouse, joy, ~20 kbyte)
-modell.c (no specific calls, only the loaders, ~100 kbyte)
-fizika.c (phisics, collision, 30 kbyte)
-kamera.c (my existing camera codes being copyed there after a bit rework)
-grafika_API.c (deprecated and reworked version of my current graphics engine OR my new engine wich i will
speak later, ~400 kbyte, textures and models also being stored here)
-textura.c (textre loading, managing, decoding, ~70 kbyte)
-sprite.c (my new spritehandler will go here, 10 kbyte)
-audcodec.c (~ 10 kbyte)
-hang_hw.c (my current sound engine comes here, ~10 kbyte)
-engine.c (the passice engine structure and engine core, engine coordination, ground, anim handling, etc, ~300 kbyte)
-engine_effekt.c (some predefinied cpu time leet effects, ~100 kbyte)
-engine_compatibility.c (for compatibility wrapping my old engine, BASIC interpreter, ~300 kbyte)
-menu.c (my current code of opening screens, settings, loading screens, menu handlers, ~20 kbyte)
-game.c (the game, or a wrapper that inits the stuffs to my old engine)


SPRITE HANDLING:
-------------------------------------
Some parts stays as old, but i will rewrite a lot of extras in it. Snitts, flows... much more passive.

GRAPHICS:
-----------------
-I will keep my current OpenGL based graphics engine for compatibility purposes.

-My new graphics engine is a multi-cpu ray tracer. I want ideas for this. Texhnologies, effects, ideas, how to speed it up even more. I want to use this engine from ~2014 (if the world begin destroyed in 2012, not). I would be very happy to see your favorit effects related to this.


SOUND HANDLING:
----------------------------
Maybee i should write realtime environmental audio handling based on the ray tracer, for example, real time calculated environment effect if the voice comes out from the bathroom. Maybee i should write 3d audio positioning. I have never doned such things before, i got no experience, so i will use temporally my current sound code. Suggestions?

PHISICS:
--------------
This was shit until now also, but i cant made anything with it. I will write some new stuffs to it, for example, falling dow item wich brokes, etc.


OTHERS:
---------------
I wait for ideas, for everything, except for:
-What compilers, languages, ideologies, platforms should i use.
I dont care about your fetishes and about your virtual lovers.

I WOULD LIKE THE FOLOWING BENEFITS FROM THE NEW ENGINE COMPARED TO THE OLD
-----------------------------------------------------------------------------------------------------------------------------------
I will introduce this engine only after my old engine fully become obsolete. These engines are for my personal use
to create my softwares in them, so i want not blow up all of my rockets for the first shoots.
-Possibility to write brutal graphics (this also will need modellers, however)
-Simplyer maintaince, modular built-up
-Faster, easyer develop.
-Much smaller memory demand
-Better automatic caching and loading
-Compatiblity with my current stuffs at function(); level
-Better gaming experience
-Simply to create support for new platforms later (who knows what will be is after 5-6 year)
-Independent from everything


Thank you!

Share this post


Link to post
Share on other sites
The one thing that you don't mention is how content is created, and how this content is delivered to the engine's runtime. There's no planned workflow or asset pipeline. These parts of the engine are just as important as the runtime itself.

Do you have an existing tool-chain that you'll be reusing?

Share this post


Link to post
Share on other sites
[b] sirpalee [img]http://public.gamedev.net/public/style_images/master/user_popup.png[/img] [/b]
[b] szecs [img]http://public.gamedev.net/public/style_images/master/user_popup.png[/img] [/b]
The engine (its a base engine) itself would not be public, the previous releases was also not public. So it does not matters how i call the stuffs, or how other peoples would enjoy coding it. The things i build on this engine are the important (for example, Maker3D), not the engine itself. It must satisfy only my needs, and of course, deliver technologies that gamers and end-users would enjoy.

[b] Hodgman [img]http://public.gamedev.net/public/style_images/master/user_popup.png[/img][/b]
I dont plan to change that parts of the engine (hint: check Maker3D)
However, i decided not to create new graphics engine. I will upgrade my current code instead of it.
I alreday started, for example, i coded texture cacher (automatic free-up from the memory), resizeable windowing, modifyed sprite engine... recoding every thing would take too much time (years). And i started to remove deprecated codes also.

I would like to hear ideas instead. Anyway, thank for the replyes.

Share this post


Link to post
Share on other sites
The level editor, the scripting and the asset pipeline is part of any game engine. (and maker3d is basically with your engine, without a native API and with some limitations - so the API design, the scripting is important for your users)


And don't write anything yourself, there are a lot of already great opensource / multiplatform tools, that are heavily tested and used in many application. For example you can use OpenImageIO for texture caching / loading in the system ram (you can specify the amount of memory it uses etc... and pretty fast too!), or instead of using your own "shader language", Open Shading Language is there for your raytracer (since I guess it's cpu only, or with some modifications even for the GPU).

Is there any game in development with Maker3D?

Share this post


Link to post
Share on other sites
[color="#000080"][i][size="1"]is part of any game engine[/size][/i][/color]
Yes it is, but i currently want ideas mostly for the graphics engine, and technologies depthly inside the code. Maker3D relies on this also, but Maker's editor or script language / etc does not affects this. I am not needing any suggestions related on this at the moment. So i am currently only curious about the things i have mentioned.

[color="#000080"][i][size="1"]there are a lot of already great opensource [/size][/i][/color]
I not writing everything myself ofc. I using some existing format loaders when necessary. But i dont think i would let any third party code in the rendering core, even if it is opensource or public domain, even if its mutch faster. If a bug appears in it, fixing would be very painfull, maybee also would strict me away from some later platforms, or would decrase the scalability or the flexibility of my code.

[size="1"] [color="#000080"][i]Is there any game in development with Maker3D? [/i][/color][/size]
I have no such informations.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Announcements

  • Forum Statistics

    • Total Topics
      628355
    • Total Posts
      2982249
  • Similar Content

    • By test opty
      Hi all,
       
      I'm starting OpenGL using a tut on the Web. But at this point I would like to know the primitives needed for creating a window using OpenGL. So on Windows and using MS VS 2017, what is the simplest code required to render a window with the title of "First Rectangle", please?
       
       
    • By DejayHextrix
      Hi, New here. 
      I need some help. My fiance and I like to play this mobile game online that goes by real time. Her and I are always working but when we have free time we like to play this game. We don't always got time throughout the day to Queue Buildings, troops, Upgrades....etc.... 
      I was told to look into DLL Injection and OpenGL/DirectX Hooking. Is this true? Is this what I need to learn? 
      How do I read the Android files, or modify the files, or get the in-game tags/variables for the game I want? 
      Any assistance on this would be most appreciated. I been everywhere and seems no one knows or is to lazy to help me out. It would be nice to have assistance for once. I don't know what I need to learn. 
      So links of topics I need to learn within the comment section would be SOOOOO.....Helpful. Anything to just get me started. 
      Thanks, 
      Dejay Hextrix 
    • By mellinoe
      Hi all,
      First time poster here, although I've been reading posts here for quite a while. This place has been invaluable for learning graphics programming -- thanks for a great resource!
      Right now, I'm working on a graphics abstraction layer for .NET which supports D3D11, Vulkan, and OpenGL at the moment. I have implemented most of my planned features already, and things are working well. Some remaining features that I am planning are Compute Shaders, and some flavor of read-write shader resources. At the moment, my shaders can just get simple read-only access to a uniform (or constant) buffer, a texture, or a sampler. Unfortunately, I'm having a tough time grasping the distinctions between all of the different kinds of read-write resources that are available. In D3D alone, there seem to be 5 or 6 different kinds of resources with similar but different characteristics. On top of that, I get the impression that some of them are more or less "obsoleted" by the newer kinds, and don't have much of a place in modern code. There seem to be a few pivots:
      The data source/destination (buffer or texture) Read-write or read-only Structured or unstructured (?) Ordered vs unordered (?) These are just my observations based on a lot of MSDN and OpenGL doc reading. For my library, I'm not interested in exposing every possibility to the user -- just trying to find a good "middle-ground" that can be represented cleanly across API's which is good enough for common scenarios.
      Can anyone give a sort of "overview" of the different options, and perhaps compare/contrast the concepts between Direct3D, OpenGL, and Vulkan? I'd also be very interested in hearing how other folks have abstracted these concepts in their libraries.
    • By aejt
      I recently started getting into graphics programming (2nd try, first try was many years ago) and I'm working on a 3d rendering engine which I hope to be able to make a 3D game with sooner or later. I have plenty of C++ experience, but not a lot when it comes to graphics, and while it's definitely going much better this time, I'm having trouble figuring out how assets are usually handled by engines.
      I'm not having trouble with handling the GPU resources, but more so with how the resources should be defined and used in the system (materials, models, etc).
      This is my plan now, I've implemented most of it except for the XML parts and factories and those are the ones I'm not sure of at all:
      I have these classes:
      For GPU resources:
      Geometry: holds and manages everything needed to render a geometry: VAO, VBO, EBO. Texture: holds and manages a texture which is loaded into the GPU. Shader: holds and manages a shader which is loaded into the GPU. For assets relying on GPU resources:
      Material: holds a shader resource, multiple texture resources, as well as uniform settings. Mesh: holds a geometry and a material. Model: holds multiple meshes, possibly in a tree structure to more easily support skinning later on? For handling GPU resources:
      ResourceCache<T>: T can be any resource loaded into the GPU. It owns these resources and only hands out handles to them on request (currently string identifiers are used when requesting handles, but all resources are stored in a vector and each handle only contains resource's index in that vector) Resource<T>: The handles given out from ResourceCache. The handles are reference counted and to get the underlying resource you simply deference like with pointers (*handle).  
      And my plan is to define everything into these XML documents to abstract away files:
      Resources.xml for ref-counted GPU resources (geometry, shaders, textures) Resources are assigned names/ids and resource files, and possibly some attributes (what vertex attributes does this geometry have? what vertex attributes does this shader expect? what uniforms does this shader use? and so on) Are reference counted using ResourceCache<T> Assets.xml for assets using the GPU resources (materials, meshes, models) Assets are not reference counted, but they hold handles to ref-counted resources. References the resources defined in Resources.xml by names/ids. The XMLs are loaded into some structure in memory which is then used for loading the resources/assets using factory classes:
      Factory classes for resources:
      For example, a texture factory could contain the texture definitions from the XML containing data about textures in the game, as well as a cache containing all loaded textures. This means it has mappings from each name/id to a file and when asked to load a texture with a name/id, it can look up its path and use a "BinaryLoader" to either load the file and create the resource directly, or asynchronously load the file's data into a queue which then can be read from later to create the resources synchronously in the GL context. These factories only return handles.
      Factory classes for assets:
      Much like for resources, these classes contain the definitions for the assets they can load. For example, with the definition the MaterialFactory will know which shader, textures and possibly uniform a certain material has, and with the help of TextureFactory and ShaderFactory, it can retrieve handles to the resources it needs (Shader + Textures), setup itself from XML data (uniform values), and return a created instance of requested material. These factories return actual instances, not handles (but the instances contain handles).
       
       
      Is this a good or commonly used approach? Is this going to bite me in the ass later on? Are there other more preferable approaches? Is this outside of the scope of a 3d renderer and should be on the engine side? I'd love to receive and kind of advice or suggestions!
      Thanks!
    • By nedondev
      I 'm learning how to create game by using opengl with c/c++ coding, so here is my fist game. In video description also have game contain in Dropbox. May be I will make it better in future.
      Thanks.
  • Popular Now