http://members.home.nl/ejm.martens/ViperFighter_test.zip

My game works perfectly on my computer .. and also on some other comps
but on some computers is just stops when using my GUI .. if I ripp out the GUI is workt on those computers too..

I added a logfile that logs everything important the program seems to "crash" when deleting a GUI object.. but it does so even with the simpelest objects...
and if you swap the deletion order it crashes in the destructor of the others

how is this possible ??

I cannot really debug this because it works on my computer whatever I do

I tried resolving all warnings but OpenLayer comes with a big load of warnings...

If someone could help me in finding the solution to this I would be very gratefull..

Hi Edwin,

sorry to tell you the game still crashes for me at exactly the same point (pressing the start button), but here are the contents of your log files.

BSG.TXT

Starting GUI
Creating Choose player dialog
Listbox created
Loading Player Info
Adding Edwin to listbox
Adding Edwin successfull
Loading Player Info
Adding stghse to listbox
Adding stghse successfull
Loading Player Info
Adding test to listbox
Adding test successfull
Loading Player Info
Adding kees to listbox
Adding kees successfull
Loading Player Info
Adding cxbfgnhmnghm to listbox
Adding cxbfgnhmnghm successfull
Choose Player dialog created
[Adding GUI Object]
Start button clicked
Invoking callback function for ChoosePlayerDialog
Get record with name Edwin
Edwin found in player database
creating mission
Mission created
[Request removal of all GUI Objects]
Doing mission briefing
[Removing GUI Object]
Destroying Choose Player dialog ...
Saving Player Info
Saving Player Info
Saving Player Info
Saving Player Info
Saving Player Info
Destroying ListBox dialog ...
Listbox destroyed

ERROR.TXT

#0 0x6965ae9c nvoglnt!DllMain (??:??)
#1 0x03390fb4 ?? (??:??)
#2 0x0334a518 ?? (??:??)
#3 0x0022fc98 ?? (??:??)
#4 0x00001401 ?? (??:??)
#5 0x00447890 gk_render_line_gl_utf8 (C:/Program Files/CodeBlocks/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.4.4/iostream:77)

Hope these help,

It is crashing for me as well in XP SP2. What third party libraries does it use?

bsg.log:

error.txt:

#0 0x6965ae9c  nvoglnt!DllMain (??:??)
#1 0x03390fb4  ?? (??:??)
#2 0x0334a518  ?? (??:??)
#3 0x0022fc98  ?? (??:??)
#4 0x00001401  ?? (??:??)
#5 0x00447890  gk_render_line_gl_utf8 (C:/Program Files/CodeBlocks/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.4.4/iostream:77)

openlayer.log:

I don't know if it helps, but edwin.tst is empty (0 bytes) and I just happened to select the Edwin option.

You could ask for permission to debug on the computers where it does crash.

hey i think its your list box that crashing it. add and new crash as well.

edit:
witch file contains your listbox code.

I'm installing OpenLayer and FMOD so I can build the project myself... I don't know if I'll be any help, but I'll try...

Add a config file, my monitor can't(EDIT) view 800x600 for some reason, would be nice if one could switch from full screen to windowed with a config file.

CodeBlocks project link libraries:

openlayer
freetype
png
z
agl
alleg
user32
gdi32
glu32
glyph
loadpng
opengl32
fmod

I think you should add OpenLayer to the additional compiler dirs

Openlayer\include to the compiler
Openlayer\lib to the linker

I only use OpenLayer and Fmod

and CodeBlocks with MinGW

@ piccolo: see bsgGUI.h and bsgGUI.cpp

I copied the OpenLayer libs to the C:\MinGW\lib directory. I tried adding C:\MinGW\include\OpenLayer to the compiler directories and it didn't change anything...

http://www.allegro.cc/forums/thread/595417/733887#target

Hope it helps.

@bamccaig never copy or even worse overwrite the tings that come with your compiler !!!

Use the additional dirs !!;)

I wouldn't overwrite anything... Unless the installation instructions say otherwise I usually copy the contents of the include and lib directories into the corresponding compiler include and lib directories. I suppose it is a better idea to group them into a subdirectory though...

PErsonally, I think its better to properly install 3rd party libraries into the compilers path structure. That way if you ever upgrade the compiler and other libs by blowing the mingw folder away and replacing it, you KNOW you need to reinstall the 3rd party libs, instead of just hoping you dont have to.

Yeah, that's why I would group them into a subdirectory of the compiler directories...

<tt><mingw_dir>\include<library_name[_version]></tt>
<tt><mingw_dir>\lib<library_name[_version]></tt>

Or did you mean something else?

Sorta. Just install it as the lib tells you to. includes and any subdirs into <compiler>/include and libs into <compiler>/lib. Anything else just makes for confusion later with trying to figure out why "#include <foo.h>" doesn't work cause you forgot you placed stuff into "#include <foo_version/foo.h>".

Which is what I normally do, but I do see the advantage of being able to quickly uninstall a library that you no longer use... It would make the job a lot easier if the library had it's own subdirectories... And it should be easy enough to add those subdirectories to the compiler include directories when compiling...

I hope someone catches this horrible bug ...
It's ruining my game, and the fun of making it ..

I need this code to work, after this project an RTS is in the planning, using almost the same engine ...

Bonked out when I selected the 'test' pilot and pressed start. I'm on Vista. Wouldn't let me switch out to other applications with Alt-Tab or Win-Tab either. Had to open task manager to get to the window that said it stopped working and closed it with that.

