Evochron Legacy SE - Remaining Checklist...

[Vice]

I've been going through what remains on my to-do list consisting of requests and several of my own objectives for the game as part of its finalized feature set. Many larger and more complex elements were mostly worked on and implemented over the winter, spring, and summer of this year while some of the remaining smaller objectives have been worked on in recent weeks. For examples of the latter, these were implemented in the most recent updates:

- Expanded button index limit in the 'Advanced' control input mode to 128.
- Added key/button mapping options for panning right/left/up/down view control and centering panning view (Page 4).
- HUD indicator frames updated to better color match, improve contrast, and reduce obstructions.
- Image font system updated to supported custom active button edges (see customizing kit).
- MDTS lead indicator revised to display circle with a connected directional arrow.
- Expanded tractor beam asteroid mining retrieval range.
- Primary alert sound revised for a more subtle effect.

One of my next objectives involves revising the structure and texture layout of the pitch ladder. It is the last piece of the HUD that is still using a relatively lower resolution texture. As part of this modification, the pitch ladder will be split into two parts so that the texture resolution can be increased without increasing the video memory overhead (so two 128X4096 tape textures as opposed to one 1024X2048 tape texture). This has the added benefit of being able to adjust the position and scaling of each part of the pitch ladder far beyond just what modifying an image can do. The original system will be preserved to continue to support existing custom modifictions to the pitch ladder, the new structure and options will simply be optional.

I'm also working on changing the external panning view mode to align with the curvature of planets when in atmosphere. This will keep the view level with planet terrain while panning around the player's ship, rather than remain aligned with the galactic constant.

Are there any other minor audio, control, or graphics tweaks you'd like to see applied to the game? Feel free to reply here or send me an e-mail.

[TraderDan]

It's funny we were just talking about the pitch ladder, what a coincidence lol
I'll have to look up what active button edges are in the customizing kit

I guess environmental effects on the ships front glass like gif animated rain filter and a few frames of gif animated computer screens wouldn't be considered minor? :-D

[Vice]

For button edges, this section provides details: https://www.starwraith.com/evochronlega ... me.htm#502 Characters 16 and 30 in 'bitmapfont32c.png' are the new ones recently added for custom edges for selected/active buttons.

Animated gifs aren't supported in the game engine/language, so that would indeed be beyond the scope of what is feasible. - Or so I thought, it appears they can be supported with a particular way of rendering. I'll explore this further.

You can design custom displays that 'animate' for their readouts/indicators (text or bargraphs) using available options.

[TraderDan]

"Animated gifs aren't supported in the game engine/language, so that would indeed be beyond the scope of what is feasible. However, you can design custom displays that 'animate' for their readouts/indicators (text or bargraphs) using available options."

I need to look into this too :-O

[TraderDan]

Vice was so johnny on the spot with animated HUD menus I feel like a chump for asking, but there is another thing I thought about, I think the screen should light up with a bright white flash right before the explosion animation for capital ships, I think it would make it more epic.

[TraderDan]

Ok here's another cool effect I thought of, (please don't phaser me lol) just as you engage the afterburner it briefly blurs the peripheral edges of the screen to give the effect of the loss of blood flow from the excess g forces

[Vice]

Incorporating the blur shader used with the jump drives could be a way to achieve that. We can see what others think to gauge interest. One consideration is that it might be somewhat difficult to see with the shake effect that is already applied.

[TraderDan]

I think it would only need to blur for just a second, as I recall the view draws back slightly to simulate a head jerk and then the model will make the shake animation I think the blur around the edge would just need to be active during the moment (probably only a second or two at most) just as the model draws forward before the shaking effect takes over

[TraderDan]

thanks for not phasering me ;-)

[Marvin]

... just as you engage the afterburner it briefly blurs the peripheral edges of the screen to give the effect of the loss of blood flow from the excess g forces

One must assume that, in sci-fi, G-forces are negated. We still have lift (which is why ships can stall out when flying planetside) but even a momentary loss of the anti-G system during a normal acceleration (let alone a hyper-jump) would (at best) push your eyeballs to the back of your head. During the type of maneuvers available to the ships during combat would exceed a continuous 5-G limit (positive G), which, in order to keep the blood from pooling in the gut and legs, requires the pilot to wear a G-suit.

