Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Destructavator

Pages: [1] 2 3 ... 11
Offtopic / A goodbye note, a token offered in respect.
« on: October 08, 2017, 05:32:46 pm »
One needs wings to take to the skies.

One needs to channel a Letharg to push a bull; One needs courage, bravery, determination, and confidence to cleave.
One needs other virtues as well, but as to what those may be I'm not going to tell you - at least not here.

One needs to chill if they have a lack of tolerance for my sucky poetry.

One cannot recover what one never had to begin with.

Now, to cut the ****, I'm going to talk straight (as if I ever did otherwise):  I'm not going to be here much longer, and those that know my face might not see it much longer, as I'm moving on from playing video games, a well as programming video games with regards to coding, etc., and I'm moving forward to undertake some serious work on issues that will make changes far beyond the potential influence a video game would make on society.  Granted, I have more than one role, more than one job as such, although I have to focus on a few select roles that are the most important and leave the rest to others.  The concept that a single individual can only do so much within the scope of a human lifetime is relevant.  Others would see that change is coming yet of a spiritual nature not typical of most is also relevant.

Don't look for me here, not after the time this is written, but look for a better future, one where there is a better future for most, in particular for those who may come along to survive in a better world as one may see it.  I would advise not to look down a rabbit hole, but to look for those who fly the skies like the eagle, have predatory instincts and other traits like that of a tiger, puma, or other great feline, grow to one day have a mighty yet modest spirit like that of a dragon, have a magical and spiritual nature not found in most others, have a responsibilty to life, culture, and virtue of many worlds, many lands, and many beings including those not found on this planet, and this galaxy in the long term.

Look for beings that bring about and enforce a new way of life, new lands to live in, new relationships in the long run among the galaxies.  Look for new ways to live free of harsh attitudes, runaway bureaucracy, sicknesses, laziness, inefficiency, cruelties and unfair punishments, injustice, ruin and derelict, false empty promises offered by cruel gods, godesses, and the fates that pretend to offer.

Look for life with deep respect to culture, spirit, honesty, trust, art and music, nature, and respect for life and the lands and air and waters about oneself.

Look for this to be enforced, as all things do have a price, and one cannot expect such things to come via instant gratification, and there is no solution in living in a pretend world of such.

This shall be enforced in the form of justice, as criminals are evil as as a matter of common sense and are not tolerated.  Keep in mind that good and evil are not black and white, much as these other concepts I have mentioned and talk about in this text.

Look for those that enforce this justice, as well as these other roles, and more which might or might not come with time.  Understand that this justice is relevant to removing deception and lies - especially of extreme nature, which is itself certainly evil any way one slices it.

Look for those who slay and remove such evil, meaning those who create and back such madness and craziness, sickened by their own influence that they perpetuate.  Those who push such insanity are themselves criminals, and are even more evil for offering a so-called cure for the Lifemare they create.

These beings who offer and bring about such justice are not human, and although some would call them "space aliens" perhaps, they are spiritual beings of a special nature.  They also have emotions and something of a playful nature as well when they are not working hard within their roles.  Their roles differ, as they are not clones.  Their personalities are dynamic, and they can be creative, insightful, and wise in different ways.  They are magical in nature, a key and vital part of their spirit which is inseparable.

These beings have respect for honor in their own right, and are not to be feared or misunderstood as enemies as long as they are not provoked or mistreated.

They can also both teach and learn, and have much to offer, although they are not doctors or nannies.
They all have potential to be a warrior in their own way, although what titles others have for them will vary, as well as what they call themselves.

Look for their wings, their feathers, their personalities, their magics, their spirit, dynamic in nature, and especially their courage and altruism.  They are best known by face to conversation, not by gossip.

Scorchcrafter is not dead, and although much was not uploaded, it will be passed along and still available in one form or another.  It will not disappear, or what inspired it.  This is not what will be a severe issue, in the face of maturity and non-involvement in petty childish arguments, as solving problems are more important than blame.

I do not expect to paint any more guitars any time soon, and as such I would not expect anyone to look for the workshop that offered such in the town of North Olmsted, Ohio.

