Sign in to follow this  
Followers 0
ST34MF0X

TiaraCE

41 posts in this topic

About

TiaraCE is an open-source, cross-platform reimplementation of the Halo Custom Edition engine, written in C++.

 

The primary goal of this project is to bring the Halo Custom Edition engine to 64-bit operating systems and to free the engine from the limitations imposed by the original closed engine.

 

The secondary goal is to correct design flaws and bugs that plagued the original engine, and to extend the modding capabilities of this new engine.

 

The tertiary goal is to put the engine code in the hands of the community. This will help facilitate the development of new modding and mapping tools, and as a result afford more freedom of creativity to the community as a whole.

 

 

FAQ

 

Q: Is TiaraCE a mod?

A: No.

 

Q: Is TiaraCE a standalone game?

A: No.

 

Q: What is TiaraCE?

A: TiaraCE is an open-source, cross-platform reimplementation of the Halo Custom Edition engine.

 

Q: What can I do with TiaraCE?

A: TiaraCE will let you play maps made for Halo Custom Edition on Windows, Mac, and Linux, and allow you to connect to servers for online play. You'll also be able to host your own servers within a feature-rich dedicated server.

 

Q: Will TiaraCE support HAC2?

A: No. You won't need it. All of HAC2's features will be built into TiaraCE after the release of TiaraCE v.1.0. The same applies to SAPP and Chimera. 

 

Q: Will you add X feature?

A: Any and all enhancement features will be added after the release of TiaraCE v.1.0. Until then, we are focusing on 1:1 compatibility with Halo Custom Edition.

 

Q: Can I test the it?

A: As of the time of writing, we are still in the research stage and laying out the fundamentals. You can become a tester, but you'll have to wait a while before there will be anything to test.

 

Q: Can I help with the project?

A: If you know C++, feel free to show us a portfolio or a sample of your work, and we'll see if we can hook you up. If you can't code, you can always sign up as a tester, or you can help us with research on the inner workings of Halo Custom Edition's engine.

 

 

Links

 

TiaraCE GitHub Reposirories

 

Project Task List/Road Map

 

TiaraCE Official Discord Channel

Website (Under Construction)

 

Icons

Zetren likes this

.:.:LOADING.:.:

Share this post


Link to post
Share on other sites

Tiddy-bits:

I will do my best to answer any questions you might have regarding TiaraCE and the project as a whole. 

Takka likes this

.:.:LOADING.:.:

Share this post


Link to post
Share on other sites

With this application, would it be possible to do things such as implement new render features & functions, as this is all open source? Or will it all be taken right from CE? If it is possible, what would the limitations be on the map-file end? As far as bitmaps go would it be limited to what we can already use? Or would it be possible to make the new program understand custom shader passes/effects? (E.g. normal maps, or possibly parallax mapping on environments if someone were to put enough time into it. Hell, if someone was talented and patient enough, maybe even a global realtime lighting system?)

ST34MF0X likes this

Share this post


Link to post
Share on other sites
16 minutes ago, Vuthakral said:

With this application, would it be possible to do things such as implement new render features & functions, as this is all open source? Or will it all be taken right from CE? If it is possible, what would the limitations be on the map-file end? As far as bitmaps go would it be limited to what we can already use? Or would it be possible to make the new program understand custom shader passes/effects? (E.g. normal maps, or possibly parallax mapping on environments if someone were to put enough time into it. Hell, if someone was talented and patient enough, maybe even a global realtime lighting system?)

Excellent questions.

Yes, new shaders and materials will be possible in TiaraCE through GLSL and a shader preset system, soon after the release of TiaraCE v.1.0. This would allow for enhancing the look of existing maps without necessarily editing the maps themselves, although you could if you wanted to. Some of the bugs and development oversights like the way flashlights and fog volumes worked will likely be corrected before the 1.0 release.

As for bitmaps, it will be possible to use PNG, TGA, JPG, and BMP format images in TCE maps. Because of this, things like normal maps, specular maps, and alpha masks could be done in-engine thanks to the aforementioned shader system.

These are just some of our plans for the TiaraCE client. However, it is important to note that we are starting with the core engine and dedicated server (v.0.9), as those are easier to implement, and much of the code used will be used to create the client. Basically, once we have the first two, the client will take far less time to develop, since most of the work will be done by that point.

Edited by ST34MF0X

.:.:LOADING.:.:

Share this post


Link to post
Share on other sites

Thanks for the quick answer, and it's good to know you have a workflow set up.

 

One more question I just now thought of, As this is an open-sourced client, does this mean it's entirely possible people will be able to make maps or functions only able to be run on a custom build of the client? I'm just worried something like this could cause a split similar to what we saw with Opensauce.

ST34MF0X likes this

Share this post


Link to post
Share on other sites
39 minutes ago, Vuthakral said:

Thanks for the quick answer, and it's good to know you have a workflow set up.

 

One more question I just now thought of, As this is an open-sourced client, does this mean it's entirely possible people will be able to make maps or functions only able to be run on a custom build of the client? I'm just worried something like this could cause a split similar to what we saw with Opensauce.

Glad to be of help. 

We aim to keep backwards compatibility in our engine. People should refrain from creating forks that use non-standard features and instead should make feature requests or pull requests to the official repository.

If somebody creates these non-standard custom branches anyway, one should be warned to use them at their own risk.

Edited by ST34MF0X
Vuthakral likes this

.:.:LOADING.:.:

Share this post


Link to post
Share on other sites

The map parser has moved to Invader. Check out Invader here:

