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

Pages: [1] 2
1
Framework development / What about triggers?
« on: March 25, 2013, 07:35:30 am »
Many of you heard me ranting about this last week.  I'm thinking about starting on a trigger system and am putting some thought into it's design.  First I'd like to get some input from you guys.  In order to design a trigger system we have to agree on the definition of a trigger.  What comes to mind for me is something like this:   A trigger is something that waits for a particular event or set of conditions to be met and reports it to the system.  By "reports it to the system" I'm referring to the active listeners that are listening for the trigger to report (yes we should probably conform to our current observer pattern standards).

This of course is a pretty broad definition of a trigger compared to what I was thinking before.  Initially I was thinking a trigger could only listen for particular instance/cell interactions, like when an instance enters/exits a cell.  Now I think by keeping a broader definition of a trigger in mind it might keep the design a bit more flexible.

Here are some ideas I have for requirements of the trigger system:
  • Conform to the observer pattern
  • Allow client definable triggers/trigger types
  • System can be disabled (save on a bit of overhead if they are not required)
  • Trigger type that reacts to a instance+cell interaction messages
  • A single trigger can watch an arbitrary set of cells
  • A single trigger can watch an area of cells
  • Cell interaction triggers can move (perhaps be attached to an instance/object and move along with it)
  • Trigger type that reacts to an instance being changed (moved, removed from layer, etc etc)

Thats all I have for now.  Thoughts?


2
Framework development / Fog of War issues on Mac
« on: March 24, 2013, 08:51:18 pm »
Hi all,

I just got FIFE compiled on my macbook (osx 10.7.5).  I installed all latest versions of the pre-requisites from source (including boost, swig, and SDL).  I should note that I needed to turn off the frame buffer and non power of 2 textures to get any sort of performance.  I recorded a quick video of the issue I'm having with Fog of War.  You'll see when I turn on Fog of War and where I click around the map.  Pay attention to the girl in the top left camera.  She appears to hold still for a second before actually moving.

http://www.youtube.com/watch?v=mU6S7XTX88I

Is anyone else experiencing this on Mac?  Or any other OS for that matter.

3
Framework development / GSoC 2013 - Ideas needed
« on: March 21, 2013, 09:03:15 am »
Wow time has been flying.  We need some ideas for GSoC 2013.

GSoC 2013 Timeline: https://github.com/unknown-horizons/unknown-horizons/wiki/timeline-2013
Ideas: https://github.com/unknown-horizons/unknown-horizons/wiki/Ideas-2013

Some ideas I've been tossing around are:

  • Split up the fife python module into multiple modules (much like vdaras did for fifechan)
  • Tools - editor needs some love, atlas creator should be re-written as a plugin to the editor, etc etc
  • Website needs an overhaul (probably not a good GSoC task but just throwing it out there.  Could potentially be a bunch of code)
  • New C++ sound manager - this was on the list for last year
  • More guichan/pychan improvements - still a lot of bugs in the tracker for pychan, maybe a WYSIWYG editor?
  • Trigger system - Could work with the new cell cache code helios has done to provide a descent trigger implementation (need to integrate with the editor).
  • New file format - I know helios had started something here... not sure where he is at.  In any case it would be great to complete the C++ loaders/savers with the new file format.

Anything to add to the list?  We need to get these posted in the next few days!!!

4
Framework development / Move to GitHub
« on: March 13, 2013, 08:52:23 am »
Quick FYI to all.   I have completed moving the SVN repo to GitHub and all the Trac issues/tickets to GitHub issues.  Check it out here: https://github.com/fifengine/fifengine.  Please check it out and let me know if I messed anything up.   Unfortunately I was unable to keep the original authors+dates for the Trac tickets so they all appear to be created yesterday by me.  I added some date stamps to the comments which should suffice.  Also, I was unable to keep ticket attachments because github doesn't support it.  It's a feature I never really made much use of but I'm sure will be missed to an extent.  We'll have to provide another procedure to link to files to somewhat retain that functionality.  I haven't really put much thought into it yet.

Please officially stop using Trac and SVN.  Any work that you have done locally should be made into a patch and applied to a branch in the git repo.  We have some learning to do about git but I encourage you to explore git branches!  See you all in IRC!  I'll be posting an official announcement shortly as well as updating all of our links that point to CloudForge (svn and trac service).

