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

Sir Ementaler

  • Content count

  • Joined

  • Last visited

Community Reputation

1472 Excellent

About Sir Ementaler

  • Rank
  1. Well, it's written in C++, not C, so... it sort of is in such a language, what with std::string storing its length and all. That aside, if a script file I load via this function contains a null character for whatever reason, I'd rather the AngelScript engine reliably produced an error than loaded only part of it. Yes, a typical C string specifically will not contain a null character unless to terminate the string, but nothing else that the AngelScript library interacts with has to act the same, not C++ strings, not file streams, not other languages that AngelScript can be potentially used with. For example, if your application loads script files created by users into an std::string, appends something significant at the end of them and runs that, a user may maliciously create a script that ends with a null character to load their part of the script but avoid loading yours, with unforeseen consequences. A valid script will not contain '\0' but that's exactly why the library has to parse them as well: to be able to report an error when an unexpected '\0' is found.
  2. The application cannot register any entities that rely on something only defined in scripts (even if said script is always loaded) so the straightforward approach is not an option. There are many possible workarounds though. The best one I can think of is to register an interface for GameObject to inherit from. AngelScript doesn't allow script classes to inherit from application-registered classes, but it does allow them to inherit from interfaces, and handles to interfaces can be returned, e.g. In the application: engine->RegisterInterface("GameObjectInterface"); engine->RegisterObjectMethod("GameObject_t", "GameObjectInterface@ getNearestObject()", asMETHOD(InternalGameObject, getNearestObject), asCALL_THISCALL); In the shared script section: shared abstract class GameObject : GameObjectInterface { // ... GameObject@ getNearestObject() { return cast<GameObject>(m_obj.getNearestObject()); } // ... }
  3. sizeof(kClass) will be the size of the kClass array including the terminating null character, so technically you specifically requested AddScriptSection to read up to and including '\0', which is an unexpected token. You should pass sizeof(kClass) - 1 to the function.
  4. I don't actually know a language where the above is valid but I can imagine that some exist. However, it may be worth considering that C++17 introduces a similar but more consistent and, to me, far better looking syntax, for if and switch statements, similar to that of for loops: if (auto it = m.find(10); it != m.end()) { return it->size(); } See init-statement here and here.
  5. Regarding the above solution, please bear in mind the following code: class Object { float real; private float _virt; float get_virt() const { return _virt; } void set_virt(float val) { _virt = val; } } void main() { Object obj; any a; // Sets a to float 123.f a = obj.real = 123; // Would intuitively set a to float 123.f but in the proposed solution sets it to int 123 instead a = obj.virt = 123; }
  6. Using a slightly outdated 2.31.2 WIP version (but I didn't find any notes about this getting fixed), if the application registers a funcdef such as by engine->RegisterFuncdef("void voidFunc()"); the following script reports a compilation error: shared void call(voidFunc@ f) { f(); } According to the error, "Shared code cannot call non-shared function 'void voidFunc()'". This appears to be unjustified, because funcdefs are supposed to always be shared, all other parts of the application-registered interface are accessible from shared code, and the error only occurs when the function is called, rather than on any other use. The same error doesn't occur if the funcdef is defined within the script.
  7. As stated by its documentation, the ref type "can refer to any object type (as long as it is a reference type)". However, the string type is registered as a value type. The distinction between a value type and a reference type is somewhat important in all of AngelScript, as value types don't support handles (@) or inout references (&), which, deeper down, is because they don't register garbage collection/reference counting mechanisms, thus making it unsafe to store any references to them other than the object itself. With some effort, it's possible to register string as a reference type, although consider whether the purposes you need it for are worth it.   The second problem you're experiencing is, first off, because the ref type can't hold references to strings, as explained earlier. If it were to occur for other types, make sure you're using an AngelScript version that incorporates revision 2347, such as the latest stable release (2.31.2). If updating the library version your project uses is not viable, or just if you'd rather have reasonable code, change the AngelScript function signature to "void test_pass_ref(ref@)" and the C++ one to "void test_pass_ref(CScriptHandle *arg)". There is no reason to ever use "@ &in" in AngelScript. And regardless of all that, if assigning it to the reference and passing it to the function actually worked, I guarantee that casting what's internally an std::string* to char* and printing that, wouldn't do anybody any good.
  8. We use r2351. I had viewed the repository and hadn't noticed any changes in the involved code but I could be wrong.
  9. Sample code #1: const uint8 foo = 0; int bar = foo;  Sample code #2: const uint16 foo = 0; void bar(int16) {} void main() { bar(foo); } The assertion failure happens when function asCCompiler::ImplicitConversionConstant calls asCExprValue::GetConstantDW, which expects a type of exactly 4 bytes in size.
  10. If AngelScript were as fast as your initial post claims it to be, i.e. 2.5 times slower than C++, it would likely be the fastest scripting language known to man. If, when bringing up Lua, you're thinking of this benchmark, take some time to actually read what it says and you'll find out that AngelScript performance was tested without a JIT compiler and compared against JIT-compiled Lua. Not to discredit the author, as neither could I get the only known AngelScript JIT compiler to work, but that is not a fair fight. Putting AngelScript up against C++, a language designed from the beginning to end to be efficient, whose compilers had decades to improve their optimization, is even less of a fair fight. Perhaps you ought to consider that the intended use of AngelScript does simply not require great speed. You're not supposed to use it to carry complicated calculations and find undiscovered prime numbers; it's a scripting language, use it to make things happen in games and stuff.
  11. If your class is registered in a way as straightforward as you present it, the most reasonable thing to do would be to register the property as a non-virtual property. Getters and setters are only useful if it is unsafe to access the variable directly. If a setter is necessary because a change to the property may have side effects, then, well, you need a setter. AngelScript supports variable type functions but type compatibility is not verified at compile time, i.e. the function would accept arguments of any type. I don't recommend this for cases where the number of supported types is finite, but if it works for your purposes, you can read about it here. Otherwise you will unfortunately have to register multiple setters. That said, I'm not sure why you're so opposed to this idea, as you can do this without much work using a couple of C++ templates. Our project does this for a couple of methods with >10 overloads.
  12. Using AngelScript version 2.31.1, the following behaviors were observed regarding the "Value is too large for data type" warning:   The warning treats int8 and int16 as if they were unsigned and produces a warning iff the assigned value is respectively outside of the ranges 0-255 and 0-65535. The following snippet produces two warnings: int8 x = -1; int16 y = -1; The following snippet erroneously doesn't: int8 x = 255; int16 y = 65535; When a 32-bit variable overflow occurs during assigning a value to an int8 or int16 variable, the warning may be erroneously omitted. The following snippet doesn't produce a warning: int8 x = 4294967297; int16 y = 4294967297; The warning is never displayed for types int32, int64, and uint64 no matter the assigned value. The following snippet doesn't produce a warning: int x = 4294967295; int64 y = 18446744073709551616; uint64 z = 18446744073709551616; For the remaining unsigned integer types, the warning may be erroneously omitted if a 64-bit variable overflow occurs. The following snippet doesn't produce a warning: uint8 x = 18446744073709551616; uint16 y = 18446744073709551616; uint z = 18446744073709551616; I would be thankful if these issues could be fixed, especially the first one, where warnings are produced incorrectly. Some of our API functions have default arguments such as int8 arg = -1, which cause users' logs to be flooded with warnings whenever they make intensive use of them.
  13. Yes, but that doesn't relate at all to what I claimed. Notice how in C++ too, the signature "int find(const T&)" for T = int* would become "int find(int* const&)" and not "int find(const int*&)". Instantiation of a template is more than just replacing every "T" with the type name. You should be checking the signature for the type array<Item@> if you want to determine anything.
  14.   To my information, that is incorrect. If you attempt to query the signature of the method, it's actually "int array::find(Item@const&in value) const" (or likely "int array::find(const Item@const&in value) const" in the WIP version I am not using). Notice the const qualifier in front of "&in", meaning that the handle should be passed by const &in reference rather than just &in, and thus it's possible to avoid creating a copy of the handle. The same signature would not be considered valid in other contexts, i.e. outside of templates. As such, outside of templates it is unnecessary and actually somewhat inefficient to use the signature you're using.
  15. That appears to be some sort of a side effect, possibly a bug, of passing the handle by non-const &in reference. There is no good reason whatsoever to pass handles by &in reference. A signature such as "int32 getIndexOf(const IItem@ hItem)" should work correctly.