The new HPI handler coded by Cire replaces the old one, it builds and run on linux (32 & 64) not on windows with mingw32 (network code doesn't build). The game loads but it seems there is a memory leak and it crashes on exit (this was happening before replacing the HPI handler), but worse sometimes the HPI handler can't find files which are in its database (I checked, they are in) and can't load them. So it can't load weapon FXs from gafs (textures are ok) and some weapons are missing: some units can't fire because they have no weapon.
I think we can fix a few things with a hash table replacing the map but we need to fix this memory leak since it disturbs everything else!
new HPI handler
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
new HPI handler
=>;-D Penguin Powered
Your stl lib that is being used underwindows must be the same one that is used in vc 6 as thier are serious issues with map in 6.0, i believe its fixable but for the life of me i can't remember how.
I wrote a test application and compiled and run the code and thier is no issues using 2005.
I could try to get the newest code and see if I can compile it now, with all the changes it just might now.
++Cire.
I wrote a test application and compiled and run the code and thier is no issues using 2005.
I could try to get the newest code and see if I can compile it now, with all the changes it just might now.
++Cire.
Ok I went to the cvs page and started to sync my copy of source with yours, one thing I noticed was in stdafx.h where it shows...
I have an extra include, which you probably wana add so we don't need to worry about adding that as well, like so.
I also did NOT include ta3d_hpi.h in my code, however in the namesapce for vars i put this...
This should do it as its just setting up a external ref that should work itself out without the need to include the hpi header. We really don't want to include any 'internal' code in this since if we need to do updates to hpi code it would force a recompile of our pch.
++Cire.
Code: Select all
// Cire:
// Now to include allegro openGL support.
#include <alleggl.h>
Code: Select all
// Cire:
// Now to include allegro openGL support.
#include <alleggl.h>
#include <GL/glu.h>
I also did NOT include ta3d_hpi.h in my code, however in the namesapce for vars i put this...
Code: Select all
namespace VARS
{
extern class cHPIHandler *HPIManager;
}
++Cire.
Well in case I don't catch you, I notoiced a serious issue.
I notice that in most of the funcitons that pull files from hpi that you walk the string replacing '//' with '\', then you strip off a begining '\' if it exists.
These are extra instructions that should NOT be implemented, you have to think that thiere are TONS of hpi calls. Now what I suggest is...
First, look through and find all referencs in the cpp file for ta3d_hpi.cpp, where it builds the path, and change any "\\", to "/" since that is how u handle building your paths. After you done this you shouln't need to do that replacements.
Next do a search for any calls to the hpi code in the entire engine, and look for anything that is starting out with '/' at 0, and remove them, or set the starting path as '/' either or, now u shouln't need to do a erase and construct a new std::string.
I realize this seems trival, but if u figure there are say 2000 calls to hpi at start, then say nother 2000 or more calls during a game, you are saving about 40 opps per call in lowest case, for a whoping 80,000 instructions, and thats the smallest savings, most likely u'r gona save alot more.
++Cire.
I notice that in most of the funcitons that pull files from hpi that you walk the string replacing '//' with '\', then you strip off a begining '\' if it exists.
These are extra instructions that should NOT be implemented, you have to think that thiere are TONS of hpi calls. Now what I suggest is...
First, look through and find all referencs in the cpp file for ta3d_hpi.cpp, where it builds the path, and change any "\\", to "/" since that is how u handle building your paths. After you done this you shouln't need to do that replacements.
Next do a search for any calls to the hpi code in the entire engine, and look for anything that is starting out with '/' at 0, and remove them, or set the starting path as '/' either or, now u shouln't need to do a erase and construct a new std::string.
I realize this seems trival, but if u figure there are say 2000 calls to hpi at start, then say nother 2000 or more calls during a game, you are saving about 40 opps per call in lowest case, for a whoping 80,000 instructions, and thats the smallest savings, most likely u'r gona save alot more.
++Cire.
Who is online
Users browsing this forum: No registered users and 27 guests