5
Framework development / FIFE Wiki Updates and Usage
« on: June 02, 2012, 09:51:06 pm »
FYI to all... I have finished round 2 of the Wiki cleanup.  As you all may know I have cleaned the Wiki once before already a while back.  This time I know a little bit more about Mediawiki and decided to create some archive categories and move old wiki documents into there for reference.

I'd like everyone to start using categories and sub-categories on the Wiki whenever possible (if you dont already..  most of us already do).  We already have a good set of categories on the Wiki so be sure you add your document to one of them.  If it doesn't fit into any of those categories be sure to create a new one for your document.  Also try and make use of sub-categories.

Next on the list is to clean up a few document names and fixing the links to them.  After that I'd like to start getting the main documents reviewed and start updating them on a regular basis.  The idea being that any page linked directly or indirectly from the Main page should alway be up to date.  This way clients (or potential new clients) will always trust that the documents are up to date.

As I'm typing this I kindof had a thought that we could put all documents into a category named after the release.  Every release we would make a copy of all sub documents ( I think I could automate this ) and create a new category for that release.  This way old versions of the documents can still be referenced by clients.   Not sure if this is a good idea.  I think that a versioned FIFE manual may be the way to go.  The FIFE wiki should probably be reserved for FIFE developers to hammer out ideas and other things.  /endbraindump

Thoughts?

6
Framework development / Finalizing the C++ Coding Standards
« on: May 29, 2012, 01:32:11 pm »
Hi all,

I'm currently working on finalizing the C++ coding standards I've been talking about in IRC the past few days.   Here is what I have so far:  http://wiki.fifengine.net/New_Coding_Standards

Some of the standards we currently use in FIFE have not really be followed and we have a mash of different standards.  Using the old standards document I tried to sum the up what I think the standards are the best I could.

There are a couple outstanding questions in my mind as far as standards go:
  • variable names -  currently is a mash between lowercase, camelcase.. etc etc.  We need to finalize our standard here.
  • qualifying variable scope - we use m_ for members.  Did we want to change that?  What about adding some more?
  • abbreviations and acronyms - we currently use a mixture of class/type names that capitalize abbreviations and acronyms.  I did some searching online and some suggest that when you use an abbreviation or acronym that is 2 characters long, put them all in caps and when the acronym is longer then 2 char's, use a capital for the first character.
  • typedefs - We use a mixture of a lot of different standards here like:  SomeType_t, SomeType, sometime_t, uint32_t....   What should we do here?

What are you guys thoughts?


7
Framework development / Guichan/Pychan and licensing fifechan
« on: May 23, 2012, 10:46:32 am »
Because it's difficult to get everyone in #fife at the same time I thought it best to post a topic here regarding the future of Guichan/Fifechan.  As you may know we have decided to fork guichan into a new project called fifechan.  Because guichan is licensed using a 3 clause modified BSD license we are allowed to do so.  We can re-license it but the original license/copyright must stay intact.  I believe it is safe to keep the original guichan header in all source files and add a new "fifechan" header.  The question is what license do we want to use?  I understand that the license that Guichan uses is compatible with LGPL so we could license the code using LGPL since this is what FIFE uses.   Any thoughts/ideas regarding this?

http://stackoverflow.com/questions/10004867/bsd-license-how-to-manage-attribution-and-project-name-in-a-fork

Possible header:

Code: [Select]
/***************************************************************************
 *   Copyright (C) 2012 by the Fifechan team                               *
 *   http://www.fifengine.net                                              *
 *   This file is part of Fifechan.                                        *
 *                                                                         *
 *   Fifechan is free software: you can redistribute it and/or modify      *
 *   it under the terms of the GNU Lesser General Public License as        *
 *   published by the Free Software Foundation, either version 3 of the    *
 *   License, or (at your option) any later version.                       *
 *                                                                         *
 *   fifechan is distributed in the hope that it will be useful, but       *
 *   WITHOUT ANY WARRANTY; without even the implied warranty of            *
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU     *
 *   Lesser General Public License for more details.                       *
 *                                                                         *
 *   You should have received a copy of the GNU Lesser General Public      *
 *   License along with fifechan.  If not, see                             *
 *   <http://www.gnu.org/licenses/>.                                       *
 ***************************************************************************/

