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.

Topics - Joshdan

Pages: [1]
General discussion / SEO for website
« on: February 24, 2008, 12:38:18 am »
It was discussed on the forums that it would help to have some SEO on the homepage so that people who are looking for us or just a 2d engine can find us.

Pages to optimize

2d game engine
open source

(and combinations thereof)

  • Change title, description, and keywords tags to include keywords
  • Replace the word fifengine with FIFE almost everywhere (fifengine is both more unique and less searched for)
  • Avoid coined/mashed words like FIFEwiki, etc.
  • Remove links to unrelated sites, especially things in the footers.  If links are required by terms of use,  use nofollow
  • Link back to the homepage from child sites;  ideally on every page, but certainly on the landing pages. Links should include keywords.
  • Link Exchange -- just listing this one to say I think it's not worth it.  Page Rank is basically a zero-sum game, so an exchange can't make both site's scores go up.

Please respond with any other ideas / opinions.

Framework development / Playing movies alongside content
« on: February 13, 2008, 02:12:52 am »
I am working on re-integrating ffmpeg into FIFE, and would like a little feedback in order to proceed intelligently.

I've gotten the basic decoding and playing handled.  It's probably suitable for cut-scene usage if we shut everything else down, but it can't currently play while the rest of the framework is chugging along. There are two major concerns which I would like to hear opinions on:

#1) Can the movie playback be asynchronous to the rest of the screen refresh?  This would probably allow for both a higher and smoother frame rate (otherwise frames would be unequal in duration, making it look jumpy).  The major issue with this would probably be:

#2) Can we avoid overwriting the movie frames?  If we draw on top the movie, the movie would have to immediately re-write itself to avoid flickering with whatever is writing on it.  This wouldn't be too big a deal, but would make things a little more complicated.

Framework development / Movie module based on ffmpeg
« on: February 02, 2008, 01:56:36 am »
I have been looking into ffmpeg and SDL_ffmpeg.  They are apparently not particularly MSVC friendly, but it can be made to work.

Regarding SDL_ffmpeg, I'm thinking it's not much help for our particular need.  It seems like it may be even harder to get working cross-platform than ffmpeg is on its own.  It's probably a bit more abstract than we want, taking away flexibility we may want later.

It might be worth using as guidance and incorporating some of the code, except that it's under LGPL 3, and I assume we are planning on going with version 2.1.

If anybody's got experience or seen some project that put SDL_ffmpeg to good use, then I'd be interested in checking it out further, otherwise I'm going to focus on using ffmpeg directly.

We had discussed including the necessary files in the SDK, but this won't be done for the release tomorrow.

Framework development / MSVC Project File [template]
« on: January 30, 2008, 03:57:29 am »
I would like to re-work the MSVC project files, as they've quickly become a frustration for me.  Some things I would like to adjust:

1. Remove project file from SVN.  Since it is created by scons, its only use in SVN is to create conflicts.  And this disaster is far too impatient to wait before happening.  Rather, it happens about once a day.

2.  Solution file has configurations for all of the project build options, which actually match semantically (e.g. Debug solution configuration should not build the Release version of the project).

3. A debug build that actually includes debugging symbols, and works without jumping through any hoops.

4. Debug build with island_demo as default run target, since that is our current debugging target.  This won't add any more overhead to debugging a different target than having a blank target by default.

6. Something clever so that you don't get that stupid reload project question every time.

So first off, I have a question: do we need the static builds?  I've looked over the project file and these seem designed to build a static version of the fife library (i.e. one which will be compiled into another C++ program).  Since the current project is designed around SWIG, I am not sure this makes sense.  Also, static builds don't seem to be included for any of other supported compilers.  Still, I am new to the project, and quite possibly totally confused.

Secondly, if anybody has any particular concerns / desires for the project or solution files, please let me know.

Framework development / Quadtree
« on: January 25, 2008, 03:39:41 am »
I've noticed in the logs a bit of a game of "telephone" going on with something I said about the effectiveness of the current quadtree a while back, and I was a bit confused in my description in the first place.  Luckily, Sleek has shone a brilliant light into the discussion with an excellent demo application.

Basically, I was expecting something like this:

But phoku's implementation was more like this:

