Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

1

Framework development / Re: Trac ticket #351: non-standard rpaths

« on: September 28, 2009, 01:48:04 am »

This is it prock. What rpath does is add the given path to the parameter to dynamic library search path. If you have a patched dynamic library, most probably you have not added it to ld.conf, and hence it's not in the search path. I am afraid LD_LIBRARY_PATH is available to Linux/*nix only. It would not work on Windows, for example.

2

Framework development / Re: Trac ticket #351: non-standard rpaths

« on: September 27, 2009, 08:30:14 pm »

Hi everyone.

As far as I remember it, ext/install/lib contains the dynamic libraries that are external to but depended on by FIFE. E.g. OpenGL, guichan, SDL and such. Also, as far as I know this rpath need is specific to Windows-case. The SConscript file still applies the rpath under linux, but probably ld.conf takes precedence there.

I can't remember it very well, but I think...  I/We were trying to get the executable to run on Windows based on the SDK that barra prepared. The directory structure of that SDK was in that manner, and there were discussions on having a better directory structure, but I guess we never got to a conclusion on that.

So it's possible to remove the rpath, but on Windows, we will have to move all the .dlls to the same directory as the executable.

3

General discussion / Re: Fife Coder meeting with the OpenAnno and Zero Procjet Coders

« on: February 19, 2009, 07:11:56 am »

I am going offshore on the 25th. Don't know whether I will have easy access to internet or not by 28th. In any case I'll be checking the logs. These are my concerns that I would like to discuss on :


- Improving the renderer - discuss on a code design that makes it easy for people to write their own rendering path. Discuss our default rendering paths : E.g. Texture atlas will only be used together with OpenGL. Only SDL needs Dirty Rect implementation. SDL doesn't and should not know what vertex array is. The important point is that different rendering paths has a system-wide impact: Texture Atlas needs different image loading mechanism. Dirty Rect needs it's own Quad Tree for collision/overlaph detection.

- Map Editor - Bring up all features that we want in the map editor, and classify into must-haves ( Save as ), nice-to-haves ( a tool to offset instances with varying sensitivity - 0.1, 1.0, 10.0 coord unit with arrow keys ), and others. It would be best if we can get info from Zero and OpenAnno on their mapping workflow to have an idea of all the crucial tasks. Make and review proper mock ups of Map Editor UI, with descriptions of how one would achieve a simple task.


IMHO we should list down in detail what ( features ) we want to include in the project so that we have a target and motivation to continue working . It would also be efficient if we could specify a priority feature to work on for a specific time. Most functionalities depend on another, so there should also be a workflow diagram that shows the bigger picture of FIFE development plan ( I volunteer to maintain this if we agree ). People can still work on what they want, but at least they are aware that some planned things will need to wait.

4

General discussion / Re: Fife Coder meeting with the OpenAnno and Zero Procjet Coders

« on: February 09, 2009, 06:27:31 pm »

It's okay as long as it's weekend and I don't have work the next day ( Friday /  Saturday ).

5

General discussion / Re: Fife Coder meeting with the OpenAnno and Zero Procjet Coders

« on: February 04, 2009, 12:07:07 am »

That would be at 4 am here :S

I can't attend on that time sorry. and the date is 01.03. Is it over already ? Why not have it in the weekend ? I don't mind staying up then.

6

Framework development / Re: C++ interface

« on: February 02, 2009, 02:35:06 am »

Dzverot, care to come by our IRC channel ?

#fife @ QuakeNet

I'll try to get on around 12:00 noon GMT

7

Introduce yourself / Re: Interested in contributing to FIFE engine

« on: February 02, 2009, 02:28:08 am »

Come by the IRC channel and stick around. If we see newcomers we'll usually initiate a conversation

#fife @ quakenet ( irc.quakenet.org )

I'll be there around 12:00 noon GMT.

8

Framework development / Re: SWIG Takes A Very Long Time To Compile [proposal]

« on: January 23, 2009, 10:47:44 pm »

I believe the reason for the long build time is the large monolithic produced code, instead of the amount of input files. Thus, this probably will not do it for FIFE. But let's give it a try

9

Framework development / Re: C++ interface

« on: January 23, 2009, 04:46:00 pm »

Dzverot,

How advanced are you with C++ ?

Last time I used gcc and auto-exported all symbols, so I can use fife.dll directly without any major changes.

