Blade

Yeah, its Westwood that wanted to lock the mix files to make it harder to retrieve the individual files out of them. We've just had to implement these algorithms to unlock the already locked content. As I mentioned, XCC has had code to do this for a long time now but its messy and pretty much impossible to know what its doing from looking at it.

Okay, so we recently wrote a MapClass implementation as part of our drive to get map drawing done. This handles the cell grid and a bunch of stuff relating to it and with a bit of glue code it might be enough to get a basic map renderer on the go. In the game its one of the lower classes in a hierarchy of inherited classes that control all the aspects of the in game UI, so to get something basic drawing as it does in the game, there is still a bit of work ahead. After that we've taken a change of pace into some code that we previously investigated, but struggled to get a working implementation going. The code in question is the internal "Multi Precision Integer" library that is used to do the RSA part of the mix header encryption. Now we have header decryption working as it is using an embedded library, but if we stay with that library we are bound to its license terms so really we wanted our own version of the games internal "XMP" library. In fact the code everyone and their dog uses to handle the encrypted headers, the XCC decryption code, is pretty much already the code from the game reversed to C. It has problems however, for a start, GCC seems to hate compiling it with optimizations. Secondly, its not big endian friendly which might harm future attempts to port the code to systems other than x86. For all these reasons we started writing our own implementations and its pretty straight forward like doing long addition, subtraction, multiplication and such like you learned at school only with each "place" in the number being a 32bit int rather than 0-9. It all went well until we got to the "modular" operators, specifically modular multiplication. If you've ever looked into the XCC code, this is done by a function called calc_a_bignum there, but its really the Thad Smith Modular Multiplication algorithm as far as we can tell. In fact it looks like the WW coders were heavily influenced in their algorithm choice by the PGP algorithms (presumably as that was one of the few crypto libraries with available source at the time). It does some crazy bit shift magic to speed up calculating this value and even in the PGP code it is hard to follow, much less the XCC code version. So crazy in fact that currently we still can't get a fully 32bit version to work, we've had to resort to a simpler algorithm based on long division to calculate the modulo of the multiplication result. Its not as fast, but it does mean that we finally have a home grown "Multiple Precision" library that can decode mix file headers. Now, back to those scenario hierarchy classes.... Edit: I've managed to implement an alternative to the Thad Smith algorithm that is still fast, so another external library dependency is definitely eliminated.

At a guess, are the guest OS's using NAT to share the networking of the host? Try it with bridged networking instead.

This is like petitioning George Lucas to remaster Starwars some more. Its the abused spouse syndrome of the gaming world!

Dunno if Nyerguds moved the code for that as well, but the entry in conquer.ini in the original binaries is "Rotation=dancing" to enable that effect.

I don't get why 6 player stuff hasn't been fixed as it doesn't even need an exe hack anymore as we figured out the correct option to use in conquer.ini. You just need Players=6 under [Options] IIRC, just need the client to take that into account.

No, I think just adding it to rules.ini is enough, don't need it in every mission, but you might also want to consider the tech levels as well.

So no pretty pictures for this one, but we got side tracked messing with the audio engine and now have a working implementation built on OpenAL that plays all the original aud files as well as the HQ ones that were released by Lightning Hunter. Next stop, map loading and drawing!

I don't really want to get into a debate on the pros and cons of licensing, but its only strict in that people can't use the code to create a proprietary version, they have to release their code changes as well. Apple doesn't like it because it would mean if they distributed GPL code, they would also have to give up the signing keys needed to install things on iOS breaking their monopoly on software distribution to their devices. I advocate jailbreaking to get round such issues. The GPL wouldn't require that people also license their assets as GPL as well, only any code changes and personally, I don't see that being a big limitation, it ensures that no one has to go to the trouble of re-creating the game again, they can just port the code to whatever it needs porting to on going so its playable forever. The assets have to be distributed as part of a mod anyway, no way to get out of that.

Why would the GPL deter modding? Its not like the closed source binary is a great boon to modders is it? Perhaps you don't understand what the GPL is?

To be fair, the WSA issues might not have anything to do with your inability, it might just be the tools still aren't right. I was trying to create a version of the compression code that would match the WW code exactly and I'm close, but it isn't there yet and I'm busy with other things.

We are going for a 100% authentic ra game experience and that means duplicating the path finding logic accurately as well. Any changes will be for obvious bug fixes, anything where its not clear it wasn't intentional or it was done because of restraints at the time we will try and replicate exactly. Any "improvements" will be optional off by default features for modders to use.

I've been looking into the audio engine a bit more and I think I may have a plausible explanation why the game stutters on these files. I think its because the game only buffers a small amount of audio data at a time and relies on a callback to keep pumping more data into the buffers. The callback looks like it may be called more often during a game than on a menu and since the data rate is > 4x for the enhanced sound track, the game can't keep up with the lower frequency callback.

