Jump to content

nesqi

Members
  • Posts

    8
  • Joined

  • Last visited

nesqi's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. nesqi

    B6.1 Bug Thread

    Bug report. Reproduce, on linux. 1. start spriter 2. file->new project 3. choose any folder 4. (Animations tab) press "New entity" (the guy with a +) 5. Move NewAnimation in entity_000 to entity_001 by drag and drop. This causes a new NewAnimation to be created outside of any entity. This looks incorrect. 6. change the name of this outside-of-entity-NewAnimation. Now you get crash.
  2. That would be great. Can you email it to me or attach it to a new issue? Ok, I created a new issue and attached SCMLpp.c and SCMLpp.h with fixes. https://code.google.com/p/scml-pp/issues/detail?id=3
  3. I have a bugfixed verison but this forum will not allow me to attach a .cpp file. Send me a message if you want it.
  4. Hi. First of all, thank you for all the effort of putting together scml-pp. I'm trying to use the library in my game and I found some bugs along the way. Bug1: As far as I can tell void Entity::update(int dt_ms) does not handle updates that skips two or more keys. So if keys are very close in time or the application is not calling update very often the wrong key will be used for drawing. Bug2: In both void Entity::draw_tweened_object and void Entity::Bone_Transform_State::rebuild sprites and bones are tweened between their Mainline references. This is however incorrect as the references might be pointing to the same key in which case the tweening will be halted. In Bone_Transform_State::rebuild the line Animation::Mainline::Key::Bone_Ref* ref2 = nextitem.bone_ref; should be removed and the line Animation::Timeline::Key* b_key2 = entity_ptr->getTimelineKey(animation, ref2->timeline, ref2->key); should be replaced with code that fetches the next Timeline key after b_key1. I modified getTimelineKey to handle out of index keys and changed the line to Animation::Timeline::Key* b_key2 = entity_ptr->getTimelineKey(animation, ref1->timeline, ref1->key+1); My animation renders correctly after this dirty hack. The logic in Entity::draw_tweened_object needs to be updated in the same way.
  5. This sounds like a nice implementation. I'm interested.
  6. nesqi

    Linux support.

    It looks like the symbol for memcpy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy is the only reason for the requirement of glibc-2.14. Se here for a list of solutions to this problem. http://stackoverflow.com/questions/8823 ... -a-so-file
  7. nesqi

    Linux support.

    All I'm saying is that when the time comes to compile a new release for Linux, then it would make sense to compile it for libc-2.13 and 32bit so that as many people as possible can run it regardless if they have a good or bad reason for not running on a later system. spriter$ objdump -T Spriter | grep GLIBC_ 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 atan2 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strlen 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 sqrt 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __cxa_atexit 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 acos 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 memmove 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main
  8. nesqi

    Linux support.

    On what linux distribution was the linux-binary built? I noticed that it's using libc-2.14, which is newer than my 2.13 used in most Debian versions. Allot more people would be able to run Spriter if it was compiled for libc-2.13 and a 32bit system. I doubt Spriter needs any 64-bit features.
×
×
  • Create New...