Jump to content
XCOMUFO & Xenocide

Concept Art / Fan Art


gu35s

Recommended Posts

here's another set of icon edited from previous.

smaller base and terror site icon.

edited hover text background hopefully to a better and more obvious animation.

 

getting a headache so i ll probably try the latest build tomorrow.

 

thx Mad. not sure what to do to build the new patches but i m sure PezzA would find it very useful.

Link to comment
Share on other sites

  • Replies 521
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

thx Mad. not sure what to do to build the new patches but i m sure PezzA would find it very useful.

Well, with this you could make your own builds without any hassle - so you wouldn't have to wait for me to provide a new build to see your new icons in action (How, is described in our wiki). But I don't mind doing the builds, it's just an offer to anyone interested in playing around with this stuff, and I though it might be a good idea to keep track of the patches and have a source including all the patches in the svn, so anyone interested in helping out would have the possibility to see what is already being worked on.

 

So, here's the new build. The animation is much more obvious now, thank you.

 

PezzA, I have to say, I don't think the occluded icons are visible enough yet. It's still very dark. Plus, it doesn't seem to have any color - it just seems to be grey.

As for the freezing problem: I noticed, that the FPS drop dramatically when the freezes occur, however, CPU load is close to zero - at least on my machine. This problem gets worse the more bases you build, up to the point where time won't advance at all (not even with a lot of waiting) although the FPS are still above 24 and, as mentioned before, the CPU load is close to zero. Unlike kafros, I was not able to overcome this problem by starting a new game. It seem to be quite hit or miss... If you're lucky game-time will advance, if you're not, well, try again next time... I have tried several combinations of waiting or rushing at the different points of interaction from starting the game to advancing the time, but none seemed to have any reproducible influence.

Edited by Mad
Link to comment
Share on other sites

As for the freezing problem: I noticed, that the FPS drop dramatically when the freezes occur, however, CPU load is close to zero - at least on my machine. This problem gets worse the more bases you build, up to the point where time won't advance at all (not even with a lot of waiting) although the FPS are still above 24 and, as mentioned before, the CPU load is close to zero. Unlike kafros, I was not able to overcome this problem by starting a new game. It seem to be quite hit or miss... If you're lucky game-time will advance, if you're not, well, try again next time... I have tried several combinations of waiting or rushing at the different points of interaction from starting the game to advancing the time, but none seemed to have any reproducible influence.

Stupid question.

1. When the game "freezes" can you save it?

2. If you save it, can you restore it?

3. When restored, does it remain frozen? (If so, a copy of a frozen save file would be very useful.)

 

I'll try to find some time this weekend to look into it (as well as inspecting PeeZa's latest patch and getting it into the trunk, and Cube2 research, and RL obligations. etc.) If anyone else wants to have a try, can I suggest nprof http://code.google.com/p/nprof/

Link to comment
Share on other sites

Stupid question.

Is it that time again? ^_^

 

1. When the game "freezes" can you save it?

Yes

2. If you save it, can you restore it?

Yes

3. When restored, does it remain frozen? (If so, a copy of a frozen save file would be very useful.)