/*      _______   __   __   __   ______   __   __   _______   __   __
 *     / _____/\ / /\ / /\ / /\ / ____/\ / /\ / /\ / ___  /\ /  |\/ /\
 *    / /\____\// / // / // / // /\___\// /_// / // /\_/ / // , |/ / /
 *   / / /__   / / // / // / // / /    / ___  / // ___  / // /| ' / /
 *  / /_// /\ / /_// / // / // /_/_   / / // / // /\_/ / // / |  / /
 * /______/ //______/ //_/ //_____/\ /_/ //_/ //_/ //_/ //_/ /|_/ /
 * \______\/ \______\/ \_\/ \_____\/ \_\/ \_\/ \_\/ \_\/ \_\/ \_\/
 *
 * Copyright (c) 2004 - 2008 Olof Naessén and Per Larsson
 *
 *
 * Per Larsson a.k.a finalman
 * Olof Naessén a.k.a jansem/yakslem
 *
 * Visit: http://guichan.sourceforge.net
 *
 * License: (BSD)
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 * 3. Neither the name of Guichan nor the names of its contributors may
 *    be used to endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

prock

8
Framework development / Prioritizing our time/efforts
« on: March 29, 2012, 04:53:41 pm »
Hi All,

As you know I'm trying to get a list of priorities together for the direction of FIFE.  I'd like to have these discussions throughout the summer, have the milestones set out, and be able to start on some major components by the time GSoC is complete this year (or even before if possible).  I have placed a bunch of our ideas from the FIFE 1.0 meeting we had as well as a bunch of existing tickets into a document on the wiki available here.  Please review it and add any items you want for consideration there.

What I'd like to do in this thread is gather the high priority major component items for FIFE 1.0.  These are items that we MUST include in 1.0 and cannot be left out under any circumstance and they are a major chunk of work.  Once we have a list of high priority items we can begin breaking them down into a logical sequence of implementation which will be used to help derive our milestones.  The rest of the tasks will hopefully fall in there somewhere.

Here is an example of a list (in no particular order)
  • Automated Unit Tests
  • Unify all renderers
  • Proper scene management
  • Documentation (FIFE manual)
  • Component based / inheritance hybrid architecture for (or to replace) FIFE::Instance
  • Complete toolset
  • Sound Manager/Dynamic Sounds
  • GUI Library Support (hammer the details out here)
  • Shader Support
  • Movie playing capability with synced audio

I just threw that list together off the top of my head...  What do you guys think?

9
Framework development / Forking Guichan
« on: March 26, 2012, 12:25:35 pm »
As you all know we need to do something badly about guichan.  We have a GSoC idea that should help us get it handled once and for all.  Check it out here: http://wiki.unknown-horizons.org/w/Ideas_2012/Guichan_and_Pychan_improvements.  Hopefully after the GSoC student is done with Guichan we will be able to compile FIFE without Guichan and perhaps use an alternate GUI library instead.  I wanted to get everyone's input in how exactly we should handle Guichan in the future.  One idea, as specified by the subject of this post, is to fork guichan into another project.  I think we could keep it as part of FIFE's codebase for now and rename it to allow us to easily work with it.  In the future (depending on how development goes) we could split it into it's own project and it's own repo.  That way everyone can benefit from any modifications we make to it.  This option allows everyone to continue to use Guichan if they wish!  I'd like to avoid dropping support with it as it's used extensively by a couple FIFE clients but if we provide an option to use another GUI library and everyone jump ship the future of Guichan is pretty obvious.

Does anyone have any other ideas?  If not this is the approach we will take.

Prock

10
Framework development / GSoC 2012
« on: February 27, 2012, 03:37:18 pm »
Hi all,

It's that time again.  We have to start thinking about tasks for GSoC 2012.  We need a list of ideas for this year.  Please post them here!  We need to get them in by March 9th.

Timeline: http://wiki.unknown-horizons.org/w/Timeline_2012
Ideas:http://wiki.unknown-horizons.org/w/Ideas_2012

11
Framework development / FIFE 1.0 Feature List - Discussions/Meeting
« on: February 27, 2012, 02:44:34 pm »
Hi all,

I'd like to try and get everyone (clients and FIFE devs) together at some point for a meeting of the minds to discuss the final feature list for FIFE 1.0.  This may include completely new features or features that are lacking or buggy.  I'd also like to try and get a list of workarounds that clients have put in place because of a FIFE bug or an incomplete FIFE feature.  One of the reasons why I want to do this is because I want to start attracting more developers to FIFE.  Before I do this I want to be sure to have a good set of prioritized tasks in Trac so people have a good idea of what work needs to be done and that things dont get forgotten along the way.  It also shows that we are well organized and have a good vision of where FIFE is headed.  Besides all that it's been a long time since we've had a meeting like this so it might be a good idea anyway.

As far as a date/time is concerned I'd like to push for a Sunday sometime around 12:00 GMT in a couple weeks.  This should give you enough time to get some ideas together.  Any thoughts on the date/time?

I realize that trying to organize a meeting where everyone can attend is pretty impossible so please gather your ideas and post them on the forum here if you cannot make it.

12
Framework development / FIFE 0.3.3 and some OpenGL rendering problems
« on: October 11, 2011, 10:19:17 am »
It has been brought to our attention that several people are having problems with the OpenGL renderer in FIFE 0.3.3.  We are looking into the the problem and have created a ticket to track issues anyone is having.  Please post your problems to the ticket: http://fife.trac.cvsdude.com/engine/ticket/581

13
Framework development / New Resource and Memory management
« on: December 14, 2010, 10:31:12 pm »
As you all know I've been talking about a complete re-design of the resource and memory management within FIFE.  After looking a great deal at FIFE itself and some consultation with vtchill we have decided to do a complete redesign of the resource handling portion of FIFE (or at least have a really good look at doing so).  This doesn't mean that we cannot reuse some code, it just means that to make the process easier we will be stripping out what is there and replacing it with a re-written version.  The interfaces in question are the pools, IResrouce, and the resource loaders.  I haven't gone into great detail on how this all should be redesigned but I'll go over some of the things we have been talking about in IRC.

First we would like to get rid of the "Pool" idea in favor of a master resource manager.  The manager will act as a factory class and manage all resources internally.  The interface will create and load the resource when the client requests it.  The resulting resource will be return to the client using the boost::shared_ptr template class.  There is a swig wrapper for boost::shared_ptr (new to swig 2.0 :D) so we hope to make use of that as well.  The types of resources the manager will take care of specifically will be images (or textures), fonts??, audio files and movies (if we ever get movie support).  Basically anything that should be globally accessed and is not a game/engine related structure.  Everything else will be managed by their container classes..  e.g. Layers will be managed by the Map.  Instances will be managed by the Layers... etc etc.  (I'm still a bit foggy on this idea).  Objects and Animations are global objects as well so they will be handled by a global container of some sort (again, still working this all out).  I realize that this could potentially create a lot of API changes but once the re-design is complete and implemented it will be a definite improvement to FIFE.

There is also the resource loaders that need to be looked at.  Keep in mind that in this case we are talking about the game/engine related data (i.e. maps, objects, layers, animations.. not images or sounds).  We are still working out the details about how exactly we want it to look.   We have a couple ideas we are exploring.  One method would be to provide a "plugable" interface much like there is now where you create your own loaders and savers and add them to the engine.  The engine would then select which loader to use when loading a resource based on filename or some other means.  The other method would be to remove the idea completely and leave it all up to the client.  We would provide a default set of loaders in the engine itself and the client could choose to extent it or write their own.  Any thoughts on this?  I would prefer a simple interface myself as the loaders and savers would almost always be provided by the client anyway.

Thats enough for now (I could probably go on for a lot longer)...  if you have ANY thoughts on the subject please post it here.  I"d like to hear what everyone else has to say.  Oh and if any of this doesnt actually make sense please ask about it and I will try and clarify it.

Peace,

prock

14
Framework development / view_performance branch testing
« on: December 04, 2009, 10:50:36 am »
Hi all,

As many of you already know Phoku has almost completed his work on the view_performance branch he has been working on.  I'd like to say thanks to Phoku for his efforts!!!  We are all very happy (and lucky) to have such a talented member on the FIFE team!

Down to business.   I started this thread so we can collect and discuss any bugs that you can identify in the view_performance branch.  Phoku has merged trunk back into this branch so it is up to date.  If you find any issues please post them here so Phoku and the rest of the FIFE team can try and resolve the bugs.

As soon as we can resolve any issues that arise we would like to merge the view_performance branch back into trunk so that all clients can start benefiting from the better performance we have been seeing in testing.

15
We didn't talk alot about this subject in the meeting.  I'm hoping to get more input here in this thread.

New Feature Suggestions:
  - better GUI, fonts in bold, italic and colors, more flexible styling
  - tool for generating animations

That it.  We didn't have a chance to talk about the Fog of War feature totycro suggested.  We'll talk about it next meeting.  Until then does anyone else have any suggestions?  Is FIFE missing something?  Is something not working correctly or as expected?  Let us know here!!!

Pages: [1] 2