Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on June 15, 2004, 04:10:59 pm
-
http://fs2source.warpcore.org/exes/latest/C06152004.zip
- hud-set-colors SEXP added, self-explanatory, works only for custom HUD gauges at this point. Overrides user's settings.
- current-speed SEXP; gets the speed of the selected ship or wing (For wings, the lead ship's speed is used; inaccurate during a battle)
- Mission messages limit bumped from 300 to 500
- SEXP node limit bumped from 3000 to 3500
- Sound quality bumped to 48000 khz; if you experience sound distortion, this is probably why. If you'd post where it happened it'd be much appreciated.
-
Originally posted by WMCoolmon
- SEXP node limit bumped from 3000 to 3500[/b]
:eek2: After I bumped it from 2000 to 3000? Is this actually needed?- Sound quality bumped to 48000 khz; if you experience sound distortion, this is probably why. If you'd post where it happened it'd be much appreciated.[/B]
Is this going to affect the quality of the existing (FS2) soundtracks?
-
I added it because of this topic (http://www.hard-light.net/forums/index.php/topic,24204.0.html), did you bump the limits after FRED 3.5.5?
-
Indeed I did. There was a topic about it several months ago. Looksee:
// DaveB 9/02/99 bumped to 2200
// Goober5000 01/20/2004 bumped to 3000
-
Does the amount of sexp's allowed, not used, during the game affect the speed at all? I'm assuming the memory/interrupts etc for these would be set at loading stage. And while having 3500 sexps would probably slow the game down a fair bit, would simply allowing them do so?
-
The higher the limits are bumped, the more static memory the game occupies. So it depends on your RAM.
-
Oopsie :o
-
Who uses more than 300 in-mission messages?
-
Fix the waypoint displaying system!
It is still weird, distances are not shown.
-
Apparently the WC saga does :nervous:
-
If I knew the WC universe, I would join the WC saga just to see that mission.
-
Er, correction; messages.tbl stores info in an array, whose size is determined with the variable MAX_MISSION_MESSAGES. They wanted the array size bumped, but I keep thinking of it as the maximum messages in a mission b/c of the variable name.
You never know though. :p
-
If I remember correctly, it's not the messages-per-mission limit they're running into but the limit on the number of SEXPs. I'm not sure I want to know how many of those things go into setting up a nav point.
-
Many, trust me. But not as much as you think. :)
For one Nav-Point I need 3 Events. One for activation (very simple),
then chained the second which enables autopilot and has between
8 and 12 operators, depends how I would like the ships to act like,
and also chained a third which ends the autopilot and reassign
commands to the ships (around 8 op's).
The problem with this sexp-limit is not really a matter of the
message-number. I have no idea of coding the available
source-code, but I see it like this :
Technically the problem-mission has around 90 messages, and
about 120 events overall (including messages).
First I thougt the counter, which limit I reach is for every single
value that is in the event (4 for each messages in example), but
now that I read the current limit is around 3000, I have not really
an Idea what it counts.
I guess there is much more included like ships, goals, maybe even
the background-data.
Maybe this is a good place to ask for a sexp-controlled
time-compression ? With manuel control the autopoilot is not so
good, because sometimes you missed the correct time to deactive
the time-compression, which can end deadly. :)
And thank you for the updated version. (btw, has it fixed the
waypoint-display problem already ? )
(edit) on the side-note, must I be worried that the new filesize is
almost only 60 % of the old file ?
-
Am I correct when I assume this does [size=huge]not[/size] include Bob's work on decals, particles and the like?
-
It's still not in CVS, so no.
-
OK.
Bob, perhaps it is a good idea to do a merge, before it becomes impossible?
-
Incidentally how is everyone's experience with sound going? I'm not actually certain if sounds were playing at or below 22050 hz before, but they should be playing at 48000 hz now.
This means double the sound quality, incidentally.
-
And the filesize and speed?
What does it do to them?
-
The build seems to run ok.
How can I know about the sound? It "crips" some times, though.
And the HUD's Target Hull Indicator is better. Though sometimes it gets out of alignment.
-
You can't hear any difference with the current files!
The reason is that they were sampled at 22KHz when recording / mixing them for the game.
The difference will be apparent only when listening to new files or versions of the files that were recorded at 48KHz.
-
Originally posted by WMCoolmon
Er, correction; messages.tbl stores info in an array, whose size is determined with the variable MAX_MISSION_MESSAGES. They wanted the array size bumped, but I keep thinking of it as the maximum messages in a mission b/c of the variable name.
You never know though. :p
one the one side we are using mainly missions to tell the story of the game (not to count our 200 pages novell :) )
Due to a very complex story line we also have a lot of different characters that appear more than one time in the game. There are 5 wing commanders, 6 wingmen a few generic pilots, which we call red shirts.
The messages.tbl only allow 7 entries (if we replace Vasudans)
-
Please fix the hud positioning. The reticle energy gauges as well as both shield icons are shifted towards the upper left hand corner. I know that's not realy a new bug, since about the first build with modular hud gauges, but I thought I'd post this with the hope that it might get fixed.
Later!
-
Originally posted by Flaser
You can't hear any difference with the current files!
The reason is that they were sampled at 22KHz when recording / mixing them for the game.
The difference will be apparent only when listening to new files or versions of the files that were recorded at 48KHz.
The reason I ask is that DaBrain claimed he was having trouble in this thread (http://www.hard-light.net/forums/index.php/topic,24128.0.html) using the 22khz effects w/ 48khz sound.
-
Is that 48Khz Mono or Stereo?
-
Stereo.
-
Thank you :) A game tends to be broken up into 3 parts, Gameplay, Graphics and Sound, it's nice to see the 3rd section being taken on :D
-
Small complaint about this build of FRED, I can't seem to select any music for the mission. Other than that, looking good. :yes:
-
Fixed both of those bugs, thank you for reporting them. :)
-
New build: http://fs2source.warpcore.org/exes/latest/C06172004.zip
- Fixed mini-hull-strength info (Hopefully for good)
- Fixed FRED music list
- Freespace 2 now only loads used weapons effects. Perfect if you're using high-res weapons effects.
- Sound quality is now settable through registry variable SoundSampleRate and SoundSampleBits; default values are 22050 and 16, respectively.
If you plan on messing with the sound quality variables, note that it's currently experimental. I actually have no clue if anything actually changes. Someone with proper sound expertise PLEASE PLEASE PLEASE check and see if this ups the sound quality if you're using higher-quality sound files.
-
Originally posted by WMCoolmon
[If you plan on messing with the sound quality variables, note that it's currently experimental. I actually have no clue if anything actually changes. Someone with proper sound expertise PLEASE PLEASE PLEASE check and see if this ups the sound quality if you're using higher-quality sound files. [/B]
In theory, if you have the sound settings set to 44.1 Khz, and your source sound files are the same frequency, you should be able to listen to the file in unmixed quality. Meaning that you shouldnt be able to hear any difference, better or worse. I havent tried plugging in a 44.1 K sound file in place of one of the 22.5 K sound files. I'm sure it'd be easy to test, but it'd take me some time. There would be no way that the game could "clean up" already existing 22.5 K files just by setting the sound settings at 44.1K, as it would have to re-sample the audio file whenever played, and that just wouldnt work in a game, unless it's just changing it's sample RATE.
IF the game changed the sample rate, you would be able to tell immediately the difference between settings caused, and the changes would be undesirable. Sample rate changes change the pitch of the sound, whereas if it actually re-mixed the frequency to the desired freq, it would sound different quality-wise. Put simply, remixing the samples is like listening to a file that's been encoded as an MP3 at 64K and then again at 196K Ovbiously, you want your source to be as high as possible, then downmix from there. Otherwise, when you try to "up-mix", the sound will sound terrible. I dont know if FS ever did mixing like that.
After reading this thread (http://www.hard-light.net/forums/index.php/topic,24128.0.html) changing the physical sample rate of the existing file usually will not yield better sounding sounds. If you were to take a 22.5K file and up mix to 44.1K, you would probably get a little more distortion in the sound. Sometimes, I experience an increase in treble, which produces higher pitched sounds, which sound more annoying to me than anything.
Anywho, I shall test and see if running a 44K file thru makes a difference or not with these new settings.
So to test, just add the registry DWORD 's as listed above with the decimal value of what I want the sound to be set at?
-
First of all-those sounds really are higher-quality. I grabbed them off of Freespace 2 Sector, they're the MP3s on the site converted to OGGs and processed to have the same music as their end-product counterparts.
And yes, that is correct-although I'm pretty certain that at the moment it will only effect sound effects and not music. Music is played on its own, separate buffer, it seems.
-
I gave our script a short glance... We have 6 main pilots, 6 command grades, 8 red-shirts/fodder. That makes 20 personas:wtf:
-
EDIT : posted to Mantis
-
I've inserted a 44.1 K file in and have tried the three popular modes (11,025, 22,050 and 44,100) and can hear no difference between the modes quality or pitch wise. I bet this would be an OK addition to the soundtrack buffer if possible. It'd be nice to have music for new campaigns in higher resoultion than what the original limits are, though I dont think it matters,c ause with my samplerate set at 11,025, the engine still plays the sound I inserted which is a 44,100 hz file, 16 bit the exact same sound, quality...
-
*Grumbles* So there's no difference with SoundFX or voice?
BTW thank you, even though it's not what I wanted to hear. :)
-
Originally posted by WMCoolmon
- Fixed mini-hull-strength info (Hopefully for good)
[/B]
Were you refering to the hud mis-alignment I was bit... that is, complaining about? If you were, then I'd like to report that its still screwed.
-
Yes, that's it. You don't have a hud_gauges.tbl anywhere in your Freespace 2 directory, do you? I could've sworn it was working properly.
*Crosses fingers*
-
Oh, I missed your question.
Originally posted by WMCoolmon
DB: Which mission are you having problems with?
I tried the first mission. But it also happend in other missions.
The main problem were the comm voices.
But it might be related to another problem I have.
http://mgo.maxgaming.net/mantis/bug_view_page.php?bug_id=0000196
-
Query:
Are the modular .tbl files in this build?
-
Both versions of Fred2 posted crash if you try to do duplicate model texture replacement.
-
DaBrain: I suspect it is, unless this only happens if you run the build in the H-Q sound thread, and the first one in this thread.
Originally posted by Moonsword
Query:
Are the modular .tbl files in this build?
Yes :)
Originally posted by Man
Both versions of Fred2 posted crash if you try to do dubpicate model texture replacement.
:blah:
Do you have any error info, and is the bug not in mantis? RT is working on patching up Fred2 at the moment, I don't know if I'll be much help unless it's something simple.
-
All I get is Window's "Fred2_open 3.5.5 has encountered a problem and needs to close" window, no details.
Older Fred2s I have work just fine, even OGL ones. I haven't put anything in Mantis, I thought that was just for "offical" builds? I can if it will help.
-
This is basically the 3.6 EXE with a few extra SEXPs and the fixes for it to work with modular tables. Nothing to do with the texture replacement system.
Do you have any older 3.6-or-later FRED exes that work?
-
Originally posted by Mant
Both versions of Fred2 posted crash if you try to do duplicate model texture replacement.
When is the crash? As soon as you select the texture, or not until you save the mission?
If it's the latter, can you still load the mission in FRED after the crash?
-
Not to derail the current discussion, but what exactly is the new sound samplerate settings supposed to do? Are they supposed to lift the limits of the 8B22k and 16B11K sounds so far?
I honestly dont know if it matters what format the sound is in, because in V's original files, there are 16B11K files in the 8B22K directory in the main VP. Plus the bitrates range between 8 bit and 16 bit in that directory too. I wonder if this has something to do with DirectX?
Perhaps, inserting our own high quality SFX files at 16 bits, 44K would not matter to the engine, and could be played back without problems? That is if anyone wanted to do that in a future mod or something.
-
That's how it seems ATM.
-
Originally posted by Goober5000
When is the crash? As soon as you select the texture, or not until you save the mission?
If it's the latter, can you still load the mission in FRED after the crash?
I select the texture, then is takes me back to the ship menu. When a close that down it crashes within a few seconds. I don't get time to save.
I have a version that works, but it is just called fred2_open_r, all I can tell you about which version it is it that it is OGL and I downloaded it 9th May, sorry.
Worse though, it turns out Freespce 3.6 does a CTD the moment a ship with duplicate model texture replacement turns up, and ignores regular texture replacement :( . I was using duplicate as I never had a build in which regular worked. I've tried some later builds (such as Bobboau 6-10-04) and get the same error.
If someone could look at these I'f really appricate it. I've got a 30 mission campaign using SCP stuff just about ready to release, but it uses a lot of texture replacement and half the missions don't work on recent builds.
I've put both of these into Mantis. If I can help with any testing or anything please let me know.
-
OK. That's it.
I'm not expert in digital media storage, or encoding, but there's a point where I feel it's necessary to clear some things up. (My father graduated from this stuff, so he took the liberty to explain a thing or two...)
The KHz that's displayed in Winamp or the properties in the PCM file have nothing to do with the pitch of the sound you hear in the file itself.
It's a sampling rate!
When you take an analog signal, and try to digitalise it, you have to sample if at equal intervals to be able to replicate it.
Basicly the more often you do this, the better the authenticity - (HIFI implies High-Fidelty) - CDs use 44 Khz, DVD-s 48 Khz. Once again this is a sampling rate, this has nothing to do with the properties of the sound!
Freespace used 22 Khz, 'casuse it the smaller sampling rate wasn't as much of a dowgrade. (However it IS noticable! Listen with a good headphone and you'll pick up on it!)
Now we have some samples of the audion we want to store digitally. Now comes the actual digitalisation. The question is the following: how many bits per sample?
CD-s use 16 bits.
This may seem little - the main reason for fake/superstitious audiphiles to whine about the murdering of the good 'ol 100 % authentic vynil dics - in fact, it's is so precise that the recording equipment can't keep the pace with the precision it provides.
You can use less bits and end up with a smaller file.
This is uncompressed, CBR - which means Constant Bit Rate - encoding. Simply put regardless the complexity of the sample I always use the preset ammount of bits for it.
I'll take a small detour here - why do CDs nowadays sound crap? 2 reasons:
1 - they are mixed to be aired. Ergo the volume should be hitting the bottom all the time, this kills the dynamics of the music.
2 - the equipment most people use to listen to their music is far from perfect, moreover - especially when dealing with classical music - some elemets of the music have to be removed to prevent the destruction/damage of your equipment.
Okey, that's an Audio CD a basic digital audio format. What about the rest?
Well now comes the fun part. - All that data is uncompressed. Moreoever a CD also has a lot of redundant data for recovery algorythms to ensure the CDs is playable even when it takes a couple of scratches.
When putting it to hard-drive we can get rid a lot of that redundant stuff.
OK, done it. What's next?
Compress baby! Even Lossless compression methods can free a lot of space.
Now what? Well the opinions differ here:
Use VBR (Variable Bit Rate) encoding/recoding. VBR encoding doesn't always assign the same ammount of bits for each sample, but a varying ammount. - Welcome to MPEG-I layer 3 or in orther words: MP3
Get rid of stuff the human ear can't pick up - don't store too high or too low frequencies, also don't store too quiet stuff for each given frequency. - This is the source of the greatest debates.
Now what does this whole crap mean for the FS_Open?
A file that was sampled at 22 KHz - CAN'T be improoved to sound like one sampled at 44 KHz!
Moreover even though if the engine can play a 44Khz file, it will play a 22Khz as if every second sample was the same as the previous one - listening to a 22KHz stuff won't show any improovement.
The bitrate is a second filter that affect quality, but the same applies here too as with the sampling rates. Raising the limit won't improove existing files.
What good is this stuff then?
Listen to your CD - now listen to an MW radio.
That's the jump the campaign makers can make with the new limits.
What is this Ogg suff?
The same as mp3, except it's free. (Unlike whatever is widely believed mp3 is not free - well building software that uses it is Not).
Nix - get you speakers checked, or get a better one. There is always a very notable difference between files of that quality.
-
You're right, of course.
In any case, moving from ADPCM to OGG or whatever else will be an improvement. ADPCM is old and stinks.
And there's no point to re-do the existing sound files. You may convert them, yes, but not resample them.
If you want it done right, you should record every sound again from the source.
-
I made an attempt at resampling the original FS1 m4 track a bit ago. The results (http://fs2source.warpcore.org/temp/m4_hiquality.exe) were actually, IMHO, pretty good. I also phase shifted the tracks a bit.
If we decide to implement new file format support for the sound system, I stumbled upon this library (http://www.un4seen.com/) which I think would satisfy modders, at least for a bit.
Note that as of now, I don't really know what the two registry values do. They change the quality of the Primary buffer (Which is stereo) and the secondary buffer, which is used for EAX. However, setting the sampling rate or number of bits per sample to 0 doesn't seem to do anything.
Bug
It seems that something is escaping the list of used weapons that are loaded. Not sure where it is, though, but I've run into it in a couple of Derelict missions, and the second time it was a Harpoon that caused it...I suspect it might be because a Loki is using the default config.
This will probably be fixed in the next build (Or at least a command line option to revert to loading all weapons)
-
Sound quite good. I heae a little backgroung noise, though.
But well, this is an AWE64 in this linux box.
FYI:
Playing m4_nrml1.wav.
Audio file detected.
==========================================================================
Opening audio decoder: [msadpcm] MS ADPCM audio decoder
AUDIO: 22050 Hz, 1 ch, 16 bit (0x10), ratio: 11155->44100 (89.2 kbit)
Selected audio codec: [msadpcm] afm:msadpcm (MS ADPCM)
==========================================================================
Checking audio filter chain for 22050Hz/1ch/16bit -> 22050Hz/2ch/16bit...
AF_pre: af format: 2 bps, 1 ch, 22050 hz, little endian signed int
AF_pre: 22050Hz 1ch Signed 16-bit (Little-Endian)
AO: [oss] 22050Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 22050Hz/1ch/16bit -> 22050Hz/2ch/16bit...
Video: no video
Starting playback...
A: 1:08.1 0.3% 0%
Playing m4_nrml1.ogg.
OGG file format detected.
==========================================================================
Opening audio decoder: [libvorbis] Ogg/Vorbis audio decoder
AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 16000->192000 (128.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==========================================================================
Checking audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int
AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 48000Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...
A: 1:08.1 5.3% 0%
-
I can't hear any background noise.
It sounds better than the orginal waw.
I don't unsterstand why though.
It just shouldn't be that easy ;)
-
Oy yes, that sure is clearer.
However, you seem to have messed up some of the low frequences i some of the tracks (screechy screech). Also, get rid of the phase shift (or make it smaller) as it is it is kinda annoying.
-
Well...maybe FS1 files were so low quality (22KHz - 4 bit! - mono), that even an interpolated resampling (using some kind of algorythm to guess the "lost" data) could end up with better quality...now if we could grab the original HQ source...(I know keep on dreamin....still I doubt :V: or :I: has any use of it).
-
Originally posted by Lightspeed
Oy yes, that sure is clearer.
However, you seem to have messed up some of the low frequences i some of the tracks (screechy screech). Also, get rid of the phase shift (or make it smaller) as it is it is kinda annoying.
Heh. now you know how well I can hear. Even with a whole of noises coming from the datacenter just aside me :)
-
Originally posted by Flaser
Freespace used 22 Khz, 'casuse it the smaller sampling rate wasn't as much of a dowgrade. (However it IS noticable! Listen with a good headphone and you'll pick up on it!)
Correct, Actually Freespace 1 used a lower bitrate than Freespace 2, I believe FS2 used 16 Bit audio for music files, whereas Freespace 1 used 4 bit audio files. I can hear a WORLD of difference between the two files quality-wise.
Originally posted by Flaser
Compress baby! Even Lossless compression methods can free a lot of space.
Now what? Well the opinions differ here:
Use VBR (Variable Bit Rate) encoding/recoding. VBR encoding doesn't always assign the same ammount of bits for each sample, but a varying ammount. - Welcome to MPEG-I layer 3 or in orther words: MP3
Get rid of stuff the human ear can't pick up - don't store too high or too low frequencies, also don't store too quiet stuff for each given frequency. - This is the source of the greatest debates.
I Like this idea, if FS's sound subsystem can play compressed ADPCM formats, that'd be an easy way to have compressed audio. OGG would be the best solution, but that would require extra code to be written for FS2Open, which I dont know how to do.
Originally posted by Flaser
A file that was sampled at 22 KHz - CAN'T be improoved to sound like one sampled at 44 KHz!
Moreover even though if the engine can play a 44Khz file, it will play a 22Khz as if every second sample was the same as the previous one - listening to a 22KHz stuff won't show any improovement.
The bitrate is a second filter that affect quality, but the same applies here too as with the sampling rates. Raising the limit won't improove existing files.
I was stressing that the source audio must be in a higher quality format in order for it to sound better. I know that you can not make a 22K file sound as good as a 44K file. It's just not possible. You CAN remix the audio to that higher sample rate and bitrate using Sound Forge, but the result probably wont sound better. It sounds DIFFERENT than your original 22K source, but sometimes in a worse way.
My recent test was to take a source file recorded at 44K, 16 bit, and insert it into a mod for FS2Open, then change the settings in the registry to see if the engine would play the file AT ALL. It did, regardless of the registry setting. What I was concerned with, was if the sound subsystem actually played files ABOVE 22K, meaning if a file had the properties of my newly inserted file, the sound subsystem would ignore the file and play the original, or not play the sound at all, due to it's properties not matching the engine's capabilies. Ovbiously, the engine will play the file back regardless of what format the audio is in. When my primary weapon noise was played back, it sounded EXACTLY the same as I made it in Sound Forge. I did NOT hear it "downmixed" to 22K or anything. Which makes me think that FS2Open doesnt CARE what format your audio file is in to be played. If your SOURCE file is of high quality, then it will be played at that same exact quality.
Originally posted by Flaser
Nix - get you speakers checked, or get a better one. There is always a very notable difference between files of that quality. [/B]
I've been using a Soundblaster Audigy with custom tweaks in my environmental EQ adjustments in my system with a pair of Sony MDR V700DJ's for about two years now. When I wore those out I switched over to a pair of Sony MDR CD780s and I can tell the difference between the two headphone's quality. My v700DJ's had a higher dynamic range than my CD780s do. I can tell a noticable difference between a file at 22K 8 Bit and 22K 16 Bit, and a world of differnece with a file encoded at 11K 4 bit and 44K 16 bit. I've also used Sound Forge as my primary audio editor for about 4 years now. I know how to augment audio files and what the results turn out like. Just so that we're on the same page. :) I've always wanted to get ahold of the original source music files for Freespace 1 to make some sort of new package with the higher quality music. I play that, and it almost drives me nuts to hear the music in such a low quality compared to FS2's music. Trust me, I know the audio sounds worse than it COULD sound. The only way to make it sound better, is to have the original sources. Changing bitrate just wont cut it.
:nervous:
-
Trivial Psychic, did you have an old hud_gauges.tbl in your directory? I've had no problem with it, but I've only run it in 1024x768 since I fixed it.
Has anyone else noticed any problems with the mini hull/shield display?
-
Originally posted by WMCoolmon
Trivial Psychic, did you have an old hud_gauges.tbl in your directory? I've had no problem with it, but I've only run it in 1024x768 since I fixed it.
Has anyone else noticed any problems with the mini hull/shield display?
I have.
-
I did in fact have a hud-gauges.tbl file in my directory. I've since disabled it, but I haven't had the time to test to see if that fixed the problem.
-
Hmm, mrduckman can you make sure you don't have one in your directory and are using the latest build in this thread? Hate to sound egotistical, but if it's working for me, I see no reason why it shouldn't work for everyone else. It was an addition problem that was causing the last problems.
-
I've nothing in my table's directory. I'll upload a screenshot to see if we're talking of the same thing.
-
http://webs.uolsinectis.com.ar/dsusman/screencaps/screen20040622.jpg
-
That's extremely odd...try this hud_gauges.tbl
#Gauges
$Resolution: (1024 768)
$Gauge: Shield Mini
$Text 2 Digit: (7 7)
$Text 1 Digit: (11 7)
#End
If that doesn't fix it, or makes it worse, try changing the y-values of the 2 text entries to -7s.
-
Seems to work well, but when the target gets below 10% the number gets out of alignment
-
Erg, well, try this build.
- Modified load_hud_defaults slightly; also fixed small bug in code for 640x480 mode
- Disabled load-only-used-weapons code, all weapons are now loaded on mission start.
- Threw in the current OGG code, just for fun. It doesn't work, but it does make a sound. Useful if you like indeterminate squeaks/pops. Not implemented for music, because I don't want to just implement another nonworking OGG decoding system.
Edit: Also adds new motion debris.
Somehow I missed all the responses to the m4 waves I put out, thanks for the feedback. :)
-
your zip appears to be damaged...that, or ie is re-directing me to attachment.php rather than the file itself.
-
Gahh!
http://fs2source.warpcore.org/exes/latest/fs2_open_C06222004.zip
:sigh:
-
Works well now.