Note the way that in the first one, it takes at least a few dozen points before you get down to the smallest size box, while in the second, a single small rectangle will cause this.  There are advantages and disadvantages to each approach, but since I was expecting the first, and only coming to grips with the second glimpse by glimpse, I was a bit baffled.

I do think we have a bit of a solution looking for a problem with the current quadtree approach.  That is we took a quadtree optimized for one particular use, and then tried to figure out how to build our needs around it.  Rather than go further down that path, I think it would be best to determine what we want to use the quadtree for, then build the quadtree (or quadtrees, or some other data structure) up around that.

Here are some general areas that seem like likely candidates.  If someone knowledgable about these areas can comment on how they would like to utilize a quadtree (or other instance-locator), please do.  That is very specifically what data you would expect want to pass in (e.g. top left and bottom right points in floating point model-layer-substrate coordinates), and what data you would want to get out (circular doubly linked list containing all rectangles intersecting the box described).  Also, if you know of other areas that could potentially benefit from this sort of optimization, please add them.  I'll try to fill in any gaps.

Rendering -- we only want to process and draw stuff that will actually show up.  We don't want to have to check each object individually to know if it will show up or not.

User Instance Picking -- The user clicks (or just points) somewhere on the screen; the game needs to know what is there.

Pathfinding -- As the pathfinder looks around the map, it wants some way to tell if there is anything locally to avoid.

Radius effects --  A grenade goes off, or a poison cloud spreads through the air ducts.  The damage dealing code needs to look for instances near them to damage without having to check every single instance to see if it is close.  NPC/critter visibility would probably also fall into this category.

Framework development / Quadtree points of interest
« on: January 22, 2008, 03:17:58 am »
#1 I'm not sure what all we use it for, but in core/model/structures/instancetree.cpp, we have the following line, which is used when looking for an instance which has been clicked on.

Code: [Select]
m_tree.find_container(point.x, point.y, w, h);
I think maybe find_container is not appropriate for this use, as it will actually create new (empty) subnodes, bypassing those with data, or may stop early if it decides it prefers to be higher up.  The correct approach is probably to use a visitor, as illustrated in the 3 examples visitors on

#2 The current quadtree seems a bit quirky.  It's logic for deciding when to use a subtree seems based on the location of the single element being placed, rather than a desired node density.  In particular, the logic seems to be tied to whether the object fits into its current cell without touching either the right or bottom borders.

Phoku, could you please comment on the above?  I am told you were the implementer of the quadtree, and your thoughts would be appreciated before we go off and do something silly :-).

Note:  The odd behavior shown in this pic: is a combination of the above two effects.  Clicking on a cell with x=15 when the width is set to 1 by instancetree.cpp will decide that it belongs at 32x32 width, since that is the only way it can avoid touching the border of its bounding box on the right.

Framework development / Dropping SDL rendering support
« on: January 13, 2008, 04:35:12 am »
I have been going over the profiling results with Sleek, and it seems like a lot of effort both in performance and in code size is devoted to rendering a 3d scene into 2d (for example we apply our own orthographic projection).  In the long run I think we could easily get several times the framerate by taking advantage of hardware rendering, avoiding any need for other optimizations for a long time.  Over time we could also probably simplify a bunch of things using OpenGL since it can apply camera/matrix transformations too.

The only major roadblock to moving in this direction seems to be our current 2d SDL support.  Since basic OpenGL support (e.g. drawing textured rectangles) is pretty much a guarantee on any platform, is there any reason to continue SDL graphics support?

Framework development / VFS restructure
« on: January 05, 2008, 09:05:26 pm »
In order to simplify VFS, improve platform independence and remove the dependency on boost, it has been proposed that we use PhysicsFS. The way it works is:

1. You pick a write directory
2. You pick any number of read directories / archives
3. All the read directories are combined into a single hierarchy (e.g. music/ from one folder is merged with music/ from another; the files from the first folder take priority).

PhysicsFS supports a lot of different sorts of archives, so we'd gain that support as well.

As part of this, I'd also want to move the DAT file reading out of the loaders module into VFS.  DAT1 and DAT2 files are just archive files, so there's no reason they should be handled differently than any other archive format.

Please let me know your thoughts.

Pages: [1]