svn branch 2.9.x

The development of the game itself or new resources for it. Any new stuff you're working on would go here, as well as the discussion of in-development stuff.

Moderator: Developers

Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

svn branch 2.9.x

Post by Serge »

Hello.

I checked out the whole repository and built the version from the trunk on Windows without problem. When i launch the game it then exit early because it cant find some game datas that are located in svn\egoboo\branch\install, but not in the trunk.

Then i attempted to build the branch 2.9.X (last rev, #1717) and had some surprises:
- Some files were no where to be found at compile time. After a little glance it appears that in svn\egoboo\branches\2.9.x\game\Makefile.lua you gave the extension ".cpp" to some files that in the repository got the extension ".c". These files are egoboo\branches\2.9.x\game\egoboo_vfs and egoboo\branches\2.9.x\game\file_common.
- Then again the compiler could not find .\log.cpp and .\rpc.cpp: it appears that in the repository you in fact have a egoboo\branches\2.9.x\game\log.c, not log.cpp. Now for rpc, it appears that you got an egoboo_rpc.cpp instead of rpc.cpp.

After correcting these, i went into other problems of the same nature and decided to stop there for tonight.

Notes:
Apparently the project expect SDL dev files to be located in MSVC directories. I take it that you did that because of a lack of time. In order to make things a little more clean i created locally 2 directories which are respectively:
- svn\egoboo\dependencies\SDL1.2
- svn\egoboo\dependencies\SDL2.0
Then in the project additional include dirs i add something like $(SolutionDir)\..\dependencies\SDL1.2\include, which work well.
Finally in the project additional lib directories i add something like $(SolutionDir)\..\dependencies\SDL1.2\lib\x86, which also work well.
This allow me to build against a specific version of the SDL without having to overwrite these files each time, and without messing with a folder that should stay the property of MSVC for obvious maintenance reasons (or at least, this is what we believe in the video game industry).
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

The updated version of 2.9.0 is actually in /branches/pf5234/egoboo; branch 2.9.x is a bit past that, but in the process of being converted into C++ (apparently).

I can only guarantee that OS X works with my 2.9.0 branch, POSIX should be doable with little tinkering; Win32 I have no idea (is a form of strtol and strtod in Win32?)

Trunk is an old version (2.7.7 devel, released before 2.6.0), don't use that.
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

It seems that the pf5234 branch do not compile either on Windows. Something to do with physfs, and some functions trying to assign a vfs_FILE* to an lvalue of type FILE* (in script.c for exemple), or trying to call fclose on a vfs_FILE* in id_md2.c.

Note regarding the fclose on a vfs_FILE: it seems you are trying to implement a kind of HAL in order to make your project multiplatform, that's why it seems curious to find some mixed file types in your sources. When we build for either NDS, 3DS, IOS, Android, WII, PSP, PS and PC, we have only one file type used. Is this intended ?
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

Those issues listed should be fixed in r1721.
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

i got a compilation error in egoboo_vfs.c at line 1381: char * loc = strrchr(filename, '/'); because of a const object reference being assigned to a non const object reference on windows.

It seems to be the last compilation problem for now, after that msvc switch to linking.

Then it fails to link because of some missing functions definitions like ChrList_init() which is contained in a file ChrList.c which is not part of the project. After adding this file to the project i then run into other problems of the same nature.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

Hmmm, looks like there's a game_vs10.sln in game/, but no egoboo_vs10.sln (I dunno how VS works so I can't provide support). You should be able to find what you need from there. :|
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

I have been able to add all the missing files to the project solution. The Windows project version now build and execute.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

Serge wrote:i got a compilation error in egoboo_vfs.c at line 1381: char * loc = strrchr(filename, '/'); because of a const object reference being assigned to a non const object reference on windows.
Wait, how?
strrchr is defined as:

Code: Select all

char *
strrchr(const char *s, int c);
and filename is a const char *?
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

I dont have the code with me because i am at work, but from memory here is what was going on:
On windows, the rvalue returned was const char*, while the lvalue was char*, hence the rejected implicit cast.
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

If one day we have nothing better to do...

Image
Last edited by Serge on Sat Jan 25, 2014 3:11 am, edited 1 time in total.
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

In graphics.c you are passing structs by value, it means that scr_rect and ego_frect_t are copied each time you pass them as parameters. Normally you call something like
void draw_quad_2d( oglx_texture_t * ptex, const ego_frect_t& scr_rect, const ego_frect_t& tx_rect, const bool_t use_alpha )
instead of
void draw_quad_2d( oglx_texture_t * ptex, const ego_frect_t scr_rect, const ego_frect_t tx_rect, const bool_t use_alpha ).

More over, quads are not grouped by texture usage / alpha property. We call that display lists, they limit the number of draw calls and the number of gl params switch /costly operations by rendering batchs of primitives(here quads) that share the same properties. On small platforms they are mandatory to the point that the api will force you to use exclusively display lists that must be aligned both in size and adress. So normally, you would have a pool of primitives (so that allocations times cost nothing) from which you would grab a quad. Then you would add the quad to the texture's list of primitives, or material's list of primitives if multi textured (one list for alpha, one list for non-alpha). Then upon rendering a scene you would render the lists separatly. So if your scene would use only 32 textures for 8192 quads, you would have only 32 potential gl setups / GPU overheads instead of 8192 actually. The act of deferring rendering until all primitives have been registered is often called retained mode and allow to control when rendering occurs (in a thread ? at a specific location in the main loop ? etc.)