Yes, but I haven't tried rebooting my machine (atm, I can't afford to do that), nor have I tried it on another machine, let me get back to you when I have tried both (I'll post it here). Then I'll also post the savegame in question.

Link to comment
Share on other sites

I have observed a slowdown in time progressions, however, this hasn't correlated with any observed drop in frame-rate. My suspicion is that game-time updates are just a fraction of what they should be.

 

dteviot, are you OK if I pick this up and Saturday and report findings to you? I've been looking forward to doing something useful around the underlying game-state code, and this seems like a good in-road to that (I also want to make sure that aliens can land, is this something that you think should be working at the moment?)

 

Also, regarding the shader. I'm totally green as far as HLSL is concerned. My patch was based on the determination that the shader function was just returning a transformed colour value based on how much of the night and day texture pixel to return and sought to split the geoscape into day/night/degree of partial day-night. I'll review.

Link to comment
Share on other sites

i tried the latest build. the day/night transition is much better. but now i m kicking myself since the base and terror site icon is small and blurry. failed attemp.

 

it'd be great if there are a minimum lag as possible. I don't really know hot the code actually works, but is it possible that maybe the refresh rate actually slows down the game because it has to redraw several icons at once? maybe a stuck loop somewhere? well it's not quite my skillset to find out. hope this get solve soon and a new build posted in the front page news.

 

i just have an idea of making px poster... hm. maybe maybe not. better fix those icons first.

Link to comment
Share on other sites

dteviot, are you OK if I pick this up and Saturday and report findings to you? I've been looking forward to doing something useful around the underlying game-state code, and this seems like a good in-road to that (I also want to make sure that aliens can land, is this something that you think should be working at the moment?)
Go right ahead. And yes, the aliens are supposed to land. See http://svn.projectxenocide.com/xenocide/xn...del/Geoscape/AI (for code) and

http://svn.projectxenocide.com/xenocide/xn...oBehaviour.html

http://svn.projectxenocide.com/xenocide/xn...fAIandCraft.htm

 

Also, regarding the shader. I'm totally green as far as HLSL is concerned. My patch was based on the determination that the shader function was just returning a transformed colour value based on how much of the night and day texture pixel to return and sought to split the geoscape into day/night/degree of partial day-night. I'll review.
You're mostly correct. The operation was two step.

1. From sun angle figure out if area is day or night, and then put together pixel based on pixels from day and night image.

2. If day, apply bump map to sun angle to figure out how dark it is, and update day intensity from that. The problem with this is that at the day/night transition, the earth is already almost at 90 degrees to sun angle, and bump mapping doesn't work very well.

Link to comment
Share on other sites

Yes, but I haven't tried rebooting my machine (atm, I can't afford to do that), nor have I tried it on another machine, let me get back to you when I have tried both (I'll post it here). Then I'll also post the savegame in question.

Ok, I've done a reboot, no change so far. But it seems this is a special on my PC (strange thing is, it happened "over night"). On my spouse's PC the game runs without major problems, only short freezes when a new UFO/event is scheduled. The savegame I made is loadable without problems and runs perfectly on her PC. When I load it on my PC the time counter disappears.

 

So what's different?

 

I got VS 2008EE installed

My PC has got a Quadro FX570, she's got an Intel chipset GFX card

Core 2 Duo - Centrino Duo

both run WinXP SP3 32bit, XNA FW installed (but she's got the 1.0 RF + 3.0 installed, I only 3.0 and the GameStudio 3.1, but I don't think this would make any difference?)

 

I honestly have no clue what's going on here... But it seems this is a very special problem... Anyone still interested in the savegame?

 

Edit: I noticed something odd: After a fresh restart Xenocide works flawlessly - the FPS drop to maybe 32 minimum, but always shoot up to around 60 FPS in an instant. Open another app, like for instance Firefox, and the FPS drop to 30-40FPS, and won't come up again. If this is the case, the time won't advance either, the game "freezes" (regardless of build). Now this happens regardless of "binding" Xenocide to one core or several cores. From the point of "freezing" it doesn't matter what I do - close / restart Xenocide, save/ reload, it simply won't "love me" anymore. But if I do a fresh restart of the system, and load Xenocide all is forgiven, and it works flawlessly, until it looses focus for more than a few seconds. After that it is time for a reboot again (And that goes for any of the (admittedly many different) builds I have on my system (So if the last RC is "f*****-up", it doesn't matter if I try another build (in another directory), the other build will behave exactly as the first one).

Curious behavior, huh?

 

Could it be, that Xenocide, if it looses focus for too long somehow "disturbs the inner peace" of the XNA FW, or DirectX? Sounds esoteric, I know, but I really wonder what else could be the reason for this behavior.

Edit2: Interestingly enough it seems that only my PC is that easily disturbed. On the other PC, it doesn't matter how long Xenocide looses focus, it will always come right back, right as rain.

Edited by Mad
Link to comment
Share on other sites

I've added John's "Bump" patch to the trunk.

1. I didn't check in the shader. I'm not sure it's correct.

2. The scaling of the focus ring while it zooms in and out doesn't compensate for time. (i.e. speed of animation depends on frame rate) same problem exists with rotation speed, and flickering of text background for icon label.

3. sceneToolTip in GeoscapeScreen does not appear to be used. (It's always an empty string.)

Link to comment
Share on other sites

This is just a hunch, but I suspect your problem is in function Update(GameTime gameTime) in Xenocide\Source\UI\Screens\ScreenManager.cs

					// pump current screen
				// unless game is running slow, in which case skip the update
				// we've probably been loading resources or something like that, and they don't count
				Debug.Assert(Xenocide.Instance.IsFixedTimeStep);
				if (!gameTime.IsRunningSlowly && (gameTime.ElapsedRealTime.TotalMilliseconds < 20))
				{
					screenStack.Peek().Update(gameTime);
				}
			}

Basically, if things start going slow, the game skips updating the game state, in an attempt to get the frame rate up.

Try commenting out the if statement. e.g.

					// pump current screen
				// unless game is running slow, in which case skip the update
				// we've probably been loading resources or something like that, and they don't count
				Debug.Assert(Xenocide.Instance.IsFixedTimeStep);
				// if (!gameTime.IsRunningSlowly && (gameTime.ElapsedRealTime.TotalMilliseconds < 20))
				{
					screenStack.Peek().Update(gameTime);
				}
			}

Link to comment
Share on other sites

This is just a hunch, but I suspect your problem is in function Update(GameTime gameTime) in Xenocide\Source\UI\Screens\ScreenManager.cs

[...]

Indeed commenting this out fixed the "freezes" as well as the "stutters". Thanks! :)

Now, only thing left is: why is the framerate dropping so low on my machine, and not on the (much less powerful) machine of my spouse? And why would the FPS drop, although Xenocide takes almost no CPU time?

Link to comment
Share on other sites

The sharper Day/Night transition was my doing. There were a number of errors in the shader logic that I "fixed" in check in 1838.

A side effect of the errors was that the shadows cast by mountains were significantly exageraged.

Specifically, the "night" term was derived from both the sun and the earth's bump map (normalFromMap is the bump map) and that the night term was exagerated. (resulting in much more noticable mountains.)

 

The relevant sections (old code)

	Input.ViewDirection = normalize(Input.ViewDirection);
Input.LightDirection = normalize(Input.LightDirection);		 

// Calculates light intensity using the normal map instead of the model normal
// Ambient is hard coded to 0.25
// and we multiply sunlight by 3 to quickly ramp to full daylight.
float dotL = max(dot(normalFromMap, Input.LightDirection), 0);
float sunlight = clamp(dotL * 3, 0.25, 1.0);

// Night lights bitmap.  (Note, lights start going on at twilight)
// and make lights ramp up quickly to full
float nightTerm = saturate((0.2 - dotL) * 3.0);

// Base Color
float4 diffuseTexture = tex2D(GeoscapeTextureSampler, Input.TexCoord);
float4 nightTexture = tex2D(NightTextureSampler, Input.TexCoord);

Output.Color =  diffuseTexture * sunlight + nightTexture * nightTerm;

Newer version:

	Input.ViewDirection = normalize(Input.ViewDirection);
Input.LightDirection = normalize(Input.LightDirection);

// figure out if pixel is in day or night
float sunangle = dot(Input.TangentToWorld[2], Input.LightDirection);

// quantity of night texture to apply (1 for night, 0 for day)
float nightTerm = step(sunangle, 0.01);

// initially set lighting to night conditions (easy case) (Ambient is hard coded to 0.25)
// but if pixel in daylight, recalc values to day conditions
float dayTerm   = 0.25;
if (0.01 < sunangle)
{
	// Calculates light intensity using the normal map instead of the model normal
	// light intensity on day must be at least 50%
	dayTerm = (max(dot(normalFromMap, Input.LightDirection), 0) * 0.5) + 0.5;
}

// Base Color
float4 diffuseTexture = tex2D(GeoscapeTextureSampler, Input.TexCoord);
float4 nightTexture = tex2D(NightTextureSampler, Input.TexCoord);

Output.Color =  (diffuseTexture * dayTerm) + (nightTexture * nightTerm);

I tried the original code and all seemed to work OK. Was the reason for the change? The effect as per the original code is great, very sinister and fun to watch (especially over Asia).

 

Still working on the slowdown and time v rate rate items, just experiencing an unexpected alignment of the those bothersome planets, work and duty.

Link to comment
Share on other sites

I tried the original code and all seemed to work OK. Was the reason for the change? The effect as per the original code is great, very sinister and fun to watch (especially over Asia).
The main reason for the change was with the older shader, it was very hard to see the transition between day and night. Which meant that for a player, it was hard for them to tell if they'd have a day mission, or a night mission from the Geoscape.

There were also (in my opinion) issues with the bump mapping logic using the same calcs as the "day/night" which resulted in exagerated bump mapping artifacts. My objections to that were purely theoretical, and I forgot one of the cardinal rules of game programming, ignore reality, if the simulation is better than reality, use it, who cares if it's wrong.

 

So, long story short, if people prefer the pre 1838 shader, we can revert it.

Link to comment
Share on other sites

As for the freezing problem: I noticed, that the FPS drop dramatically when the freezes occur, however, CPU load is close to zero - at least on my machine. This problem gets worse the more bases you build, up to the point where time won't advance at all (not even with a lot of waiting) although the FPS are still above 24 and, as mentioned before, the CPU load is close to zero. Unlike kafros, I was not able to overcome this problem by starting a new game. It seem to be quite hit or miss... If you're lucky game-time will advance, if you're not, well, try again next time... I have tried several combinations of waiting or rushing at the different points of interaction from starting the game to advancing the time, but none seemed to have any reproducible influence.

Stupid question.

1. When the game "freezes" can you save it?

2. If you save it, can you restore it?

3. When restored, does it remain frozen? (If so, a copy of a frozen save file would be very useful.)

 

I'll try to find some time this weekend to look into it (as well as inspecting PeeZa's latest patch and getting it into the trunk, and Cube2 research, and RL obligations. etc.) If anyone else wants to have a try, can I suggest nprof http://code.google.com/p/nprof/

