Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on February 17, 2013, 12:29:08 am
-
I actually know what happened, but I just want to keep some attention on their sad absence!
Starfield streaks - these were cool, but I have no idea how the hell to implement them now that we all use skyboxes for everything, mostly I am just saying this because they were cool, forget about it
Beam whack - baby oh baby do I miss this. What happened to our beautiful beam whack? Did Goob ever implement his proposed medium between SCP's totally neutered beam whack and retail's wildly unpredictable coordinate dependent beam whack?
-
What was beam whack again?
-
i think this may have something to do with moi generation in pcs2 being different from old skool ships and stock assets. in the very early days we didnt have any way to change moi except using a hex editor. it would just be an identity matrix causing a case of the 'spins out of control when the pilot sneezes' syndrome. that was followed by a period where moi was exposed for modding, but most moders either fudged it or copied data from an existing asset. then pcs (not sure if it was pcs1 or 2) came along with a moi generator (http://www.hard-light.net/forums/index.php?topic=39723.0) based on collision detection and maths (which may or may not be how volition calculated their moi data). so i figure we went with the physically correct method and v may have just fudged the data based on rule of cool. thats my theory anyway.
-
I was getting whacked pretty good by Ultra AAA beams doing some testing the other day so beam whack is still there.
-
- If you want starfield streaks, you need to add a number of stars in fred background editor. Usually these won't play together well with skyboxes, because stars are placed in random positions. I believe the only way to replicate this sort of behavior would be to create a post processing shader that only applies to skyboxes. But I don't know if that is technically possible. The E and Zacam would be the experts in shaders.
- Beam whack is determined by mass in its weapons.tbl entry as well as ship's mass in pof. To get same whack as in retail, you need to use same mass value as AAAf or AAAh uses. Only the Ultra and weak shivan AAA has different mass values IIRC. The AAAf/h mass value is hardcoded to certain amount of whack to retain same whack as in retail. Any other number than that and you need to experiment what value works for you.
-
I know how to get starfield streaks - it's just that like you said they don't play well with skyboxes.
-
I always hated starfield streaks. Made me dizzy.
-
Star streaks are a poor man's motion blur, basically. I suppose we could implement a full-on motion blur (which, to be honest, would probably be easier than introducing workarounds to make star streaks play nice with skyboxes.
I wouldn't work on such an effect though, as I find motion blur to be really bad.
-
Yeah I don't miss it enough to give a ****, as I think the first post made clear. Beam whack is of much more interest
-
When PP was being implemented, motion blur was added at some point. IIRC, they couldn't get it to look right, so it was removed.
-
i remember $nd: tags. those were the days.
-
I miss the starfield streaks myself, and I'd be all for figuring out a way to implement motion blur, since I think it can add a really cool element of immersion if it's pulled off right. I'd imagine it'd take quite a lot of doing, though.
And that's right, I remember Goober discovering that the retail beam whack was entirely dependent on where you were in the mission, which is one of those "only in FS2" coding moments.
-
I always disable motion blur in games if possible. It annoys the hell out of me.
-
This thread is know known as "who likes or hates motion blur/starfield streaks".
-
Well, the only other point was beam whack, which is supposedly still in (though I made an AAA beam with 10 mass and it didn't had a noticeable kick...).
-
Beam whack is alive and well. Just assign your beam a mass other than 100.0 and you can make it as wild or as tame as you like.
-
I didn't realize I missed the beam whack until Battuta pointed out it was gone (or reduced? or whatever).
-
I seem to remember the retail intensity of beam whack was actually the result of an unintended bug in the code, which was since fixed, but like Fury, Goober and others pointed out, the engine is still perfectly able of doing it.
-
I seem to remember the retail intensity of beam whack was actually the result of an unintended bug in the code, which was since fixed, but like Fury, Goober and others pointed out, the engine is still perfectly able of doing it.
Yeah, it was dependent on your position in the coordinate system, so it was sometimes larger and sometimes smaller than it is in SCP right now.
-
I miss being able to hold Keypad Ins (0) and being able to look around in cockpit view. Why'd it get removed?
-
that or something like it will probibly be re-implemented when we get our new pilot files and the possibility for new controls is added.
-
I miss being able to hold Keypad Ins (0) and being able to look around in cockpit view. Why'd it get removed?
Freelook mode was disabled whenever the TrackIR stuff was first added in. I made a patch some time ago that re-enables freelook while keeping the TrackIR functioning (hopefully). I think the plan for it now is to add freelook mode along with the new analog and digital slew controls after the pilot code gets in trunk, so it'll be in soonish.
-
While we're talking about such things, doesn't the pending addition of the new pilot code finally give us the potential to break out of the four-axes-on-one-controller limits? I know it'd still be a separate thing to implement, but I seem to remember taylor saying a long time ago that the original pilot files were what was preventing an attempt at it from happening.
-
While we're talking about such things, doesn't the pending addition of the new pilot code finally give us the potential to break out of the four-axes-on-one-controller limits? I know it'd still be a separate thing to implement, but I seem to remember taylor saying a long time ago that the original pilot files were what was preventing an attempt at it from happening.
Yes. If I did my homework correctly, the pilot code is the last remaining milestone to allow for full usage of the DirectInput controllers (I think a max of 128 or 256 buttons, and a max of 6 or 9 axes). The SDL code a little further down the road should allow for multiple controllers/joysticks and also allow for even more buttons and axes.
-
I miss being able to hold Keypad Ins (0) and being able to look around in cockpit view. Why'd it get removed?
Freelook mode was disabled whenever the TrackIR stuff was first added in. I made a patch some time ago that re-enables freelook while keeping the TrackIR functioning (hopefully). I think the plan for it now is to add freelook mode along with the new analog and digital slew controls after the pilot code gets in trunk, so it'll be in soonish.
Ok, I waited a decade, I can wait a bit longer :yes:
-
While we're talking about such things, doesn't the pending addition of the new pilot code finally give us the potential to break out of the four-axes-on-one-controller limits? I know it'd still be a separate thing to implement, but I seem to remember taylor saying a long time ago that the original pilot files were what was preventing an attempt at it from happening.
Yes. If I did my homework correctly, the pilot code is the last remaining milestone to allow for full usage of the DirectInput controllers (I think a max of 128 or 256 buttons, and a max of 6 or 9 axes). The SDL code a little further down the road should allow for multiple controllers/joysticks and also allow for even more buttons and axes.
Now I just can't wait to see what sort of Frankenstick Nuke will cobble together to take advantage of those limits. :D
-
yea i just got a new grip from an old late 90s saitek which will be installed in the joystick of doom (tm). i was also looking to populate the panel with arcade buttons and toggle switches and i want to add a dual throttle as well. the interface boards support i think 8 12-bit axes and a 6x6 button matrix (36 buttons). but im currently going through a number of usb firmware tutorials and i think i can make better interfaces down the line (16 bit adcs, and an 8x8 button matrix, though i may just use i2c port expanders to simplify wiring). till then i will just have to settle for my 9 axes, 8 hat switches and 8 buttons on my ch fighterstick/throttle/pedals. input upgrades have been a thing ive wanted ever since the code was released.
-
I always disable motion blur in games if possible. It annoys the hell out of me.
Well, to reproduce star streaks the motion blur would be applied only to the background, right? It wouldn't affect the ability to understand what is going on and spot ships, in fact it would give the player one more visual clue to their velocity, increasing awareness. The feeling of speed in the game would be enhanced, increasing immersion and diminishing the feeling of being in the middle of the emptiness going nowhere.
It would be pretty cool if we got this feature back... Perhaps with even a bit more intensity than retail. That is if it did apply to the background only of course. Would this be possible?
-
Well, to reproduce star streaks the motion blur would be applied only to the background, right? It wouldn't affect the ability to understand what is going on and spot ships, in fact it would give the player one more visual clue to their velocity, increasing awareness. The feeling of speed in the game would be enhanced, increasing immersion and diminishing the feeling of being in the middle of the emptiness going nowhere.
It would be pretty cool if we got this feature back... Perhaps with even a bit more intensity than retail. That is if it did apply to the background only of course. Would this be possible?
Part of the problems with post processing currently is that there's no way to exclude some parts of the graphics from the post-processing treatment.
It's a problem because what makes ships, weapons, explosions, light sources and local stuff in general look heart-wrenchingly good, often completely ruins the beautifully rendered backgrounds by changing the contrast or adding excessive amount of bloom to planets; for example many Blue Planet skyboxes don't actually look much like I intended them to look like as long as you're using the default post-processing values. Decreasing the Bloom value to zero or very low helps a lot in this case.
The reason I brought this up is that the same thing that would solve the background post-processing issue, would also potentially make background-only motion blurring possible:
The solution would be to use Render Layers, and apply different post processing on different layers - for example, only apply motion blur to Background layer and other PP effects to Foreground layer - but I have absolutely no idea how feasible that would be, or what wizardry would be required to make that work...
-
It would make the post pipeline rather complex.
Right now, we do this:
1. Render background
2. Render models and effects
3. Render cockpits
4. Do post processing
5. Render HUD
To exclude the skybox we would have to do this:
1. Render background into separate frame buffer
2. Render Models, Effects
3. Render Cockpit model
4. Do post processing on the model/effect buffer
5. Do post processing on the skybox buffer
6. Merge skybox and model buffer
7. Do full-screen post-processing (for effects such as desaturation or film grain)
8. Render HUD
It's possible, but it would add several fullscreen passes and increase video memory usage by a lot.
-
I seem to remember some posts that claimed that FSO doesn't use much GPU horsepower, so I guess the questions now are:
1) Would that increase in video memory usage be enough to slow down the game in modern PC's?
2) Will the benefits of having many post-processing layers (not just for star streaks) make the game prettier enough to be worth implementing this?
3) Could this feature be able to be disabled for those with weaker GPUs?
-
GPU use can be roughly divided in two sections that define the performance:
1. VRAM usage
2. Graphics processor usage
VRAM is something that doesn't really depend on how complex the graphics are. It just depends on how many textures are used, what size they are, and what quality they are. With DDS files, the filesize of the textures directly correlates with VRAM usage.
Because majority of assets these days use quite high-resolution textures - and there are a lot of them - it's fairly safe to say that FS2_Open usually uses quite a bit of VRAM, but this depends entirely on what assets are being used.
VRAM usage correlates with performance as soon as it goes over the total amount of VRAM that the graphics card has. At that point, the card will need to start shuffling textures in and out from the video memory to render all the textures, and it has to do this every frame. This increases the time it takes for the GPU to fully draw the frame it's working on.
If the frame drawing time exceeds the target frame rate's frametime (1/60th second for 60 FPS, etc.), then performance is affected.
Graphics processor usage wise, FSO didn't use much of the potential, until the rendering was changed from fixed render pipeline to shader-based. This basically unlocked a lot of unused potential, and things like normal mapping and other shader magicks became possible.
Of course, the shader based stuff started taxing the GPU's processing power, and more and more stuff has been added relatively recently. Shadows, crepuscular rays, all post-processing filters such as FXAA, bloom, film grain, hue/saturation/value, brightness/contrast filters... all these sort of accumulate together and the result is that at present, FS2_Open very much takes advantage of modern GPU's processing power via shaders.
If reasonably modern GPU's can support reasonable performance with real-time compositing on post-processing, then I think it would very much be worth it. But that would need to be determined by testing. The good thing is that this addition would be unlikely to cause variable performance loss based on what's actually happening on the screen; the defining factor would likely be simply screen resolution.
And yes, it would likely be possible to turn off with a command line option. Almost all graphics features are customizable in that sense, as far as I know.
-
The thing about post processing stages is that they're relatively hard on the memory bandwidth available. If your video RAM is slow, then a post stage will have an enormous effect as reading and writing textures will take longer than expected.
-
How do commercial game engines handle similar situations?
-
By not caring.
-
I remember fixing the beam whack bug. How nostalgic
-
Pretty sure it was me who fixed the beam whack bug.
-
By not caring.
So commercial games don't do layered post-processing? How cool it would be if FSO had a graphic feature no other game has?
-
By not caring.
So commercial games don't do layered post-processing? How cool it would be if FSO had a graphic feature no other game has?
Very very cool!! So when are you going to implement this, iVoid? Can't wait!
-
By not caring.
So commercial games don't do layered post-processing? How cool it would be if FSO had a graphic feature no other game has?
I did not say that. It's just that commercial game developers have a degree of control over what happens at any given moment in the game that we do not have. They can budget their performance for all these things, we however cannot; As such, keeping things simple and robust is the best way for us to operate.
Right now, our post-processing pipeline is a five pass setup already (FXAA prepass, FXAA pass, bloom downsample pass, lightshaft pass, postprocessing pass), this would add another composite and post pass to this setup (This could feasibly be done in a single run, but I am not sure about that).
-
So commercial games don't do layered post-processing? How cool it would be if FSO had a graphic feature no other game has?
Very very cool!! So when are you going to implement this, iVoid? Can't wait!
Oh come on, he wasn't demanding they implement anything. He just misunderstood The E and was getting excited about SCP. :rolleyes:
There are totally times when such sarcasm is warranted, but this wasn't one of them.
-
Yeah, you're right. My bad.
-
These forums seem to be pretty friendly most of the times, I don't see a lot of flamers or trolls here, but I guess people are just people... There is always some poison to spit, and if not in the open then it's underneath the surface, hidden on things like sarcasm.
I don't code for a living, I only had 3 curricular units about programming on college and have an interest on the subject. Trying to contribute to FSO and playing around with shaders is something that I thought would be fun to do while learning a bit more about coding. I don't know that much and you won't ever see me acting like a bigshot. I might contribute with something someday IF I ever feel like it, I don't need to prove nothing.
-
Wait, you've got coding experience? SCP could always use a coder, especially a graphics-oriented one. Great rewards and respect await those who dare to delve into arcane depths of FSO codebase and perform their coding rites in there. :)
-
Sorry, I'm portuguese and english isn't my native language so I'm not sure if I explained myself correctly. I don't have professional experience in programming, when I said "curricular units" I was unsure about the right word to use, I think the right word is "subjects", as part of my college course.
-
Perhaps you misunderstand his response. :) We don't require SCP members to have professional programming experience. In fact, most members of the SCP joined without (or before) any professional experience. Just amateur experience is sufficient.
-
More importantly, you don't need to be a SCP member to access the code, and although only SCP members have commit access, you can very well do a code patch on your side from the publicly available trunk and then ask for SCP members to review it and, if it is good, commit it.
-
Awesome! I don't mean to hijack the thread so I'll just stop by the IIRC channel sometime.