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 / 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.

2

Game creators corner / A demo for you

« on: July 19, 2008, 03:35:01 am »

Here's a python client of a simple game. I'll let you discover what the game is. The game rules is not implemented yet, and it's by no means complete. Instruction is in the Readme.

Rename demo.png to demo.zip, and unzip into your FIFE/clients folder.

p/s: You will need the latest rev : 2549.

3

Framework development / Improving the renderer

« on: June 08, 2008, 01:37:27 am »

I think we can improve the  renderer a lot. Think about 500fps at no movement at all, and 200fps for 2 moving instances across the screen, in SDL. I've tested this with my usual hackery and it is achievable. The problem now is how to implement it properly, with a dirtyrectlist, and for multiple cameras on the screen.

So.. here is what I plan:

- Add a default InstanceChangedListener for instances. When an instance is changed, the onChangedListener receives the instance, compare it's dimension/rect with a list of camera and see if it's in the viewport. If it's, the rect  is push_backed into the (*cam_iter)->dirtyrectlist. If more than one cameras show an instance, the instance is push_backed once for each camera.

- DirtyRectList is a class that contains a list of dirtyrect. When a new rect is push_backed, the rect is compared with each existing rect. If any one can be merged, it will be. We need to optimize this of course.

- Add a CameraChangedListener... When the camera is rotated, or moved.. , a rect with the dimension of the camera's viewport is push_backed into it's own dirtyrectlist. Possibly we can make that quick by clearing the dirtyrectlist so it doesn't need to merge anything.

- Modify Camera::render. This function should no longer collect all visible instances to be drawn. Instead.. it collects all instances that is contained by any rects available in dirtyrectlist.. and calls the renderers. All it has to do is something like ScreenQuadTree.getInstances( dirtyrect1 ), and that to the list. We still sort the instances here.

- InstanceRenderer renders the instance like usual..

- RendererBackend updates only the dirtyrect region.

Code: [Select]

while( dirtyrect_iter != dirtyrectlist.end()){
SDL_UpdateRect(surface, rect.x, rect.y, rect.w,rect.h)
dirtyrect_iter++
}

Please comment.

4

Framework development / To layer or not to layer, and height maps ( Model review )

« on: January 20, 2008, 07:39:56 pm »

There were some discussions on the IRC on how to solve the current z-order problems. There are several aspects to this and here I try to elaborate a bit on my thoughts on it.

==When to use layers==

Layers are mainly used for

1) Positioning instances ( x,y - by cells )
2) Grouping instances into one rendering iteration ( z - by layer )

For a normal RPG games like fallout and island_demo, I believe we can divide the layers category into the following list :

 - fog of war ( top )
 - sky
 - roof
 - instances/walls/blockers
- items layer !
 - ground tiles ( bottom )

Note that each category doesn't represent one layer, but can be divided into several layers. As suggested by jasoka, the quays in the island_demo map should be moved into a separate layer. While I resisted the suggestion for a while, I guess it's a valid idea after all. The quay will always be under everything else, but above terrain tiles, so both could be grouped into 'ground' layers category.

Recently an instance grouping tag was introduced into the map format. This allows us to set a property to a group of instances at once, emulating a layer. However, instance grouping will use the existing layer's cellgrid for x,y positioning. Thus, the subtle factor to look at when choosing between a layer and an instance group is whether a new positioning system is required.

Earlier I suggested a z-offset solution. My argument was: I would imagine if we walk over the quays, the PC should get lifted a bit upward. The method I would do this is by  PC.setZ( Quay.getZOffset( ) ). If we were to move the quays into the 'ground' layer instead of using offsets, this information would be 'flattened' and we couldn't do the above anymore. I guess this argument is invalid, since we can still do something like PC.setZ( QuayLayer.getHeight( PC.getX(), PC.getY() ) )  ( Yes, I am talking about a to-be-implemented height map here  ).

==Heightmaps and stairs==

To extend to the idea, imagine stairs leading from a lower elevation to a higher one. The higher elevation would represent the 2nd floor of a multi-storeyed building. Now the stairs would exist in the object layer, with the height increasing as we approach the top of the stairs. Once the PC reaches the top area of the stairs, we load the 2nd elevation and switch to that elevation.


