• 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.

TheAtom

Members
  • Content count

    62
  • Joined

  • Last visited

Community Reputation

330 Neutral

About TheAtom

  • Rank
    Member
  1. It is an improved version of the good old preprocessor by Anthony Casteel (also known as Deyja), from sources dating back to 2005 or so. I was going to mention it in relation to the other topic: http://www.gamedev.net/topic/640629-cc-like-define-directive-patch-attached/   It is built over version 0.5 of that preprocessor. I couldn't find any newer version (if it ever existed), in fact I can't seem to find the original sources whatsoever, anywhere. In addition to the features from 0.5, our version includes: - multiline macros, - recursive macro expansion, - token concatenation with ## operator, - evaluation of constant expressions (somewhat incomplete), - additional features for #pragmas, - minor things such as #warning and #error, - incidentally, character literals are now converted to unsigned integers.   It is still independent from AngelScritpt and is platform-agnostic, and features a working line number translation between sources and the preprocessed file. And it is still pretty lightweight.   I have hopes to release (or should I say re-release) it soon, although that's not entirely up to me. And following that, discuss a possibility of including it in AngelScript sdk in some way (probably as an addon).
  2. Indeed they are. I just realized that it is our preprocessor that converts the character literals into integers, as a normal step of preprocessing. We don't even have asEP_USE_CHARACTER_LITERALS enabled. Another false alarm!
  3. It appears that character literals are now treated as signed (most likely per rev 1600), but scriptstdstring addon's index operators still use uint8. This forces a rather awkward syntax needed for working with literals of high ASCII codes without getting any warnings: somestring[5] == uint8('?'); I think character literals should stay unsigned, but in any case their sign should match that of the addon.
  4. The thing turned out to be a false alarm: it was Windows' CR/LF conversion mess up while loading the bytecode in our new test tool. Sorry to have bothered about this.
  5. Edit: false alarm, see below   Tested on rev1602. Empty lines (or otherwise syntactically insignificant lines, such as comments) can make the saved bytecode unloadable due to some problems with source line debug information. The following fails to load from bytecode unless debug information has been stripped:   funcdef void FUNC(); class T {     FUNC@ f; } void tmain() {     T t;     @t.f = test;     t.f(); } void test() { } LoadByteCode() returns asERROR. Removing any of the empty lines before the actual code begins seems to solve the issue.
  6. It is unnecessary to hold RefString's clones in each RefString instance. Simply replace pString with a smart pointer to a reference-counted version of std::string. This way there are two reference counting mechanisms involved: 1. Each reference-counted std::string holds the number of RefString's that refer to it. 2. RefString's own reference count holds the number of AngelScript (or C++, if necessary) objects that refer to it, such as string handles.   So RefString's assignment can simply acquire the source RefString's smart pointer to the reference-counted std::string. By doing so it will release the reference-counted std::string it held previously (if any), decreasing its reference counter, which will result in its deletion if and only if no other RefString holds a reference to it.   That aside, unless you are handling reference of your string object inside ScriptUtils object, you may want to register your functions with signatures like "void removeHtmlTags(string@+, const string& in)" `+` indicating an autohandle.     About COW strings in general, they often prove to be more trouble than they are worth. If lots of raw assignments are expected, they might be a good thing. See http://stackoverflow.com/questions/707014/why-vc-strings-are-not-reference-counted for some reasons why many stl implementations just skip it (at least vc++ and stlport do; gcc libs apparently do not).
  7. On storing of an object, CScriptAny will hold the copy of that object. On retrieval, the copy is assigned to the argument passed by reference (which involves making another copy), and CScriptAny still holds the first copy. No freeing should happen at that point.   The copy of the object held by CScriptAny is freed when either another object is stored in it, or when CScriptAny is destroyed.
  8. I just noticed that removing "T Dummy;" still leaves the crash with a slightly different callstack: asCArray<asSDeferredParam>::PushLast + 62, as_array.h (180) asCCompiler::AfterFunctionCall + 403, as_compiler.cpp (7711) ...   so indeed it has nothing to do with the error output.
  9. Tested on rev1558. Likely related to http://www.gamedev.net/topic/639247-import-function-with-default-argument/ (indeed the code is a chopped down version of the one found there). The following two modules crash on compilation:   // mod1 import void g(bool dummy, int x = -1) from "mod2";      void f(bool dummy, int x) { } void run() {     f(true, 0);     f(true, 0);     g(false); }   // mod2 import void run() from "mod1"; void g(bool dummy, int x = -1) { } class T {     T()     {         run();     } }; T Dummy;   This should give an error saying that an unbound function has been called, but instead it crashes (null pointer access) with the following callstack:   asCTypeInfo::operator= + 110 asCArray<asSDeferredParam>::PushLast + 78, as_array.h (180) asCCompiler::AfterFunctionCall + 403, as_compiler.cpp (7711) asCCompiler::PerformFunctionCall + 1450, as_compiler.cpp (11745) asCCompiler::MakeFunctionCall + 563, as_compiler.cpp (10071) asCCompiler::CompileFunctionCall + 1957, as_compiler.cpp (8203) asCCompiler::CompileExpressionValue + 1919, as_compiler.cpp (7256) asCCompiler::CompileExpressionTerm + 169, as_compiler.cpp (6655) asCCompiler::CompilePostFixExpression + 296, as_compiler.cpp (6603) asCCompiler::CompileExpression + 277, as_compiler.cpp (6579) asCCompiler::CompileCondition + 2440, as_compiler.cpp (6534) asCCompiler::CompileAssignment + 420, as_compiler.cpp (6344) asCCompiler::CompileExpressionStatement + 152, as_compiler.cpp (3304) asCCompiler::CompileStatement + 145, as_compiler.cpp (2520) asCCompiler::CompileStatementBlock + 260, as_compiler.cpp (1016) asCCompiler::CompileFunction + 319, as_compiler.cpp (546) asCBuilder::CompileFunctions + 434, as_builder.cpp (709) asCBuilder::Build + 41, as_builder.cpp (241) asCModule::Build + 110, as_module.cpp (223)   Removing any code makes the crash go away, leaving the expected error message, but I am unsure whether default arguments are necessary in the sample to see the crash.
  10.   I am wondering why this warning is even needed. We have: 1. Multiple inheritance for interfaces, i.e. abstract classes. 2. Single inheritance for regular classes. 3. All inheritance is virtual anyway.   This is a nice setup, and we can't ever suffer from the diamond problem. However, 4. It's impossible to decouple class declaration from its implementation (notwithstanding the shared keyword).   Because of 4. it's still reasonable to create otherwise superfluous interfaces, if only to make script headers more readable. For now I don't see a reason to report that an interface is already implemented as it manifests itself in typical and practical situations. But maybe I don't see the entire picture (how do mixin classes come into this?).   edit: this might be interesting:   interface I {     void f(); } interface J : I { } mixin class M1 : I {     void f() { x = 1; } }; mixin class M2 : I {     void f() { x = 2; } }; class T : M1, M2 {     X() { x = 0; }     int x; }; This does not generate any warning, but it does if I change "mixin class M : I" to "mixin class M : J". But in both cases T inherits I along two paths.   edit2: Another issue:   mixin class M1 {     void f() { x = 1; } }; mixin class M2 {     void f() { x = 2; } }; class T : M1, M2 {     T() { x = 0; }     void g()     {         f(); // cannot use qualified names: M1::f() or M2::f()     }     int x; }; There is no warning that T inherits f() twice (but g() calls f() in M1, the closest base class, I assume this is correct) and maybe this actually should warrant a warning, since it's actually a real function being inherited, not just an an interface method. Especially since there appers to be no way to explicitly call f() from the other base class, M2 (is this at all intended?).
  11. Strangely enough, I observed the bug even when the script was in the "middle" of all the loaded modules the whole time, without any moving. A case where ids should also stay the same.   Nevertheless, revision 1558 seems to have fixed the issue. I can no longer reproduce the bug in any scenario.
  12. About the IDE: if you can make your (postprocessed) AS code appear as close to C++ as possible (enforce semicolons at the end of class definition, use array<int> instead of int[] etc.), #include a file that defines some keywords (like #define interface class), and autogenerate "headers" with definitions of your registered classes and functions, then Visual Studios (including the free Express editions) prior to 2010 do more than good job for working with AS. Syntax highlight, type sensitive (sic) autocomplete, jumping to code definition, search for symbol references, class view and all other features work without any problems. The only thing that this setup is lacking is the embedded debugger.   The (detailed) propaganda continues here: http://www.gamedev.net/topic/594639-symbols-table-andor-syntax-tree/#entry4806355 with screens: http://www.gamedev.net/topic/603001-creating-as-ide-thoughts/#entry4817006   It requires some initial, one-time investment of time to make it work, but it's definitely worth it. And let me stress it again that it works with free versions of MSVC,
  13. The constructor just initializes a single integer field to zero. Rest is by the book. There is only one global variable of my value-type (the type's name is FuncBind) in that module, by step debugging I see that ExecuteNext() reaches asBC_ALLOC (with a script object), then executes the following line   asDWORD *mem = (asDWORD*)m_engine->CallAlloc(objType); where objType is what it's supposed to be - FuncBind. However at this point the func variable (which I understand is supposed to be the id of the type's constructor) is the id of some unrelated function. This function is called with CallSystemFunction, and the crash happens soon later on   if( a ) *a = mem; at which point I see a corrupted stack.   It might be important that in our case the registration of certain global functions happens in between loading of modules (either from source or bytecode). Each module has a list of "dependencies" which are registered to the engine just prior to the compilation of this module, unless they are already loaded. The constructor that fails to be called (and the function called instead of it) are both registered like this.   edit: I can also reproduce this with func being the id of a nonregistered function, i.e. a script function. Naturally, CallSystemFunction fails with them on the spot. I have a question, where in ReadInner() "linking stage" there is the translation of registered object's constructor calls? And where are ids of these actually stored - I see that asBC_ALLOC opcodes are followed by a (correct) type pointer, and then pointer to function id - to where do those pointers point specifically?
  14. If I put the offending script at the top of the modules to be loaded, it works every time, both from source and from bytecode. But when I move it to the middle of the scripts and load everything from the (already existing) bytecode again, I get a crash and likely a stack corruption (the callstack is garbage). That would indicate there's still some problem with the restoration routine.
  15. I am now getting a crash in my first scenario and it happens somewhere inside this loop:         if( engine->ep.initGlobalVarsAfterBuild )             r = module->ResetGlobalVars(0);   The problem occurs with only one module (after many others have been loaded), and it is the only module where I have a registered value-type variable declared in (the module's) global scope. Everything here is loaded from previously saved bytecode. I'll see if I can provide more details, perhaps it's me at fault here.