Alpha Centauri 2

Sid Meier's Alpha Centauri & Alien Crossfire => Modding => Bug/Patch Discussion => Topic started by: PlotinusRedux on November 29, 2014, 10:03:35 am

Title: Nope
Post by: PlotinusRedux on November 29, 2014, 10:03:35 am

Thought I'd see what the AC textures looked like over an Endless Legend type frame (though with squares instead of hexes).  Well, now I know--I definitely won't be going that route...

Title: Re: Nope
Post by: Geo on November 29, 2014, 02:40:43 pm

 ;lol

Title: Re: Nope
Post by: Flux on November 29, 2014, 04:44:57 pm

It'd be worthit to re-draw those in a higher resolution I'm thinking.

Title: Re: Nope
Post by: Sigma on November 29, 2014, 08:29:12 pm

Honestly it doesn't look that bad to me, for a game released 15 years ago.

Title: Re: Nope
Post by: PlotinusRedux on November 30, 2014, 02:26:52 am

Here's the same thing with Civ 4 textures--it could be improved a bit by having the tiles bleed into each other, but I think the stepped frames are just a dead end.  I might add them as an optional view at some point in the future just because it makes elevations easier to judge, but I wouldn't want to play on anything like this--AC today already looks better than this.

Title: Re: Nope
Post by: Flux on December 01, 2014, 02:58:57 am

Hm. That does look like crap. Also made me want to play Civ 4 again.
It would be pretty cool to see one of these open-source WIP ports like JAC or opensmac be made in 3D. Maybe one day.
I haven't the faintest idea of how to program something like that though.

Title: Re: Nope
Post by: Yitzi on December 01, 2014, 12:23:48 pm

Quote from: PlotinusRedux on November 30, 2014, 02:26:52 am

Here's the same thing with Civ 4 textures--it could be improved a bit by having the tiles bleed into each other, but I think the stepped frames are just a dead end.  I might add them as an optional view at some point in the future just because it makes elevations easier to judge, but I wouldn't want to play on anything like this--AC today already looks better than this.

As for elevations, I know of at least one bug intrinsic to the way that elevations work, and one of the potential future projects is making them work in a more intuitive manner (so that having a 1999 elevation square next to a 1 elevation square is not easier than having a 2001 elevation square next to a 999 elevation square.)

Title: Re: Nope
Post by: PlotinusRedux on December 02, 2014, 07:18:55 am

Yitzi--That's funny, I've really only looked at elevations from a graphics point of view.  Divide by 1000 then compare, eh?

BlueFlux--I haven't abandoned using 3D (via DirectX 9), just doing so with the Endless Legend stepped look.  At least, 3D for the terrain--unless there's someone here with a lot of time that's good at making 3D models, I plan to leave all the units, etc., as 2D sprites, just with better color depth and possibly a little animation and run through DX9 for better scaling algorithms.

If I had time, I *could* do an open source rewrite of everything except the AI--I've never looked in to how AI is done for games like this.  That would really take more time than I have to spare, though.

Title: Re: Nope
Post by: PlotinusRedux on December 02, 2014, 09:02:11 am

I'm still trying to decipher this terrain shading code.  It's actually quite sophisticated for a paletted 1999 game, complete with spectacular lighting, all done in code without any help from DX or OpenGL.  To increase the color depth, I either need to convert all that code to handle 32-bit color, or just bypass it and let DX or OpenGL handle the shading--the latter will be easier, give better results, and run faster, as even a basic intel chip without a graphics card can handle a good part of it in hardware today.  But I'm impressed at what they managed to do themselves--you can really tell the difference between a game like SMAC Sid cared about, and Civ:BE where he's phoning it in from a beach somewhere....

   

Title: Re: Nope
Post by: Yitzi on December 02, 2014, 12:34:35 pm

Quote from: PlotinusRedux on December 02, 2014, 07:18:55 am

If I had time, I *could* do an open source rewrite of everything except the AI--I've never looked in to how AI is done for games like this.  That would really take more time than I have to spare, though.

It's mainly done via "maximize function X" functions.

However, the AI for SMAX, and I think even SMAC, isn't too bright, and it would probably make more sense to just rewrite it from scratch.

Title: Re: Nope
Post by: ete on December 02, 2014, 05:46:12 pm

Quote from: PlotinusRedux on December 02, 2014, 07:18:55 am

