Fallout engine movement animation system

H

hardsetHead

First time out of the vault
Hi everyone, first time poster, long time lurker.
I'm working on bit of a port of the fallout engine at the moment, I'll spare you the details but I've got a fair bit of progress done, but there was a lurking question I had regarding the original engine that I was wondering if anyone could answer.

I've been able to decode the original FRM files, and in the movement animations the walk and run animations move more than one hex in their full animation. The walk hex moves a total of two hexes in the animation's direction in 8 frames.
I was wondering if anyone knew how the original fallout engine handled animating movement across single hexes.

In my present version, the animation plays with the offsets intact, so the sprite will appear to move in the correct direction. After each 4 frames of movement I then update the actor's actual hex coordinates to reflect the new position of the actor, and then use the new coordinates as the basis of the rendering offsets. To keep this looking correct, if the animation is between frames 4-8, I offset the sprite's position so that it is aligned with one hex backwards along the axis of it's movement.
This system does work and seems to be a valid solution...
but I was wondering if anyone else had any more details regarding how the original devs handled this issue, or how teamX or FIFE had managed the same problem.

I hope I've explained things correctly, but if anyone has any questions feel free to ask.
My current solution seems to work, but I was thinking there had to be a better way of doing this. Plus I wanted to keep it as aligned with the original as possible, so as to prevent any future asset issues.

If anyone could help me out with this, would be greatly appreciated!
 
Another member of your team directed me to your source code. It's quite easy to follow, and has been a big help!
I really like how you solved this problem, a very nice system. Makes alot of sense, It's probably identical to how it was done in the original.
One question, is your map loading code finished?
I've been having a few problems with my own, and checking it against yours, mine seems more or less the same. But I keep running into some problems loading the objects for a few maps, it'll get to certain objects, then will fail returning incorrect ObjectIDs.
My port is kinda platform specific, it's not in C++. It's actually just more of a demo than a port. Just to demonstrate what I can do on the platform. Once I'm done with this, I'm more than happy to lend a hand on other projects.
 
hardsetHead said:
Another member of your team directed me to your source code. It's quite easy to follow, and has been a big help!
.
Click to expand...

Actually you should check out the code again, the movement animations particularly wasn't working correctly and I fixed some stuff. There are some hard-coded action frame numbers (eg. not in FRM file, because there is only one action frame for animation, and we need several for running) which just seem to work. Also note that when character changes direction during movement, his animation continues from the last frame.
 
Hi Phobos and iSage,
Work has been continuing on my project, and I've been doing a bit of cross reference with your code. I'd like to commend you guys on a great effort. And in a month or two, once I'm done, I definitely think I could contribute some of my knowledge to your work.
There are a few ways I think I could help out.
I have my own MAP2JSON code, I didn't realize you'd already started on one. My converter loads the mapfile through Javascript and outputs a JSON object, which can then be written to a file from a browser.
Also, from looking at HexagonGrid.cpp, Am I correct in seeing that you use a brute force approach to mapping mouse coords to hexagons on the map? If so, I can give you my code I use for the translation.
( please excuse any errors, I quickly rewrote it in C++ )

Code: 
[INDENT]int s2h(mx,my) {        [/INDENT]
[INDENT]        int hCol, hRow, cOffset, rOffset;
        
        if(mx < 0) mx -= 32;    // compensate for -0 effect
        mx *= -1;
        
        hCol = (mx/32 | 0);
        hRow = (my/12 | 0);

        cOffset = abs(hRow/2 | 0);
        if(hRow >0) hCol += cOffset;
        
        rOffset = (hCol/2 | 0); // correct
        hRow -= rOffset;
        
        return ((hRow*this.h_width)+hCol);
        
    }[/INDENT]

Make sure to subtract the camera coords from the vars you pass to the function. This function assumes that the hexgrid counts from the top right as it does in the original fallout. This method should be alot faster than a brute force array search, and doesn't require storing any screen coordinate variables for the hexes themselves.

