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.

Messages - m64

Pages: [1] 2
Game creators corner / Re: Updating the Network Demo
« on: September 10, 2008, 03:29:33 pm »
About the networking part - I understand the main idea here is to wait for OpenAnno (or other game) to finish their networking code and then draw upon their experiences?

Game creators corner / Re: Updating the Network Demo
« on: September 09, 2008, 04:09:04 am »
I think it would be cool to have another tutorials: one about character movement and other about map editor. I will try to write them when I have some time, but if someone with more experience feels an urge to help I would greatly appreciate it.

Game creators corner / Re: Updating the Network Demo
« on: September 07, 2008, 02:40:36 pm »
I've finished the first iteration of the update. The biggest changes have been made to the second part. As the camera api has changed quite a lot apparently I've removed the part about setting the camera by hand and assumed that the cameras will be specified in the map file. Instead I've added a section about implementing a simple scroll system.

Game creators corner / Updating the Network Demo
« on: September 02, 2008, 07:09:28 pm »
Hey there. I've recently tried to complete the Network Demo introductory tutorials. I've noticed that they are quite outdated - some example code won't run with current FIFE, there are also some obvious errors. I've decided to try and update those 3 documents. I will be updating them to be compatible with current svn trunk - this is probably the way most serious developers get the FIFE at the moment anyway.

Game creators corner / Re: A demo for you
« on: September 02, 2008, 04:18:06 pm »
You could improve the input handling a bit - currently it never goes into the CHESS_PICK_PIECE state , so it's hard to move anything.

General discussion / Re: Renderbackends: do you use SDL or OpenGL?
« on: September 02, 2008, 03:53:43 pm »
I've been using the SDL version due to a bug.
AFAIR you were affected by the segfault when throwing an exception bug. This has been recently fixed by yonibear.

That's correct - I only have not explicitly stated it in my post.

General discussion / Re: Renderbackends: do you use SDL or OpenGL?
« on: August 29, 2008, 12:25:52 pm »
I've been using the SDL version due to a bug. On the AA1 (the Linux UMPC) I've managed to compile FIFE with OpenGL support.

The problem with OpenGL is that broken OpenGL setups are rather a rule than an exception under Linux, and for some potential players of FIFE based games this might pose a problem.

Therefore if we ditch SDL we should make sure non-accelerated or partially accelerated OpenGL installations can handle FIFE reasonably - that doesn't mean that they should be able to give identical performance, but that software renderers should be capable of handling a rather uncomplicated scenes.

That way an actual game author would be allowed to make decision how demanding should his game's graphics be, depending on his envisioned "target market".

Another possibility is keeping a half-assed SDL support that handles only some basic features - if a game author wants better SDL support, he is free to improve it.

Frankly speaking this should be based on the shape of our user base, so probably autors of the games using FIFE are the ones whose voices should be the most releveant ones in this discussion. I am constantly planning to create a game, but so far I have not gone out of the concept phase.

Framework development / Re: Proposing new rendering algorithm
« on: June 10, 2008, 01:06:59 pm »
Does SDL support Z-buffer? Or are you thinking about software implementation? I hope it won't be slow like hell.

Framework development / Re: Improving the renderer
« on: June 10, 2008, 06:07:38 am »
I wonder how the Aplha blits are implemented in SDL. If we have easily accessible back buffer we could try to optimize them a bit ie. by using vector operations.

Framework development / Re: Color Overlays
« on: June 09, 2008, 09:26:32 am »
On overlay management, imho once we get the OverlayImage, we should add it to the image_pool, attach it to the ObjectVisual of our object, and be done with it.

The problem with this approach is that when we create another instance of the same Object with identical coloration this new instance gets its own copies of OverlayImages, instead of reusing the ones generated for the previous instance.

Framework development / Re: Color Overlays
« on: June 09, 2008, 05:22:35 am »
I'm trying to do this with as little core code change as possible. Still some parts will have to be written in C++. The minimal amount of core change is the code to actually generate a coloured images - which as suggested perhaps can be moved to an utility class.

More problems are with the whole overlay manager thing, but I think it's a necessary evil. Perhaps I will be able to code it in python, so there would be no core changes. If not, the worst case scenario is one additional pointer added to Object class - I'm definitely not going to force every instance to be colored.