If I had time, I *could* do an open source rewrite of everything except the AI--I've never looked in to how AI is done for games like this.  That would really take more time than I have to spare, though.

If you end up having more spare time than you expect or feel like taking it on as a long term project I would be *extremely* interested in this and willing to help out as much as I can (mostly organization and testing, I'm not much of a programmer but worked closely with the guy who wrote Pokemon Online (http://pokemon-online.eu/) for several years dealing with bug reports/making suggestions/collecting data/helping out with anything that's not serious programming). There are a couple of opensource clones that've been started already (python (http://alphacentauri2.info/index.php?topic=6124.0) (code (https://github.com/dominx/opensmac)), java (http://alphacentauri2.info/index.php?topic=13276.0)), but I imagine you working on this would massively increase the chances of completion, so would throw my weight behind whichever you worked on if you went for it (including starting from scratch).

Especially with regards to AI, I've been thinking for a very long time that having AI as adjustable/easy to swap around scripts acting on an API (like bwapi (http://bwapi.github.io/index.html)) would massively improve the game, and have a lot of ideas about how that could work with UI and interact with the rest of the game. Judging by the interest by AI designers in BW, I'd bet SMAX would be able to attract several people who'd create AI if a vaguely easy to use API was provided. BW AI must be significantly more tricky due to real time, and afaik there's no real top-quality TBS with an API for AI to use. There would even be potential for things like scripting governors who are non-stupid, handling of large armies lategame without total lack of tactics, and custom automate-former settings, ideally reloadable from in-game so it was changeable by text quickly for testing. I'd seriously love the opportunity to fiddle with AI and try to create something that's a real challenge to beat, but I'm not quite dedicated enough to learn assembly and try to fix the AI directly in that.

Quick sketch of my ideas for handling AI:
API which lets scripts read data from game-state efficiently and return actions in a neat format.
General helper script which contains a bunch of universally useful functions, like a library.
Individual AI scripts, which using functions in the library and direct API (plus current faction personality from faction files if they like) make decisions based on game-state.
Each AI script is in a separate file, with UI on the faction selection dialogue to pick the AI loaded for each faction (for humans this deals with unit automation only). We'd bundle easy, moderate, hard, etc AI scripts, with later some of the best/most interesting user-created AI scripts.
Ideally tolerant of reloading scripts in-game, so you could switch windows to notepad++ or something, edit, save, and immediately see the reaction.
Ideally having a time-out system that gave some default action (and an error message?), so the game did not freeze if the script gets stuck.

Title: Re: Nope
Post by: JeroenDStout on December 02, 2014, 08:44:54 pm

PlotinusRedux,

Out of interest, could you perhaps post screenshots of the various factors it uses for rendering? I am guessing the one you posted above is the specular component. I am quite curious what other components the game uses. The final look has a certain uniqueness to it which is not reflected in many games of the time.

Title: Re: Nope
Post by: PlotinusRedux on December 03, 2014, 03:56:10 am

Jeroen--that's the entirety of the shading shown.  I just replaced the terrain texture.pcx with solid yellow of the color seen in the flat squares to isolate the shading results.

Title: Re: Nope
Post by: JeroenDStout on December 04, 2014, 02:05:15 am

Quote from: PlotinusRedux on December 03, 2014, 03:56:10 am

Jeroen--that's the entirety of the shading shown.  I just replaced the terrain texture.pcx with solid yellow of the color seen in the flat squares to isolate the shading results.

Ah, OK! That perhaps makes more sense.

Interesting, considering it is done in the code (not on a GPU), it would have been capable of some more shading effects, like a normal map or shadows. I wonder how this game ran back in 1999, considering it also uses voxels for the units, which cannot have been cheap.

Title: Re: Nope
Post by: gwillybj on December 04, 2014, 11:43:07 am

"I wonder how this game ran back in 1999"

On my K6 266, it was reasonably quick for the first 100 turns or so, became very slow until factions began to fall, then speeded up some. I read a lot of thick books during those games.

Title: Re: Nope
Post by: PlotinusRedux on December 05, 2014, 07:17:48 am

Jeroen,

There's also a bit of palette magic going on with the shading.  If you look in palette.pcx, it's got several color gradients in it.  The shading code just increases or decreases a pixels palette index with no concern for what actual colors that represents--so the degree of luminosity change in each gradient is essentially defining it as a different material with more or less participation in specular and shadow lighting.