edit: Fixed code up. Looks like I left some of the old vars in there from the previous version.
 
Last edited:
hardsetHead said:
Hi Phobos and iSage,
I have my own MAP2JSON code, I didn't realize you'd already started on one. My converter loads the mapfile through Javascript and outputs a JSON object, which can then be written to a file from a browser.
Click to expand...

Heh, is your engine in JS? Also, is it going to be open source? :)
 
Yes, yes and yes! (:
Should be up on github in under a month!
Also, if needed I can fix up the code for being pixel accurate. I've kept that out of my translation functions at this point due to the efficiency constraints of Javascript. Compared with C++ it's terribly slow, an order of magnitude slower.
The project is more for my portfolio than being a real, usable port. But it could definitely have potential!
Currently I have map/object loading/rendering sorted. Simple pathfinding implemented. Will definitely be opensourced. More details soon!
 
hardsetHead said:
Yes, yes and yes! (:
Should be up on github in under a month!
Also, if needed I can fix up the code for being pixel accurate. I've kept that out of my translation functions at this point due to the efficiency constraints of Javascript. Compared with C++ it's terribly slow, an order of magnitude slower.
The project is more for my portfolio than being a real, usable port. But it could definitely have potential!
Currently I have map/object loading/rendering sorted. Simple pathfinding implemented. Will definitely be opensourced. More details soon!
Click to expand...

Neat. If you haven't checked out the DarkFO thread, here it is: http://www.nma-fallout.com/showthread.php?202410-DarkFO-Announcement
It's my engine reimplementation implemented in (now) TypeScript. :)
I plan on making it open source some time in the future when it is more complete, but feel free to ping me about it and check out my devblog.

The hard part is mainly just un-/under-documented stuff, game bugs, and engine oddities (there are quite a few).
 
Nice! Very nice!
Wish I was aware of this before I started. I'm definitely going to follow this too.
As I said, this is more just a portfolio project to prove my abilities than anything else. Shame someone's already done it though! d: But that's life. I figured it had at least been attempted. I don't expect mine to be playable really anytime soon.
When I get mine done, I think I'll definitely be able to lend my skills and knowledge around. Would be cool to help other people on their work!
 
Hey, mine's nowhere near finished! A lot of stuff just isn't implemented.
Stuff like most character stats, traits, perks; sound (although I don't suspect that to be a problem); lighting (I'm working on reverse engineering this, but it's a massive pain); many weapon modes (I only have the "single" modes working, and without ammo, etc.).

The things that are implemented usually have bugs or aren't entirely featureful (the AI is very barebones for example, critters just move, attack and flee; the animation system, like yours according to this thread, is pretty messy and isn't correct. Scripts always have problems because, well... have you even seen their scripting language/API? Jeez, the 90s, man.)

Are you going to see it through completion to the order of "You can play Fallout 2 in it"? :D That would be awesome. Maybe we could pool together work then.
 
Well, you're a long way ahead of me!
I intend to just get mine to a point where you can load a map, walk around, talk to an NPC, with minimal interactions and then leave it as a tech demo. After that, I'd be definitely keen to help out.
I haven't tackled the lighting issue yet, but I just figured I'd be loading light values from world objects then blitting those to the alpha channel of a lightmap buffer, then blitting that to the backbuffer with globalAlpha adjusted for the ambient light level. Figured that'd be the fastest way to pull it off.
I'll get in touch over the next few days to talk more in depth!
 
Main problem with lighting is how to build the lightmap. It's, well, a real mess.
 
iSage said:
Main problem with lighting is how to build the lightmap. It's, well, a real mess.
Click to expand...

That's putting it mildly. :D
There are several lightmaps, many look up tables, a bunch of insane algorithms ... .

I'm looking into it, but I think (according to what I've seen in FO2), my hexagon and tile transforms are probably off by quite a bit so I'll have to take care of that first, then comes
the slow process of putting the pieces in one by one until I get something that resembles a working system.

Deities guide me. :D
 
You must log in or register to reply here.
Back
Top