Guess I''ll have to wait and see if I can partake....🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Defect Reports
heh - no. It rises to 1.2 meg in size if I do Guess I''ll have to wait and see if I can partake....
Guess I''ll have to wait and see if I can partake....
Is it possible that the problems with DevC++ are caused by incompatible function name mangling between MingW and MSVC?
(that''s not meant to be rhetorical btw, it''s just a question for anyone that knows more about this stuff)
John B
*hoping that isn''t the problem and it can be fixed with something less than converting the interface to pure C*
(that''s not meant to be rhetorical btw, it''s just a question for anyone that knows more about this stuff)
John B
*hoping that isn''t the problem and it can be fixed with something less than converting the interface to pure C*
While firing the laser weapon it appears that after one shot goes out of bounds, then all the rest disappear shortly after.
I have the most recent version from a few minutes ago.
I have the most recent version from a few minutes ago.
The angle given that the bot sees an object at is always positive. Shouldn''t the angles to the left of the bot be different than those to the right of it?
I see that, if I make a bot with g++, it quickly crashes the main executable. There is no need for this to happen:
The Component Object Model — MSDN
The Component Object Model — MSDN
A summary of the mingw problem -
I have downloaded the gdarena and gdarenabin files - both display the same results.
The program works fine with the supplied TestPlayer.dll, but any dll built with mingw crashes the app.
The arena binary loads fine with a mingw bot, but as soon as you hit F5 the app hangs, and is automatially terminated by Windows after a few seconds (usually the result of a very serious memory breach - I''m presuming you don''t make use of SEH)
This also happens regardless of bot size - usually dev-cpp outputs SampleBot at about 450k (?!) - with a bit of judicious linking I can get that down to 19k (God knows what dev-cpp is passing to the linker). However, it makes no odds - the bot still crashes the app.
My system :
1GHz Athlon "P3" w/ 128MB RAM
Win 2k [5.00.2195] SP 4
RIVA TNT2 M64/Pro
My first guess was that as botname::Update() was empty the compiler might be doing something stupid and throwing it away, but even with a token instruction the results are the same, so I guess not...
I have downloaded the gdarena and gdarenabin files - both display the same results.
The program works fine with the supplied TestPlayer.dll, but any dll built with mingw crashes the app.
The arena binary loads fine with a mingw bot, but as soon as you hit F5 the app hangs, and is automatially terminated by Windows after a few seconds (usually the result of a very serious memory breach - I''m presuming you don''t make use of SEH)
This also happens regardless of bot size - usually dev-cpp outputs SampleBot at about 450k (?!) - with a bit of judicious linking I can get that down to 19k (God knows what dev-cpp is passing to the linker). However, it makes no odds - the bot still crashes the app.
My system :
1GHz Athlon "P3" w/ 128MB RAM
Win 2k [5.00.2195] SP 4
RIVA TNT2 M64/Pro
My first guess was that as botname::Update() was empty the compiler might be doing something stupid and throwing it away, but even with a token instruction the results are the same, so I guess not...
quote: Original post by JohnBSmall
Is it possible that the problems with DevC++ are caused by incompatible function name mangling between MingW and MSVC?
(that''s not meant to be rhetorical btw, it''s just a question for anyone that knows more about this stuff)
John B
*hoping that isn''t the problem and it can be fixed with something less than converting the interface to pure C*
Even converting it to pure C would not work.. you have to retrieve the interface to the IPlayer class. There are only a few exported "C" functions anyway.
quote: Original post by Beer Hunter
I see that, if I make a bot with g++, it quickly crashes the main executable. There is no need for this to happen:
The Component Object Model — MSDN
Actually, the reason your executable is crashing is because the DLL is crashing. There is something different between DLL''s built with g++, DevC++, and VC++. I don''t know what that difference is, and I''m not going to worry about it either.
As for COM, my suggestion is that you read up on it yourself. Its capabilities are beyond the needs of this contest, and considering the point of this contest is to make it as accessible to everyone as possible while keeping it as simple as possible, COM is certainly not an option. What this contest DOES use is a COM-like design. It''s just tailored to the needs of the application. This allows for flexibility in the future, including data collection, easy recording, and other easily added and fancy features that would not otherwise be (as easily) capable if COM was being used.
quote: Original post by Anonymous Poster
While firing the laser weapon it appears that after one shot goes out of bounds, then all the rest disappear shortly after.
I have the most recent version from a few minutes ago.
I''ll look into that, but I think it''s more of a graphics issue than the simulation itself. I''ve seen it before, but it never affected the results of a player being hit.
quote: Original post by Anonymous Poster
The angle given that the bot sees an object at is always positive. Shouldn''t the angles to the left of the bot be different than those to the right of it?
Which angle? And in what context?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
