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

Pages: [1]
1
Framework development / Matrix transformation
« on: November 25, 2007, 10:08:28 am »
Okay, let's use forums to clarify the matrix transformation issues. Sleek has some ideas how to improve the code, but the communication via irc seems to be quite difficult (due to time differences). Later when the issue is solved, we can document this thread properly into wiki.


Let's take the basic principles first:

Visible game level (elevation) consist of layers. Layers can be positioned against each other via offsets. They can also contain rotation. Layers are partitioned into cells via cellgrids (each layer contains 1 cellgrid).

Cell related calculations are placed into cellgrids. For different kinds of cells, we have different kinds of cellgrids (e.g. hex, square). You can transform from one layer's coordinate system to another via elevation coordinates, i.e. layer1->elevation->layer2. For graphical representation of cellgrids, see http://wiki.fifengine.net/index.php?title=Model_Design_Documentation. I've been calling calculations that do mentioned transforms as Model transforms.

All model activity (e.g. instance movement) happens in logical space. In principle you can think that this is overhead view from elevation's layers. There is no camera concepts involved (i.e. pather doesn't even know that there is camera). View module contains visualizations for our pseudo-3d looks (isometric with 3d calculations). This is just one way to visualize the model data, and might be later supplemented with other types of views (e.g. full 3d or nethack character type). The way stuff is shown on screen is calculated in view. Elevation coordinate <-> screen coordinate transforms (matrix calculations) reside in camera. I've been calling these as view transforms.

Video module doesn't know anything about view stuff; it only renders images on flat surface (meaning it cannot display proper 3d atm). Even OpenGL backend renders just images on flat surface.



Now, Sleek had some questions, picked from channel (my interpretation):

Q1: Camera transforms seem to be model transforms. Why is that?
A1: Like stated above, my current terminology for these is mostly related on code/module placement. In case of mathematical point of view, that might be the case indeed, however I'm still not sure what exactly that would result in the code. Code snippet to illustrate this would be appreciated.

Q2: Is rotation left or right handed?
A2: Rotation is meant to follow polar coordinates (http://en.wikipedia.org/wiki/Polar_coordinates), i.e. rotation goes counterclockwise. In case there is some code that doesn't implement this, it very well might be a bug.

Q3: Why view does zooming when camera is rotated?
A3: View calculates reference scale on camera updates. Reference scale is used to calculate grid dimensions based on given cell width/height (usually tile image dimensions). When grid is rotated, also the size of cell bounding box changes. This causes zoom pumping.

My guesses of possible bug points:
  • Cellgrid transforms. These convert from layer to elevation. Functionality is verified with unit tests, but there might be some holes. In case I've unintentionally placed clockwise rotation there, it should be fixed. However before making the corrections, please make sure that it really is incorrect e.g. by observing the demo behavior.
  • Camera matrix transforms. This has been tweaked already many times, might still contain some bugs.
  • Camera reference scale caculations. Incorrect pumping functionality seems to disappear when I removed matrix inversion. Perhaps this matrix/inverse matrix stuff was changed with latest matrix tweaks but this was not?
  • Pather facing direction calculations. Currently agent seems to moonwalk. This naturally might be due to incorrect facing direction information coming from pather.
  • Instance renderer contains code how instances are drawn on screen. It also calculates angles between current location and facing direction. Sounds like a possible bug point.


Hopefully these things help with clarifying the code. I have no illusions that current code would be bug free from any point :) Therefore just be critical on things that you see. In case of unclarities, please use the forums. It also helps a lot to give concrete code examples what one would like to change. Also textual reasoning for changes is usually helpful to explain what one really means.

Also in case of changes to codebase, let's try to focus on one thing at the time. There's many spots that need to be improved in the engine, however if we do those all in single commit, tracking them gets hairy.
In case it feels that there are need for drastic changes to fix the view, branch might be appropriate. Before that however, I would like to hear the plan what would be changed and why.

2
Hi all,

Techdemo starts to be in such shape, that it gives a first glimpse of possible engine scripting APIs: https://mirror1.cvsdude.com/trac/fife/engine/browser/trunk/techdemo.py?rev=1733. At this point of time it could be a good opportunity to stop and think for a while where we want to go with this. Even though the current python code is quite readable (personal opinion), we clearly could do better. To prove this, I tried to write  the logic of techdemo in more fluent way using more pythonic idioms. The result can be seen here: http://pastebin.com/fb9e00c0.

As you probably guessed, the code cannot be executed at the moment due to heavy api changes. Therefore there's naturally also some bugs & typos there. Anyway I hope it makes my thoughts clear, and you agree that a) code amount is much smaller. b) it is easier to understand and c) it contains the same functionality.

The problem with the example is that such functionality is hard or even impossible to reach with plain swig interfaces. Therefore I propose that we should consider the possibility of writing still another wrapper layer on top of most of the swig apis with scripting languages (meaning the extension layer, see http://wiki.fifengine.net/index.php?title=Architecture_Documentation#High_Level_Layering)

Another point with scripting apis is documentation. Despite of my search, I haven't (at least yet) found any good way to auto-generate documentation from swig interface files. Furthermore if we write extensions on top of that, we should be able to mix their documentation with the documentation from swig generated interfaces. Properly documented apis are probably one of the most important factors when thinking about possible adoption of fife for game development purposes.

On top of that we still have engine memory management issues. I have written a wiki article pointing some of the problem aspects: http://wiki.fifengine.net/index.php?title=Engine_Memory_Management. Any comments on that area are more than welcome.

With previous points + techdemo example in mind, I would like to point out the following:
  • The need for extension wrapping increases along with the need for more fluent interfaces
  • Generating documentation for plain python interfaces is easy, see e.g. epydoc http://epydoc.sourceforge.net/
  • Combination of some consistent memory management strategy AND extension layer on top of SWIG interfaces would probably give us the best alternative to provide clean memory management design for games using FIFE
  • Extension wrapping would give us additional buffer to keep our APIs, after we have stabilized them a bit
  • Wrapping would also add our code amount and make it harder to port fife to other scripting languages  :-[

Despite the last bullet, my current feeling is that we should really look into our scripting apis at this point of development and increase the size of extensions. I would also like to hide most of the plain swig interfaces from games, and provide properly documented and easy to use alternatives to them from extension layer.

Any thoughts?



Pages: [1]