Hi again. Nevermind the previous post. I checked several more missions and I think I have the pattern now.

There are 2 cases:
- If Arrival Delay value is lower than or equal to 20:
The value is the amount of minutes.

-Otherwise, if Arrival Delay value is higher than 20:
Minutes = Quotient of Value / 10, minus 2.
Seconds = Modulo of Value / 10, times 6.

It could have been all the time like the second case. But I guess the developers were bored of mentally passing minutes to seconds and added the first case shortcut.

Regarding Obj-conversion:
Could anything regarding animation and rigging be lost in the process as well?

Most likely. OBJ seems to contain only basic mesh, UV and simple material information. Nothing about animations, rigging or skin meshes.

We will not be using this for the "demo" release of XWVM. It's too much complication for just a demo.
For now, we will keep on manually importing the models into Unity and having them work.
At a later point we will have another round of thinking on this and decide further what we use for importing ships on the fly.

I believe this is the most productive way. What do you think?

Agreed. That's low on the priority list overall I think.

May I ask the rough progress of this project ? Is it good to say it is roughly over 50% ? Many thanks !

Same here. I think doing otherwise would go too far beyond the demo's purpose of giving off a first taste of what's to come.

Hi. There is lots and lots to do yet, but lots has been done already.
I'm not sure what you understand by "this project". Our first goal is to release a demo with one mission that is fully playable. My inspiration is the TIE Fighter demo (a video of it).
Most likely, the demo will contain only some intro text explaining Y-Wing Historial Mission 6, some screen to configure your input method (buttons, axes, etc), and there you go into the flight engine.

We are limiting ourselves to clear, reachable milestones so that we deliver something.
If we set our milestones too far away, probably that would lead to disinterest creeping in and end with the abandonment of the project.

Back on topic, you are asking for a progress percentage. I can tell you what I can think of that is missing from the project to reach that goal:

- Capital ship AI, with turret aiming and, perhaps, turret turning. We need this for frigate Vehemence.
- Mission goal tracking, with both updates for goals achieved and goals failed that lead to a final Mission Complete or Mission Failed message.
- Whole hyperspace sequence for the player ship. Currently the player just appears at the mission start.
- Proper inner cockpit 3D modeling to replace my programmer art. Before that, I can't really enable the feature of looking around, because there is literally no 3D art out of the current point of view.
- Realistic looking model for the Nebulon-B frigate. Alternatively, I could ask in the XWAU forums if it's okay to release the demo with their frigate model. The Nebulon-B frigate is a tricky model full of details, and much more work than creating models for several other ships.
- Sound effects. The original idea was to get them at runtime from the original game files. For this demo, though, I think it could be okay to just include some ripped off the game. It's a technical demo, not a fully realized game, so I hope that would be okay.
- Some kind of pre-mission and post-mission interface to show the briefing text and the debriefing text. (*)
- Space dust. It's those particles that move around the player ship to help giving an impression of the current speed.
- Space objects (**). In X-Wing, the planets that can be seen as a backdrop are objects placed on the 3D map. The test mission uses a "Ring World" space object. I guess it's a planet that has a ring like Saturn, not a ring-shaped planet. :)
- Torpedos for the Y-Wing.
- Collisions between ships.
- Player death.
- Testing, testing, and more testing, both looking for bugs and for balance issues. We need to make sure that the test mission plays as close as possible to the original to keep the same difficulty level and the same resolution process. MajorParts has been helping a lot with this lately.

(*) On the briefing:
It could be just temporary menus in the style of XvT even when in the final game they would be recreated 3D interiors mimicking the 2D interiors from the original X-Wing.
We don't need to have the 3D interiors for the demo, neither a fully animated Dodonna pointing at the presentation with his baton. That sounds like a lot of work for something that is mainly cosmetic.
What would be great is to have the "mission powerpoint" working. I mean, the briefing map with ship icons, highlights and panning.
Problem is that the briefing file format is not well described anywhere that I have found. Obviously, the many mission builders developed during the years have had to figure it out. But nobody seems to have bothered to disclose their findings, so I guess we will need to figure it out all over. (At least, this time we are documenting everything on a repository, so there will not be a need for anyone after us to do this work again)