As for how it ran--unlike a modern 3d game, it doesn't re-render the scene every frame.  It draws the terrain in view to the backbuffer once, then just keeps displaying that backbuffer until something changes (you scroll the map or terraform or something).  Since it limited scrolling to big jumps, essentially all it needed was a framerate of maybe 2 fps even when scrolling, at 1028x768x8 resolution.

Still pretty impressive for it's day, though.

Title: Re: Nope
Post by: BFG on December 05, 2014, 06:55:38 pm

It's too bad SMAC didn't have a 16-bit option.  I'm pretty sure that 16-bit was available at that point in time, and I know for certain 12-bit was (though it was never very widespread).  I supposed they stuck to 8-bit to maximize compatibility.  Still, as you've said, it's quite impressive what they were able to pull off.

Title: Re: Nope
Post by: Vidsek on May 24, 2015, 09:26:39 am

  To Yitzi and Plotinus:

             Making the elevations rational and more realistic would be a truly great thing!
 
   Probably more for mapmaking than actual gameplay, but I'm sure there are a fair number of us who like to mess with the maps. 
   My main annoyance is placing a river source and then having it run what looks to be uphill, along the side of a ridge (instead of in the valley), in a circle, or so on.
   (Also irritating is having an added river totally changing the course of existing ones, but I'll wager that is determined by a different part of the code.  As is an added then removed river permanently changing the elevation of some tiles)

   Drawing the non-stepped appearance with each tile having only one slope for the whole tile apparently required some serious compromises with a good look taking precedence over the underlying topography.
   My initial suggestion would be having the center of each tile at it's "true" elevation and the visual slope(s) being comprised of "graphic tiles" who's 3D orientation is determined by the four tile centers at their corners.  The "real", locational tile boundaries could be drawn onto that surface to reduce the visual confusion there would be between the landscape squares and the movement/location ones.

   Another peculiarity I've noticed is for areas and strips of elevation 10, 1010, etc. to occur between places you have changed the elevation of.  Often these are the rogue tiles that send the rivers off in weard routes.
(Probably part of the calculation oddity mentioned by Yitzi earlier in this thread, and hopefully one that is easy to find, and better yet, change).

   I haven't played a hex-map game in so long I can't remember how they deal with slope in them.

 (side question: would it be possible to convert SMAC/SMACX to hex w/o it becoming an absurdly huge project?  I'm sure folks have considered it before, but don't know how many would welcome it.  I personally prefer the greater realism in travel distances they allow, even if square tiles look more familiar and  "maplike".)

                                                                                Vidsek the Cartographer

Title: Re: Nope
Post by: Yitzi on May 26, 2015, 03:51:14 am

Quote from: Vidsek on May 24, 2015, 09:26:39 am

  To Yitzi and Plotinus:

             Making the elevations rational and more realistic would be a truly great thing!

It would take a bit of doing, but probably not that much, and it would solve some otherwise unsolvable bugs.  When I start taking nominations for the next patch...
 

Quote

My main annoyance is placing a river source and then having it run what looks to be uphill, along the side of a ridge (instead of in the valley), in a circle, or so on.
   (Also irritating is having an added river totally changing the course of existing ones, but I'll wager that is determined by a different part of the code.  As is an added then removed river permanently changing the elevation of some tiles)

I was just thinking of changing the way elevations themselves work; rivers are another matter entirely, though I could probably figure out those as well.

Quote

Another peculiarity I've noticed is for areas and strips of elevation 10, 1010, etc. to occur between places you have changed the elevation of.  Often these are the rogue tiles that send the rivers off in weard routes.
(Probably part of the calculation oddity mentioned by Yitzi earlier in this thread, and hopefully one that is easy to find, and better yet, change).

Yes, this sounds like a side effect of the calculation oddity.

Quote

(side question: would it be possible to convert SMAC/SMACX to hex w/o it becoming an absurdly huge project?  I'm sure folks have considered it before, but don't know how many would welcome it.  I personally prefer the greater realism in travel distances they allow, even if square tiles look more familiar and  "maplike".)

If someone else can do the graphics, I could probably do the rest; it would be quite a large project, but not a hugely large one.

However, "probably" in this case is of the "I won't know even after I do it, and if I don't catch every relevant function it could lead to significant bugs", so doing it safely would probably be an absurdly huge project at this point.