Nyerguds

As far as I know, display scaling is generally a graphics driver or even monitor property... unrelated to the game. The only thing we can do is offer the cnc-ddraw scaling options to compensate.

Under about two dozen names

That is a completely nonsensical statement. The creators have no obligation whatsoever to release source of their products, not even after a hundred years.

I don't ban people for telling me I could be nicer. And I see no point in euphemizing what I mean to say. Anyway, I'm not going to discuss what Vendetta did or didn't do, since I wasn't there, but Funky could've been more forthcoming with telling Vendetta how long he was banned, yea... he didn't even tell me; he just said it was permanent. It's always nicer to handle these things on the channel instead of having yet another one of these topics appear on the forum They're shown in the cncnet lobby channel every time you log in on it. There's no link, just, "Rules: No racism, harassment or impersonation allowed! No Religions/Politics!" Is that not clear enough?

You know, neither microwave nor X-Ray are light spectra... both are in the electromagnetic spectrum. It's kind of a completely different thing Overall, this seems like something that could be in Tiberian Sun (in fact, internally, it HAS more types of tiberium, including a red type), but for TD? Nah. It's just way too early in the terraforming process. Oh, and people already sometimes use harvesters full of blue tiberium as demo trucks in TS: Firestorm, so, even more explosive types? Might have unintended superweapon effects :laugh:

I resized my browser window to see how it would look in tablet mode, yes. That's how I noticed the fact that clicking any game / mod on the mane page has the same effect, instead of actually going TO that game on the downloads page.

Ugh, stop bumping this.

Yeeah, Imma just lock this now, 'kay?

I think the whole site takes waaay too much surface area for what it tries to convey, personally. If you scroll down on the main page, the whole "ONLINE ANYWHERE" thing, that takes up a whole screen, is just a huge duplicate of the "status" link at the top. Who will ever even scroll past the games anyway? It looks rather lost and useless, there. The whole intro screen at the top of the page is kind of the same thing, really. It reminds me too much of these old websites with a small useless intro page you need to click through to get to the actual site. Only difference is that this one you have to scroll through. Either way, same function... or, lack of function. Also, clicking on a game in the main page list should really scroll you to that game on the downloads page. On the subject of the download page... again; same remark. A huge "intro page" again, with a button that does nothing but... scrolling down? Seriously? Why not just give people the actual games list right away? Oh, small remark: all the covers on the downloads page are squashed together in width. You should fix that; it looks kinda bad. Either trim the sides, make the images show as less high, or make them show to their full width. But keep that aspect ratio.

Well, I didn't ban anyone today

I miss the overview of current games per game entry, really.

...I'll just conclude you fail at "thinking about it for a minute"? -_-

I know that. But Tore should put it in the news post somewhere.

Ehh, as far as I know there's no math involved in remapping. It just relies on the fact that in 256-colour mode, each colour 'value' is really just an index on the palette, and thus a value from 0-255. The table is simply a list with 256 entries, telling the game which colour to substitute, for each possible colour index. I imagine the game just goes over the pixels in the affected area, and for each pixel it takes the colour value (meaning, palette index), and uses that value as index in the remapping table to get the replacement colour value. So basically, for the affected area, it just does graphicsbuffer[pixelAddress] = remaptable[graphicsbuffer[pixelAddress]] As for how it determines the "affected area", well, in the case of shadow and map shroud edges, that's what the index table before the filters in the .mrf file is for. It tells the game which of the .mrf file's filters to use for each colour index used on the .shp file.

You may want to, um, add the link. Y'know, just for convenience's sake

yeeah... you can generally figure it out by thinking about it for a minute. It's not exactly espionage-tier encryption

Heli rotors have always been a special case. But, yeah... get some of these RA hackers to look into that and fix it, hehe. I know CCHyper knew about the filter classes in RA which handle the equivalent of the C&C1 .mrf files, so they should have that stuff mapped. As for it drawing it onto the shadow, that doesn't really surprise me. As far as I can see, index #4 on the air units likely uses a filter like the shadow, only one without an actual effect, which results in simple transparency. But for the shadow, it likely just takes all pixels that aren't colour #0. Westwood code, yay!

Well, he did suggest a 15x15 map right after that

You know, honestly? I never looked at anything C/C++. I'm a C#/java programmer by profession, so overloading of classes and such was part of the curriculum in my studies. All the rest I mostly learned by seeing it in the disassembler.

Huh... so you're saying colour #4 is not drawn on the airplanes? That's annoying... It's probably because their shadow is generated on the ground, then, yea... I guess the game seems that as an excuse to NOT draw it on the plane itself Having looked into the filtering mechanisms in C&C1, I doubt that'll work; the game has no reason whatsoever to apply the filters of OTHER effects to the units. In fact, it surprises me that the game doesn't just draw the index #4 pixels as green ingame, like it does with the phase tank cloaking bug.

There are moderators who care too, so don't make racist jokes or it won't just be one week

Bad idea as well. Maps smaller than the playing resolution have a ton of problems all by themselves... making a 1x1 map could crash the game for reasons completely unrelated to the scripting. That doesn't work. You can't 'not' give starting waypoints. Multiplayer logic says each player needs a spawned army, each at its own waypoint. You'll just run into the same bugs we had before when there were less starting points specified than there were players on the map, namely, the waypoints getting read from an array that was never filled, resulting in it using whatever crap happens to be left behind in memory there from previous operations and using that as starting points. In fact, with my patch, the ingame LAN UI will see it as a 0-player map (since there are 0 valid waypoints) and refuse to let you start the game, and I sincerely hope cncnet copied these logics. Not to mention, manually putting MCVs on the map will make those MCVs be there for all 6 players even if the map is played with less than 6, resulting in AI MCVs. Oh, and, um, that would in no way solve the problem of the chinook landing spots, since those ALWAYS need waypoints Glad you got it working!

Depends. Names composed of different pieces (like ????ICON.SHP for the unit icons) will not have the full name strings in one place, so I assume these are similarly composed of separate pieces, somehow. Though I guess it could be traced back from the code that makes/uses these ????_vtx.pal files.

Ohh, that! I'm fairly sure I fixed that in my patch. Waypoints above 11 (0-11 being twice the maximum number of players) can be used in multiplayer scripting and will never act as MCV spawn points Waypoints are a specific range, by the way, from 0 to 27, because internally, somehow, they represent 'A' to 'Z'. (You see this on the trigger "DZ at 'z'", which puts a flare at waypoint 'Z', meaning, waypoint 27.) So you can't just use waypoint 302 or something ridiculously high like that; the game only reads them up to 27. Also, they don't need to be filled up in order. So just use waypoints 11 and above.