I've been looking into this but without much luck. What i can say is that there is no JIT, GC or IO happening when we get a stutter or freeze.

 

The profiling I've observed just seems to be a general slowing down of all methods, with no one in particular standing out.

Link to comment
Share on other sites

here's another modified icon set. hopefully better visibility and less blur.

 

http://i37.tinypic.com/mlo47m.png

 

i'd been asked to make a concept for the chaser window. well i have an idea so maybe i ll put something up soon.

Edited by gu35s
Link to comment
Share on other sites

Nice updates on the icons gu35s. In the blank cell on the bottom right, can you include a white icon to use for the when the object should be hidden from view? At the moment I'm using the xcom aircraft icon and that doesn't recolour to well. I've also got almost all of it working of time rather than frame intervals as well now.

 

BUT, still banging my head against a wall trying to find the performance drop. I'm going to perform a small u-turn on what I said before, I think it's probably some 'managed' service that is causing the slowdowns. Look at this screenie.

 

The blue lines in events are mouse clicks which i was clicking to mark-up areas of slowdown/freeze. The 'pinned' section was an area of slowdown, and the highlighted graph line is IO Read.

 

Butwhatdoesitallmean.jpg

 

The only method that increases considerably during slowdowns (that I can see) is program.main(). Now this should just be called once at the start of the application, so my current thinking is that the time reported here (the game's entry point) is coming from the .net runtime?

Link to comment
Share on other sites

The only method that increases considerably during slowdowns (that I can see) is program.main(). Now this should just be called once at the start of the application, so my current thinking is that the time reported here (the game's entry point) is coming from the .net runtime?
Yes, Program.Main() is entered when the program starts, and exits when the program ends, so all time must belong to Main() or one of it's children. But I assume the question you're asking is why does the frame rate drop when focus moves to another app, and then never go up again afterwards?
Link to comment
Share on other sites

no the interceptor is not bigger but since i made others smaller, interceptor seems bigger. so i made them a tad smaller. and added a white dot for coloring for other side of globe icons.

http://i36.tinypic.com/2yjtstg.png

 

havent had time to make chaser hud yet. soon.

Edited by gu35s
Link to comment
Share on other sites

A personal collection of concept pictures and models found in this thread, one by Zero Energy (the one with the xenomorph :D), and the rest by gu35s!

 

In addition, that's the final research lab render!!! Could someone please replace the old render in the gallery with this one?

 

( In addition, the above archive would make a nice addition to the concept gallery! :) )

Edited by kafros
Link to comment
Share on other sites

I noticed you moved it into the trunk from last update so I updated that one.

I did? WTF

 

Edit: Nope, I did not, but neither did you :) Everything is where it's supposed to be: in the "unrevieved patches" branch, where dteviot can take it from if he thinks it's time to put it in trunk.

