FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


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.

Messages - jasoka

Pages: [1] 2 3 4
Framework development / Re: Trigger support
« on: March 30, 2008, 05:41:04 am »
For result actions that would take more than a frame, we could have a timer or other thread-launching mechanism.  SWIG can be called parallelly from multiple threads, yeah?

afaik yes, but other than that I would still try keep everything in a single thread. Running things in multiple threads creates new set of requirements, i.e. making potentially lots of code thread safe. Instead of threading, we can split the processing into slices, and run that across multiple frames.

What I had in mind for the study is listing possible cases where triggering is required. Some examples:
- Enemy sees the player. Ability to see is enemy, distance and object size dependent. Seeing through walls is not (normally) possible
- Enemy hears the player. Ability to hear is enemy, distance and volume dependent. Walls affect the hearing range to some extent.
- Agent wanders randomly on the map. Based on smell triggers it finds food. Ability to smell is agent, distance and odor dependent.
- There's jack in the box on the ground, which pops up in case anyone enters it's 1 meter radius.
- ...

Framework development / Re: Trigger support
« on: March 29, 2008, 12:06:42 pm »
yep, in case we encounter performance problems, there are several ways to tackle them (like you mentioned). In any case I would first focus on island demo functionality, and in case we encounter performance problems there, optimize as needed.

Calling from c++ to python via swig results the same kind blocking than any call in plain c++ side. In any case even if we limit trigger amount to one, scripter is able to stall the engine e.g. by creating eternal loop in scripts. With that in mind, I would leave the impact to the scripter, and not limit the amount dynamically.

I agree on listing typical cases for triggers. Perhaps you would like to create a brief analysis about this e.g. into the wiki?

Game creators corner / Re: Graphics Format
« on: March 29, 2008, 08:18:31 am »
I think you can use your existing angles. E.g. if your single direction is in angle of 36.93 degrees, round it to nearest integer (37). Then if you want to have six directions for your characters, just add 60 degrees (360 / 6) to each of your following angles. This results the following angles for you:


That should prolly do the trick.

1) What to say to that. Some good things of FIFE are e.g. infrastructure (wiki, forums, trac, svn, irc channel), generally positive attitude of people, and lots of interested crowd.

2) My worry is not so much about the lack of direction. In my mind the direction is quite clear at the moment, focus being the island demo and 1.0 functionality (see e.g. First estimate tickets to implement this functionality are already written to trac, however their status might not be totally correct. Basically it comes down to the fact that developing even plain 1.0 island demo takes quite amount of time, and there's plenty of boring and tedious tasks to do. Clear improvements would be a) people would invest more time to FIFE, b) tickets would be used more precisely and c) even the boring tasks are taken to completion by people who start them. On the other hand, all these problems are quite understandable for non-paying project which tries to keep doors open to new collaborators  :-\

3) see (1)

Framework development / Re: Networking support
« on: March 19, 2008, 12:12:33 pm »
I was one of the devs raising concern about security side of networking. Basically the concern can be generalized to the networking support as a whole (not just to specific implementation), on the grounds that a) networking related security flaws tend to be quite common and b) they are relatively easy to make (both based just on my personal understanding on the subject).

However having optional networking support in the engine sounds like a good idea, and like jwt stated in the channel, just adding any networking support will probably bring out some flaws to be fixed in the engine logic.

The way I have understood this task is that actual messaging between clients and server is quite trivial to implement (since there is plenty of textbook implementations available for generic messaging). The hard part is to integrate networking transparently and  game type agnostic way into the engine. I would personally appreciate some kind of design document which I could comment on.

Game creators corner / Re: Multilayer pathfinding/blocking
« on: March 19, 2008, 11:54:36 am »
Multilayer path finding has been discussed a few times. Basically the optimal approach would be to inspect all layers in pather based on instance blocking information. At the moment the reason why its not so, is just the way pather is implemented. It was easier to start with one layer only, and future versions can include also other layers. Now we just need somebody to implement that into pather  ;)