Artworks are sacred, precious, worthy of respect, and are worth fighting for, so that they survive.

Farewell, I offer.

Offtopic / Getting this going again (pics attached)...
« on: April 17, 2014, 02:52:32 pm »
As some of you may have guessed, I've been busy for quite a while, but I never gave up on any of the open source projects I've been working on, just slowed down quite a bit for a while.  Anyways, I plan to soon be not only working on UFO AI again, but also my own game project.

I've got a new main character model for my game, as shown in the pics, and I think it looks much better than the old, clunky one.  This model has the benefit of normal-mapping technology that the old one did not have, as well as some newer modelling tricks and techniques I've learned.

I've also studied up on how to use per-pixel special maps (lighting, specular, bump/normal/tangent-mapping, etc...) in shader code, and at a glance it doesn't look much harder than some of the shader work I've already done so far.

I'm especially proud of the feathered wings in this model, which I think look much more real.  There's a trick to how the wings are rendered, done with a total of less than 350 faces for both sides of both wings (They do have depth, they are not simply flat planes), yet by looking at the pictures one might guess at a glance that there would supposedly be a lot more mesh verts and faces for all the detail.  Most of the edges and faces are broken up simply for the joints, so they can be animated (each side has 11 bones, 1 base connected to the character's back, and 10 for bending/flapping the wings).

I think the material for the clothing came out kinda cool, too.

I'm still doing some planning for exactly how the game will work and what it will be like, but one thing I know for sure: Much of the game's content will be generated randomly for each campaign/gaming session, so it won't be exactly the same game every time it is played, including map layouts of game areas being different every time.

As for UFO AI, I *do* plan on finally getting together some kind of air combat system in 3D, although I'm probably going to keep the first implementation rather simple and try to add to it, rather than trying to shoehorn a complex, extensive addition all at once like I had tried to do before with the code than got busy part-way through coding it.

Hope to see more of you guys around, soon, and hopefully get to know some of the newer faces in this community since the last few times I checked in to the project...

(I've been involved with UFO AI for years, a long time now, on and off...)


All right, for those of you who for whatever reason didn't see the chatter on IRC about it, I've finally registered and started my own game, open-source GPL:

It is still in infancy, but already has a simple demo where you can make the main character move around in the game world and do a few things, including basic flight implementation.  (The main character is a creature that is somewhat like a human, but has large feathered wings to fly with and also fangs and retractable claws.)

I currently plan to make it into a game with a mix of fantasy (spells and magic) and technology (also fighting enemies with machine guns, pistols, grenades, etc.).

Eventually the game will be built for all three major platforms (Win, Mac, Linux) as all the libraries used support this.  The code uses OpenMP for easy multi-threading on machines that have multiple cores.

At this time I don't even have many people to test it, and I've found a few issues with running the demo on my laptop with an ATI graphics card, although I get spectacular results on my desktop with an NVIDIA card.

I'd welcome opinions and feedback from anyone interested.

OK, if anyone wants to try my code for rapid terrain generation for use in realtime 3D animation or gameplay, I have an updated version of my demo that includes it on my website:
or the very latest with a different rendering technique (read the thread) at:

The basic, non-technical topic which also talks about implementation is at :,6771.msg53947.html#msg53947

I'm designing it not just for UFO AI but also for other GPL projects as well, including some of my own.  I'll try to make it so that the code can be easily brought into nearly any C++ project.

NOTE that although the demo uses Irrlicht to display the created map, my code itself doesn't require Irrlicht, it just relies on a few basic libraries that are standard for C++.  At some point I plan to add a check for #define statements that indicate the presence of libPNG and zlib, and if it finds that they are present it will enable a few additional functions to write the created map and object textures to a file, so that the programmer doesn't have to write a loop using GetTexturePixelData() for the color values of each pixel one-by-one.

The created map can be thought of as a grid of 250x250 "spots" - each spot having several pixels of texture and other information that is retained by the instance of the terrain class after it makes the map.  The reason it isn't 256x256 is that the number of verts for the mesh that the map is made on MUST be 1 unit greater (in each dimension) than the number of spots, because each spot on the map has four corners, with most of the spot and texture data pertaining to the center or the whole square.

So the default size map is 250x250 spots, with 251x251 verts, and each spot by default (unless specified otherwise in map creation parameters) has 4x4 pixels of texture, which means the texture is 1000x1000 pixels.

If you ask "Why don't you just make it 256x256 spots anyways, with 257x257 verts and a 1024x1024 pixel texture?" the answer is limitations of the OBJ model format.  The info I've found on the format says that 257x257 verts would mean too many index entries in the model file, which some 3D engines wouldn't be happy about.

The data retained for each spot currently is in several structs for each spot, aside from the texture pixel data, there's also a struct that one can get() information from:

Code: [Select]
struct TerrainPointData
float cornerHeight[4];
int cornerIndex[4];
float lowestPoint;
float highestPoint;
float centerLocation[3];
float steepness;
terrainLevels terrainAtPoint;
int isCoveredInSnow;
int isAboveWater;

I'll eventually expand this to include population information that can be used to decide what map tiles to load for the battlescape when a UFO lands or crashes at a certain spot on the map.  The reason for the isCoverdInSnow and isAboveWater being int and not bool is that each spot could have part of it under water or snow, and other part of it not, so the int value is compared with how many sub-parts of each spot there are, to make a ratio.  (By default the demo makes the map with 16 sub-spots as 4x4 for each spot, so a value of "8" for isCoveredInSnow means half the spot has snow on it.)  The "terrainAtPoint" is an enum that holds data on the type of terrain at that spot.  The "climate type" refers to what basic type of terrain the whole map is.

Code: [Select]
enum climateTypes

enum terrainLevels

Design / Improved Air Combat (coming soon...)
« on: June 13, 2012, 09:56:24 am »
EDIT:  The updated version of the demo (version 5) is at
EDIT:  The updated version of the demo (version 6) is at
Note: The download is just under ~70 MB, and the pre-compiled Windows version (built for 32 bit) requires SSE2 (which shouldn't be a problem unless you have very old hardware).  It also uses OpenGL, and as such I'd recommend using the latest graphics drivers direct from the manufacturer (NOT Windows Update) for best performance.

EDIT (again) Please also look at:

Sorry, I used the wrong compiler, the working version for 32-bit is at:

-- For reference, on my several-year-old Dell desktop (i7 CPU, 2.67 GHz) with an almost-as-old Nvidia GTS 450, I can run most terrain selections in the demo at full screen with anti-aliasing cranked up all the way and get around 150 to 190 FPS while viewing most parts of the generated terrain and objects in the demo, using Windows 7 HP.  Also, the demo is not currently multi-threaded, right now it is built to use just one CPU core.

The technical, coding thread on this is at:,6772.msg53968.html#msg53968

OK, I've been working on developing code and stuff for a new system for air combat / interception.

It'll work in a 3D environment, and unlike the battlescape all aircraft and things will move and fight all at the same time, although the speed and pause controls from the geoscape will still be available - in fact the player won't leave the geoscape at all, it'll all take place in a custom UI node on top of the main geoscape view.

As I picture it, if the combat starts with the player's aircraft chasing the UFO, the UFO will start in the center of the map, with the Phalanx aircraft at an edge, approaching the UFO.  If the UFO is coming after a dropship or player craft, this is switched, and if both are coming at each other, all opposing forces start at opposite edges of the map.

The biggest obstacle I ran into was trying to get background terrain - I needed to code something that could quickly (with an optional seed value) generate background terrain that wouldn't leave the player waiting a long time, and also be displayed as a 3D model in the scene graph able to be rotated and moved around in realtime.

I've worked hard on this, and I've now gotten together some terrain generation code that can do these things in a work-able way.

Don't expect anything photo-realistic like Terragen 2, that wouldn't run fast enough for realtime animation for a video game.

The code I've written isn't fully complete, but could generate different types of terrain for various areas on the map, so arctic terrain would be made over Antarctica, mountain terrain over a mountain region, etc.  It could also make lunar or alien-world terrain.

Oh, and any aircraft that pass beyond the border of the generated map would be considered to have escaped combat (for the moment).

The code I wrote also retains data for each spot on the terrain, so when a UFO is shot down the game will know if it fell in a lake, on some trees, on a mountainside, etc.  This information would then be passed to the battlescape, so a ground battle in a matching map would occur.

I also plan to extend this to generate buildings, cities, trees, etc. and place them on the terrain.

Right now, if anyone wants to demo the terrain generation, it is currently compiled to run with 64-bit MS Windows, using OpenGL via the Irrlicht 3D Engine (also on SourceForge), just for a quick demo.  If you can run it, use the cursor arrow keys to move around and the mouse to tilt and steer to move around the landscape.  Use the usual ALT-F4 to close the program.

For the technical side, this code generates and writes WaveFront OBJ model files of the terrain, water plane, and other objects.  It also generates a texture map for each, and the texture pixel data, although it doesn't include any PNG writing library of its own, but has get*() functions for getting the data.

I kept this version of my code very general as I intended to use it in not only UFO: AI, but also other games and programs.  For UFO AI I plan to modify the code and extend it to feed the generated terrain directly into memory instead of a file, as well as the texture, and of course render it with the game's engine, not Irrlicht.

You can download the demo at .
EDIT: Look at the top of this post for the latest download.

Newbie Coding / New Auto Mission code proposal
« on: March 30, 2011, 10:22:08 am »
OK, I've talked with BTAxis and looked over the old proposed Auto Mission code on the wiki page.  The old proposal doesn't factor in a lot of stuff, doesn't have some realism factors (Two wounded units can be more deadly than one healthy one), and it also has the issue of the Balance Of Power slamming into a "solid wall" if it strays above 1.f, rather than curving towards it.

This pseudo code I'm going to list here would fix much of that, and after something like this is put in the could could then pick back up on the old proposal starting from "Injuries and Casualties" once the Balance Of Power is calculated.  This new system would let that balance curve in a controlled amount (anywhere from a slight adjustment to leaning heavily) towards the range boundaries of 0.f and 1.f without completely reaching them.  This means a lone soldier could still have a very slight chance of winning a mission against a group of aliens (although that slim chance wouldn't be pretty for the soldier.

I'm also attaching two pics showing examples of how the curve function can work with different values.  The result isn't quite "exponential" but is very controllable.

Code: [Select]
// Custom functions for manipulating floating point number
//    up and down without straying outside of 0.f and 1.f,
//    also doesn't need min() or max(), but rather keeps
//    everything in a nice curve.
// "pushV" and "pullV" are floating point parameters
//    that set how rounded the curve is, or in other words
//    how much to push or pull toward 1.f or 0.f.
// "pushV" and "pullV" can range from 0.f (very subtle)
//    to just under 1.f (extreme change).  I personally
//    would not recommend going above 0.99f (usually).

float PushUpward(float oldValue, float pushV)
    float newValue = (((1.f-pushV)+1.f)*oldValue) / ((1.f-pushV)+(1.f*oldValue));
    return newValue;
float PullDownward(float oldValue, float pullV)
    oldValue = (1.f - oldValue);
    float newValue = (((1.f-pullV)+1.f)*oldValue) / ((1.f-pullV)+(1.f*oldValue));
    newValue = (1.f - newValue);
    return newValue;

// Now for the actual Auto Mission code

float BoPindex = 0.5f;  // Starting or "base" balance of power (chance of sucess)
                        // for the mission, can be set lower for hard game
                        // difficulty, or higher for an easier game.  NOTE: If
                        // this is set higher or lower it should NOT be set to a
                        // perfect 0.f or 1.f, it should always be somewhere
                        // in-between.  Normal games start at 50% success rate,
                        // before we of course "play" with it.

float numberOfSoldiers;  // Total number of soldiers on a mission, and yes, it
                         // needs to be casted into a float, you'll see why shortly.
float numberOfAliens;    // Same thing for aliens.
float numberOfCivs;      // Same thing for civilians.

float playerFactor = 1.f;
float alienFactor = 1.f;
float civFactor = 1.f;

for(x=0; x < numberOfSoldiers; x++)
    float tmpF;
    tmpF = soldier[x].currentHealth / soldier[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);  //This accounts for the fact that two wounded
    playerFactor += tmpF;           //Soldiers can be more effective than one healthy one.

for(x=0; x < numberOfAliens; x++)
    float tmpF;
    tmpF = alien[x].currentHealth / alien[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);
    alienFactor += tmpF;

for(x=0; x < numberOfCivilians; x++)
    float tmpF;
    tmpF = civ[x].currentHealth / civ[x].maxHealth;
    tmpF = PushUpward(tmpF, 0.5f);
    civFactor += tmpF;

float playerFactor = float (1.f / playerFactor);
float alienFactor = float (1.f / alienFactor);
float civFactor = float (1.f / civFactor);

if( Civilians are infected and hostile )  alienFactor = PullDownward(alienFactor, civFactor*0.5f);

if ( playerFactor > alienFactor )
    float tmpF = playerFactor - alienFactor;
    BoPindex = PullDownward(BoPindex, tmpF);

if ( playerFactor < alienFactor )
    float tmpF = alienFactor - playerFactor;
    BoPindex = PushUpward(BoPindex, tmpF);

// Here the sums of equipment scores are factored in.
float plyrWeaponFac = float (1.f / soldierEquipmentScore);
float alnWeaponFac = float (1.f / alienEquipmentScore);

if ( plyrWeaponFac > alnWeaponFac )
    float tmpF = plyrWeaponFac - alnWeaponFac;
    BoPindex = PullDownward(BoPindex, tmpf);

if ( plyrWeaponFac < alnWeaponFac )
    float tmpF = alnWeaponFac - plyrWeaponFac;
    BoPindex = PushUpward(BoPindex, tmpf);

Note: All the "0.5f" values within the custom push/pull functions are "magic" numbers that could be changed to alter game mechanics.

Artwork / MUCH Better! (heads/faces)
« on: January 09, 2011, 01:20:44 am »
Now this one was a piece of cake compared to my past character heads.

With the new test dev release of MakeHuman, a little rendering work from Aqsis, and a few adjustments to a mesh, I was able to put together a low-poly head/face that still retains nice texture detail.

This head has less than 400 total verts, despite what it might look like.

(I've only mapped it from the front so far, which explains the artifacts on the sides.  When I'm done it'll look nicer.)

Thanks to recent developments in the Makehuman software, this took only a few minutes to put together once I figured out just how to go about doing it.  Yes, the days of the old, hard way of making character heads is fading, and much less of a chore now.

BTW, MH software now automatically makes clothing too, automatically shaped to fit the body meshes it exports.

It still needs some tweaks, and of course hair, but it should come out much better than my past works.

Artwork / High-Detail pilot model for video cutscenes / Intro
« on: November 26, 2010, 01:51:26 am »
I decided to put this in a different thread from the new Stiletto model, to keep things more organized.

I've gotta say, the new Blender has LOTS of improvements that make modeling much easier, and using them I've found a neat trick for texturing a 2D image over curved surfaces, wrapping around in a way where there aren't any jagged seams where the polys connect, unlike my past models.

In this case, I've used this trick to apply folds and wrinkles to a solid blue color to make fabric for a pilot model.

I still plan to add a lot to this high-detail pilot model, and do more work on the helmet as well.

Besides adding straps, buckles, and flight gear, what color should the flight suit fabric be?  In this example it was done with a light blue color (not exactly sky blue, but it's just an example).

I'm not really sure what color military air force groups use for their flight suits.

Side note:  If needed, I can eventually also make a low-poly model for use in-game - I noticed we already have a simple pilot MD2 in the trunk but last time I checked (some time ago, I admit) it didn't have too much detail.  Thoughts?

Artwork / New design for Stiletto interceptor model?
« on: October 29, 2010, 04:48:55 am »
OK, I've been using the Stiletto model as it is with test videos for a new intro and such, and there's some things about it that bother me a bit, making me think we could use a new model for it:

1 - If it was really built as it is depicted by the model, with those dimensions, I doubt it could fly like a jet:  How the hey could those little, tiny, itty-bitty wings that look more like fins provide enough lift for normal flight?

2 - It really does look a lot like a helicopter, just with the top rotors ripped off.  I'm wondering if whomever originally designed it started it out that way and then made a quick and dirty change to try to change it into a jet.

3 - Looking through the data source I found a Blender file, although it doesn't have the texture source components (they appear to be missing, not packed into the file), and it doesn't have a high-detail (high-poly) version very suitable for video cut-scenes.

4 - It has markings and logos on it that I don't recognize, and doesn't have any Phalanx logo on it.

5 - I tried to alter it to make a high-poly version with more detail, just for rendering video clips, and it didn't work too well because, again, I don't have all of the original source components of the texture/skin.

I would be willing to come up with a new model for the Stiletto if needed - In fact I do have a partially finished small fighter aircraft on my hard drive that is about the same depicted size, and it wouldn't be too hard to touch it up a bit and display it here.  I also of course have the complete source for all of its texture and such.

Offtopic / Wish me luck...
« on: October 26, 2010, 04:44:53 pm »
Just an FYI, I live in a part of the United States which, today, has the worst weather forecast prediction since about 1979.

There's already a tornado watch in effect for this roughly half of the state, and a lengthy windstorm is expected to move through shortly, one with potential winds up to ~70 MPH or so.  (For you Euro guys, If my quick math is right I think that's over 100 KPH or so at least.)

Hopefully it won't be too bad - I live in a concrete building - But I've got my flashlight, food, and other stuff prepared.

Needless to say, after an hour or so I might be away from this forum for a while, depending on just what happens.

I guess I'm about to find out.

Artwork / Intro Video (specific) planning thread
« on: October 21, 2010, 03:49:21 pm »
(As I mentioned in the sticky thread, I'm breaking up discussion so each video has its own thread, and the sticky thread can be for general plans that apply to all in-game videos.)

This is a ~20 second test render of several clips put together.  It doesn't start at the start of the storyboard plan because I don't have enough low-poly city buildings yet.  It also skips some clip plans because I don't have a modeled cockpit and Phalanx pilot yet.

This is a work-in-progress, far from complete.

I'm thinking of seriously re-doing the radar screen display, but this is a start.

BTW, You've gotta admit - The Stiletto looks pretty bad*ss with those weapons shown mounted on it...  (Shiva cannon and two mounted Sparrow missile launchers.)

I'm hoping to get mostly idea-feedback at this point, so I don't end up polishing something that won't get used.

Artwork / Video in-game cut-scene movie clip planning
« on: October 18, 2010, 04:22:14 pm »
OK, now that I have some serious tools for rendering outdoor scenes, terrain, skies, and backgrounds, I'd really like to get going on ideas for in-game cinematic clips.

Ideas and storyboarding plans can go here, in this thread, anything from hand-drawn sketches to quickly rendered low-quality still drafts.

If you propose an idea, please keep in mind the following:

- If it isn't terrain, clouds, scenery, etc., and we don't already have a 3D model for it, someone will have to make a 3D model and possibly animate it.  Please don't dream up something with outlandish details that require lots of highly detailed models and then expect one of the modelers here to simply do all that work for you.  We already have quite a bit in the data source to start with.

- Also about models, large objects that are viewed from a distance (buildings) should be rather simple, without too many polys, or else rendering scenes would take too long.  Close up content should have fairly good detail though - An example would be the interior cockpit of a Phalanx fighter aircraft and the pilot, to depict a pilot pressing controls and operating the aircraft in the middle of air combat, looking out the window, etc.

- Between Crystan and myself there shouldn't be too many issues coming up with SFX and soundtracks for the movie clips, however:

- No language, written, printed, or spoken please.  That would create localization issues, as we would then have to have alternate video clips and alternate soundtracks for every single language the game supports, which isn't really feasible - I personally wouldn't support such a thing.

- Even without language, we can still depict characters that communicate.  If a civilian is shown watching an alien ship land, a later shot of the video clip could show the same person frantically interacting with another person, out of range for hearing any exact words, but making gestures and pointing to where they saw the UFO as if to imply "It's over there!  I'm serious - I saw a UFO land!"

If a good plan for a video is put together, approved by BTAxis and Winter, and it seems do-able (doesn't require tons of fancy modeling work beyond reason), I will put it together and make it happen.

Artwork / Solution - Rendering large city for animation video cut-scenes
« on: October 17, 2010, 08:44:20 am »
I think I've finally figured it out.

I've been playing around with a 3D terrain/world rendering program called Terragen 2, which is designed for large-scale renders of outdoor scenes in photo-realistic quality, and can do movie clips as well by rendering individual video frames and then applying motion blur.

The program also has an OBJ loader which can load static meshes and move/rotate/etc them among animation frames, as well as applying lighting and transparency FX.  It can do this not only as single objects, but also as procedurally-created populations which can be set to automatically sit on top of terrain.

Normally the population render is for trees, plants, vegetation, etc., but I've found it also works for buildings and other imported models.

AFAIK the free version makes renders compatible with GPL Open-Source projects, although the free edition doesn't do animation (only one single frame at a time) and has other limitations.

Here's a quick example with a simple, spartan terrain and no clouds/sky stuff, but just to show off a 3D model of a building in a population.  I got this "factory" model from an open art collection, according to that site this model is public domain IIRC.

...So all I need now is a few good OBJ models of modern buildings of various types, even half a dozen is good, and I can make what looks like a city.

I'm in the process of getting the full version of the software with animation.

Windows / Attn Windows players with lag/slow performance w/2.4 dev builds
« on: October 02, 2010, 08:37:24 pm »
I've noticed over time as the game developed that the Linux version, once compiled, runs rather smooth compared to the Windows build of the 2.4 dev branch, which runs at a godawful crawl on Windows 7 machines with multiple cores, and I've found a fix to this issue.

I found this works well and makes a *profound* performance difference on my new 64-bit Windows 7 i7 (eight cores) machine.  Before this method I had to turn all graphics options down to lowest settings, and still the battlescape was painfully slow to the point of making it un-playable.  After doing this method I'm about to describe, I can now turn everything all the way up and get smooth framerates.

This involves editing the config.cfg file inside the APPDATA folder with a text editor.

- First, you need to know exactly how many cores your machine has.

- Change the "set sys_affinity" value to exactly one greater than the total number of cores in your computer.

- If you don't plan on running other apps while playing, you can also change the "set sys_priority" to "1" instead of zero.

- In my case I also found it helped to increase the "set cl_maxfps" value to a multiple of my screen refresh rate, which in my case is ~60 (I live in North America, EU players might have a different default screen refresh rate, I really don't know for sure - I know that TV sets are different but don't know if the same is for computers over there).  In my case I put it up to "120" and got very nice results.

That's really it, just those steps made a huge difference.  I noticed that the default sys_affinity when I set up the game was "3" which would have meant both cores on a dual-core machine, but since I have eight cores the game - according to the console log - was confused and used just one core, the third one.  Now it uses all 8 of them.

P.S. - I've installed NSIS installer system again and I hope to have a new, complete 2.4 dev test build for win32 uploaded soon, in the usual thread - for those who want to try this out.

OK, this is what I've found is necessary to build with the new MSYS thing on Windows, and it looks like I actually got "game.dll" to compile but not most of the other stuff.

1 - Download the custom C::B package from UFO:AI site.

2 - Unpack it and add the MinGW/bin folder to the Windows PATH

3 - Go in to MinGW/bin and COPY the "gcc.exe" (not re-name!) file to "cc.exe"

4 - Run the MSYS shell from the batch file in the C::B package under MinGW

5 - Change directory inside the shell to where your downloaded Git copy of the game is

6 - Run "configure"

7 - Run "make"

8 - Watch happily as some stuff compiles and other stuff bombs out (until things are fixed).

As you can see in the log, I also ran "make ufo2map" because when testall failed, it stopped there and I wanted to see if I could make other parts compile.

Pages: [1] 2 3 ... 11