CCHyper

We have a huge INI engine, and it is very extendable. I do not think there is one of this size public (outside of a AAA company). As for your questions; 1) Of course, if you want to put in the work! 2) We make use of templates in many cases, a few classes require templates due to the item they are storing. 3) We use CPP, H and HH for file extensions. HH is used for defines and enumerations of classes where we do not want to include the whole class header.

Just adding to what Blade also mentioned, a lot of the core is ready and waiting for one key element from the low level systems. Once we sign off the low level as being tested and passed, then a lot of the visual features will come into play and allow us to roll out features at a rapid rate. But for now, just like any other project, build the foundations before you worry about the colour of the brick! OpenDUNE was started in '09 IIRC, and made its first playable build two years later. RedAlert++ has been under development for quite some time behind the scenes, and we aim on producing a friendly, accessable and highly extendable engine too. We might make a decision that would add a few months onto the project time, but in the future, this decision will shave a lot of time development in the future in terms of extending and porting the engine across multipule platforms.

You mentioned that. Why exactly are you changing it? Red Alert uses bitfields to pack all boolean values, this is a optimisation that the Watcom compiler did at the time, and something that is not longer done (as we don't have the constraints they at the time). Second, is that the enumerations where packed depending on the size of the largest entry, so where UNIT_NONE would equal "-1" 32bit integer in our codebase, Red Alert stores this is a "-1" 8bit char. This causes more headaches that you would think. The same goes for some structures too, but this was intentional and no longer applies to us.

Uh. You're gonna have to explain that one to me, Hyper. Unless you are drastically changing the internals, I really don't see why that wouldn't be possible. It is just that, some internal classes will not be exactly the same size, and/or will not use the same storage type.

Apolagies LavenderMoon , I was using my phone. I disagree that being able to load original Red Alert save games would require your in-memory formats for the objects be the same. You said yourself later in the post that it wouldn't be impossible to write a parser for the old saves that converted them to RedAlert++'s native format, so calling that converter at runtime when loading a legacy save game would also not be impossible. The way C&C games work, they do. I had the same issue with HyperPatch, once I extended a class, previous save games are no longer supported, as the save game packs the information into the stream and the stream must match the allocated data by the game. It is just not possible for us to do. It has nothing to do with 'hacking' the binary, Red Alert is coded in such a way that it is not possible for us to do so. We can not support save games.

Not a problem, these are all questions related to the project, and I have no problem discussing them here Just to settle the discussion regarding save games. We will not be support them at all. It is not possible for us to due to the way Red Alert stores the information.

Just as Blade mentioned. The Carryover handler is a global object that stores the information, to be retreived at any time using ToInherit. Legacy Savegame support will not be included. It would hold us back from taking advantage of modern features just to support a save game file, but we will allow game saving in a newer format, and the resulting file will be smaller too.

I know about the Carryover so let me re-word what I said. I don't where it saves the data it need to carryover all of the units and buildings that need to be saved from Allied 2 and applied to Allied 4. The only other way I can see the game transfering player objects from a previous scenario would be the using the [bases] section in the scenario.

We see the goals in a simple order; First is to recreate Red Alert as accurate as possible, and only adding features that extend the overall game but do not effect gameplay (A keyboards controls dialog for example). The second, and only once the project is close to complete, will be where we can focus on adding many features. Though all these features will be disabled by defualt, so the end user decides if he wants to use them in the scenario or mod they are creating.

Red Alert has whats called a "Carryover" logic, it saves the the houses objects with the strength and location on the map so they can be replaced in the next scenario.

Build queues and shift box selecting should be added to CnCNet's version of Red Alert so that I can keep up with the P4 Gold Medal pros and all their hotkeying Won't it be a reimplementation of the vanilla game? That would mean no add-ons on gameplay. Actually I would be sad if there are any changes that makes the game feels different from it's original. There will be slight things we will have to abide by, but we hope that the collective communites can help us trace anything that feels off We are aware of the rendering tool zzattack released, but we are already well under way with our own. We will not be using any 3rd party tools as a base for any feature of the engine.

SiRaLeX, as much as I appricate you commendation towards us, I feel it is a topic best suited under its own subject. I would like to keep this topic mostly focused on the project itself. But thankyou for your input

The effort needed to do that would be minuscule, compared to what they need to accomplish to actually recreate RA from nearly scratch, so I guess (and hope) the answer is 'yes'. I have a low priority side project to research and map the changes that appear in C&C95, hopfully adding these features into the new engine so it supports said features from the start.

No more than OpenRA, OpenDUNE or CorsixTH. I have it on good word that we will be ok as long as we do not try to profit from this project, as C&C is still very much a active and in development IP.

This is the first time I have heard of such a term, but that would be correct. We are trying to recreate that exact gameplay, as much as possible (we do not have the original source code or design documents), so we are aiming for 99.8%

Unfortunately, this is not possible. There is no way for us to perfectly replicate the system Red Alert uses.

There is a mixture of of research and writing the code from scratch to ensure we make full use of the feature available to us in this day age, 20 years later from when Red Alert was first released! We will be aiming for cross platform deployment, and we will be also working towards making a public repository in the future

It has been decided after a lengthy discussion with the OpenRA team that it would be best for us to rename the project, while in its infancy. We would never ask OpenRA to rename their project as it has cemented itself as a project with a great future, and that name is now engraved into the internet. We have decided to go with RedAlert++, I will be updating the topics and website shortly.

_

I do also experience a similar sound, perhaps this is a issue with the allocated buffer not being large enough for what some tracks demand.

Awesome stuff! I would be interested in seeing your style for Red Alert 1 and more Tiberian Sun stuff.

The crash is nothing to do with DDraw or anything related. Its actually a common, and at this moment (I never found a fix) unfixable crash to do with drawing the coloured laser beams. You could try lowering the visual details under the Options, that has worked for some people I have heard.

Well, if you upload the EXCEPT.TXT file, I'll see what I can do!

OK, so I was on the right track, just needed to change the "short"' to "byte". The game handles the first two bytes as a struct, and the basic common format for coords or position in C&C games is CoordStruct, weather the data be byte, short or int. EDIT: All BIN's are formatted as if the map is 128x128. So 0xFF/255 means ignore/skip, while anything less that 128 means a valid cell coord and thus loads the data into the internal hardcoded map struct. So CoordStruct should be CellCoordStruct and the entry's represent the XY location of the cell in the internal 128x128 map structure. Correct me if I am wrong as I'm new to the map formats of Pre-TS games...

Do not hold me to this, but from my old notes (that is seriously outdated, Dec 2010...), it should be; I used "short" as the game handles pretty much everything as a byte, though that might have been a compiler optimization and I'm sure they coded it as a "int". struct CoordStruct{ short X; short Y; }; struct MapPackStruct{ CoordStruct Coord; TemplateType Template; short TemplateTileIndex; }; Also, SS can load C&C95 maps when you set a internal integer "INIFormat to "0", its +0x28 from the static MapClass Map.