Help and troubleshooting / Re: Segfault with latest SVN; Ubuntu 7.10
« on: March 14, 2008, 07:03:06 pm »
looks like there's similar case:

From post:
this behaviour does not occur, when i have version(4.0.2-9) installed on my system.

Framework development / Re: Request for a getTopInstance function
« on: February 20, 2008, 02:33:51 pm »
yes, the instance picking already takes transparency into account, i.e. if you click on instance image's transparent pixel, it wont be returned. However the ordering of returned instances is not currently based on distance or anything, so I need to work on that still a bit more.

The plan is to arrange clicked instances based on distance, and return that list then. We could also implement something like getTopInstance for optimization purposis, after ordering issue is resolved.

Framework development / Re: Playing movies alongside content
« on: February 17, 2008, 04:37:01 pm »
 I would say its reasonable to refresh synchronously, just like with other graphics. We certainly strive to keep framerates over 25fps even on modest system (according to current standards), so video should be smooth enough. Also, it might look even more funny video being smooth while its otherwise slow.

Framework development / Re: MSVC Project File [template]
« on: February 09, 2008, 03:34:38 am »
there should be option in scons to do that; try:
Code: [Select]
scons projectfiles_only=1

Framework development / Re: MSVC Project File [template]
« on: January 31, 2008, 03:54:30 pm »
ok, off it goes then  :)
Like jwt already mentioned, glad to see someone taking a look into msvc support side.

Btw, would it possible to just define some file scan path for msvc (so that files wouldn't be saved at all into project file). Works that way with KDevelop.

adding some markup support sounds like a nice idea. Did you already check the implementation of
Image* FontBase::getAsImageMultiline(const std::string& text) ?

Implementation residing in FontBase should be usable both in guichan widgets and in plain video area (floating texts, coordinates...)

Framework development / Re: MSVC Project File [template]
« on: January 31, 2008, 09:24:33 am »
For question no 1: in case we remove the file from svn, what's the plan for msvc users to update the project files after svn update? In case they run scons manually, don't they get the same conflicts for the file? Also in case two people are using msvc, how they would keep the project files synchronized?

Many things in this thread, I try to address those one by one.

Instance groups:
It could be beneficial to think grouping concept a bit further. I'm a little worried how current definitions expand e.g. in case when we add grouping behavior to editor and want to save those groups. On the other hand, seems that the intention of instancegroup is to add same attribute values to many instances, thus perhaps tag could be renamed e.g. to "commonattribute"

Heightmaps and multilevels in general:
Sounds like an useful feature. On the other hand, even flat surfaces would be hugely useful for plenty of games. Perhaps we could think this feature further after "1.0" release?

Separate classes for different layer types:
Basis for this proposal was different renderers for different layers. Atm the intention has been that renderers themselves would be "pluggable" for layers. That way you would define renderers only (e.g. for grid, coordinates, instances, fow...) and hook those into different layers. Layers themselves are display agnostic, i.e. they don't know how they are rendered, instead view knows this. That should allow us to create many types of visualizations for model data (e.g. 3d/2d)

Pure 3d rendering:
The basis on switching to pure 3d rendering has been that it would avoid z ordering problems. Atm I'm not sure how this would work in case we wouldn't be also using real 3d models (which should prolly be left post 1.0). In case we would be using pure 3d with "flat models", I guess we wouldn't manage to get pixel perfect graphics e.g. for tiles(?). One target for isometric 2d has been to be able to use really exact and detailed graphics. It sounds that we would lose this feature with pure 3d.

Not quite in similar category as other, but it could be a nice thing to have fife mash-up page somewhere. This could collect all rss-feeds available (wiki, forums, svn activity, blog updates, automatic build results, irc activity statistics...), so it would be quite easy to see how active we really are.

Perhaps yahoo pipes or something similar could be used for that.

Pages: [1] 2 3 4