FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - chewie

Pages: [1]
1
Moin @all :)

For those of you who suffer from sound problems under Ubuntu (> 9.10), too, I may have a solution. For me, the sound performance is unacceptable bad, I hear cracking sounds and my CPUs are at 100% - so e.g. screencapturing is impossible, actually playing a FIFE game with audio volume > 0 is a no-go.

So, I found this forum thread and the hint about editing the alsoft.conf helped - the sound issues are gone :)

-> http://www.wildfiregames.com/forum/index.php?s=&showtopic=12478&view=findpost&p=204336

Quote
In the terminal:

sudo gedit /etc/openal/alsoft.conf

change the divice line form Alasa backend stuff to this:

## ALSA backend stuff
##
[alsa]

## device:
# Sets the device name for the default playback device.
device = alsa


remember to un coment it.

Hope this helps.

Edit: added the workaround here to avoid that it will be lost

2
Framework development / [FIFEdit] The official map editor
« on: March 17, 2009, 08:05:32 am »
>> This is the official attempt to revive the editor development (yeah  :D) <<

On the last FIFE meeting, the developers have agreed to revive the editor development and start to collect proposals for enhancements.

We started a cleanup at the Wiki editor category and so far you can find two articles there:


Your feedback

We would also like to invite everybody who is working with FIFedit to tell us:

  • your current workflow with the editor
  • which feature you miss the most in your daily work with the editor

Of course, everybody else is invited to give feedback about the editor / must-haves for editor tools in general.  ;)

Where to post feedback?

The starting point would be to add comments to this thread, additions to the proposals article are welcome, too.

And - of course: You can join the IRC channel and tell us your ideas :)


3
Framework development / [FIFEdit Plugin] layertool
« on: March 17, 2009, 07:49:07 am »
The layertool plugin already is integrated in FIFedit for some time now, but due to the latest activity about reviving the editor development, I decided to start this thread here.

So, here are the features of the plugin:

  • list all layers of the current loaded map
  • hide / show specific layers
  • select layers by clicking on the layer name

Here´s a small demo screencapture of the plugin, tested on a zero map: FIFedit layertool plugin

Future plans for the plugin are:
  • replace the builtin layertool (lacks some workflow IMO)
  • add layer deletion
  • add possibility to add new layers

Please let me know how / if this plugin works for you - and how you think about replacing the builtin layertool with this plugin. Also, if you have additional ideas for the functionality - just post them here  :)

4
Framework development / Your feature requests
« on: October 27, 2008, 03:37:12 pm »
Greetings :)

This thread is a pointer on how to create feature requests for FIFE.

You can find a short article about this topic in the -> Wiki.

Some useful links:

5
Framework development / [FIFEdit Plugin] Object editor
« on: September 11, 2008, 10:31:26 am »
Moin moin :)

I'm currently writing a small plugin for FIFEdit - an offset editor.

The goal is to add a possibility to the editor to adjust object offsets to the chosen map geometry, save the changes. The plugin should take care of wether the user wants to edit static images, rotated images and also frames of animations.

After some work, it seems that I can turn this plugin into a general "object editor".

Features so far:
  • Instance selection
  • Instance indication via InstanceRenderer (addOutline)
  • Manipulation of x / y offsets via GUI
  • Showing all (?) data of the instance / object in the GUI
  • Working offset changes for map objects which aren't providing wired rotations (33°, 67° etc...)
  • Manipulation of instance rotation

Changes to mapeditor.py plugin:
  • Instance rotation code was hardcoded to 90 degree steps - I tried to make this a little more flexible. But this isn't a long term solution

Problems / lacking features so far:
  • Different rotations are still an issue
  • Animations are not editable for now - they need quite some knowledge about the way FIFE is handling animations
  • Saving object data

Problems:

  • Instance rotation differs from object rotation (rotation value which you define in the XML files) due to camera tilt.
  • Animations doesn't provide something similar to "visual.getStaticImageAngles()"
  • In general the internal FIFE animation data is hard (?) to collect and needs a lot of code (so no animation['x'][alldata] structure, instead you have to build this on your own)

I guess I am missing something important due to image pool / animation pool handling - so I would be glad for any help about this issue.

Attachements:
  • (new) Screenshot

The plugin itself can be downloaded from here:

Edit: the plugin now has the name "object editor"

6
Framework development / FIFE RAM usage - animation loading
« on: August 13, 2008, 10:44:51 am »
Moin @all :)

We (Zero) discovered that FIFE eats a lot of RAM when loading multiple maps. (we are talking about ending with 1.5 GB RAM after 3-4 maps). After some testing we discovered the cause for this behaviour.

Major issues are:
 - pool has no cleanup method (spq told me that this is already known)
 - loading huge xml files for agents

