It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Laserschwert: Would it be possible for "XWVM" to support soundfonts on its own? ScummVM allows usage of soundfonts via its FluidSynth implementation, so it would be a nice feature for this as well.
avatar
Tarvis: It could, but if the user has soundfonts set up as a MIDI device already, why not just use that instead? It would save having to locate them and configure it all over again
Well, for those users there should be a "Use system MIDI" option, wheras including a soundfont option in-game makes it a lot easier for less tech savvy people (and more self-contained, since there's no need for an external tool).

BTW, I've finished arranging all the inflight music with my EWQL samples, and I will output all of them tomorrow.
avatar
MjrParts: So do you have anything flyable by a player yet? Any screenshots?
I have spent the last month or so developing a multiplayer x-wing/tie thing in Unity. I have flyable x-wings, a-wings, y-wings, TIE fighters and TIE interceptors so far. I plan to include many more but limit how many are available in any session.
Although I can fire lasers from each, the way I've done it isn't ideal as hits are not always registering. I still have a long way to go...setting weapon modes, linking canons and implementing a shield system etc, but for a novice it's all going ok.
I doubt I could help, as you sound much more competent at it than I am :)
avatar
Azrapse: Hi. I developed a little prototype several months ago with flyable ships. They were not star wars ships, but models created by my own team for an unrelated indie project.
However, creating an entire game is way more work than focusing on remaking the flight engine of an existing game. We made some bad (at the moment) decisions, like using the Unity physics engine to model a more realistical space combat than the one in X-Wing.

The problem is that more realistic doesn't equal more fun, and also figuring doing something as simple as a homing concussion missile, or two ships docking while one is still moving, as seen in X-Wing, it's way more complex with a realistic physics engine where you need to account for linear and angular momentum and continuously correct the thrust applied in all directions. A headache.

That project is now on hold for other reasons (art assets responsible chickened out). So instead, for this one, I am moving to a simplified physics approach, just like the X-Wing series use and needs.

If you feel curious about what we had back then, this is one of the later builds of the flight engine. There is no story or anything. Just a few flightgroups, fighting in a team deathmatch.
The controls, during the development, were a mix of X-Wing's and Quake, so that someone could test the game by using their hands as they play a FPS.
W: Speed up throttle by 33%.
A: Rotate counterclockwise.
S: Slow down throttle by 33%.
D: Rotate clockwise.
ENTER: Attempt to match speed with target. It tries to keep it matched, unlike in XW series.
T: Select next target.
Y: Select previous target.
You move the ship with the mouse like in X-Wing and TIE Fighter DOS versions.

The game has several navigation aids that will not be used in this remake. You will identify them easily.
You will also identify some placeholder sounds taken from XvT.

In any case, I'm writing the flight engine for this XW project from scratch. It can already read the .XWI mission files so that I can test the engine with real life missions from the X-Wing installation folder or its CD. It has basic definitions for the different craft types, and programs all ships with their objectives, orders and other data.

avatar
Altureus: It's great that you have been working on your own version of X-Wing in Unity. Maybe post a link so that we can test it out. I don't think Azrapse has actually programmed or made anything yet but rather just planning and I think Tarvis started his own iMuse system already trying to mimic the X-Wing one as well as play wav versions of the ingame music.
avatar
Azrapse: It is not that I have been just planning. However I am approaching the development of the flight engine from a different direction than what I did with Ships On Fire. Instead of having something flyable as soon as possible, I am going for writing the code that takes care of simulating the mission and the AI of the different flight groups.

The reasons are two:
- Flying a ship requires the cockpit art and instrument panel definition work done. I don't want to program something to later scrap it with another thing, so I will program the player craft last.
- X-Wing missions are more than deathmatches. They have many events and triggers that rely on everyone following their choreography to the letter. I need to have the AI fly around in the same way as it does in X-Wing, otherwise the missions' balance will be broken.

So what I am doing currently is a mission flight engine where the player can only look around with a free camera and see how the different flightgroups carry out their designated orders.
It's basically the same as what you could see if you pressed Shift+M in XvT. You would go to the Map screen and your ship would be taken over by the AI. And you could see the battle going on without you.

I am using the XWAU models as placeholders. I repeat, they are placeholders until we find something else (or we get their permission to use them).
These are some screenshots:
Wow! Great work Azrapse. I downloaded and messed with your Ships on Fire game and I was actually having a lot of fun blasting those weird ships to pieces. Their AI is much harder than the AI in X-Wing and TIE Fighter I like how they do the rolly loop thing to get away. Anyway, I'm super excited for your completed work on this X-Wing project. :) Also, I don't think the XWAU guys will mind if you borrow their work, just as long as you give them credit. Also, I'm sure you'll be able to find some 3D artists who could whip you up some even better models and textures.

