Jump to content

SyntaxError

Modders
  • Content Count

    928
  • Joined

  • Last visited

About SyntaxError

Profile Information

  • Gender
    Male
  1. My whole life is a lie! I thought I remembered having a conversation with Fuzzie about why (much of) the code more resembles C than C++... Polymorphism shouldn't have fallen into the category of poor support. Now I cant fathom why there are so many type checks in the base classes instead of polymorphic overrides and template methods (not to be confused with C++ templates). Oh well.
  2. The code you referenced the caster is not always "this" so that is why it must check for NULL. PCs/NPCs should always be "Actors" so checking the type should get you that without needing to access PCStats. A lot of this logic is due to the quick port from C to C++ so we kept a lot of the old conditionals in the base class instead of leveraging polymorphism like we would have done if this were originally C++ code. Its not noise it is helpful even if we have to clean it up a bit; no apology necessary!
  3. You can't just arbitrarily cast a Scriptable to an actor; thats a great way to induce a crash or other bad behavior. You need to check its type: caster->type == ST_ACTOR I'm also a bit confused to why you are accessing PCStats since you don't do anything with it... but on a non actor accessing that field is going to point to something else and it may or may not be "truthy", which is all you are checking. Additionally the check for caster truthiness is meaningless. `this` should never ever be NULL in C++ (says so in the standard). to see this crash/not work correctly just trigger a projectile trap. A last nitpick please don't use C style casting. I know the code is littered with it, but IIRC thats due to the C roots of the project. C style casts are the ultimate in "trust me" programming. Use a C++ static_cast to cast within an inheritance hierarchy where you know the type (you do though caster->type). Thank you for looking into it, however. We always appreciate helpful assistance.
  4. Flickering problems will occur anytime you have interface elements that overlap the "Game Control" area. As Lynx noted work in progress has fixed this behavior, but won't be consumable for a while yet (even longer for you since PST/SDL2 are the at the bottom of the todo list on that). For now you would have to hack something to size the GameControl differently.
  5. Seems like the windows build might be including/linking things more than once. moving the template specializations from the .cpp to the .h file and declaring _all_ the specializations with the inline keyword should fix it.
  6. I believe the answer is the 4th line of the log. You see we try to initialize with a pixel format of `RGBA8888`, but as you can see from the log we are getting back `ABGR8888`. I don't know if it is a bug in SDL, or if that is expected because that is the only hardware format your device supports. You can possibly work around it by building yourself. You have to fiddle with the masks at the top of SpriteRenderer.inl. BSHIFT should be 8, GSHIFT = 16, and RSHIFT = 24. That leaves alpha... we probably hardcoded that in a few places. It might not matter if only the hardware texture is in that format tho.
  7. SyntaxError

    Hacking the iesh

    We prefer this. However, we prefer such cleaups to be done as commits separate from code. I think one big push is just fine if thats all it is.
  8. SyntaxError

    Hacking the iesh

    It is hosted on github... where were you getting it from?
  9. This post on the SDL forums might be relevant to the SDL sound problem.
  10. Not all OpenAL implementations populate the version/render/vendor attributes so that might be nothing. We had some recent audio driver work committed in 8aed23e, did your previous working build predate that? I dont see anything more recent that touches audio, unless you mean only specific audio is missing.
  11. When I say "its not that hard to fix" it is because I'm speaking about my development branch where the UI hierarchy was rewritten completely and the cursors arent hacked into the video driver. In fact it *is* fixed in that branch, but there is much to do before that branch would be usable by anybody that actually wanted to play anything. After the semester ends I'll once again have some free time to work on that over the summer so hopefully get that merged (or at least somewhere people can use it) by the start of the fall semester.
  12. After much trial and error, I've been able to get our "buildbot" to make Mac builds that aren't dependent on on the Homebrew install of SDL. The newest Mac build will run out-of-the-box without additional dependancies; no more error about "No Video Driver Available" which was caused by linking against the aforementioned libSDL.dylib from homebrew.
  13. It would be helpful if you could post the backtraces. We aren't aware of any segfaults or they would have been patched by now.
  14. ah, yeah, OS X doesn't have a case sensitive FS by default. I'll have to check this out tomorrow and see about that.
  15. Thats fantastic The OS X build is the entire directory "GemRB.app". probably should be zipped in some way.
×
×
  • Create New...