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 - jwt

Pages: [1] 2
Framework development / Re: June developer meeting
« on: June 02, 2009, 09:04:12 am »
I'll do my best to make the June meeting. The only date I absolutely cannot do is June 7th.

Framework development / Re: Guichan Upgrade
« on: July 06, 2008, 12:36:05 pm »
One major thing to note: the upgrade seems to have messed with the event consumption logic. For an example, try clicking the About button in rio_de_hola: the about box opens, but the character also goes to the clicked position. More seriously, the right click menu doesn't work at all (clicks go right though to the ground and never get registered by the gui).

I haven't really been a big contributor to the guichan/eventchannel/pychan toolchain, so I don't really know where to start tracking this down. Phoku, if you could have a look at this, I'd appreciate it.

Framework development / Re: Guichan Upgrade
« on: June 29, 2008, 10:32:56 am »
Sorry it took so long for me to weigh in on this. Anyway, apart from some minor permissions issues (fixed) everything looks good here. Thanks!

Introduce yourself / Re: Hello friends!
« on: May 20, 2008, 05:08:23 pm »
Hey m64. Glad to have you with us. We hang out in our irc channel most of the time (#fife on quakenet). Feel free to stop in there and say hello.

Glad to hear you got it working!

Help and troubleshooting / Re: Can't run editor
« on: April 19, 2008, 12:29:51 pm »
Sorry for such a late answer. I believe the current "release" version of fife is intended to work with python 2.4. However, the next release (and current svn) only works with python 2.5.

Framework development / Re: libpng for linux devs
« on: April 19, 2008, 09:22:11 am »
Works here!

Ok, longest forum post ever: is FIFE is suitable for JA2.

The most important question--and one that I can't answer--is whether FIFE could be reasonably integrated with the JA2 codebase. I suspect this might be very complicated. If you're looking for a few "quick fixes" to make JA2 look better, then it would almost certainly be easier to just hack the existing JA2 code.

As those of you who have browsed FIFE's code have probably realized, FIFE is not just a rendering engine. It also does audio, events, scene management, pathfinding, provides a scripting environment, xml resource formats, editing tools, and much, much more. In short, it aims to be a complete toolset for making games.

As near as I can tell, you are looking for just a rendering engine that can be plugged into the backend of JA2. FIFE's rendering engine is housed in the Video and View modules.

The good news is that FIFE is very modular, and these 2 modules can certainly be separated from the rest of FIFE (you would need to make some adjustments to View, since it "views" our Model module, and you would need to make it View JA2's internal representation of game data).

But FIFE doesn't have a particularly "fancy" rendering engine. Our renderer is a flexible, extensible, adequate platform on which the rest of FIFE can rest. It's certainly better than JA2's current engine, but based on some of the questions that have been asked, it seems that your looking for something really "cutting edge" in the graphics department. Creating a cutting-edge rendering engine is not FIFE's goal. I don't know if such a cutting edge 2d rendering engine exists. If it does, it might be a better fit for you than FIFE.

As to the technical questions:

FIFE uses SDL surfaces or OpenGL textures. Is there a performance difference between these modes? I suppose the SDL surfaces are in software mode. Have you experienced any trouble switching from software mode (SDL) to hardware mode (OpenGL), like running out of video memory (on smaller graphics boards)?

In an accelerated environment, OpenGL will typically give much better performance than SDL. Both implementations currently support an identical feature set, so switching between the two is purely a matter of performance. The renderer must be chosen at launch; it cannot be changed "on the fly" during game play.

I suppose the SDL and OpenGL implementations are supposed to be interchangeable. Thus you use only the very basic capabilities of OpenGL (i refer especially to OpenGL's immediate mode). Have you thought about using newer stuff
that may increase performance (if there is a performance issue at all), or is it impossible, because you would give up compatibility between SDL and OpenGL?

OpenGL optimization would desirable, but we don't have an OpenGL guru on the team. The OpenGL backend hasn't been worked on much since it was first written (a couple years ago). A new guy recently joined the team who expressed some interest in the OpenGL code though, so we might see more work on that front soon.

You always use rgba textures, right? Do you support palettes or is it something that the user code has to deal with?

Palettes aren't in yet, but they're on my personal short list of tasks. A game currently being developed with FIFE has requested this, and it's clearly a very important feature for many games.

I'm asking this, because JA2 uses only palettized images. There is a huge amount of these images and they are usually very small. So, using OpenGL, we would have a LOT of textures and always switching between them (binding) could have a negative impact on performance. In your example projects/techdemos, how many object are you drawing (in average) per frame? How large are these objects/images in average?

Probably the best way to answer these questions is to fire up FIFE and test it out for yourself. FIFE has fine performance in the situations we have encountered so far. I have no doubt that if performance becomes a problem, we can find ways to substantially improve it.

A way to get out of this binding hell is to use texture atlases, but FIFE doesn't support textures atlases, right? Looking into the code, i suppose it would be possible if there were some access to texture coordinates from outside the GLImage::render method.

Texture atlas behavior may be possible using our SubImage code. I'd have to take a closer look.

Does FIFE support any kind of lighting or shading, or is it again somthing for the user code? FIFE does not support multitexturing (shader programs). Is it planned to support multitexturing (shader programs) anytime in the future?

Not at this time. This might change if a developer joins the team who's interested in working on OpenGL magic, but is not part of any current plans.

How is visibility/draw order of objects determined? Does the user has to do it? Is there any kind of Z-Buffer support?

Z-order is handled by the engine, and is determined by the location of instances in relation to the Camera. It fails for pathologically shaped objects, but I think this is true for most 2d engines. Such objects can be handled by judicious splitting into multiple smaller ones. I don't know how pathological JA2 objects can be, but I doubt the JA2 team had more sophisticated z-ordering algorithms than us, so existing JA2 data should be ok.

Let me know if you have any more questions.

Framework development / Re: Trigger support
« on: April 03, 2008, 08:01:39 am »
I can think of at least several "generic" preconditions that many triggers might need to satisfy: distance check (and more generally, model change), time check, input check (mouse, keyboard event). I'm sure there are others; maybe people can think of additions for this list.

Anyway, many of these checks should be pretty quick to do: input and time should take almost no time, and model change is being worked on.

Of course, the scripter can always make more detailed "game-specific" checks in their code that allow the trigger to bail out early.

I think the right analogy here is to "clipping" in 3d rendering. We want to clip as many events as possible, with minimal processing, before making an expensive call to python.

Some data that might be helpful to this discussion is exactly how expensive the c++ to python context switch is. That will be important in determining how much we need to fine-tune engine-side trigger clipping.

Framework development / Re: VFS restructure
« on: March 15, 2008, 11:00:18 pm »
Linker errors are resolved; it was a settings issue with ld that I should have noticed. Anyway, island demo is working fine now. Editor is broken (it looks like it just hasn't been updated to the new api). Also, a few tests are broken (memory access violations). Let me know if that's unexpected and if you need more info.

Great work by the way; seems like physfs will substantially reduce our codebase!

Framework development / Re: VFS restructure
« on: March 15, 2008, 12:35:33 pm »
Hi, I seem to be getting errors under ubuntu linux with physfs 1.1.1:

Compilation of main program succeeds, but when I try to run island demo it fails at startup with this:

ImportError: engine/swigwrappers/python/ undefined symbol: PHYSFS_close

Compiling tests fails with this:

engine/ undefined reference to `PHYSFS_getLastError'
engine/ undefined reference to `PHYSFS_exists'
engine/ undefined reference to `PHYSFS_freeList'
engine/ undefined reference to `PHYSFS_deinit'
engine/ undefined reference to `PHYSFS_fileLength'
engine/ undefined reference to `PHYSFS_init'
engine/ undefined reference to `PHYSFS_seek'
engine/ undefined reference to `PHYSFS_mount'
engine/ undefined reference to `PHYSFS_tell'
engine/ undefined reference to `PHYSFS_close'
engine/ undefined reference to `PHYSFS_enumerateFiles'
engine/ undefined reference to `PHYSFS_removeFromSearchPath'
engine/ undefined reference to `PHYSFS_read'
engine/ undefined reference to `PHYSFS_openRead'
engine/ undefined reference to `PHYSFS_isDirectory'
collect2: ld returned 1 exit status

It seems that the linker can't find physfs, but I have it installed (/usr/local/lib, /usr/local/include). I've also tried manually installing to ext/install; no luck.

Framework development / Re: PyChan Feedback
« on: February 05, 2008, 09:19:34 am »
Another bug.

Create a ListBox. Map an event to it. In the event function, hide the widget the listbox is part of (possibly this works just hiding the listbox itself). Clicking on the listbox will cause a crash, throwing a gcn::Exception.

Framework development / Re: MSVC Project File [template]
« on: January 31, 2008, 12:12:47 pm »
Joshdan, these all look like great changes. Improving the MSVC project files may also help us attract new developers and users in the windows world.

Framework development / Re: PyChan Feedback
« on: January 31, 2008, 12:08:01 pm »
I've got a bug report for you.

In the pychan_test client, if I scroll to the bottom of the contributors list in the redzone style the client crashes with a segfault. Happy debugging :)

Framework development / Re: PyChan Feedback
« on: January 23, 2008, 02:18:08 pm »
One more for the wishlist: real menus. :)

Pages: [1] 2