[aldo_14]

Just thinking...how hard would it to be to implement the same sort of 'animated' ship loadout screen that was in FS1? (see loadfighter01.ani or so-on in the FS1 vps).

Seeing as it's a once off ani, I'm wondering if it could be relatively simple to do - merely(?) showing each frame, then stopping on the last.....

[Solatar]

We could probably just make the .ani non-repeating. Unless it is hard coded:nervous: .

[aldo_14]

Originally posted by Hades
We could probably just make the .ani non-repeating. Unless it is hard coded:nervous: .

I'm not sure you undertsand what i mean....... i mean the pcx file which shows the overhead of the ship ,and which you drag your weapons onto.  In FS1, that was an ani, where the weapons locations 'flashed' up on screen one by one.  Look at the loadfighter / loadbomber anis in the FS1 data (?) VP file.

It's not really anything beneficial...just could be neat (maybe specify whether an ani or not by giving an (optional) extenstion to the tbl filename, or check for both files ending in *.pcx and *.ani when deciding what to use....or whatever).  I'll take a peek myself at the code, anyways... maybe I can get myself round to getting Borland to work and actually doing some work for once.

[Galemp]

I always liked the FS1 way better, because it showed you where your weapons were going. If you loaded a Banshee into the first slot on your Herc, and a Prometheus in the second, you knew that your quad guns would be Banshees and your chin guns would be Proms. It's not so easy with the Myrmidon if I want 4 Kaysers and 2 Subachs.

[DTP]

Originally posted by Hades
We could probably just make the .ani non-repeating. Unless it is hard coded:nervous: .

no, fs1 had both an PCX and a ANI file for the weaploadout section.

but some of the original code may still be there.

[Solatar]

Yeah, now I know what you mean. I think we could do this, and it probably wouldn't be too hard. Like DTP said, the code is probably still in there. Just probably commented it out.

[Star Dragon]

