X mod v 1.3

[Xenon]

Restored the mod who has not previously worked in the later versions of the game and slightly improved it.
Maybe someone remembers my work x mod 1.1 and 1.2 version is now 1.3. load. try to play in the regular installation folder mods.

link for download: http://www.mediafire.com/download/dojxm ... d_v_1.3.wz

almost did not make screenshots. who make and lay them in this thread, I'll be very grateful, but for now here's a couple))

[Jorzi]

Very nice work
But how come some of your textures are so low resolution? That's quite unfortunate.
Btw really cool cyborg design

[Rman Virgil]

.

I too especially like the your Cyborg designs. The detail is amazing. (Also imagining them side by side with XANAX's Mechs.) But there is that contrast with some of the textures being lower res, like Jorzi said, and the screens below illustrate.... something you can always get back to down the road, I imagine.

I took some screens while testing it with my "New Pangaea" and I'm happy to report no conflicts with running it side by side with "USM" and also no Pixel Buffer Overflow CTDs like I unfortunately experienced when running AR mod after the 45 minute mark. So I'll recommend running your mod in my Pangaea thread.

.

[cnceo]

Very nice cyborg indeed . What is the license by which you release those models? That would be nice to know, just in case someone would like to use those models for his/her project or combine it with other mecha models.

[Jorzi]

@Rman: Pixel buffer overflow? Could you please elaborate, info about your graphics card would also be nice. Does the game crash or do you just get weird artifacts?
Sry for hijacking the thread:P

Btw, I noticed that some models, especially tracks & halftracks, have pretty high polycounts, and I saw some slowdowns (my processor is a 3.4GHz phenom II), but only when using shadows. Since Per has been experimenting with shadow buffers, I hope we can soon use these high polycounts in AR mod too, and still be smooth on any openGL 2.0 capable machine.

[Rman Virgil]

@Rman: Pixel buffer overflow? Could you please elaborate, info about your graphics card would also be nice. Does the game crash or do you just get weird artifacts?
Sry for hijacking the thread:P
.....

Hey Jorzi, I did get into all this when it came up in my "Oddities" deving thread. But that's awhile back now and buried in mountains of my rhetoric.

So i'll sum it up quickly....

2X Nvidia 9600GTs in SLi. Crashing direct to DT, no artifacts that I could tell. Thing is I ran AR & USM from the start, & for months, as I deved without any issues. It seemed to me that as what I was making became more complex that I crossed some threshold of overall graphic complexity processing. I then did a lot of research (coding wise) on "Pixel Buffer Overflows". With WZ originally constructed in C (with its inherent limitations in this area), and presenting a legacy situation wherein you cannot go back to wholesale re-design code in this area to account for no basic, direct, pixel buffer overflow checks in C, a remedy doesn't look good for the results I was triggering with what I was doing. However, the good news is that it is highly unlikely anybody is gonna do what I did so this may be a singular consequence - but I'm really just guessing.

The obvious question is why has my running X-Mod not, so far, at the same runtime juncture, triggered the Pixel Buffer Overflow ? All other factors being the same, what could be the diff between both graphic Mods that could make the diff between one triggering the consequence and the other not ?
.

[Jorzi]

Ah yes, now I remember.
I guess the AR mod is fairly taxing on texture memory and doesn't really expect to share it with anything else. Not sure if that would cause a crash to desktop, though.

[Rman Virgil]

Ah yes, now I remember.
I guess the AR mod is fairly taxing on texture memory and doesn't really expect to share it with anything else. Not sure if that would cause a crash to desktop, though.

Which brings to mind that Pumpkin designed thier C code to help prevent pixel buffer overflows 17 years ago and with a mind to the graphic load they intended for retail release in '99. We know it had to be creative and clever to begin with, and to have held up to this point.... but makes you wonder, going forward, how robust that code design is gonna continue to be as graphic loads continue to evolve.
.

[Rman Virgil]

Very nice cyborg indeed . What is the license by which you release those models? That would be nice to know, just in case someone would like to use those models for his/her project or combine it with other mecha models.

Yup.

And actually, to post work here Xenon, you need to include a release license.

.

[Xenon]

I recognize that my job requires some refinement. For example you need to deal with some textures, reduce the number of polygons in the 50% of the models and to replace the model of fashion art Revolution on their own. - I hope the guys will not be much that I swear they borrowed some shell tanks

Do not quite understand what you said about the license. where to take it?)

[Jorzi]

Depending on your target hardware, your polycount might be ok. Overall very good work

About license: Just choose one. (For example CC-By-SA).

If you don't, it means you technically have full copyright and we're not allowed to install it without asking for explicit permission every time.

[Boris]

to much yellow colors,,and low polygons,,not impressive..