I don't think we have plans for any sweet merch (unless CCHyper wants to correct me), so no Xmas goodies I'm afraid. The original game had most of the low level stuff done already for C&C. There was the porting to windows and the new ini engine that was added, but we are having to write it all mostly from scratch and are trying to keep it cross platform. In short, don't be a cheeky git, it will be done when its done and be the next best thing to the original code being released

Problem is that the game code itself can decode the files initially, so what causes the eventual crash? The only difference is the preference the code gives to certain xordelta instructions when encoding, but as far as I can tell, they are all within the original spec even if they don't match exactly. I haven't looked at reversed code for the XORDelta_To_Viewport code though to ensure it decodes correctly, only the code that decodes to a buffer. At some point I will analyze the difference the commands between the original data and my implementation and try and make them conform exactly so it can round trip the data properly, it will loose some compression, but it will guarantee that any file would be indistinguishable from files encoded by the original.

This isn't a finalised menu structure so don't worry, we only just got the thing drawing. Currently its just text anyhow, the buttons don't do anything yet and we can label them anything we want.

After much toil we have finally got to the point we can properly draw the games main menu. Behind this there is a lot of initialisation code that sets things up for the game proper, but that isn't strictly needed just to draw the menu and its buttons, so don't look at this as only a bit of drawing code. Basically, whatever the game had to do to get to this point, our code can more or less now do (no videos yet I'm afraid ) There are still issues to resolve though. For one thing, the original game doesn't follow what is now a standard game loop of input > logic > render, but instead relied on being able to draw directly to the frame buffer, which was possible under Direct X and DOS, but isn't so much under modern graphics frame works. Currently we use a timed callback on the main thread to draw the mouse as the original does and at the same time we refresh the screen. This happens at 60 fps, but whether this is workable as the game gets more complex or for higher resolutions remains to be seen as we are just pushing the whole frame buffer to the SDL renderer in one go. Another issue that we are currently having is that our event handling doesn't appear to be polling correctly, currently to activate a button you have to mash the mouse repeatedly to get the event recognised, so the next thing we need to pour some time into debugging is the input handler. At any rate, getting to the point where we can display the main menu as the original did is a fairly big milestone for us, as it represents the first interactive part of the game that a user will typically encounter.

I don't really understand the physics, but neutrons and protons are made of quarks held together with the weak force which lets them change "flavour" under certain conditions, changing the particle that they are part of and emitting the electron or anti-electron (positron) along with a neutrino. Its not really that the neutron is "made" of an electron, its more that at this scale quantum effects govern and they don't follow conventional understanding. I don't see how its any harder to imagine a positron than an electron though, they are essentially the same difficult to imagine thing with a different charge. Positrons are part of anti-matter BTW.

Hmm, the plot thickens if the file plays through fine at least once. It is in theory possible the WSASet xordelta algorithm could cause issues as it generates subtley different encoding to the original WW one, but why would it decode correctly a few times and then cause an issue? The decoding functions don't keep any state that I can see.

I'm not really sure why you keep mentioning XCC in all this as it shouldn't affect the in game results, but for the record, if I copy the wsa to pal in XCC from the one I generated and the original, they both export the same palette and neither has that pink index in them. I've attached the version I generated, I would suggest you do a binary diff against the version you generated and see if they differ and then test mine in game. hearth_a.zip

Okay, at a glance the palette is the same as the original version of this wsa, so there should be no need to generate new stretch tables as far as I can tell. wsaset for me generates a wsa file that seems to be valid and has a palette that matches the pcx files. I can't test in game at the moment, but I don't see why you should be having these palette issues. I built it with "wsaset -p -l hearth_a" out of interest just to make sure we are on the same page.

I've uploaded new versions of all the tools at http://omniblade.cncnet.org/tools.zip, I'm fairly confident the WSA tool should be working correctly. As I said, if you can upload your source PCX files somewhere, I can test building the wsa at my end if you want and debug wsaset if it isn't working.

Could be WSASet, it hasn't had extensive testing out the the wild yet so it could have bugs such as not encoding the palette correctly perhaps? I'd need the PCX set to run tests on it to debug it. You could also try the version in the tools pack I uploaded, that has slightly altered palette handling which shouldn't alter the results but might fix it if it was broken. Edit: Err forget the new version for the time being, looks like it definitely has issues with handling the palette correctly :/

I wouldn't have thought so either, but if you checked that his generated wsa has the correct palette, what other explanation is there?

Game still somehow using the old palette then? Guess its not loading it from the WSA or if it is, it isn't setting that as the current palette?