WC4 Remake

You misunderstood me there, I just believe that we, as software developers as a whole, could do way better than C++, with Rust being a prime example of how to combine sensible programming contracts and language abstractions with performant compilation results and low-level access.

As a lead architect and software engineer with experience experience with both core and custom tech, I agree with your statement ☺️ and your above assessment in general. Quite simply, in practice with today's popular technology, you are completely right.

Allow me to answer two specific points in more detail though:
C++ is as good or as bad as the developer using it.
Yes. The same is true for C#, Javascript, Scala, Python, Java and pretty much every other programming language but it is certainly even more true for C++.

The good game engines I've worked with only use a restricted subset of the language, especially if it's in gameplay code, either enforced through design or coding guidelines. Usagi doesn't even use inheritance in gameplay code as it's based on the CES pattern, and then on top of that of course there's scripting. Allocations and deallocations are all abstracted away from anyone on the gameplay side. It'd be a mess to even try and implement the same system with C#, and at the end of the day the code visible to a gameplay programmer is very limited.
This entire paragraph confuses me, as it is divorced from the actual topic, at least in my humble opinion. You are talking about engine-structure here, which just has nothing to do with the programming languages involved at the conrete level of different abstractions.
In addition, what functionality to expose at which level is a general question of architecture and is thus, again, independent of what will be compiled to your assembler, bytecode or whatever the low-level language employed by your framework/platform/language is.
So, while all of this is true, the actually relevant piece of info is that all successful and big game engines out there right now have either a C or C++ core at its heart and that is just an immutable fact at the moment.

Let me repeat again that the intention of your statement, for purposes of both practical game development today as well as this project in particular, is simply correct and not in dispuste.

Therefore, rephrasing my earlier statement:
I am looking forward to the day that C++ is finally dead, which means that it has been replaced with something that follows more modern programming paradigms. To that end, I will take any action possible on my behalf to speed up its demise, which includes not using it for new projects I am resposible for in some form or another, as long as any valid alternative exists.

As such, I am not the programmer you are looking for since I am incompatible with the tech base of this project.

Let's stop de-railing the thread, but I am certainly happy to do a tech-filled nerdy software dev discussion via PM or a different channel 😇
 
Last edited:
This entire paragraph confuses me, as it is divorced from the actual topic, at least in my interpretation You are talking about engine-structure here, which just has nothing to do with the programming languages involved at the conrete level of said abstraction.
What to expose at which level is a general question of architecture, independent of what will be compiled to your assembler, bytecode or whatever the low-level language of choice is.

This wasn't a defence of the language, and more stating that it's not important enough to hate. If the language gives you enough freedom once you've built up your design, issues like threading, memory safety etc; they aren't exposed to the majority of developers.
 
Last edited:
After much, much experimenting, I've decided to abandon 4K FMV for the remake. My reasons are twofold:
  1. The quality improvement over 1080p was neglible at best (it's just asking too much to upscale by 600%)
  2. The file weight for all the game's FMV at 4K would have been excessive
When you combine those two reasons, the decision effectively made itself.

However, I have good news - the quality of the AI models available is improving at an exponential rate. I recently got my hands on the 11th generation of models for Topaz Video Enhance AI and the results are a marked improvement over previous versions. On top of that, I finally calculated an excellent set of tweaks for the h.265 codec which provide an astonishing balance between image quality and file size. Current experiments have all the in-game FMV at double the image compression quality of the h.264-encoded HD Pack V5.0 at far less than half the file size!

If I could, I'd bring these improvements over to a new HD pack - but sadly, the original game won't accept h.265-encoded video - so I believe my time is better spent bringing as many improvements to the remake as I can.

So, how about a sneak preview?


And there's more reason to be optimistic for the future. We still have a long road ahead before we're ready to release the remake in its entirety - and by the time we do, I can only imagine how much better the AI upscaling tech will be :)
 
I approve of this. I recently managed to talk another upscaling-person out of it. When upping low-res stuff, there is only so much than can be gained and while 4k sounds nice, it is often not worth it, considering the filesize.

Do a really good 1080p, that is where its at.
 
Since I have a full set of footage upscaled, here's the original theatrical trailer again, this time re-rendered with the current latest FMV from the remake project :)

Great job on the video editing.. but the space station in the end of it?
 
Since I have a full set of footage upscaled, here's the original theatrical trailer again, this time re-rendered with the current latest FMV from the remake project :)

Seriously, I guess this smooth & clear & 90s texture feeling is very distinctive now.
 