Some very simple "benchmarks" had this result:
 - Loading a map with one tile, two trees, the player (13 defined actions, ~2140 png files) and one zombie (6 defined actions, ~600 png files) = ~500 MB RAM usage
 - Loading the same map without the zombie = ~240 MB RAM usage
 - Loading the same map without player & zombie = ~ 60 MB RAM usage

Loading time steps are somehow equal (~ 30, ~15, ~2 seconds).

(my machine: 2.8 Ghz DualCore, 2 GB RAM, Nvidia 8600 GT, Ubuntu 7.10)

As the results may of course vary when using different systems, one thing is very strange:

The zombie + player file size is ~15 MB. Why does that lead to a RAM usage of ~440 MB for these two instances (only)?

We had a little discussion about this at the fife channel:

Quote
<chew-ie> barra, do you happen to know who created / worked on the pools of FIFE? (imagepool, animationpool)
<barra> AFAIR jasoka wrote at least parts of the code
<barra> svn blame could shed some light
<chew-ie> Okay, that's good :) So the person is at least still @FIFE :)
<barra> yep, always hard to get in contact with the people who don't work on the engine anymore
<GreyGhostNew> chew-ie, resource freeing?
<chew-ie> yes... I discovered that rio de hola only needs 160 MB RAM - whereas any map of zero eats ~500 :( (per load)
<GreyGhostNew> :(
<spq> how big are all the imagesyou load?
<chew-ie> that's variable. I set up a testmap with "real" tiles - and they have a size 629x315
<chew-ie> Our trees are huge images, too
<spq> hm
<spq> could you load the map in rio de hola?
<chew-ie> But strange enough - this tiny little map eats the same amount of ram -> http://zero.vaultnet.ath.cx/pictures/1024x_zero_13_08_2008-13_44_04.png
<chew-ie> my only guess is that the animationsets of the player & zombie can cause this ...
<chew-ie> The framework without loaded map only needs 50 MB RAM - with all the gui loaded
<spq> how big in mb are all your images you load in a game?
<chew-ie> In this little map.. wait a second
<chew-ie> about 20 MB - whereas the player character animationset has ~ 13 MB
<chew-ie> holy shit...
<MuteX_> chew-ie, what happened?
<chew-ie> spq, I deactivated the player and the zombie on the little map - and the map is loaded within seconds - RAM usage has little difference to framework startup (~ 60 MB)
<chew-ie> So the player and the zombie causes a RAM usage of ~ 440 MB ...
<GreyGhostNew> chew-ie, you mean .. 1 player and 1 zombie?
<chew-ie> yes ...
<barra> hmm please paste the map markup chew-ie
<GreyGhostNew> O_o ..
<chew-ie> ~ 15 MB (player + zombie animationsets) end up in 440 MB used by FIFE...
<barra> it might be possible that you use batch loading to load ALL agents
<chew-ie> barra, no - I only load object files of zombie and player
<GreyGhostNew> somethings looping in the loader maybe?
<spq> how much images are there in the animations?
<chew-ie> Why doesn't that affect rio de hola then? There are animations loaded, too.
<chew-ie> spq, depends ... a typical idle animation has 20 frames for each direction - whereas reloading has 60 frames.
<chew-ie> I've to correct myself: I am batchloading ->
<chew-ie> "<import dir="../objects/agents/malehuntingclothes001"></import>
<barra> hmm try to just load the animations that are actually needed
<chew-ie> But I'd say that's equivalent to import file (because there is only one object,xml to load)
<barra> I think there should be a feature in the editor tool to " finalize" a map
<barra> could you please paste the map markup chew-ie ?
<barra> or tell me which map is causing the issue, I got a local checkout here
<chew-ie> barra, it's not only a map ...
<barra> so free choice for me?
<chew-ie> I changed import from dir to file now
<chew-ie> Let me explain:
<chew-ie> A map without any agent animationsets loads fast and doesn't cause high RAM usage.
<chew-ie> But as soon as I introduce an agent, the RAM usage is awfully high.
<chew-ie> This is a major showstopper - because these are the critical components of the game :(
<barra> I agree on that one, hopefully somebody could take a look into it, as SVN access is given
<chew-ie> The funny thing is : these animationsets are far from being finished - they are lacking dozens of actions / equipment etc. I don't want to imagine what happens to the RAM if we have 20 different weapons * 10 different armors... -.-
<chew-ie> (so far we have 2 weapons and no armor)
<barra> I would propose to either try to catch a developer here and convince him to look into it or to post about it at the forums
<chew-ie> spq, are you loading animations on demand @openanno?
<dauerflucher> chew-ie, did you and the other zero devs already agree about graphical limitations?
<chew-ie> dauerflucher, what exactly do you mean with that?
<dauerflucher> somethign like all rifles use the same animation
<chew-ie> sure
<chew-ie> The first idea was to provide animations for all weapons - but we dropped that very soon.
<dauerflucher> a good decision :)
<chew-ie> So we now have the "Fallout method"
<barra> yep, I think the weapon class approach used in the old RPG classics of the 90s is the way to go for prerendered art
<chew-ie> yip
<dauerflucher> i think you still _might_ handle a lot of stuff using overlays
<barra> yep, but I think an overlay concept might be complicated
<dauerflucher> but it's still a shitload of work
<dauerflucher> it's sad but true :)
<chew-ie> yep - and you get very generic animations
<barra> that's another drawback of it, yep
<chew-ie> because all movements have to be synced against each other *brr*
<chew-ie> I'd say agents should load the needed animations due to their current equipment - so no huge xml file with all animations, but small ones with e. g. pistol:leatherarmor etc...
<dauerflucher> that's the only way to get stuff done at some time...
<chew-ie> of course this needs also a way to clear animationpool from unused animations
<dauerflucher> chew-ie, wether OA already got something beiong of use for you or it will be there at some time... spq is taking care for a lot of interesting code details others might not have thought about
<chew-ie> dauerflucher :)
<chew-ie> sure, but I guess this one is connected to the xml datasets - which oa doesn't use (I start to understand, why ;-) )
<chew-ie> I'll talk with helios & jasoka - maybe we can develop a solution for zero and hand it back to fife :)
<dauerflucher> maybe... i mean just maybe... you should think about using databases as well :)
<dauerflucher> i can't tell about long time effects, but for now it works pretty fine
<chew-ie> I'm not so convinced yet  - openanno has very low fps on my system here ... (~ 19; zero has 400 on zombie playground)
<chew-ie> I don't know if that's connected to the db approach - but every method has some drawbacks I'd say...
<dauerflucher> hm, dunno if this is cause by the DBs, but you're right... there's stuff to be cleaned out first
<dauerflucher> might as well be the fucking small tile size we use :S
<chew-ie> ^^
<chew-ie> I did some tests in the meanwhile - loading the player agent with 3 actions only (idle, walk, run = 246 files) causes a RAM usage of 80 on the small map. Adding the zombie with 6 Actions (idle, walk, run, hit, dead, death = 642 files) causes a RAM usage of ~240 MB.
<kaelis> insane
<chew-ie> So if we talk about 3 different animationsets for humans and some critters (zombie, boar) you can get past 1GB with only using "default" animations.
<chew-ie> kaelis, indeed ...
<chew-ie> a map with 3 different visuals of humans and 2-3 types of critter is what I'd call the minimum (for a small map)
<kaelis> indeed!
<kaelis> that sounds like.. massive ram reqs