Framework development / Re: Color Overlays
« on: June 08, 2008, 01:25:58 pm »
I have started creating an implementation that is loosely based on my proposal. To avoid effort duplication probably you should wait with coding till I have something to show.

Framework development / Re: Improving the renderer
« on: June 08, 2008, 10:23:18 am »
I have also looked at it and my main observation is that optimization will have to go in different directions for different backends.

For SDL backend we will probably have to minimize number of unnecessary surface blitting. I think that pure "dirty rectangle" method will be insufficient due to scrolling. But if we would make it aware of scrolling it could work - generally the first step of each frame rendering would be to copy the previous frame from frontbuffer to backbuffer with translation to compensate for scrolling, than to render dirty parts including those newly visible.

On the other hand OpenGL wouldn't rather benefit that much from such strategy. In this case we should probably think about a way to transfer geometry from CPU to GPU in larger chunks, as current method of using single quads looks like a possible bottleneck.

Another thing that should be considered is redesign of pixel operations, because at the moment they are implemented in rather inefficient manner. But I don't think that they are the main computational burden at the moment, so they should be rather left for some other time.

Framework development / Re: Color Overlays
« on: June 08, 2008, 09:51:08 am »
It looks like my "vision" of the overlay system was a bit different. Let me sum it up.

Functional requirements:
F1) we are doing this to simplify level creation by allowing designers to change colouring of specific instance without having to define a new object;
F2) therefore it should be possible to specify instance colouration from the map definition file, probably by using instance metadata;
F3) it would be also desirable to be able to interactively set instance colouration from map editor.

Non-functional requirements:
NF1) Computational cost of rendering a coloured instance should be comparable or identical to that of a normal instance.
NF2) Coloured instances memory consumption should be proportional to the number of colour variants used.
NF3) Changes should not destroy current instance rendering pipeline.

So, format proposed by Sleek should be a bit modified. Object definition would stay the same, but overlay image should be defined something like that:
Code: [Select]
<overlayimage namespace="" id="House:000" x_offset="0" y_offset="0">
<base source="base0000.png" />
<overlay source="overlay0000.png" />
<colorkey R="0" G="255" B="0" name="walls" />
<colorkey R="255" G="0" B="0" name="roof" />
<colorkey R="0" G="0" B="255" name="windows"/>
<colorkey R="255" G="255" B="0" name="doors"/>

And in the map this instance should be invoked like that:
Code: [Select]
<instance object="House" x="15" y="21">
<param name="walls" value="255,67,45"/>
<param name="roof" value="0,67,89"/>

To make it possible to colourize instances interactively in map editor there should be a colourize in Instance.
Code: [Select]
void Instance::colourize(map<string, Colour> palette);

To keep the computational cost similar to that of normal instances the coloured images shouldn't the recalculated each frame. Instead when colourize is called or a new colourized object is loaded all necessary images should be generated for future use.

To keep the memory usage possibly low the images of coloured object should be shared between objects using the same palette.


First I wanted to modify or subclass the InstanceVisual, to be able to supply modified images on a per-instance basis. But subclassing does not make much sense because InstanceVisual doesn't use any virtual methods and I'm afraid modifying it could change the interface or place unnecessary burden on normal instances.

My current idea is to add a colourize method to Object, that will create coloured versions of the Object and implement Instance:colourize using it. It would also be necessary to create an ColouredObjectManger that will take care of reusing coloured objects. I still don't know how to manage the destruction of those Objects - some reference counting would be necessary but that would change the interface of Object.

Framework development / Re: Color Overlays
« on: June 03, 2008, 05:42:33 am »
m64, one of the new programmers to the team, has let me join forces with his supreme coding awesomeness


I'd like a bit of direction. Can someone point me to the code where sprites are actually being generated / loaded? Also, what is the render pipeline for FIFE? As in, where can I follow the rendering to figure out where the entry point to the actual rendering occurs?

The top-level code for rendering the instances is in camera.cpp around line 433. As you can see it's done by first getting InstanceVisual from Instance and from there an InstanceVisualCacheItem. My plan was generally to start by either extending or subclassing InstanceVisual and, if necessary, InstanceVisualCacheItem to handle the color overlays. Once this is done we should probably start thinking about supplying a proper interface for this feature.

Pages: [1] 2