==Terrain tile transition, fog of war, etc==

Because there is a possibility that we want to render each layer differently, I suggest that we inherit a class for each layer that we want to use, e.g. TileLayer, FOWlayer. Another method would be to set a layer's custom rendering function at initialization.

5

Framework development / FIFE engine profile

« on: January 12, 2008, 11:48:48 am »

Here I attach a profile of our engine. Note that this is not pure svn,containing my view changes. Also, the engine is ran by a C++ client, and the map loaded is island_demo. The map was zoomed out, and then translated up-down & left-right a bit. Below is the top 3 most expensive functions :

Code: [Select]

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name   
 53.33      0.08     0.08        2    40.00    40.00  FIFE::PointType3D<double>::PointType3D(double, double, double)
 13.33      0.10     0.02     1378     0.01     0.01  FIFE::PointType3D<int>::PointType3D(int, int, int)
 13.33      0.12     0.02                             __i686.get_pc_thunk.bx

Full profile here

6

Framework development / View module design docs & patches

« on: January 08, 2008, 08:15:24 pm »

After quite a while of meddling with the view code, I believe I have come to an understanding of most of it's working. I made a few changes here and there, and as there is not really any specs/standard specified in the wiki, I chose arbitrarily ( and slightly taking the original code in mind ) a number of key designs.

Here are the patches:

all.diff


(Updated on 16th Jan 2008, 2pm GMT)



It's by no means a clean patch for commit action, but let's look at it & review early. I'll post better versions from time to time. Also see the bottom of this post for other patches.

Changes :
#1 - transformation matrices ( load, apply, multiply & actual application in camera.cpp )
The original code seems to apply matrix transformation in an inverse way. The usual method of applying transformation is :

Code: [Select]

M = Transformation Matrix
P = Point(coordinate) in 3D space
P' = Transformed coordinate

P' = M x P
In the old codebase, it's P' = Minverse x P. I still am not sure if the original coder meant to transform the camera instead of the model, n. If this is true, I am happy to revert my changes to Camera::updateMatrices.

And just FYI, if R= Rotate Matrix, T= Tilt Matrix, Tr= Translate Matrix,
a sequence of rotation->translate->tilt is represented by the formula below:

Code: [Select]

M= T x Tr x R  // Rotation first, Tilt last
#2 - copy constructor to convert between Matrix<int> & Matrix<double>
This is simply a way to do Matrix<double/int> m1( Matrix<int/double> m2 ). I might implement this also for PointType2D<int/double> & PointType3D<int/double>.

#3 - how transformation is applied in toLayerCoordinates/toExactLayerCoordinates & toElevationCoordinates
See #1. This is simply a reversal from P' = Minverse x P to P' = M x P

#4 - moved out ScreenPoint -> ElevationCoordinate conversion into python script instead
Will comment later on this one.

#5 - cellgrid's transformation sequence
I am not sure about this one yet. There are multiple ways to do it and it doesn't really matter. It will affect how mappers align their cellgrids though. We should go for the most intuitive sequence ( as viewed in the editor ).

#6 - text colour for CoordinateRenderer
Changed to white. It's easier for me to see it in dark/colourful maps.

#7 - getAngleBetween in InstanceRenderer
Will comment on this after further testing & comparison

#8 - moved function definition from camera.h to camera.cpp
For faster compilation if any changes are made to the functions. This is also the right thing to do.

#9 - updateReferenceScale in camera.cpp
The camera.reference_scale variable affects how 'zoomed' our map is. It's a totally different variable compared to the camera.zoom variable. Basically, it allows us to specify at zoom=Z, we want this object to be this big. I thought of several ways this can be useful for game devs. He might want to specify how many grids should appear across the screen width. He could also mean that at zoom=1, 10 pixels should equal to 2cm on the screen.  I am hoping to get it to work so that our objects appear of the constant size across all resolutions. This is not really important. The current code by jasoka works as well. The bouncing effect is not to be worried about.

#10 - added a number of checks for invalid pointers in various functions
For added security