There are a few differences between the original plans of TiaraCE's map parser and Invader that are worth noting:

  • Invader is licensed under the GNU General Public License version 3.
  • Invader satisfies a larger set of use cases beyond simply parsing maps including compiling cache files.
  • Invader does not parse Xbox maps.
  • Invader does not target Visual C++ with Windows. Instead it uses MinGW.
  • Invader does not require macOS compatibility.
  • Invader does not use information from Sparky's plugins.
  • Invader's tag definitions are more complete than either Sparky's plugins or Guerilla since Invader must build maps.
  • Invader uses the C++17 standard, not C++11.

Old post (for historical reasons):

Spoiler

I'm writing this map parser for TiaraCE, though if anyone wants to use it in their programs, I'm releasing it under the MIT license. This project is written in C++.

 

This map parser attempts to satisfy a few goals:

 

Speed - Everything should load quickly. Although it should load faster on faster PCs, it shouldn't take too long to load on any modern PC. Therefore, I've made it important to test it on the slowest PC I have:

  • CPU: Intel Core i3-4030U @ 1.9 GHz (Haswell Refresh)
  • RAM: 4 GB DDR3 @ 1600 MHz

 

Safety - When you provide a broken map to Halo, it segfaults. I think I can do better than this. In this map parser, maps should either:

  • Not load at all, generating an exception error that the program can handle
  • Load (if possible), but when something is wrong, generate an exception error that the program can handle
  • Load successfully

 

Cross platform - It must compile successfully on Windows (with Visual C++), macOS (with LLVM Clang), and Linux (with GCC). It must also function identically between platforms. Note that I am using the C++11 standard.

 

Tag mapping - I'm mapping out all of the tag classes using data from Guerilla and Sparky's Plugins as well as any data of my own. This will allow the programmer to easily access tag data without having to search for offsets (assuming that data is mapped out).

 

These maps are supported -

  • Halo PC (retail and Custom Edition)
  • OG Xbox (both compressed and decompressed)

 

I'm also planning on including a map deprotector later down the line to handle maps that are protected.

 

Here are all of the tag classes that I currently plan on mapping out:

Spoiler
  • actor
  • actor_variant
  • antenna
  • biped
  • bitmap
  • camera_track
  • color_table
  • continuous_damage_effect
  • contrail
  • damage_effect
  • decal
  • detail_object_collection
  • device (subclass)
  • device_control
  • device_light_fixture
  • device_machine
  • effect
  • equipment
  • flag
  • fog
  • font
  • garbage
  • gbxmodel
  • globals
  • glow
  • grenade_hud_interface
  • hud_globals
  • hud_message_text
  • hud_number
  • input_device_defaults
  • item (subclass)
  • item_collection
  • lens_flare
  • light
  • light_volume
  • lightning
  • material_effects
  • meter
  • model
  • model_animations
  • model_collision_geometry
  • multiplayer_scenario_description
  • object (subclass)
  • particle
  • particle_system
  • physics
  • placeholder
  • point_physics
  • preferences_network_game
  • projectile
  • scenario
  • scenario_structure_bsp
  • scenery
  • shader (subclass)
  • shader_environment
  • shader_model
  • shader_transparent_chicago
  • shader_transparent_chicago_extended
  • shader_transparent_generic
  • shader_transparent_glass
  • shader_transparent_meter
  • shader_transparent_plasma
  • shader_transparent_water
  • sky
  • sound
  • sound_environment
  • sound_looping
  • sound_scenery
  • spheroid
  • string_list
  • tag_collection
  • ui_widget_collection
  • ui_widget_definition
  • unicode_string_list
  • unit (subclass)
  • unit_dialogue
  • unit_hud_interface
  • vehicle
  • virtual_keyboard
  • weapon
  • weapon_hud_interface
  • weather
  • wind

 

Tags in blue are verified completed.

 

Tags in green are completed up to Guerilla's tag data fields. There may be hidden values present that do things, but these values aren't in Guerilla.

 

Tags in yellow are partially completed.

 

Tags in in goldenrod are partially completed by extension of a subclass being completed.

 

Tags crossed out have little point to be completed.

 

 

 

 

ST34MF0X, Takka and WaeV like this

Share this post


Link to post
Share on other sites

I've updated the post with a list of tag classes I plan on mapping out. Some of these tag classes likely won't get mapped out due to being useless. Because there are 83 tag classes, I've put them in spoiler tags.

 

Note that just because a tag is completed does not mean there aren't any hidden values not listed in Guerilla that I may go back and modify.

Sunstriker7, ST34MF0X, Takka and 1 other like this

Share this post


Link to post
Share on other sites

Was interested in how much progress you guys had made so I took a quick look at your repo. Its quite empty, is that it so far or have you guys just not committed anything?

Share this post


Link to post
Share on other sites
10 hours ago, Kru said:

Was interested in how much progress you guys had made so I took a quick look at your repo. Its quite empty, is that it so far or have you guys just not committed anything?

We cannot simply make random code and expect it to work exactly like the original engine. It takes a lot of research and reverse-engineering work and documentation to start on any code whatsoever. As of the time of typing this response, we are still in the research stage. Some initial code, like the map parser, is stored in separate repositories until such a time that the code is ready to be added to the main repo.

The good news is that we are getting closer every day to having the documentation we need to actually start on the majority of the engine's code. Be patient, and we will start the long process of populating the repo with usable code. 

TL:DR: We are making lots of progress in the research department, which we need in order to develop. It's all behind the scenes, right now.

 

To see just how much has to be researched for a project like this, have a look at the roadmap. Almost everything marked "TODO" is still in the process of being researched.

Edited by ST34MF0X
Skeezix the Cat likes this

.:.:LOADING.:.:

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0
  • Recently Browsing   0 members

    No registered users viewing this page.