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.

Messages - Joshdan

Pages: [1] 2 3
1
General discussion / Re: Renderbackends: do you use SDL or OpenGL?
« on: August 31, 2008, 01:58:21 am »
One thing i discussed with barra is why you decided to use ffmpeg. It seems that it is rather complicated to use due to its universal nature, and therefore it is difficult to adapt the playback code to fife.

Yeah, from my memory we didn't really look beyond ffmpeg.  It may not be a perfect choice, but from working with it I would say it's not a bad one.

2
General discussion / Re: Renderbackends: do you use SDL or OpenGL?
« on: August 30, 2008, 01:08:01 am »
I'm still researching what options we have to support video in OpenGL better. Some Platforms (Apple and Mesa) provide extensions to use YUV data directly. Another option with newer cards would be to do the color space transform in the pixel shader.

I'm not quite sure what you are using for a base comparison on the video. I still get a reasonable framerate in SDL even doing the software RGB translation.  The trouble comes translating the SDL format to the OpenGL format.  I'm confident ffmpeg can go straight to OpenGL as well; that's just not what it does right now.

Are you using video for something right now?

3
General discussion / Re: Renderbackends: do you use SDL or OpenGL?
« on: August 29, 2008, 01:08:10 am »
Currently the SDL backend does a much better job with the ffmpeg integration, since that's based on ffplay, which renders to an SDL surface.  Converting the SDL surface to use the OpenGL backend is a substantial performance hit.  This could of course be optimized to support OpenGL natively, whether side-by-side with SDL, or on its own.

fyi, here's a thread where I previously suggested moving to OpenGL only (http://forums.fifengine.net/index.php?topic=42.0).  As I conceded in that thread, there's actually some surprising places where OpenGL support is still lacking.  Those places could be a strong niche for FIFE-based gameplay, since there wouldn't be AAA uber-shiny titles competing.

Is there an actual need for improved performance in the graphics subsystem?  I know there's some memory concerns with object animations, and loading is frustratingly slow, but the frame rate seems perfectly fine to me on my aging wreck.

4
Framework development / Re: Movie module based on ffmpeg
« on: April 13, 2008, 11:28:42 pm »
Sorry, no updates at present.  Still alive and still planning to take care of it.  I think the merging shouldn't be too bad, as right now all the files are basically independent of the existing code, so there should be no conflicts at all.

5
Framework development / Re: Trigger support
« on: March 30, 2008, 11:51:20 am »
Quote
Running things in multiple threads creates new set of requirements, i.e. making potentially lots of code thread safe. Instead of threading, we can split the processing into slices, and run that across multiple frames.

You're right, especially since the scripters themselves would have to worry about multi-threading.  Slicing good, threading bad.

6
Framework development / Re: Trigger support
« on: March 30, 2008, 01:46:13 am »
As jasoka said, optimization can wait, but couldn't help brainstorming on some ideas.

I think we could get a huge benefit just by optimizing the most common triggers:

1. Check properties of individual objects tied to the triggers.  Since this would only apply to changed objects, this should only be maybe a few thousand comparisons even in extreme circumstances.

2. After passing any checks from #1, proceed with distance checks.   This doesn't have to be every object compared to every other one.  We could use quadtrees, etc. to speed this up substantially.

3. Once those optimized checks pass, fancier checks could be done in scripts.

------
For result actions that would take more than a frame, we could have a timer or other thread-launching mechanism.  SWIG can be called parallelly from multiple threads, yeah?

7
General discussion / Re: A new name for FIFE
« on: March 30, 2008, 12:15:57 am »
Also, FIFE is a word on it's own -- it's both a piccolo-like woodwind and a region of Scotland.  Even if it's not the snazziest name, it is recognizable, has already been advertised a lot, and only needs to get the attention of developers, who we can assume will actually take the time to learn more than our name.

8
Framework development / Re: Movie module based on ffmpeg
« on: March 21, 2008, 04:47:58 am »
Quote
Would it be useful to merge stdint.h & inttypes.h that come with the ffmpeg SDK with our fife_stdint.h header? Why / why not?
I think it would be prettier to have a file called stdint.h that does the functions this header is supposed to do, and is included in the MSVC 2005 and 2008 SDKs.  Then files can include <stdint.h> the way they are supposed to, without involving #ifdefs.  The rest of the platforms would have the stdint that came with the compiler and wouldn't need any extra file.  We should avoid duplicating the definitions from stdint.h in any file; the header should be included instead.