I'm still somehow puzzled about this - as it also is a kind of a real showstopper for using FIFE in a playable demo (at least with the size we planned it). My first idea about this is to develop and introduce a system that allows the agents to load their animations due to their equipment.

So at map startup all agents only "know" the needed actions like idle, walk and run. If an npc or the pc uses a weapon or an item, he loads the proper animations - (and perhaps deletes the old ones).

Still, the amount of needed RAM in relation with the original file size on the HD seems at least to me way too high.

Any thoughts, comments...?


EDIT

Proposal / statement by spq:

Quote
<spq> anyway chew-ie, the problem is not that the xml file is too long
<spq> thats just a definition
<spq> and that you have so much animations is no problem also
<spq> the thing missing is that images (only images, no animations, animations are just definitions of which image is displayed at which time) can be unloaded and how this can be done automatically
<spq> one could either regulary run a garbage collector or have a good policy when something is to be removed from cache
<spq> an easy but probably resource consuming method would be tagging the resources in the pool, at a given time you mark all resources as not used, then every time a resource is used, you mark the resource as used, and at any time later you unload every image that is not used
<spq> if this behaviour could be controlled by the game that would be really good
<spq> you could free the whole memory by calling those two functions directly, or you could collect needed images and some seconds/frames later remove the unneeded ones from the cache

7
Help and troubleshooting / Building FIFE on Windows 2000
« on: February 12, 2008, 03:14:46 pm »
I dared to install FIFE on Windows 2000 - and failed (of course ^^).

First of all, here is what I've done so far:


So the SDK, Python and a fresh checkout of FIFE itself are present. After executing logbuild_engine.bat I get this log:
[Log] That's all, folks

Any ideas what goes wrong?

Edit:

Barra gave me the hint to use the previous SDK (2007_2_rc4) and to replace swig 1.3.33 in the batch files with swig 1.3.31

Sad to say, but this didn´t help to solve the problem... :-/

Pages: [1]