[TraderDan]

I think a lot of it is that in different mediums to comics, television and video games we aren't able to use all the senses. That feeling in your gut you get under acceleration isn't possible in a video game so we have to use visual cues to convert that information (even if it isn't always scientifically accurate in the literal sense ) trying to convey and fulfill the "expected" sensation of acceleration was my end goal if that makes sense

[Marvin]

The current chromatic aberration during a hyperjump is a relatively new visual addition to the game. I get that sense of "warped" acceleration from it and mine was one hand up voting for its inclusion.

[TraderDan]

I think it was a nice touch, I fully support it

[TraderDan]

A sound effect when inertial hold is activated? I imagine some sort of distorted whiring sound when I think about an inertial hold 180 before blasting a tailing opponent lol

Ps: animated menus made my day :-) can't wait to start making some

[TraderDan]

Ok I got another one, I feel like I'm being annoying posting so much but ... This idea I think could be easy to implement and would look pretty cool I think.

Instead of 1 texture map from an external or cockpit frame let's say there are 3

Texture map 1 is if hull damage is between 75-100 percent
Texture map 2 is if hull damage is between 50-75 percent
Texture map 3 is for hull at less than 50 percent

Each texture map representing increasing damage to the player ship (internally and externally) and to the hulls of NPC and capital ships

So the uv texture base map might be like ship1-low,med, high
Then Ship1damage1-low,med,high
Ship1damage2-low, med high

And so on.... What do you think?

[MarcusInVR]

I would simply use one additional texture that shows critical damage, and according to the damage, do an alpha over the standard texture. So 53% hull damage would be an alpha mix value between standard and damage texture of 0.53.

One could also go and use only parts of said "damage" texture and only apply it with an alpha to the affected subsystems.

Much less work and only needs one additional texture (which can have the detail levels as other parts of the game - very high, high, medium, low).

[TraderDan]

That's a superior approach for sure, the reason I thought about implementing it with separate texture maps was that I wasn't sure if the games build engine would support a blended alpha channel. Vice would know the answer to that one.

[Vice]

I set some time aside this morning to evaluate the additional video memory overhead required to implement one, as well as multiple, set(s) per ship class of additional textures for damage states. The numbers are (much) higher than the margins I want to stay in, even at half original detail. I've thought about such effects before, including mesh deformation in code. But when I've tried it in the past, the resource load is either too high or there are too many pauses/stutters when trying to manipulate the media directly. It is something I keep on the concept list anyway as I like the idea.

[Marvin]

How about using the debris, generating some of it during combat instead of only after a ship has been destroyed?

[TraderDan]

That's not a bad idea, I was just going to suggest maybe some sort of plasma fire effect and / or venting gasses / sparks etc (which also reminded me to ask Vice if I can edit the spark effect for inside the cockpit)

[Vice]

Whatever falls off the ship should probably be visibly off the ship as well. Hence, either mesh deformation or other media alteration.

[TraderDan]

Since the animated gif filter is working, can it be applied to texture maps or just hud screens?

[TraderDan]

Take a 20 frame gif apply it as a texture map, keep the gif in a paused state untill damage reaches over 50 percent. 1 of the 20 frames (the first and paused one is undamaged condition) the next 19 frames are a static damage condition. Set the speed to cycle the gif frames faster than 60hz that way you'll barely notice the undamaged frame as it cycles through giving the optical illusion of only a static damaged or undamaged state. That way the game only loads one texture map into memory. This is purely theoretical I have no idea if it's practical or possible - just trying to think outside the box, alternatively sans damage indicators animating a texture map would be cool because you could animate the emissive layer to have light that pulsed, turned on and off like running and navigation lights, windows etc.

[TraderDan]

The gif animation speed is set when the gif is made so the only thing the game would control is loading the map, play or stop/pause at beginning of animation

[Vice]

Since the animated gif filter is working, can it be applied to texture maps or just hud screens?

Just HUD indicators and custom cockpit displays. Ship textures are too large to practically import so many separate images for frames of animation.

Another part of the problem is that such damage states also have to be reversible in a staged way since there are repair systems. So either there are multiple levels of damage states applied to textures that are sequenced or some form of gradual repair to the structure. And with the negative video memory and performance considerations, neither option is very practical.