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

Pages: 1 2 3 [4]
Help and troubleshooting / Re: Trouble building FIFE
« on: July 31, 2012, 04:54:03 am »
Hey Grouflon,
I think the problem is that the iterator is not constant. It is a known problem with MSVC. You should be able to fix it if you change line 264 in routepather.cpp to:
Code: [Select]
std::set<Object*>::const_iterator obj_it = std::find(parts.begin(), parts.end(), (*block_it)->getObject());
I'm not at home so no fife source available here. I'll test the fix later and will commit it if it works.

Help and troubleshooting / Re: Location Class and it's functions
« on: July 30, 2012, 10:54:26 am »

You should use LayerCoordinates ;)
A few basics to locations:
Every location needs a layer (the layer have the grid and the grid is used for the calculations/conversions).
LayerCoordinates describe the center of a cell on a layer. ExactLayerCoordinates can describe every position on a cell.
The MapCoordinates are useful to convert, for example if you want to compare positions on two different layers or if you want to convert to ScreenCoordinates(which are simple pixel coordinates on the screen).

Since rev. 3992 FIFE has a new pathfinder. Therefore, it may be that your map is not correct. Your layer on which are the agents need the correct size (depends on your ground layer) and in the layer tag of the map file the layer type should be set to walkable. (layer_type="walkable")

You can take a look at the demos e.g. the shrine.xml map in demos/rio_de_hola/maps works with the new pathfinder.

Game creators corner / Re: [HELP] Map Editor
« on: June 20, 2012, 09:14:20 am »
We have a Atlas Creator that is able to create object files (source is in fife/tools/atlas). In case you will use sprite sheets. If you will use single images we have a script fife/tools/ but I'm not sure it is still works.

Game creators corner / Re: [HELP] Map Editor
« on: June 20, 2012, 08:42:05 am »
Hey rellikt and welcome :)
Yea you can't use image files directly. So you have to embed them in object.xml files.
Here are a few links to our xml formats to dig deeper:

You can also look in our demo clients. Rio de Hola using sprite sheets (atlas images), the object files are located in fife/demos/rio_de_hola/objects. If you have single images you can take a look at the shooter or rpg demo in the same demo folder.
If you have more questions feel free to ask here or in our irc channel


Framework development / Re: GSoC 2012
« on: February 29, 2012, 11:09:19 am »
I would say the most important is video support. In most engines this is a core feature but in FIFE it's still missing. It is usefull for intros, outros, cutscenes and so on. I think most clients would find this useful.

As second I would like to see a better sound engine. The current implementation has some problems and limitations.

Framework development / Re: The reasons for the texture chunks
« on: October 03, 2010, 04:43:10 pm »
1) I can still guarantee the chunk is a power of 2 for the texture
The old code guarantee it, too.
2) You're right.. it's not optimal but we can still optimize the texture chunk size.  Just have to add a col chunk size and row chunk size.  Pretty easy mod.
Why optimize? The old code used two chunk sizes.
3) Only one call to render needs to happen
Yeah as I said before, if you configure the chunk setting right, it needs one call to render, with the old function. Only if the texture is larger as the maximum texture size you need more chunks also more render calls. The new code can't display these large textures.
4) Drawing primitives on the texture should now become possible/easier
It's already possible. And I see no reason to remove the support of large textures only to draw primitves on textures.

Framework development / The reasons for the texture chunks
« on: October 03, 2010, 12:35:11 pm »
Hi guys,
I looked into the last changes and found a few problems/misunderstandings.
The history behind the chunking code is that we need it for two reasons, first to ensure that the texture is power of two and second to support textures which are larger as the hardware supported size. The most video cards support maximum 4096x4096 or 8192x8192 texture size if your texture is larger it can't be displayed.
The old chunking size variable in the engine settings defined the maximum size for a chunk, not the real size. The real size of the chunk is defined in chunk_width and chunk_height. We may use glGetIntegerv(GL_MAX_TEXTURE_SIZE, &max_tex_size); to obtain the maximum texture size and use it as chunking size, so we don't need the chunking size variable in the engine settings and the chunking size would be set correctly.
I found also that the new code use the same chunk size for width and height, thats not optimal, because e.g. you have a texture with 33x23 pixels then the new code makes a 64x64 texture but the old code makes a 64x32 texture.

Oh, before I forget...
The new stuff in fife_math.h is a bit inaccurate due to the limited precision of float or double. Example: PI = 4.0*std::atan(1.0) is inaccurate after a few digits, more accurate is PI = 4*std::atan(1).

Framework development / Re: view_performance branch testing
« on: December 20, 2009, 12:22:16 pm »
I tested the branch with Zero on fullscreen. (but not with the actual fife rev. because I ran into .png loader problem)
On worldmap is no difference but localmap speed up (360fps-->600fps).

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.
Zero have the same problem.

Framework development / Re: [Light] Review
« on: August 25, 2009, 12:56:32 pm »
LightRenderer.getgloballight/setgloballight need to be renamed.
Ok, there is no problem. I'll rename the commands.

I'm sure getgloballight doesn't work as intended.
Oh, yes you are right  ;D

Needs more documentation
No problem.

I will change the grouping and pushing of Global Light. Yes there are interaction between the OpenGL renderbackend and the light renderer. First it is cleaner for me to set the light init data in the backend, second when I set the state in the lightrenderer the screen is black or the cursor images are colored by global light.

A demo of it's use is necessary - add that to rio de hola?
Good idea :)
I can add light functions to rio de hola.
chewie wrote an editor plugin for global light, it is in the trunk and I wrote a simple light plugin - here are screenshots of both:

Global Light edit:

Simple Light edit:

I can maintain the light things. It's not that difficult and an example in rio de hola with editor plugins should be sufficient.

Pages: 1 2 3 [4]