-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[OTE 2017 Vision] – Technical ideas and clean up of the engine #49
Comments
I like it all, I propose we merge the two proposals |
Maybe one more addition would be to finally deprecate our usage of sdl 1.2 and switch on sdl2 by default, this will also fix OTE running on macOS as it relies on code from sdl2 to work properly. But yes i think merging the proposals is the way to go here as my ideas are meant as enrichment anyways. |
and also deprecate the use of JPG for textures, it's a lossy compression for textures, and we already have TGA and PNG for this that aren't lossy. today I'll post the combined proposal. |
I don't have time to commit but I'd prefer something playable, a level, a
character and perhaps a weapon or two and few targets to shoot.
Otherwise it's just fun programming practice.
…On Sat, Sep 23, 2017 at 12:01 PM, Biel Bestué de Luna < ***@***.***> wrote:
and also deprecate the use of JPG for textures, it's a lossy compression
for textures, and we already have TGA and PNG for this that aren't lossy.
today I'll post the combined proposal.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA19Oj6BJ59V5ywRDNH2mPiTuz_SGBDbks5slMjVgaJpZM4Pf9_3>
.
|
Open Tech Engine is creative cooperation applied to game development. A stepped process: 1 - building a meaningful community. 1.1 - build a modifiable platform 1.1.1 - building the first assets in an organized way 1.1.1.1 - building a first game 1.1.1.1.1 - building a vertical slash
we could have something build like one of them updated with the current improvements the engine has, that would serve to gather the limits of the engine we have on our hands, and a trial to resolve bugs from the new improvements, it could be something meaningful enough to stand on it’s ground but not overly complex to build. 1.1.2 - building the community pro-actively 1.1.2.1 - manage the community with creativity 1.1.2.2 – guest-mapping 1.1.2.3 – perpetual campaign for the engine and it’s possibilities 1.1.3 - enhancing the community possibilities 1.1.4 - enhancing the reach of the engine 2 - enhancing the technology of the engine 2.1 – recognizing the outsider work In order to further enrich the stepped process with technical ideas to make the engine a more stable base for development, easier to maintain and extend and more accesible to content creators. The codebase is quiet big with alot of moving parts, but some of these parts are outdated or legacy stuff which makes it unnecessarily hard for our small team to maintain it, examples for this are cg shaders and their translation into glsl/hlsl, flashbased gui system, 3rd party libs source code which is just "drop in" in the codebase, complex handling of these 3rd party libs but also git submodules. My idea would it be to firstly make the engine more "equal"on multiple platforms, one step in that direction would be to finally deprecate cg shaders in our engine and replace them with a platform-independent alternative, imho the only option we have here is glsl as shader language, this means the logic to parse and handle cg shaders should be removed by a proper glsl shader parser. Similair the flashbased menu should be removed by an alternative, we have already cegui integration but i propose that we instead try to reenable the old doom 3 gui system as it is a battleproven and has atleast some consumers within the doom3 community like for example the darkmod aka the is knowledge available how to create guis using it. 3rd party libs is a more difficult topic, we have code just dropped in as it and we also have a certain amount of git submodules. Both have certain problems, 3rd party libraries that are just dropped in like that dont receive any updates from upstream, this includes security related fixes but also potentially useful new features which we might want to integrate. Our git submodules that we have are already a bit better in that we have a copy of the upstream source which we can update easily at any time, but they also have the problem that the library in question already needs to be available via git or that we maintain the source code ourselves in git which adds alot of maintainance burden for our small team. Because of that i suggest that we remove the dropped in versions of 3rd party libraries and git sub modules and instead refactor our cmake build configuration to be smarter and find these required libraries itself. Potential devs and packagers are then free to provide the required libraries in any suitable way. Reducing the codebase like that while make it easier to maintain it but we also what to make our engine more attractive for content creators, one way to do that is to add more modern content formats, in terms of 3d models ahve have for example "only" stuff like md3, md5, lwo and probably something else and it looks similair on the audio side. We should aim to add newer formats to the engine like OpenGex, glTF 2.0 but also older but widely used formats like ogg to give content creators more ways to use their work with our engine. But content creators dont only need more available formats but also tools to work with, this means we also need to bring back the old engine tools the original version of doom3 had. These tools are sadly not platform independent and need to be reworked. We already have a simple light editor as proof of concept thanks to Daniel's work. |
I would like to add also the following provision for changing such vision and stepped process:
and also a technical proposal of mine:
what do you people think? |
this has my vote |
+1 |
1 similar comment
+1 |
vote passed! 👍 |
Biel's vision is a good foundation to build on and i would like to further enrich it with technical ideas to make the engine a more stable bases for development, easier to maintain and extend and more accesible to content creators.
The codebase is quiet big with alot of moving parts, but some of these parts are outdated or legacy stuff which makes it unnecessarily hard for our small team to maintain it, examples for this are cg shaders and their translation into glsl/hlsl, flashbased gui system, 3rd party libs source code which is just "drop in" in the codebase, complex handling of these 3rd party libs but also git submodules.
My idea would it be to firstly make the engine more "equal"on multiple platforms, one step in that direction would be to finally deprecate cg shaders in our engine and replace them with a platform-independent alternative, imho the only option we have here is glsl as shader language, this means the logic to parse and handle cg shaders should be removed by a proper glsl shader parser.
Similair the flashbased menu should be removed by an alternative, we have already cegui integration but i propose that we instead try to reenable the old doom 3 gui system as it is a battleproven and has atleast some consumers within the doom3 community like for example the darkmod aka the is knowledge available how to create guis using it.
3rd party libs is a more difficult topic, we have code just dropped in as it and we also have a certain amount of git submodules. Both have certain problems, 3rd party libraries that are just dropped in like that dont receive any updates from upstream, this includes security related fixes but also potentially useful new features which we might want to integrate. Our git submodules that we have are already a bit better in that we have a copy of the upstream source which we can update easily at any time, but they also have the problem that the library in question already needs to be available via git or that we maintain the source code ourselves in git which adds alot of maintainance burden for our small team. Because of that i suggest that we remove the dropped in versions of 3rd party libraries and git sub modules and instead refactor our cmake build configuration to be smarter and find these required libraries itself. Potential devs and packagers are then free to provide the required libraries in any suitable way.
Reducing the codebase like that while make it easier to maintain it but we also what to make our engine more attractive for content creators, one way to do that is to add more modern content formats, in terms of 3d models ahve have for example "only" stuff like md3, md5, lwo and probably something else and it looks similair on the audio side. We should aim to add newer formats to the engine like OpenGex, glTF 2.0 but also older but widely used formats like ogg to give content creators more ways to use their work with our engine.
But content creators dont only need more available formats but also tools to work with, this means we also need to bring back the old engine tools the original version of doom3 had. These tools are sadly not platform independent and need to be reworked. We already have a simple light editor as proof of concept thanks to Daniel's work.
(First draft of my proposal, will update it as i get more ideas)
The text was updated successfully, but these errors were encountered: