Welcome, Guest. Please login or register.

  Show Posts
Pages: [1] 2 3 ... 6
1  General Category / General Discussion / Re: PARPG Meeting (urgent and important) on: January 28, 2010, 08:47:09 PM
I'll do my best to attend, but my schedules are really unpredictable ...
2  Development / Programming / Re: Programming roll-call on: January 22, 2010, 07:09:09 PM

To illustrate this just look at the number of occasional people dropping by who are interested in contributing and disappear after not being able to find their way around.
3  General Category / General Discussion / Re: Project Activity and Participation on: January 20, 2010, 09:54:25 PM
1: A lack of actual, you know, PEOPLE
2: Maybe a sense of direction
3: Too much stuff split over wiki, trac and forums

Regarding 1: True, people need certain triggers to stick around, you need both to be able to attract people, to get people started and to keep them interested.

Regarding 2: Indeed people think too much demo oriented, and I mean this in a negative sense when it comes to quality. If you think demo/task oriented without a proper focus on architecture first, you end up with a ugly-hack lasagne. Next to this I strongly disagree with your statements regarding this, if you need something to be done and if you have limited resources, you need to focus on one thing. You make some agreements with graphical persons, with script writers, map creators, .... to support a set of features, you commit that these are available and focus on this, and not on the next great future that will make you rule the universe in 2020 .... using a techdemo gives you goals to attend.

Regarding 3: forums are there, as is irc for discussion and for junk. Trac is there do log work to be done and for issues to be fixed. The wiki is there (should be there) for design documentation.

4  Development / Programming / Re: Programming roll-call on: January 20, 2010, 05:41:08 PM
currently alive, but inspiration/directionless
5  General Category / General Discussion / Re: Project Activity and Participation on: January 18, 2010, 09:31:27 PM
From developer viewpoint, the main pain i've always had is that I miss a top level overview of the codebase, there is barely any architecture, it is extremely difficult to figure out where things are, where things should be and where we are going to. The proposal for the gui manager is something which should be done for all functional building blocks, at this point parpg is just a very thing layer on top of FIFE (unlike for example unknown horizons which implemented a more complex/clear architecture and only uses fife what it's supposed to do, do the rendering and the couple times I looked at their source I found it tremendously easy to locate things).

So personally I feel the development of parpg has been a series of hacks on top of hacks without any predefined direction, making it extremely difficult for newcomers (and regulars) to find tasks and to learn what/goes where.

6  General Category / General Discussion / Re: MMORPG game development on: January 18, 2010, 09:20:06 PM
well only watched the first part of it then suspended the tab and forgot to continue, but it was interesting it was on the challenges of maintaining an open source project which involves game developement, basicly the same challenges as those we're going through.
7  General Category / General Discussion / MMORPG game development on: January 18, 2010, 10:55:51 AM
Just looking at this presentation:

might be interesting to others here as well.
8  Development / Programming / Re: Saving and Loading Take 2 on: December 06, 2009, 07:09:44 PM
Well I agree with zenbitz, we should perhaps question the use of pickle, however this then raises the question, are we that much better in encoding/decoding these objects ourselves ?

But I don't think pickle is the problem, i think we mainly lack a decent view on 'how to do things', in this case mainly related on how to deal with the gamestate, nowadays people do some changes, and 'by accident' a swig-object gets glued to the gamestate. Perhaps we should foresee a more elegant solution to add objects to the gamestate something which makes sure only 'valid' objects get entered ? Or perhaps we should do some more decent education ? Or some strict guidelines on the gamestate ?
9  Development / Programming / Re: Inventory system on: December 06, 2009, 07:04:38 PM
I played around with the inventory systems and  I ran into a couple oddities/exceptions. See ticket 231 and 226.

I found some other errors too but those were mainly gui-ish things I believe.  But I also created tickets for those.
10  Development / Programming / Re: Large map performance bottleneck on: December 04, 2009, 07:12:31 PM
When I run the large map on fife trunk I get 20-30 fps, with the changes in trunk I get about 200 fps (but then again we might wish to add the possibility to render the fps string inside the hud somewhere for  more easy reference. (This is in 1024x768, not fullscreen)

The only remark I have is that now I see some artifacts (apar from the PC and NPC's starting to dans at the same locatio), these artifacts are not obviously reproducible and not screenshotable Sad so you may either believe me or think that i was drunk while seeing them.

What I see is the following ,when the PC is moving, i think mainly when starting or ending a movement i sometimes see black lines which oultine a horizontal/vertical/diagonal cut through the scene but still following the tile outlines. This occurs about once a minute, but i haven't found a real way to trigger this ... i don't believe I ever saw this on the trunk (not in the past, not on trunk (of parpg and fife)).
11  Development / Audio / Re: Abstract piano work on: December 01, 2009, 08:13:03 AM
hmmz I actually like Meinmartini's sample a lot, i think it would be great background music for some desolate place
12  Development / Programming / Re: Large map performance bottleneck on: December 01, 2009, 08:05:04 AM
shihonage, I think that FIFE already renders what is supposed to be on the screen. The bottleneck however is figuring out _what_ should be rendered. Figuring out what should be rendered is iterating over a vector which is basicly O(n) and our n is getting very large. So there would be a more efficient implementation of that vector (e.g. early abort, sorting on spatial data, ...)

edit: the UH people came to the same conclusion as we did: http://logs.unknown-horizons.org/%23fife/%23fife.2009-Wed-22.log
13  Development / Programming / Re: Inventory system on: November 30, 2009, 01:32:17 PM
I had a talk with b0rland about this too, I believe he was also working on this part. (not the gui part of it though)
14  Development / Programming / Re: Large map performance bottleneck on: November 28, 2009, 07:17:20 PM
Well, I've done some measurements, basicly I ran oprofile for 20 seconds on a small map and for 20 seconds on a large map and I looked at the differences between both.

A first measurement I did was compare the framerate, the small map renders at 140 FPS, the large map at 23 FPS.

(Logfiles can be seen in trac  http://parpg-trac.cvsdude.com/parpg/attachment/ticket/197/bench_pre.txt and http://parpg-trac.cvsdude.com/parpg/attachment/ticket/197/bench_post.txt ).

When I look at the fat functions in the output I note the following:
* 11% CPU: FIFE:Camera::render()
* 9.8% CPU: FIFE::Instance::update()
* 5% CPU: FIFE::Visual2DGfx::isVisible() (inline function used only in FIFE::Camera::render() and only used to conclude that everything is visible ?)
* 4.2% CPU: FIFE::LogManager::instance() (the logging, this one can be easily disabled through use of a macro, but this get called once or twice per instance in FIFE::Camera::render() (starting to see a pattern ? )
* 3% CPU: FIFE::Instance::getVisual() (well, called in Camera::render() for well each visual ...).

Now I added some prints within FIFE:Camera::render() and basicly it iterates over all layers, there iterates over all instances, and collects the objects to render (takes care of animations etc etc) and then sorts the list of instances to render and renders them. But these counters counted the amount of objects per layer etc.
But the conclusion was that one layer contained 62500 instances, the other contained 697 instances, which means for each frame it iterates over 65000 elements, decides whether or not they should be rendered or require some form of updates. (in the ends it decides to render about 700 objects (the number of floor tiles is almost constant, the number of things on the other layer might differ).  (It also means that at a framerate of 25 FPS, the logmanager will be asked 25*65000 = 1.625 million times whether to log 'action' or 'no action').

Another example is given a 2GHz PC, say it can execute instructions a second, then this would mean that each instance only has*25)=1230 instructions availabe. Which really isn't that much since this loop isn't the only part in the game .... it will stil require rendering etc etc.

So my initial conclusion would be:
a) we added way too much instances on one map (there is an early opt out thing for invisible instances, but everything with us is invisible)
b) the FIFE::Camera::render() loop isn't optimal.

Some wild ideas popping to my head:
-> the datastructures used in the render might be more efficient, instead of a vector, instances might be sorted in an efficient way, that the loop can be interrupted  (so that only 'likely to require work' things are checked
-> remove the logmanager calls from all critical paths (will probably be compiled out i assume in production, at least I hope Wink they already used macro's for it, but a regular scons build still uses them)
-> the big pain will be the amount of floor times, perhaps we should envisage a methode to make them en-masse invisible/visible, are there mechanisms for this already ?

I'd would really appreciate it if somebody could do some double checking and confirm what I just said here (or tell me a liar if i'm telling lies ;-) ).

But at this point my conclusion w
15  Development / Programming / Re: Large map performance bottleneck on: November 28, 2009, 04:46:59 PM
Okay, step one has been taken care of, i've taken the liberty to write some technical document on when/how/why to profile applied on PARPG. This can be found at the wiki http://wiki.parpg.net/Profiling_PARPG (feedback  is welcome, patches is something you can do yourself ;-) ).

All that remains now is to actually use this information to do some profiling Wink
Pages: [1] 2 3 ... 6