As an exemple you would have something like this:

template < typename PRIMITIVE_T, unsigned int POOL_SIZE > class Pool
{
Pool( void ) : m_iNbUsed( 0 ){}
unsigned int m_iNbUsed;
PRIMITIVE_T m_oPrimitives[ POOL_SIZE ];
PRIMITIVE_T* Grab( void ) { return m_iNbUsed < POOL_SIZE ? m_oPrimitives + m_iNbUsed++ : NULL; }
void ReleaseAll( void ) { m_iNbUsed = 0; }
};

struct Quad2D
{
UVs, coords and alpha property
Quad2D* m_pNext;
};

struct oglx_texture_t
{
...
Quad2D *m_pQuads;
Quad2D *m_pQuadsAlpha;
void AddQuad( Quad2D *const pQuad2D )
{
pQuad2D *& pList( pQuad2D->UseAlpha() ? m_pQuadsAlpha : m_pQuads );
pQuad2D->m_pNext = pList; pList = pQuad2D;
}
void ResetLists(void) // once finished rendering the lists
{
m_pQuads = m_pQuadsAlpha = NULL;
}
};

void AddQuad2D( oglx_texture_t * ptex, const ego_frect_t& scr_rect, const ego_frect_t& tx_rect, const bool_t use_alpha )
{
Quad2D *const pQuad2D( oPool.Grab() );
if( pQuad2D == NULL ) return;
pQuad2D->Setup( ... );
ptex->AddQuad( pQuad2D );
}

void RenderQuads( oglx_texture_t * ptex )
{
SetupGLMaterial( ptex );
for( const Quad2D *pQuad2D( ptex->m_pQuads ); pQuad2D != NULL; pQuad2D = pQuad2D->m_pNext ) Render( pQuad2D );
SetupGLMaterialAlpha( ptex );
for( const Quad2D *pQuad2D( ptex->m_pQuadsAlpha ); pQuad2D != NULL; pQuad2D = pQuad2D->m_pNext ) Render( pQuad2D );
ptex->ResetLists();
}

void Render( void )
{
RenderQuads( pTex1..n );
oPool.ReleaseAll();
}
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

Egoboo is currently a C89 + MSVC extensions (basically C99 minus variable declaration anywhere) project.
There is support for C++ via macros (oh dear the macros everywhere in Egoboo), but it's unfinished and shouldn't be used.

I do say that Egoboo is probably better off being redone. :|

Besides, draw_quad_2d is only used for ui stuff which in egoboo is mainly one quad per texture (except for the bitmap font).
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

I was wondering, do sometimes egoboo get stressed when you add a lot of npcs ? Or is the max number of npcs restricted like in an old zelda game ?

Image
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: svn branch 2.9.x

Post by penguinflyer5234 »

Serge wrote:I was wondering, do sometimes egoboo get stressed when you add a lot of npcs ? Or is the max number of npcs restricted like in an old zelda game ?
Max number of objects is MAX_CHAR (512); Also of note is that there is a max profile ("slots") count (MAX_PROFILE, also 512) limiting how many types of objects there are. The four players and their inventory are hardcoded to be slots 0-35. book.obj is slot 127. Each module can set what some slots objects get (for spawning in scripts), the rest are filled in to wherever fits.

I imagine Egoboo would eventually slow down, but I'm pretty sure the city of Bishopia is around 256-512 objects and it doesn't seem very slow.
...
Serge
Acid Blob (New member)
Acid Blob (New member)
Posts: 9
Joined: Sun Jan 19, 2014 8:27 pm

Re: svn branch 2.9.x

Post by Serge »

Then this is the one i should measure to get an idea of how the engine behave. However when i load this level i can't move and hence cant go anywhere near a lot of creatures... Do i need to setup something for my character to be able to move ?

PS: i went into the controls menu and there is no default inputs, that explain why i cant move
I have been able to walk the level and it definitively looks like a zelda game of the 90s. By judging how many creatures chased me (1 or 2) it seems that there is no hurry optimizing code for the moment. It would seem that in fact one of the biggest concerns for the moment is to port the project to c++, am i right ?



I did have a look at differents parts of the project and here are the 2 things that strike me the most for the moment:
- AStar: uses sqrt(), target nearest reachable location code shouldnt exist (each time the astar start a roll back you register the last verified node, the target nearest reachable node is the registered node with the best heuristic), lots of for() loops that shouldnt exist, not thread safe, etc. (If you want i can send you an example where 2048 entities are constantly pathfinding at 700fps). However i did put a breakpoint into your astar and it seems it's never triggered at any point in the whole level (i tried 3 of them, including the one recommanded for the tests).

- General: the engine suffers from a poor structure, mainly because it's old and written in C. Because of this, the engine spend most of its time in search loops that could be avoided by putting more effort into how objects reference each other. This is partly due to the fact that some objects are allocated dynamically from the heap (i saw no real memory manager by the way). The notion of bitfields is absent (real ones, not just <= 32 bits). The particle system lacks the notion of generator, which would explain why those without physics still have to be attached individually and can be time consuming except if you will never have more than a few of them ( < 4096 ). For the one attached, normally you update them in local space, and upon rendering a batch of particles you combine the matrix of their generator with a single push matrix, but you dont have to move them one by one so that they stick to their generator.

My general impression is that it must have been a fun project back when it began, but that it' age and the fact that it havent been really maintained over the years makes it less appealling now.
Last edited by Serge on Sun Jan 26, 2014 7:29 pm, edited 1 time in total.
Post Reply