(**) On space objects:
In the original X-Wing, due to memory limitations, these planets used sprites that were quite small for saving the scarce memory that was needed for other stuff. It was even worse in X-Wing 98 and XvT when they increased the resolution to 4x the original, but the sprites remained the same size.
Instead of feeling like you are dogfighting over a planet, it was more like you could spot a planet if you were lucky enough to look at the right direction by chance.
It would be great to replace those old sprites with something better.
I was thinking on, perhaps, replacing them with 3D objects so we can make them as big on the screen as we want, without wasting extra memory. So the mission could really feel like it's being fought just outside of that ring world.
Obviously, it would be a camera trick and the player cannot actually fly to those planets, but I think we could do something with them during the hyperspace sequences, so you actually see yourself coming towards them or leaving them behind, just in the same way that the rebel feel see Endor and the Death Star approaching really fast when they come out of hyperspace in Return of the Jedi.



So as you can see, there is still lots to do, and it's just accounting for the limited scope of the demo.
But I'd say that most of the hardest stuff seems to be behind already (like the iMuse system, the AI fundamentals, the flight group logic) and once the base systems are more stable, it will be faster to add more content to this.

For example, for making this test mission work, I have had to program the whole combat system, with reactions, shooting weapons, aiming, all the instruments in the cockpit, the ship parts system, the colliders, the AI for avoiding collisions, the flight plan system for the different orders used in the mission...

From that point on, adding, for example, another mission or another ship would be relatively small work because the fundamentals are already there and most of the work will be tweaking numbers and creating 3D models.
I foresee that the game progress pace will speed up as time goes, because the work that will be left to do will be easier and more "parallelizable", that is, can be done by other people at the same time.

Another example: making the Y-Wing cockpit functional has taken me months because I had to create all the instruments and their functionality. However, creating the B-Wing cockpit, or other, would take much less work, because it uses the same instruments, only in different places. Only the 3D modelling and some minor tweaking would be needed to add a B-Wing to the game. While it took me almost 6 months to make an Y-Wing flyable, I could make another rebel ship in one day or two tops if someone gives me the 3D art because they are so the same.

So it is really hard to say what percentage there is left of the demo.
If we manage to keep this pace, I don't think it's unreasonable that we all have had a chance to play the demo by around Christmas. The amount of polish, though, is the question here.

Dear Azrapse,

When I read your reply, I was really really touched. I must show my deep gratitude to you.

I am a big fan of the TIE Fighter game, especially the Collector's CD version. However, when I tried to play the game again about a year ago, I found a nightmare. The nightmare is the fact that :

THE GAME CANNOT BE PLAYED WITHOUT ISSUE IN ANY MODERN SYSTEM WITH GOOD FRAMERATE.

Yes, even now, the nightmare is still here. ALL the Collector's CD versions (including the original version, the GOG version and the steam version) have the same nightmare. The main problem is the "Turret AI is affected by the DOSBOX's cycles", described in the following link :

http://www.vogons.org/viewtopic.php?t=24922

The issue is also mentioned in the following WiKi :