But the proper thing to do is explained here : http://mirror1.cvsdude.com/trac/fife/engine/ticket/330 . Perhaps you can help us with that ?

I had a basic maploader in C++, it was fun for a while, for the loading speed. But the code was 90% ported from our python maploader. For me, it's easier and faster to use python for prototyping your game. It has native support for more than basic data structures, and it doesn't need recompilation. Advantage of C++ is speed.

If you are just playing around with FIFE and C++, without production code ( haha I wish ), static or dynamic doesn't matter. If you don't distribute your game, you don't have to publish your source code. And if you do want to distribute it, should be no problem disclosing the source since it's a play-test code right ? You stated that you have had no experience in game development, so I think you would need to show your code to people for advice quite a bit.

I advise you to learn python if you have no idea what it is, it's worth it

10

General discussion / Re: New irc channel logging bot

« on: January 12, 2009, 04:42:32 am »

Wheeeeee !!!

If I manage to set some time for FIFE core code I am sure to come back later

11

Help and troubleshooting / Re: Segfault in __cxa_allocate_exception

« on: July 29, 2008, 04:04:55 am »

Sure, I could make it part of svn. However the tests are only for eliminating possible causes of the problem one by one, so I'm not sure if we want the test programs to stay when we have solved this issue. We can just delete them later though so it's probably a good idea.

I'm quite busy right now since I'm taking over operation job in Islamabad, and I also have to renew my visa. So I'll do it when I have the time, or someone can commit it if he can understand what the additional code/script does.

12

Help and troubleshooting / Re: Segfault in __cxa_allocate_exception

« on: July 20, 2008, 10:56:29 pm »

http://mirror1.cvsdude.com/trac/fife/engine/attachment/ticket/297/Exception_tests.4.zip

Please unzip that in the FIFE/tests folder, follow the instruction and run the tests. Describe the result to me

13

Framework development / Re: from instance loading to display

« on: July 20, 2008, 08:58:41 am »

http://forums.fifengine.net/index.php?action=dlattach;topic=167.0;attach=23

Here you go. A simple demo I made. No gameplay yet, but you can read the code how to at least get those Instances on the screen. There is no Action or ActionVisual in this one.. just static instances.

14

General discussion / Re: A new name for FIFE

« on: July 20, 2008, 02:32:06 am »

However, our engine isn't limited to 2D, at least in the future

15

Framework development / SWIG Takes A Very Long Time To Compile [proposal]

« on: July 19, 2008, 07:34:09 am »

As you all know, SWIG takes a very long time to compile. I think it's because of the memory, but upgrading isn'nt everyone's option. The main problem is we are compiling a very big source file : fife_wrap.cxx. So I went to the swig-user mailing list and asked :

Hi everyone,

I'm Sleek, from FIFE ( www.fifengine.net ). We use swig c++ - python to allow easy modding of the game engine. However, the resultant fife_wrap.cxx is really massive.. close to 3.5 MB last time I checked. This is not so much of a problem, until we try to modify the interface files and recompile the swig wrapper. Currently, this is what we have :


swig -c++ -python *some other options I don't remember*  $path/fife.i  -> fife_wrap.cxx


What we need, is something like :

swig -c++ -python -noheader view.i    -> fife_viewwrapper.cxx
swig -c++ -python -noheader model.i    -> fife_modelwrapper.cxx
swig -c++ -python -noheader map.i    -> fife_mapwrapper.cxx
swig -c++ -python -noheader layer.i    -> fife_layerwrapper.cxx

So if any changes occurs in one of the interface files, only it's .cxx wrapper will be produced. This avoids recompiling the whole thing and saves a lot of time & processing cycles. What do you think ?


On another note, we are experiencing this bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364907 on random systems. I'm not sure which libstdc++6 version is involved, or whether there is something the swig developers can do about it. But hey, congratulations for a great masterpiece. SWIG rocks !

And someone replied:

I think you can simply divide the huge module into several smaller module, for example,

view.i -> fife/view.pyd
model.i -> fife/model.pyd
...

and then in Python you can:

import fife.view
import fife.model

is that reasonable?

Best regards,

Haoyu Bai
7/19/2008

Which sounds very reasonable. Why not ? Anyone see why not ? Otherwise let's do this ! I'll have a test on my system when I have the time. Cheers all.