Edited by Mad
Link to comment
Share on other sites

( In addition, the above archive would make a nice addition to the concept gallery! :) )

It would, but I'm honest, I just don't have the nerve right now to put all that stuff in there. But you're welcome to get the latest version of the website from the svn and put it in yourself. :) I'll even upload it once you're done ;)

Link to comment
Share on other sites

this is not done yet. kinda busy so can't really finish it.

 

here's so far.

 

I have another idea of having only 1 big window and when there are more ship coming in, it would add into the window like a bar. but that's later. busy busy busy.

 

 

btw, this is concept. i have no idea how to incorporate this in game.

Edited by gu35s
Link to comment
Share on other sites

this is not done yet. kinda busy so can't really finish it.

 

here's so far.

 

I have another idea of having only 1 big window and when there are more ship coming in, it would add into the window like a bar. but that's later. busy busy busy.

 

 

btw, this is concept. i have no idea how to incorporate this in game.

This looks really great. I think the background (sky) will be difficult to get this way if we want to have a moving background. As for the other stuff, I guess we best would ask PezzA...

Link to comment
Share on other sites

this is not done yet. kinda busy so can't really finish it.

 

here's so far.

 

I have another idea of having only 1 big window and when there are more ship coming in, it would add into the window like a bar. but that's later. busy busy busy.

 

 