avatar
Tarvis: It could, but if the user has soundfonts set up as a MIDI device already, why not just use that instead? It would save having to locate them and configure it all over again
avatar
Laserschwert: Well, for those users there should be a "Use system MIDI" option, wheras including a soundfont option in-game makes it a lot easier for less tech savvy people (and more self-contained, since there's no need for an external tool).

BTW, I've finished arranging all the inflight music with my EWQL samples, and I will output all of them tomorrow.
Awesome dude! I'm excited to listen to them all. Perhaps you could also do the TIE Fighter ones as well, because I feel like once all of this work gets done for X-Wing surely everyone will want a TIE Fighter remake as well.
Post edited November 17, 2014 by Altureus
avatar
Tarvis: It could, but if the user has soundfonts set up as a MIDI device already, why not just use that instead? It would save having to locate them and configure it all over again
avatar
Laserschwert: Well, for those users there should be a "Use system MIDI" option, wheras including a soundfont option in-game makes it a lot easier for less tech savvy people (and more self-contained, since there's no need for an external tool).
I think we need to stay close to the "Do less, achieve more" motto. At least for now, we should focus on the 20% of the work that will provide 80% of the functionality. Otherwise, it will be really easy for us to drift away in an ocean of half-done features.
Think on the profile of most players that will use this program. Maybe not even 20% of them would have ever heard about what a soundfont is. And maybe 10% would know how to install one on their system as a MIDI device.

Label me pessimistic, but I believe even a noticeable percentage will mute the music (or the whole audio), and replace it with their own music playing in Spotify or whatever. I know that most of my friends do that with all their games.
Even not long ago we could read in this same forum several people that stated that they liked the Redbook music in XW95 much more than the iMuse music.

I believe the homage to Michael Land that Tarvis and the rest of your that are working on the iMuse simulation is awesome and having both a faithful MIDI synthesized music soundtrack, and at the same time an optional digitalized one (even if not perfectly mirroring the MIDI one) is the best compromise we could dream of.
I foresee that most non-initiate players will opt for the digitalized music, because it will sound better than the MIDI one in their standard PC sound hardware.
Those that know best about how this music works, thought, will use their specialized sound hardware and select the MIDI output. I bet those will have the knowledge to configure a soundfont in Windows. And probably have one configured already.

If we get to use the fluidsynth lib in the future, I guess it will not be too much extra work to allow to select a path to the sf2 file, though.
Fluidsynth would be trivially easy to implement once the MIDI implementation itself is finished; it merely acts as a MIDI output device. As far as MIDI output goes it acts no different than the Windows Software Synth or any other MIDI device.

Loading soundfonts is pretty much the only extra implementation it needs. The most user-friendly approach would be to have a SOUNDFONT folder in the game folder and let users put them in there and pick from a list. Though an alternate folder path option should be there, even if it's in the config file only, since soundfonts can get big and some users won't want to have several copies of them.

As far as the Redbook audio goes, that would be so easy to implement as well that we might as well include it for those few who prefer it. There's an inflight track, rebel victory track, empire victory track, and failure track, and that's it. The inflight track starts randomly at predetermined positions.
Post edited November 17, 2014 by Tarvis
Here's a random selection of most (but not all) pieces:

EWQL MIX2

I've only noticed a few places where I need to fix things, but apart from those I think this is done.
Post edited November 17, 2014 by Laserschwert
avatar
Altureus: Wow! Great work Azrapse. I downloaded and messed with your Ships on Fire game and I was actually having a lot of fun blasting those weird ships to pieces. Their AI is much harder than the AI in X-Wing and TIE Fighter I like how they do the rolly loop thing to get away. Anyway, I'm super excited for your completed work on this X-Wing project. :) Also, I don't think the XWAU guys will mind if you borrow their work, just as long as you give them credit. Also, I'm sure you'll be able to find some 3D artists who could whip you up some even better models and textures.
I'm really happy that you liked it, mate. Not many people has got to play that work-in-progress and I was feeling quite sad that all the effort would have been for nothing.
In any case, I find really useful that you say that the AI in that prototype is already much harder than in XW or TIE. I was expecting other to say the opposite, as I had to deal with a lot of problems related to the realistic physics.
For example, in XW and TIE (and XvT and XWA if my eyes don't decieve me) the AI has full control of the movement of their ship, in the sense that they can make it rotate to a perfect desired rotation in one go. That leads to a perfect aiming.

In my prototype, instead, the AI could only feed control input to the game! That is, the AI bot could just say "I'm pressing the joystick up this much", or "I'm pressing the joystick left this much", or "I'm pressing the fire button".
That means, I was not programming ships to move around. I was programming pilot bots to move their "virtual joystick" around. That led to an almost human-like oscillation in the direction of the craft when trying to aim at a target, because the bot had to counter the angular momentum that it had applied on the ship to make it rotate, in order to stop it when the craft had it's target on aim.

This led to much less precise, but more realistic AI. However, if you think that it is still too hard, then I need to tune it down. It's hard for the developer to know when stuff is balanced, because I get to test the AI so often that I know all its tricks and can predict its behavior.

We will definitely need betatesters later on when there is actually something to fly.
Take your time. I think AI will be one of the hardest things to get "right." There's not really any sort of empirical data you can base it on, unlike everything else there is to reimplement
avatar
Laserschwert: Here's a random selection (of most, but not all) pieces:

EWQL MIX2

I've only noticed a few places where I need to fix things, but apart from those I think this is done.
Sitting at my working place, listening to that audio file, having goosebumps... :D
avatar
Tarvis: Take your time. I think AI will be one of the hardest things to get "right." There's not really any sort of empirical data you can base it on, unlike everything else there is to reimplement
I am using the X-Wing recording camera a lot, and I playback the missions to see how ships react in different situations.
As you say, other than decompiling the game executable (that I don't think it would be legal), I can only guess which AI routines the game uses.

I'm finding strange behaviors that I think don't exist in later games in the series. For example, in that Rescue Ackbar mission, there are 5 shuttles flying on diamond formation towards the frigate Vehemence.
Well, they fly in perfect formation until I get closer to them on my Y-Wing, then they start moving slightly off their formation like if they would be nervous, but still trying to keep the formation.
In later games in the series, they will fly in perfect fromation until I shoot something at them, then they will start some evasive maneuvers and fly back to formation.
In X-Wing there is a weird "vibration" or erratic component in their flight plan that I can't tell if it's intentional or just an artifact of the fixed point 16 bit math used in that old engine. I am not ready to discard it as an error right away, because it gives the whole thing a feeling of that scene "They are too close!" "Stay on target" "I cannot hold them!" "Stay on target!"
The "vibration" I'm pretty sure It's got to be due to imprecision. Otherwise they'd actually smoothly change vectors instead of literally teleport a few feet to the left or right every second while flying. If you are handy with creating missions, you could try comparing ships flying a cardinal flight pattern VS one in a diagonal path.

A good mission to study this is the Rescue Sullustan Tech Staff mission. It's really noticeable on the TRNs. I've died several times because a TRN jumped about a foot to the left or right while I was following too close and crashed.

It could simply be that TIE Fighter and on improved the code for this. If you want to compare it with TIE Fighter, try the floppy version. I think the renderer had a lot of optimization done for the DOS CD version, even in the 320x200 mode, as the framerate is across the board much better. So, if you see the phenomenon in TIE'S Floppy version I think it's safe to classify it as a bug.

Another inconsistency I noticed: In TIE Fighter's DOS & Windows CD versions only, the Assault Gunboat pitches down about twice as fast as it turns in any other direction. This does not occur in the Floppy version of TIE Fighter, or XvT and XWA.
Post edited November 17, 2014 by Tarvis
avatar
Tarvis: The "vibration" I'm pretty sure It's got to be due to imprecision. Otherwise they'd actually smoothly change vectors instead of literally teleport a few feet to the left or right every second while flying. If you are handy with creating missions, you could try comparing ships flying a cardinal flight pattern VS one in a diagonal path.

A good mission to study this is the Rescue Sullustan Tech Staff mission. It's really noticeable on the TRNs. I've died several times because a TRN jumped about a foot to the left or right while I was following too close and crashed.

It could simply be that TIE Fighter and on improved the code for this. If you want to compare it with TIE Fighter, try the floppy version. I think the renderer had a lot of optimization done for the DOS CD version, even in the 320x200 mode, as the framerate is across the board much better. So, if you see the phenomenon in TIE'S Floppy version I think it's safe to classify it as a bug.

Another inconsistency I noticed: In TIE Fighter's DOS CD version only, the Assault Gunboat pitches down about twice as fast as it turns in any other direction. This does not occur in any other version of TIE Fighter, or XvT and XWA.
I think you are right about it being imprecision. Testing with Tugs makes it quite evident that there is something wrong going on. They are so little ships and move so slowly that the weird behavior really outstands. They move erratically like crazy.

I have not yet programmed in the different stats for the different type of craft. I guess I will have to use some of those old DOS X-Wing editors to find out the raw stats for every ship. Currently they are all the same statwise, while I program in the more general stuff like pathfinding (the kind of loose one a space sim needs) and waypoint following.

Now that you mention that mission about the transports, it reminds me something I wanted to discuss with you all to gather your opinion on it.
I consider X-Wing and TIE Fighter basically two sibling engines. TIE is younger and more refined, but I believe if the devs could have done so, they would have retroffited all the improvements made to TIE into XW. Even the XvT engine is just the TIE one with just networking added (evidence by its developer himself).
My point is, TIE removed the fatal collisions between smaller craft (you just bounce away, maybe with some minor damage), added hitboxes to missiles and torpedoes, and added time acceleration.
Should this reimplementation of the X-Wing engine have all those things from the beginning?
I think those should be optional so the player can choose between using those refinements and not using those.
I'd be fine with them, but yeah options would be fine as well.

Another thing that could be added are the threat indicators above the crosshairs
Alright, here are the final files:
https://www.dropbox.com/s/9wjc1zprsr28z8c/xw_flight_music.zip?dl=0

Since we can't have the audio-files be triggered by the MIDI timing (as MIDI speed changes would mess with sync) timing-wise I settled on this: 1 beat of lead-in (keeping timpani rolls), 3 beats of reverb trail.

I don't think it's necessary to have the digital music be in sync with the MIDI anyway, as only either one will be active at once. So it should be enough for them to act accordingly by the same "playlist" routine. What I'm not sure about is, if there are chances for the digital audio to go out of sync, miss its marks or something like that. Can any CPU hickups cause that?

Anyway, as you can see in the attached image, timing works as a 4 beat overlap. The shortest cues (like DG11) are 8 beats long, so both overlaps will fit end to end and we'll only need two stereo "tracks" for the music. Right now, all clips have a speed of 137.8 bpm ... we'd need to figure out what has to be added if we change some of the cues to 133 bpm (IF it should be necessary to have different speeds).

But I hope these will be enough for a first version.
Attachments:
overlaps.jpg (177 Kb)
Post edited November 18, 2014 by Laserschwert
avatar
Laserschwert: Alright, here are the final files:
https://www.dropbox.com/s/9wjc1zprsr28z8c/xw_flight_music.zip?dl=0

Since we can't have the audio-files be triggered by the MIDI timing (as MIDI speed changes would mess with sync) timing-wise I settled on this: 1 beat of lead-in (keeping timpani rolls), 3 beats of reverb trail.

I don't think it's necessary to have the digital music be in sync with the MIDI anyway, as only either one will be active at once. So it should be enough for them to act accordingly by the same "playlist" routine. What I'm not sure about is, if there are chances for the digital audio to go out of sync, miss its marks or something like that. Can any CPU hickups cause that?

Anyway, as you can see in the attached image, timing works as a 4 beat overlap. The shortest cues (like DG11) are 8 beats long, so both overlaps will fit end to end and we'll only need two stereo "tracks" for the music. Right now, all clips have a speed of 137.8 bpm ... we'd need to figure out what has to be added if we change some of the cues to 133 bpm (IF it should be necessary to have different speeds).

But I hope these will be enough for a first version.
My justification for using the MIDI timers to time the digital music is it means we wouldn't have to time exactly 3 beats at the end of every file to get the timing proper, since the proper endpoint can be determined from the MIDI timing instead. Any tempo changes seem to be contained within one segment (DG-S) so there is no need to worry about tempo changes messing up the sync. All that is required is for the recorded version to have the tempo change as well.

It is trivial to convert a MIDI timestamp (Beat + tick) to a time in seconds for digital music.

Essentially, every single MIDI event has a specified time to wait before playing it, that depends on the current tempo.

But it does not have to be calculated live. The MIDI file merely only needs to be read through in another function, accumulating DeltaTime values and accounting for tempo change commands while ignoring everything else, until it reaches the specified Beat and Tick to stop on. It is a simple calculation to convert DeltaTime into time in microseconds.

1 beat is 480 ticks in X-Wing. This is universal. Tempo is how many microseconds a beat lasts.
Therefore, the logic to get the fixed time at any MIDi position is by summing (DeltaTime/480) * Tempo for every MIDi event, and changing Tempo when a tempo change is encountered.

Then, the final sum of DeltaTime at that point is the time in microseconds which can be easily converted to a position to jump to (or a marker for when to play the next segment) in a digital sound file, without requiring a specific amount of leadout time.
Post edited November 18, 2014 by Tarvis