Do you think we will get in the future the some quality in WCP movies ? Or is too much optimistic ?
The WCP videos present their own challenges. The source material is lower quality to start with (I don't believe the DVD footage was ever finalised and fully "mastered" in the first place). The interlacing is more pronounced, there are dot crawl, rainbow and ghosting artefacts, the frame rate is inconsistent between live action and CG etc. etc.

I will definitely return to them and apply some of the new techniques I've learned/developed (and some others I have in mind specifically for WCP), but I doubt they'll ever be up to the standard I can achieve with WC4. I'll try, though :)
 
Many thanks ODVS !! Hope to get a new update soon.

P.S: have you find differences beetween topaz ver 19.00 and 20.00 (last) ?
 
Many thanks ODVS !! Hope to get a new update soon.

P.S: have you find differences beetween topaz ver 19.00 and 20.00 (last) ?

I think the main reason they pushed to a full version update (V2.0) was the QOL improvements to the UI (it's nicer looking, has some extra options, they added sliders instead of just input boxes etc.). There are a few new models (as I've mentioned previously, the V11 Artemis models in particular are much improved), but I think it was the changes to the application that led them to push a whole new version.

I am interested to try out the new Dionne models, which are specifically for de-interlacing interlaced footage. That's one of the things I have in mind to try for WCP, to see if it offers any improvement over the AVIsynth method I currently use :)
 
That is so cool ODVS ! better looking and smaller files...

great ;)
Thanks, John :D

Here's some fun stats for ya:

SC_0010D:
Size in original game as 360p 30fps DVD video - 47.3MB
Size in HD Video Pack V5 as 1080p 30fps h.264 - 40.4MB
Size in WCIV Remastered as 1080p 60fps h.265 - 13.1MB

I have now actually compiled an entire set of videos for the remaster in h.265 at 1080p 60fps and incorporating English, French and German audio streams, and they come to a sum total of 4.15GB. That's 2.3GB smaller than the original DVD videos, let alone half the size of the last HD pack 😄
 
Discs are so 20th Century - we could just stream the game's movies in real time today :)
 
Regarding h.265, what is it that makes it compress so many times more? I never really absorbed much information on video side of things, but back when MPEG-1 Layer III was audio format of choice for the masses (still is to a degree, I suppose), I gained a basic understanding of psycho-acoustics and what they do in trying to pack as much 'audible' data into as little space as possible. I'm aware that, generally-speaking, it's easier for people to pick up on artefacts in lossy-compressed audio as opposed to lossy-compressed video, so there may be some head-room on the video side to reduce file size. Is it the case that they just disguise artefacts better in newer standards and/or are just better at compressing what information they do decide to keep?

I stopped reading on lossy compression for audio because many years ago I switched to lossless compression and never looked back. That's not really feasible for video, though (especially in 'streaming' contexts), unless one is willing to store terabytes or even petabytes of raw video. As Chris alluded to, I know folks in the US and other places with reliable, high-bandwidth Internet are happy to 'stream' videos from on-line but I still prefer to have my movies on disc especially if squeezing video on to lower bitrates means sacrificing quality (even though the quality-to-bitrate ratio seems to be improving with each standard).

@ODVS With all the work you've done in this application, I just wonder if you should get any recognition from Topaz Labs for basically advertising for them. ;) I note they quote a popular YTer in their Video Enhance product page.
 
Regarding h.265, what is it that makes it compress so many times more?

@ODVS With all the work you've done in this application, I just wonder if you should get any recognition from Topaz Labs for basically advertising for them. ;) I note they quote a popular YTer in their Video Enhance product page.

While I don't have a total mathematical understanding of how modern video optimisation works, the laymen's version is that they nominally break the image down into a grid of squares and map pixel movements in those squares between frames. The lower the quality/file-size setting, the larger the squares in the grid (which is why in highly compressed videos, you can actively see the grid - the video doesn't look pixellated, but you can see the right angles in things like smoke, mist and other soft gradients).

Compared to h.264, h.265 can map pixel movements accurately in grid squares twice the size - so the amount of visual data vs. meta data is cut roughly in half. The down side is that it takes exponentially longer to encode and considerably more processing grunt to play back.


Far more technical detail here: https://www.vcodex.com/hevc-an-introduction-to-high-efficiency-coding/

No word from Topaz to me, but interestingly one of the Google search terms that leads people to our official site is "Topaz video enhance AI" 😝
 
Back
Top