btw, this is concept. i have no idea how to incorporate this in game.

I agree, it does look awesome. As to how it would be done, the answer is similar to the equip soldier screen. A bitmap is provided for the static parts of the dialog, and a set of sprites are provided for the non static parts (e.g. the X-Corp aircraft image, the craft's weapon slots, etc.) The really hard part would be the aircraft camera image, assuming you wanted that to be an animated 3D scene.
Link to comment
Share on other sites

this is not done yet. kinda busy so can't really finish it.

 

here's so far.

 

I have another idea of having only 1 big window and when there are more ship coming in, it would add into the window like a bar. but that's later. busy busy busy.

 

 

btw, this is concept. i have no idea how to incorporate this in game.

I agree, it does look awesome. As to how it would be done, the answer is similar to the equip soldier screen. A bitmap is provided for the static parts of the dialog, and a set of sprites are provided for the non static parts (e.g. the X-Corp aircraft image, the craft's weapon slots, etc.) The really hard part would be the aircraft camera image, assuming you wanted that to be an animated 3D scene.

I like the panel, but for the battle animation I would go for a top down view.

  • There can be a blurred fast scrolling background to give this window a much needed feeling of speed (the original game version I feel lacked this).
  • The blurry scrolling background does not nessercaily need to reflect the geoscape texture and can be used to give a visual clue as to the type of terrain the battle is happening over. ( Which I think is needed in the current geoscape).

(Actually , I suppose the above can be done in a first person view as well)

 

Does the chase window put CeGUI back in the spotlight? I saw the thread that Mad referenced about the debate to replace it, and that was a while ago. If we can skin some different buttons with the existing CeGUI code, will that get us by for now?

 

Also, regarding the performance issue..

This is just a hunch, but I suspect your problem is in function Update(GameTime gameTime) in Xenocide\Source\UI\Screens\ScreenManager.cs

The above change did take out most of the stutters and game-time freezes, but i still had the odd 3-5 seconds of shudder and slowdown, it was this I was trying to trace down. The screen shot in my last post (from the excellent Ants Performance Profiler) I think was indicating the the slowdown wasn't happening in the code source, but is probably CLR based general slowdown. I've based this assumption on the observation that the only method with a noticeably higher reported call time was the entry point method, I can think of no other reason why this would be the case. I tried the MS CLR profiler, but that slows things down so much you can't tell when a slowdown is happening.

Link to comment
Share on other sites

Does the chase window put CeGUI back in the spotlight? I saw the thread that Mad referenced about the debate to replace it, and that was a while ago. If we can skin some different buttons with the existing CeGUI code, will that get us by for now?

I meant to add, 'introducing a toggle button state', as well to this!

Link to comment
Share on other sites

I noticed you moved it into the trunk from last update so I updated that one.

I did? WTF

Edit: Nope, I did not, but neither did you :) Everything is where it's supposed to be: in the "unrevieved patches" branch, where dteviot can take it from if he thinks it's time to put it in trunk.

 

 

When I say trunk I mean from the unapproved.

 

I though at first you meant everything should be in the patches folder. When I circled is what I am talking about.

Untitled.png

Link to comment
Share on other sites

Does the chase window put CeGUI back in the spotlight? I saw the thread that Mad referenced about the debate to replace it, and that was a while ago. If we can skin some different buttons with the existing CeGUI code, will that get us by for now?

I meant to add, 'introducing a toggle button state', as well to this!

 

 

 

I believe the problem we have with the buttons now is that CEGUI# currently only supports 1 type of theme. The default. Where as the old GEGUI (C++) allowed us to have multiple themes. If this was fixed since I was gone then adding new skins is not a problem.

Link to comment
Share on other sites

I noticed you moved it into the trunk from last update so I updated that one.

I did? WTF

Edit: Nope, I did not, but neither did you :) Everything is where it's supposed to be: in the "unrevieved patches" branch, where dteviot can take it from if he thinks it's time to put it in trunk.

 

 