I'm not currently up for installing fmod and openlayer but if you upload a win32 debugging binary with the appropriate debugging dll's I should be able to run it through gdb and maybe track down the problem through the source code. You'd have to make it run in windowed mode (less than 1024 X 768) though otherwise I'd probably have to blind type into the gdb window since it doesn't show up when it's switched to and the application it's running is in fullscreen. If I could even switch back to the gdb window anyway.

I attached a zip file with the bsg.log , openlayer.log , and data.bsg files from running the program in it.

I'd sure like to figure out why the compilation fails for me at home... It doesn't make any sense... I've installed OpenLayer and FMOD, yet somehow it still fails... Unless perhaps the OpenLayer, FMOD, and/or Allegro versions conflict in some way...

bamccaig
From your compile log earlier most of the undefined references are prefixed with FT_. Perhaps FreeType wasn't installed correctly or perhaps it was because of what Audric's link mentioned earlier about linking the OL2.0 way instead of the OL2.1 way? Basically it looks like some of the .a files aren't being linked against or perhaps in the wrong order (lib dependencies?).

There is also a precompiled Openlayer 2.1 version wich is the one I use

For some reason compiling libs always goes wrong with me .. it's some curse or something

Yeah, I used the prebuilt version as well... In Linux, I'm happy compiling projects myself, but in Windows I generally use prebuilt binaries if official ones are made available.

Retracing my steps, I think I installed OpenLayer 2.0 (OpenLayer2.0.zip) from SourceForge. I then installed FMOD 3.75 (fmodapi375win.zip) from the FMOD Web site. I have Allegro 4.2.2 installed, in case that matters...

I don't really understand how OpenLayer and Allegro relate, but IIRC I didn't overwrite my current Allegro installation with the files that came with OpenLayer... So perhaps the problem is a version conflict between libraries... I see that you used OpenLayer 2.1 whereas I used OpenLayer 2.0... I don't know anything about OpenLayer so I just kinda guessed about the entire installation...

Perhaps I should try openlayer-2.1-mingw-glyphkeeper.zip per your other thread?

bamccaig: Yes that's the one I referred to as "Openlayer 2.1, mingw-glyphkeeper edition", and I can confirm it builds Ariesnl's game fine. If you use the right linker arguments.

OpenLayer just uses Allegro, it doesn't modify it. Ariesnl, maybe there's a problem with the GK routines, could you try with the internal text renderer, which comes in the 2.1 version?

Success!! It built successfully! Now if I could only figure out how to debug it...

** EDIT **

Looks like it's leading to the bsgGUIObject and bsgListBox destructors...

bsgGUI.cpp lines 1056-1062

bsgGUIObject::~bsgGUIObject()
{
  if (m_clrBrush!=NULL)  delete(m_clrBrush);
  if (m_clrPen!=NULL)    delete(m_clrPen);
  if (m_shpIn!=NULL)     delete(m_shpIn);
  if (m_shpOut!=NULL)    delete(m_shpOut);
}

bsgGUI.cpp lines 105-106

// ...
  m_shpIn    = new Rect(m_nX,m_nY,m_nWidth,m_nHeight);
  m_shpOut   = m_shpIn;
//

This set of code from 105-106 is repeated several times over different constructors of objects derived from the bsgGUIobject class and is assigning m_shpOut the value of m_shpIn which was just assigned the address of a newly allocated Rect object. This is treating m_shpOut as if it was a shared or reference only pointer but in the destructor of the bsgGUIobj class both are passed as arguments to delete which means it's trying to destroy the same object twice if the values of those pointers haven't been changed in the meantime. At least that's what I think might be happening. When a class has a virtual destructor does that mean it uses it's inherited class's destructor? Haven't worked much with inheritance before.

as far as I know first the destructor of the object itself is called after that the destructor of the ancestor is called..
Virtual is needed to call the right destructor when using a pointer defined as a pointer to an ancestor class..

like this

TShip * pShip;

pShip=new TViper;

pShip now points top a TViper

delete pShip;
to get the right destructor here ( the one of TViper instead of the one of TShip) the destructors should be virtual..

what you post looks like a pretty ulgy bug.. but why does is work on my comp ??

I'll try to fix it, see what it does...:)

If m_shpOut is never assigned memory of it's own then you should be able to just remove the line that deletes it from the destructor.

I'll force myself to start using inheritance one of these days...

If you post a new build to try can you have a separate stand alone download for the new executable? With dial-up I only get ~7MB/Hr.

Here's a new EXE http://members.home.nl/ejm.martens/ViperFighter.zip

I hope it did something good ..

It works! No more crashing for me!

It also works for me now.

The new binary is working for me now too. Will the radar have different colors between friendlys and enemys? It would be nice to have a smaller radar out of the way somewhere that could be toggled to stay on or off. As for the bug , it's strange that calling delete twice on the same memory only crashes the program on some computers and not others. Nice to see it working now anyway.

GREAT

thanks all of you..

@ Edgar Reynaldo... the bug was what you posted .. thnx

Coming weekend I'll celebrate my birthday ( I was born on april fool's day ) but as soon as I have time I'll start coding the first "real" missions

Happy Birthday!

Thanks:)

It works fine for me too now

I have found another bug however

If I highlight a player and then click 'Delete', it deletes that player ok. However any other player name I then click on gets instantly deleted!

Apart from that the games looking really promising, I look forward to playing the finished article