Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

330 Neutral

About _Vicious_

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. _Vicious_

    Handle to value type

    Thanks for your suggestion but the idea of having two identical classes felt somewhat clumsy. I ended up converting the class to use reference counting, which is only performed for script-allocated objects, looked up via std::map with pointer as the key. This incurs performance penalty but hopefully it's going to be negligible .
  2. _Vicious_

    Handle to value type

    Please correct me if I'm wrong but it just occurred to me that what I had described above sounds like a potential use-case for asOBJ_NOCOUNT handle types but not quite, as I would still like AS to perform the reference counting on script objects.
  3. _Vicious_

    Handle to value type

    Well, the first and foremost - for simplicity's sake. I didn't really want to bother myself with coding the reference counting machinery because objects of this particular POD type aren't created via the factory pattern. They are either attached to game entities, which are pool-allocated and have infinite lifetime or are temporary stack objects used to pass the entity state around.
  4. _Vicious_

    Handle to value type

    Hi, thanks for all the hard work you've done on AngelScript over the years! Is it possible to pass around references to application-registered value types in AngelScript? For typical use case I'm returning a reference to such type and that works fine but there are also cases where I would like to be able to return a handle or a null. For such handles, the memory management is taken care of by the application. Thanks in advance!
  5. _Vicious_

    Deprecation warning for application-registered entities

    My first idea would be to check the reference count of such objects and print a warning if they exceed 1 (I'm assuming that one reference is reserved for the engine).
  6. _Vicious_

    Go-inspired features in Angelscript

    Not quite true in case of Go, which features different syntax for short variable declaration and assignment.   a := 0 // declares a variable 'a' and sets it's value to 0, same as 'auto a = 0' a = 0 // sets value of variable 'a' to 0 b = 0 // produces compiler error because assignment only works for variables that have already been declared in this scope
  7. _Vicious_

    Go-inspired features in Angelscript

    The same kind of argument applies to 'auto', which found its way into AngelScript nonetheless.     I believe you are wrong here. I find it that polluting the code with structs and classes that do not serve any purpose other than storing the return values for non-trivial functions is very much an anti-pattern. You can't have too many of them without making a mess.     Again, this is debatable. I would think that the same kind of argument applies to structs or classes (having to remember which class member corresponds to what).     Overall, it seems to me that neither of you have ever tried go lang, which I recommend you should do. I know you love your C++ but c'mon, there are other languages and technologies out there.
  8. _Vicious_

    Go-inspired features in Angelscript

    Could you please elaborate on what kind of bugs you think are possible with such approach to variable declaration?
  9. _Vicious_

    Go-inspired features in Angelscript

    Hi Andreas,   thanks for your continued work on the wonderful language!   I have recently gotten my feet considerably wet with Golang and have found some of its features pretty cool and useful, multiple return values and short variable declarations to name a few. Now I would consider the former to be somewhat more difficult to implement than the later, which seems to be a little more than syntax sugar for the 'auto' declaration.   Is there a chance you would consider implementing some of these features in AngelScript? Now I'm aware your TODO list is already miles long but I figured I'd ask you anyway :)   Best regards, Victor
  10. _Vicious_

    Windows XP Compatibility

    It's pretty much the same with CreateSemaphoreEx:   http://www.warsow.net/forum/thread/t/223185#post-223185
  11. _Vicious_

    Implicit conversion changed sign of value

    Confirming as the issue as fixed. Thanks!
  12. _Vicious_

    Implicit conversion changed sign of value

    void item_weapon( Entity @ent ) { if( (ent.spawnFlags & WEAPON_ROCKET) == WEAPON_ROCKET ) { if( (ent.spawnFlags & WEAPON_BIG) == WEAPON_BIG ) GENERIC_SpawnItem( ent, AMMO_ROCKETS ); else GENERIC_SpawnItem( ent, AMMO_WEAK_ROCKETS ); } else if( (ent.spawnFlags & WEAPON_SPIKES) == WEAPON_SPIKES ) { if( (ent.spawnFlags & WEAPON_BIG) == WEAPON_BIG ) GENERIC_SpawnItem( ent, AMMO_PLASMA ); else GENERIC_SpawnItem( ent, AMMO_WEAK_PLASMA ); } else if( (ent.spawnFlags & WEAPON_SHOTGUN) == WEAPON_SHOTGUN ) { if( (ent.spawnFlags & WEAPON_BIG) == WEAPON_BIG ) GENERIC_SpawnItem( ent, AMMO_SHELLS ); else GENERIC_SpawnItem( ent, AMMO_WEAK_SHELLS ); } } Basically, each '(ent.spawnFlags & WEAPON_ROCKET) == WEAPON_ROCKET'-style comparison throughout the source code results in compilation error.   WEAPON_ROCKET again is an enum, spawnflags is an integer property.
  13. _Vicious_

    Implicit conversion changed sign of value

    Hm, after updating to WIP Angelscript version, I get loads of the following errors:
  14. Andreas,   are there any plans to incorporate this into 2.28.2? The patches have already started to bitrot...     Best regards, Victor
  15. _Vicious_

    Implicit conversion changed sign of value

    Thank you :)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!