When I say trunk I mean from the unapproved.

 

I though at first you meant everything should be in the patches folder. When I circled is what I am talking about.

Yes, I saw that in the svn log already. Sorry "trunk" for me is a synonym for the main XNA source. That's why I was surprised at first. But you've done everything right, sorry for my questions.

Edited by Mad
Link to comment
Share on other sites

damn i m busy. dont have anything this time, sorry. so here's an idea.

 

what if we separate from the classic each window for 1 of the craft, instead switch it to 1 window for 1 ufo?

 

Imagine something similar to the one I made before but larger and there are bars at the side giving the status of crafts. The command will effect all as a group instead of one per each plane. As in, aggresive attack will move all ship into an aggressive formation for higher damange capability. basically all craft move as a unit instead of individual ships. instead of cockpit camera, it'd be a satellite view or radar tracking grid where the ship could be animated for a chase, a dogfight, or something else. the coding going to be a pain though. good thing it aint what i do.

 

to take this further, we could also let the ufo crafts do the same stacking if there are more than one ufo appearing closeby. i.e. supply ship would have one or two smaller ship for protection and all that. but the console would look different of course. it'd be left vs right kinda look if it comes to that.

Link to comment
Share on other sites

damn i m busy. dont have anything this time, sorry. so here's an idea.

 

what if we separate from the classic each window for 1 of the craft, instead switch it to 1 window for 1 ufo?

 

Imagine something similar to the one I made before but larger and there are bars at the side giving the status of crafts. The command will effect all as a group instead of one per each plane. As in, aggresive attack will move all ship into an aggressive formation for higher damange capability. basically all craft move as a unit instead of individual ships. instead of cockpit camera, it'd be a satellite view or radar tracking grid where the ship could be animated for a chase, a dogfight, or something else. the coding going to be a pain though. good thing it aint what i do.

 

to take this further, we could also let the ufo crafts do the same stacking if there are more than one ufo appearing closeby. i.e. supply ship would have one or two smaller ship for protection and all that. but the console would look different of course. it'd be left vs right kinda look if it comes to that.

Interesting ideas. This doesn't sound bad, however I think, it should still be possible to give individual commands. So if you have an Interceptor with short range wraponry, you might want to have it enter "dogfight mode", but if the second interceptor carries long range missiles you might want it to be more careful. Or vice versa. But that could be added easily to your idea I imagine (usually you give commands to the whole squad, but if you choose so you can also click on an individual fighter and give it individual commands).

Link to comment
Share on other sites

Guest Azrael Strife
I am! how's things around here? is this real life action or just another barrage of salvos? :) I'd be up for some coding after my exams, plus I'm studying MS BizTalk 2009 for a job so I'm a bit busy, but I'm still around :D
Link to comment
Share on other sites

Guest Azrael Strife
Always trying to get rid of my posts :( with that criteria we should move all the programming posts to a programming thread and all the art posts to an art thread AND all of them related to actual development to the Workshops, annoying isn't it? :P
Link to comment
Share on other sites

no the interceptor is not bigger but since i made others smaller, interceptor seems bigger. so i made them a tad smaller. and added a white dot for coloring for other side of globe icons.

http://i36.tinypic.com/2yjtstg.png

 

havent had time to make chaser hud yet. soon.

 

Updated patch includes updated icon set (cheers gu35s! It was just the trick!) and the new occluded icon. Also, everything is keyed from time and not frame-rate.

TimeBasedHud.zip

 

Should get a chance to look into the chase window this week. I like what you have done for it so far, but there are some obstacles to overcome in getting it done. just got to shift this swine flu first .. *Cough* http://i605.photobucket.com/albums/tt136/KellysKoloboks/pigflu.gif

Link to comment
Share on other sites

Updated patch includes updated icon set (cheers gu35s! It was just the trick!) and the new occluded icon. Also, everything is keyed from time and not frame-rate.

 

 

Looks good, Quick note. UFO's are the Red icon, When they crash we use the White icon for the crash site. However when they repair and take back off they stay White. We should then change it back to Red.

Link to comment
Share on other sites

hey guys. sorry but still nothing out of me yet. the other guy quit so i m blasted with heavy load. i ll make something when i have the time. is there a build for whatever patch dteviot posted up there?
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...