• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
krajzega

A bug, presumably in the parser

10 posts in this topic

I am afraid that I have found yet another bug. It's in the version 1.8.0c, compiled with MinGW, under WinXP (those things probably don't matter, but I provided them just in case). The bug is an abnormal program exit occuring when the parsing (building) is taking place. After some tests I managed to pin down the problem: the crash happens when there is an unknown function somewhere in the code AND that function has a constant string as one of its parameters. I first triggered it by typing 'pile->setehaviour(ON_PICK, "pickUp")' instead of 'setBehaviour'. I tried to pin down the problem with GDB, but I've got nothing. It wasn't a segfault. The GDB just said "Program exited with code 03". No backtrace or whatsoever available, because the program is done running when this message appears. However, I think you will find useful the information that the string "function 'xxx' not found" is sent to the outstream. I tried making an error in the line next to the bug-trigerring one to check if it reaches that. It doesn't. I hope that you find that bug report helpful and will use it to make your library even better. If you won't be able to reproduce the bug (I managed to reproduce it with 3 different pieces of code, so its unlikely), I can send you the code that suffered from this bug. [EDIT] I've just had a thought... it could also be an error in the standard "bstr" package. But it's rather unlikely, when there is no errors in the code the strings allocate properly and everything works like a charm. [/EDIT] Yours, Jakub.
0

Share this post


Link to post
Share on other sites
I'll check into it. Thanks for letting me know.

If possible, could you write a small test case for the testframework that reproduces the bug? That would make it easier for me to find the error.

0

Share this post


Link to post
Share on other sites
I would have to add bstr support (or some string support) to the framework and do some other things... I'm at work now, so I'm unable to do this ;). But I can give you the smallest amount of code that causes the error, here. I hope I'm not too annoying ;)
0

Share this post


Link to post
Share on other sites
Don't worry. You're only helping making the library better.

I'm not very used to using mingw. I have installed it and msys. When I try to run make on one of the linux make files it gives me an error. Could you send me the makefile you use for building the library and let me know how to compile it with mingw?

I'll try to figure it out myself, but if you could just tell me it would be easier and faster. :)

0

Share this post


Link to post
Share on other sites
I use a slightly altered "linux_alt1" file: here. You have to make the directory "lib" under the lib root by hand though.

[EDIT] But I am pretty sure that you could compile the code I provided under any standard compliant compiler, so there's no need for MinGW. But well, having GNU for Windows won't hurt you. Oh, and if you want to use makefiles with MinGW, you need to download this:
MingW32-Make
because the make that comes with the standard package is no good. [/EDIT]
0

Share this post


Link to post
Share on other sites
I tried to reproduce the problem using MSVC but couldn't so I'm thinking it only shows up on MinGW (and similar compiler).

OK, so I did manage to compile the library with MinGW. Now I'm trying to compile the testframework. But I haven't figured out how to do the linking. Any hints?

I have 3 object files and the angelscript library.


CPP = gcc
CCFLAGS =
BIN = ../../bin/testframe.exe

bstr.o: ../../source/bstr.cpp
$(CPP) -c ../../source/bstr.cpp -o bstr.o $(CXXFLAGS)

main.o: ../../source/main.cpp
$(CPP) -c ../../source/main.cpp -o main.o $(CXXFLAGS)

test_build.o: ../../source/test_build.cpp
$(CPP) -c ../../source/test_build.cpp -o test_build.o $(CXXFLAGS)



OBJS = bstr.o main.o test_build.o

all: $(BIN)

$(BIN): $(OBJS)
ld -dn -o $(BIN) $(OBJS) ../../lib/libangelscript.a

.cpp.o:
$(CPP) $(CCFLAGS) -c $< -o $@

clean:
rm -f *.o *~ $(BIN)


When linking there are a lot of missing functions (_mainCRTStartUp, memcpy, etc). I think I need to link with the default libraries, but I'm not yet sure how. Can you show me?

I should learn to use MinGW, because it will allow me check portability issues on at least two compilers.

Regards,
Andreas
0

Share this post


Link to post
Share on other sites
I figured it out already. Reading the manual gives a suprising amount of useful information ;)

I link the program with


g++ -o $(BIN) $(OBJS) ../../lib/libangelscript.a


I also found the problem. It is an assertion error that makes the program bail out. Somewhere a temporary variable isn't correctly cleaned up when the function name isn't found. I'll find the bug as soon as possible.

I didn't find the problem on MSVC because I forgot that I using the release version of the library ;)
0

Share this post


Link to post
Share on other sites
Here's your adjusted makefile:


CXX = g++
CXXFLAGS =
BIN = ../../bin/testframe.exe
OBJS = bstr.o main.o test_build.o

all: $(BIN)

bstr.o:
main.o:
test_build.o:

$(BIN): $(OBJS)
$(CXX) $(CXXFLAGS) $(OBJS) -o $(BIN) -langelscript

clean:
rm -f *.o *~ $(BIN)

.PHONY: clean


Some things I changed and why:
1. CXX should be g++. g++ is the C++ compiler, gcc is the C compiler. You can tell gcc to compile c++ code, but it's not worth the effort.
2. Don't link directly with the .a, use the -l switch together with the name of your libfile. For you, it'll be "-langelscript". For this, you have to copy your .a file to the "mingw/lib/" directory or specify an additional library directory with the "-L" switch.
3. You don't have to specify that the object depends on its own source code (the parts you had after the colons). And you don't have to tell make to use CXX for the .cpp files, as long as you set the cxx variable. [EDIT]Haven't seen the project, but you probably need to add some headers to the dependency lists. I'm pretty sure your main.cpp depends on both bstr.h and test_build.h, right?[/EDIT]
4. It's possible to use ld directly, but most of the time you use g++ for linking also. That's because the g++ (and gcc) compiler does the linking by default. To tell it NOT to do the linking of an executable, you need to specify -c.

Whew, that's all. Look at me, I'm teaching the almighty library developer :P. But seriously, you should read some tut on makefile's and gnu compilers to quickly get the hang of it.
0

Share this post


Link to post
Share on other sites
Thanks, for the explanations. I prefer knowing why I should do what I should do. Now I can build a nice makefile for the test framework that I can release together

I found the bug-fix for you:

The assert() in asCCompiler::CompileStatementBlock() should only be done if there is no compiler errors. So change line 349 in as_compiler.cpp to:


if( !hasCompileErrors )
assert(tempVariables.GetLength() == 0);


Thanks for the help.
0

Share this post


Link to post
Share on other sites
How nice of you :). Know what, you've got better and faster support than some of the commercial libs and programs have.

I'm feeling like contributing something to your library now (for your dedication and time and so on ;). Maybe you would be interested in having a dedicated MinGW makefile, with standard interface. Standard interface, meaning that typing:

make
make install

Does all the job. "make" creates the lib, and "make install" copies the library and include files to respective directiores under MinGW. Just tell me if you want that makefile and I'll provide it in no-time ;). (Oh, and also, remember to include the empty "lib" directory in the next distribution of your library, so that all those different makes don't choke on it. And put a "delete.me" or something file in it, so it won't get lost when unarchiving, some unarchivers ommit empty dirs).
0

Share this post


Link to post
Share on other sites
I hate bugs, and I hate letting people down. That's my motivation for fixing them as fast as possible.

Actually, you were lucky since I had a little time with nothing else to do here at work (I'm still at work right now). Otherwise it could have been at least until the weekend for me to fix the bug.

A dedicated mingw makefile would be excellent. With that I'll be able to provide better testing for platform independence. I look forward to adding it to the library.

I'll remember to include the lib directory in the next release (with a delete.me file in it). Thanks for the tip.




0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0