Quote
1. Did any linux user had the chance to test this branch on his system? Did building work for you? Did you see the video when you ran island_demo?
Not sure if I count or not, but I did build and run in Ubuntu 7.10.  The video appears, but flickers, apparently due to a difference in the way that overlays are handled.  Both this and Wuntvors no-video issue should get fixed when I finally get back to work and use our Image classes and regular blitting instead of the overlays from ffplay.c.  Sound is also not working, but I think that's just my system :-\.

9
The stack trace indicates the issue was in libstdc++.so.6, and doesn't seem to include any GL or SDL anything, so I don't think it has to do with ATI.  I'd guess it has something to do with pointers judging from the lines of subimage_provider affected.

10
Framework development / Re: ffmpeg and SDL_ffmpeg
« on: March 12, 2008, 09:53:45 pm »
no comprendo.

As far as I know, ffmpeg_sdk_win32.zip in my ftp directory is everything I use to build with MSVC 2005 that's not in SVN.  Is there something in particular missing?

11
Framework development / Re: ffmpeg and SDL_ffmpeg
« on: March 11, 2008, 11:37:02 pm »
The libraries, etc. are actually still there from when I sent it to you.  I've renamed it to ffmpeg_sdk_win32.zip so that it's a bit more obvious.

No real progress to report; I have a lot of things to shuffle around, and I guess I just need to break it down into manageable parts to reduce my dread of jumping in.

Basic next steps:
1. Get ffmpeg to store cached frames in our image format.
1b. Update the "gridrenderer" to display these images each frame.
2. Create a proper renderer for movies instead of abusing gridrenderer
3. Make it so that movies can actually be loaded through script
4. Encapsulate ffmpeg code into a class
5. Make sure it works with multiple movies at once
6. Optimize so synching is smooth and minimum time is wasted
7. Allow movies to catch up in extreme circumstances (e.g. skip decoding frames)
8. Handle known issues

#'s 2 and 3 could maybe be done by someone with better knowledge of how this should work.

12
Framework development / Re: Audio module redesign
« on: March 11, 2008, 11:07:21 pm »
regarding point #1, I believe the only supported compiler that does not include these definitions is MSVC, so you could just check for that.  This method is used in our header files, so if the assumption proves false, more than OpenAL-Soft would fail anyway.

13
General discussion / Re: Fallout-dat-support: Is it still needed?
« on: March 10, 2008, 12:19:16 am »
I've done some work to implement DAT support for PhysFS.  I put it aside when the decision was made not to use PhysFS for FIFE, but I could complete it if this came to pass.  That's just DAT 1 and not DAT 2, but DAT 2 should be possible too.

I think PhysFS will be a definite improvement and simplify things nicely compared to having our own VFS.

14
Framework development / Re: Additions to coding standards
« on: February 25, 2008, 04:51:58 pm »
They all look reasonable to me.

15
General discussion / Re: SEO for website
« on: February 24, 2008, 02:04:59 pm »
Using subdomains for the forums and the wiki also is suboptimal.

Suboptimal how?  At least wrt google, pages don't get credit just for being on a domain; they get it based on links, whether they are on the same or a different domain.

Actually, I would be in favor of collapsing domains because they cause us to overly dominate search results.  Google will only display 2-3 results from one domain,  but because we have like 4 different domains, we clog up the whole front page sometimes.  However, I think it's a moot point; many of the sites are provided by different hosts, so we can't just mash them together, and doing it halfway would be inconsistent.

I have to say, that i am against using nofollow, and removing outside
links. That's unfair.
Let me rephrase the goal then -- use external links relevant to their importance.  The W3C is not so central to FIFE that it deserves two links at the bottom of every single forum page.  Maybe these should go on the main forum index, or there could be some powered-by page that all of our pages link to.   However, the current arrangement bleeds out Page Rank like crazy, basically saying that the framework that built our pages is several times more important to us than any of the content that is on it.

I'm not saying we should avoid linking to other sites that we find interesting.  However, just because a link came in a framework doesn't mean leaving it is necessary or right.

Pages: [1] 2 3