I finally got it in the mail and booted that puppy up (been over 2 years since I've seen the intro movie!)

   I like the FS1 loadout style better, looks cooler, In you face. IMHO that green grid takes away from the model, plus FS2 models pics are smaller...

[Galemp]

Yah, but this way we get smaller file sizes, you can see the stats without them being stuck in an ANI, and it's much easier to do the interface for new ships.

[aldo_14]

Originally posted by GalacticEmperor
Yah, but this way we get smaller file sizes, you can see the stats without them being stuck in an ANI, and it's much easier to do the interface for new ships.

ANIs are (I think) encoded so that each frame has a repeat count (I think it's RLE....little hazy on it).  So you'd only be storing - for the simplest possible implementation - about 4 or 5 PCX images (for a ship with 3 weapons boxes to display).  It's not that big a difference - certainly not icompared to the 3-8MB loadout animations from FS2.


Here it is - I think - from MissionWeaponsChoice in missionUI

Code: [Select]


// ---------------------------------------------------------------------------------
// wl_render_overhead_view()
//
void wl_render_overhead_view(float frametime)
{
char name[NAME_LENGTH + CALLSIGN_LEN];
wl_ship_class_info *wl_ship;
int ship_class;

if ( Selected_wl_slot == -1 ) {
return;
}

ship_class = Wss_slots[Selected_wl_slot].ship_class;

// check if ship class has changed and maybe play sound
if (Last_wl_ship_class != ship_class) {
if (Last_wl_ship_class != -1) {
gamesnd_play_iface(SND_ICON_DROP);
}
Last_wl_ship_class = ship_class;
}

wl_ship = &Wl_ships[ship_class];

if ( wl_ship->anim_instance == NULL ) {
if ( wl_ship->overhead_bitmap < 0 ) {
// load the bitmap
if (gr_screen.res == GR_640)
{
// lo-res
wl_ship->overhead_bitmap = bm_load(Ship_info[ship_class].overhead_filename);
} else {
// high-res
char filename[NAME_LENGTH+2] = "2_";
strcat(filename, Ship_info[ship_class].overhead_filename);
wl_ship->overhead_bitmap = bm_load(filename);
}
if ( wl_ship->overhead_bitmap < 0 ) {
Int3(); // bad things happened
return;
}
}
gr_set_bitmap(wl_ship->overhead_bitmap);
gr_bitmap(Wl_overhead_coords[gr_screen.res][0], Wl_overhead_coords[gr_screen.res][1]);
}

ss_return_name(Selected_wl_slot/4, Selected_wl_slot%4, name);
gr_set_color_fast(&Color_normal);
gr_string(Wl_ship_name_coords[gr_screen.res][0], Wl_ship_name_coords[gr_screen.res][1], name);
}


Ok..I don;t really have the foggiest how C++ or the *.ani format works ( ).  But I'd guess...

1/ Check for a PCX extension when loding the filename
(I'm assuming that the normal loadout would be a pcx file -  so it'd be more efficient to ONLY proceed if no PCX is there, rather than check for a - in the majority of cases - non-existent ani).

Would prob. need to do this AFTER the res is detected, for reasons of sanity.
2/ If a PCX, set some little variable as so, and parse it normally.  If not a PCX, check for ani file.  If no ani - > goto the failure condition.  Otherwise 'flag' it as so
3/ Use an if statement to decide how to show the image.... pcx as given, ANI -> parse through all frames in standard 15FPS, then stop at the last frame. ... the last frame should be the exact equivalent of a static (PCX) loadout image.

3/ is iffy, cos I don;t know how anis are handled.... I'm assuming a bit of the code form the weapons ani viewer can be used, though.

Code: [Select]


// Load in a specific weapon animation.  The data is loaded as a memory-mapped file since these animations
// can be large.
void wl_load_anim(int weapon_class)
{
char animation_filename[CF_MAX_FILENAME_LENGTH+4];
wl_icon_info *icon;

icon = &Wl_icons[weapon_class];
Assert( icon->anim == NULL );

// 1024x768 SUPPORT
// If we are in 1024x768, we first want to append "2_" in front of the filename
if (gr_screen.res == GR_1024) {
Assert(strlen(Weapon_info[weapon_class].anim_filename) <= 30);
strcpy(animation_filename, "2_");
strcat(animation_filename, Weapon_info[weapon_class].anim_filename);

// now check if file exists
// GRR must add a .ANI at the end for detection
strcat(animation_filename,".ani");
icon->anim = anim_load(animation_filename, 1);

if (icon->anim == NULL) {
mprintf(("Weapon ANI: Can not find %s, using lowres version instead.\n",animation_filename));
strcpy(animation_filename, Weapon_info[weapon_class].anim_filename);
icon->anim = anim_load(animation_filename, 1);
}

/*
if (!cf_exist(animation_filename, CF_TYPE_INTERFACE)) {
// file does not exist, use original low res version
mprintf(("Weapon ANI: Can not find %s, using lowres version instead.\n",animation_filename));
strcpy(animation_filename, Weapon_info[weapon_class].anim_filename);
} else {
animation_filename[strlen(animation_filename) - 4] = '\0';
mprintf(("Weapon ANI: Found hires version of %s\n",animation_filename));
}
*/
} else {
strcpy(animation_filename, Weapon_info[weapon_class].anim_filename);
// load the compressed ship animation into memory
// NOTE: if last parm of load_anim is 1, the anim file is mapped to memory
icon->anim = anim_load(animation_filename, 1);
}

if ( icon->anim == NULL ) {
Int3(); // couldn't load anim filename.. get Alan
}
}



(hey, i'm also named alan..... thank god that ain't me, eh)

This seems to be one of the relevant bits of code... there's also the load all animations one underneath, which may be to do with a sort of precaching thing(?) - I honestly don't know.


EDIT - haha!  could this be it?

Code: [Select]


void wl_start_slot_animation(int n)
{
#ifndef DEMO // not for FS2_DEMO

// don't use ani's
// fallback code in wl_render_overhead_view() will
// use the .pcx files
// should prolly scrub out the 1e06 lines of dead code this leaves
return;

/*

int ship_class;
wl_ship_class_info *wl_ship;
anim_play_struct aps;

if ( n < 0 ) {
return;
}

ship_class = Wss_slots[n].ship_class;

if ( ship_class < 0 ) {
Int3();
return;
}

wl_ship = &Wl_ships[ship_class];

// maybe this animation is already playing?
if ( wl_ship->anim_instance ) {
anim_stop_playing(wl_ship->anim_instance);
wl_ship->anim_instance = NULL;
}

// maybe we have to load this animation
if ( wl_ship->anim == NULL ) {
wl_ship->anim = anim_load(Ship_info[ship_class].overhead_filename, 1);
if ( wl_ship->anim == NULL ) {
Int3(); // couldn't load anim filename.. get Alan
return;
}
}

anim_play_init(&aps, wl_ship->anim, Wl_overhead_coords[gr_screen.res][0], Wl_overhead_coords[gr_screen.res][1]);
aps.screen_id = ON_WEAPON_SELECT;
aps.framerate_independent = 1;
aps.skip_frames = 0;
wl_ship->anim_instance = anim_play(&aps);
*/
#endif
}


Could maybe just call this (uncommented, of course) function in the wl_render_overhead_view operation?  witha few modifications.......hi-res support, I guess.

EDIT - added ALL the code  Just for reference (may doodle a bit of this when I'm in uni if time permits)

Here's an example of the anis from FS1 - http://www.3dap.com/hlp/hosted/reciprocity/aldostuff/loadfighter01.ani
This is displayed, then a pcx view ala FS2.  I'm not sure when it's actually put on screen (i.e. if it's 'under' the ani).  Or even if that matters.

A paltry 81kb(!)... i'm wondering if the last bit of code may be all thats necessarry, as I'm reading it as showing the pcx if all else fails.... although that may not be as efficient(?).  Also no hi-res support AFAIK.

EDIT2; Incidentally, has anyone changed the ani code for the weapons / ships loadout so that the 2nd loop point isn't hardcoded at (IIRC) frame 50?  (it seems to be, anyway - not checked yet).  If the ani classes / library (or whatever the C/C++ term is....escapes me at the mo) has a suitable method for getting it (the loop point), this is seemingly fairly/very easy IMO.

[Galemp]

Aldo: I was referring to this post by Star Dragon.

Originally posted by Star Dragon
IMHO that green grid takes away from the model, plus FS2 models pics are smaller...

He was talking about the ship loadout ani. We're concerned about the weapons loadout screen. Just wanted to clear that up.

[EdrickV]

Ok, the commented out code in wl_start_slot_animation does include the code that loads and plays the ani file used for the overhead view. Note this line:
wl_ship->anim = anim_load(Ship_info[ship_class].overhead_filename, 1);
That's where it would load the animation if it isn't loaded, but that line was commented out along with the ones around it and a return put in before that. The code to load the overhead animation filenames when the ship table is parsed still exists and is still used. (Even though said info is basically forgotten about.) To use animations, you'd have to comment out the return and uncomment the code below it. You might also want to adjust the coordinates of the animation. Not sure if it would work well where it would play. You would also have to add $Ship_overhead: entries to the FS2 ships.tbl, as per the FS1 ships.tbl. That is where it finds out what file to look for. (It will also try to load a pcx with the same name for use as the static background.) And the thing I found first, which confirms that the function noted is the right one, is:

 * 31    7/27/99 3:01p Jefff
 * crippled wl_start_slot_animation to prevent loading of overhead ship
 * .anis.  also began modifications for multiplayer interface.

[aldo_14]

Originally posted by EdrickV
Ok, the commented out code in wl_start_slot_animation does include the code that loads and plays the ani file used for the overhead view. Note this line:
wl_ship->anim = anim_load(Ship_info[ship_class].overhead_filename, 1);
That's where it would load the animation if it isn't loaded, but that line was commented out along with the ones around it and a return put in before that. The code to load the overhead animation filenames when the ship table is parsed still exists and is still used. (Even though said info is basically forgotten about.) To use animations, you'd have to comment out the return and uncomment the code below it. You might also want to adjust the coordinates of the animation. Not sure if it would work well where it would play. You would also have to add $Ship_overhead: entries to the FS2 ships.tbl, as per the FS1 ships.tbl. That is where it finds out what file to look for. (It will also try to load a pcx with the same name for use as the static background.) And the thing I found first, which confirms that the function noted is the right one, is:

 * 31    7/27/99 3:01p Jefff
 * crippled wl_start_slot_animation to prevent loading of overhead ship
 * .anis.  also began modifications for multiplayer interface.

I think it needs altered for the hi-res stuff, too, though.... not actually got round to looking at it properly yet.  No compiler, anyway.....

[EdrickV]

The high-res change wouldn't be hard to do. There's an example of it in action in wl_overhead_view() where it loads the pcx file for the ship.

[Galemp]

If the code doesn't find an ANI, will it load the PCX instead of crashing?

[EdrickV]

A PCX will be loaded when the animation is not playing and the pcx (aka bitmap) is not loaded. In a non-debug build, the program shouldn't crash because int3() is replaced by the preprocessor with: do { } while (0) which does nothing. We could borrow code from another function and load a PCX instead of the animation right in the same function though, but I think that's unneeded. If you comment out the int3(), then if it doesn't load the animation it will just return. (Which is what it does now, and the bitmaps still load.)

Edit: To clarify, if you comment out the int3() for the animation load failure, then the function will just return and the game will load the pcx the same way it does now, for both debug and release builds. The FS2 changes made this function do nothing but exit. (In otherwords, the program enters the function and then exits again.)