[url=http://pcgamingwiki.com/wiki/Star_Wars:_TIE_Fighter#Capital_Ships_and_Space_Stations_rarely_fire_their_Lasers]http://pcgamingwiki.com/wiki/Star_Wars:_TIE_Fighter#Capital_Ships_and_Space_Stations_rarely_fire_their_Lasers[/url]

The Turret AI can be corrected (hopefully) by reducing the DOSBOX's cycles, at the expense of the framerate. But stuttering gameplay is a pain. When I read more posts in various forums, I found it very likely that not even the Turret AI which is affected by the DOSBOX's cycles, but many other AIs are also affected so that some missions are ridiculously hard (or evern impossible?) to be completed.

This is a BIG issue in my opinion, but it seems that very very few guys in this world understand the truth. Even the few guys understanding the truth no longer care about it today. When facing this nightmare, I feel lonely and hopeless.

Until... I found your project. This is "a new hope" ! I can dream of a day...

I PLAY TIE FIGHTER IN A MODERN SYSTEM WITHOUT ISSUE WITH GOOD FRAMERATE.

I don't care about whether the graphic can be improved or not, the original Collector's CD graphic is already good enough. But, iMUSE is a MUST !

Again, Azrapse, thank you very much indeed ! I can dream now ! ^^

Thanks for your nice words, mate.
But we are remaking X-Wing here, not TIE Fighter. :S
I mean, XWVM stands for "X-Wing series Virtual Machine", so its initial goals were to be able to play any mission for any game in the X-Wing series. But getting it ready for the 100% of the first game is something that can take a lot of time. Years, if we want to do justice to all the cutscenes and interiors and, perhaps, coop play...
But even when remaking TIE Fighter is the next sensible step after we are done with remaking X-Wing, it might take even more years before we reach that point! :(
Neither of us are working on this project as our main job. We only can pour on it some spare hours on weekends or evenings when family or real life allow.
Sorry if I broke your dreams there. :(

Nevertheless, once the X-Wing part is completed, adding the upgrades for the TIE Fighter part should be quite straight forward. The file formats for TIE Fighter are well known (I'd dare to say, even better than those of X-Wing).
By then, we will probably have a working OPT importer, so we can use the 3D models from TIE Fighter 98 without having to dedicate a lot of effort to remake them.
Perhaps, by then, even the guys at XWAU would have blessed us with their permissions to use theirs.
The flight engine is substantially different from that on X-Wing, more complex, and more advanced. Luckily, I am already backporting a lot of TIE Fighter features into the XWVM engine, because why not? There are the targeting computer, message log, mission goal tracking, targeted ship indicator... Under the hood, ships already have their different components that you could individually target in TIE Fighter.
So in a way, XWVM is actually "we are rebuilding TIE Fighter to play X-Wing missions instead".

The whole cutscene part is much trickier. It's totally an undocumented format. Even if it were documented, it would look like crap played in high resolution 16:9 screens just scaling up the 320x200 4:3 sprites.
To make things worse, big part of TIE Fighter's appeal comes from the great cutscenes. So it's not something we can just skip.

Apart from all of that...
Not so long ago I played thru the whole TIE CD 95, all the battles from beginning to end. I lowered the cycles in DOSBOX, and even when it was a bit sloppy when there were many ships in front, it was totally playable.

Either that or we could reuse some of the soundeffects of "X-Wing vs TIE Fighter", which happen to be loose wav-files.

Edit: I don't know whether or not this was asked before, but how will placement of the XWVM on the hard drive be handled? Will it be placed in X-Wing's root directory or will it have its own, like the XL Engine does?

Yes, the XvT sounds could be good placeholders.
XWVM would create its own folder and import there (or read on the fly) all files needed from the original games' folders.
It will be a parallel installation. I don't this it's such a good idea mixing its own files in the original game's folder.

I recently had some thoughts on this subject, but completely forgot to post them up (been very busy with work lately).

I think this could be an opportunity to remedy a long-standing "bug" in the X-Wing games, where planetary objects aren't taken into account for hyperspace vectors - i.e. you can quite happily point yourself at a planet and jump into hyperspace with no ill effects whatsoever (and yet, if attempting to enter hyperspace with a 3D object in front, the jump is aborted!)

Aside from solving the minor hyperspace issue,. having 3D planets (and the Death Star in TOD 3 ;-) ) would be an excellent upgrade - even with high resolution sprites in XWA, I always thought it wasn't quite enough to sell the effect they were going for.

On the implmentation - agreed that a camera trick is probably a good way to go. The way the Source engine handles skyboxes springs to mind as a potential solution here? (In Half-Life 2 and the like, the skybox surrounding the map is actually built up on a 1/16 scale outside of the playable map https://developer.valvesoftware.com/wiki/3D_Skybox) An advantage I can think of using this type of approach is that the planet(s) are not simply static objects, and would actually be "reachable" given enough time (not that I would think there should be any handling of any kind for that type of scenario - it is just a backdrop, after all, and placed far enough away would still require a large amount of effort from the player to reach).

From memory, planets for each mission are defined in the mission files as objects, and can be given positions on the map, which from brief testing don't seem to have a great deal of bearing on placement of the sprite on the backdrop (I would be happy to be proven wrong about this :-) ) -you could place a planet just in front of a player spawn with no ill effects.

This needs further testing, but I think when you place a planet on a mission, it's precise location doesn't matter (other than for the briefing presentation) save for their relative position in regard to the center of the map at (0, 0, 0).
I mean, if you place a planet towards the soutwest of the center, then the player will be able to see it if they towards the "southwest" of the sector.
In that way, you can basically define in which direction the planet sprite should appear, but distances are irrelevant. They are always unreachable.
Planets (and the Death Star in the 3rd last mission in TOD 3) aren't the only things that behave like this. The game, randomly, adds some extra flat sprites at particular directions depicting galaxies and dust/gas clouds. I am not sure if they kept them for XvT, but they are definitely there in X-Wing and TIE Fighter.

I was thinking precisely on a 3D skybox, as you mentioned.
The difference with the Source engine is that in a shooter you can effectively lock the player in a particular area of a level so that they cannot reach the fake buildings in your skybox.
You cannot do that in X-Wing, so it would involve placing the planets truly at huge distances (so that nobody could reach them by accident during a dogfight), and making them huge size.
That soon starts causing problems with the 3D engine, because the camera likes having a culling distance that is reasonable. Otherwise, lighting and shading start breaking down.
Then we would need to place them way closer and at no so big scale. But that would make the planets feel ridiculously close and small. You can tell.
(One of the few things I didn't like from TIE Fighter CD was that they replaced the intro that was in the floppy edition with another that was kind of pre-rendered, where you can see a super star destroyer approaching what is supposed to be Coruscant, buy actually looks like a giant marble just behind the spaceship)

Instead, I had thought on another solution:
- You place the planets and other unreachable cosmic objects at roughly the coordinates specified in the mission file. Only instead of kilometers you treat them as meters. These planets aren't really at real scale, but more like a beach ball size. These planets are placed on a layer that the main camera doesn't render. So it's like they are in an alternate dimension.
- You create a camera that renders this alternate layer only where the planets are. This "planetary" camera always stays at (0, 0, 0), but it rotates to look at the same direction that the player's camera is looking at. This camera also renders the star backdrop as a background.
- You configure the player camera not to render any background.
- Finally, every frame, you render first what the "planetary" camera sees, then what the player camera sees, in that order.

As a result, you have kind of a chroma-key effect, with the spaceships and lasers that the player camera sees rendering on top of what the "scale universe" camera sees. This achieves the effect of having huge planets as background (because the planetary camera is close to them and they look huge), at the same time that those planets are unreachable, while keeping everything well into the normal culling distance, where we can take advantage of shaders and shadows and all kind of neat stuff.

(I like to imagine these 3D planets as a sphere with some geographical texture with metallic shader looking seas and bumpy shader looking continents, wrapped on a slightly bigger translucent sphere textured as atmospheric clouds. This "atmos sphere" (:D) could rotate slowly to give the impression of a "living" weather)

Also, for the hyperspace sequences, we could actually move the "planetary" camera, so that it looks like those planets are getting closer or farther away.

That sounds great!

The process you describe for planet placement in vanilla makes perfect sense, and frankly, if it isn't the way it happens in vanilla, it really should be. I wonder if it would be necessary to do a quick check on initialisation to make sure that the planet vectors wouldn't overlap if following this method and creating 3D objects - in thiat scenario, an overlap could be handled by adjusting the distance of one or more of the planets, or moving it along x,y or z until it no longer clips (and with a suitable 'realistic' distance between them).

Your description of the potential planet effects also sounds great. I wonder if it would be possible/worthwhile to automatically generate one or more of the surface/bump maps by checksumming the level + planet number, and using that as the seed for the map generation? This way, atmospheric effects would be unique per planet per mission, but consistent between playthroughs. But then again, maybe that's overkill. :-)

That is polishing, and once the game it's more or less complete and at a playable state, I bet we can spend as much time as we want on polishing it. The sky is the limit. :)