• Content count

  • Joined

  • Last visited

Community Reputation

138 Neutral

About urkle

  • Rank
  1. Andreas you are AWESOME! Thanks so much for turning around this bug fix (and every other bug fix you've ever turned around for me in the past ! )
  2. I tried bumping to 2.23.1 or 2.24a and now I get new issues when saving.. I'm getting an offset != currOffset in asCWrite::AdjustGetOffset in 64bit! Though running 32bit saves and loads the bytecode perfectly fine.. and the 64bit loads that bytecode fine.. Odd. This is using the 2.24.0 tag from SVN. Wait.. scratch that.. it's acting REAL funcy now in 64bit .. causing odd errors in game.. Ugh!!!! it's not easy to see which exact source file is causing issues as the whole thing is compiled into one file via the main.cpp. And I can send you a PM w/ the game name
  3. I'm using Angelscript 2.22.1 in a game I'm porting to Linux.. The release game distributes JUST the compiled angelscript byte code, however this isn't working correctly on x86_64 linux. Here is the breakdown of what it's doing. 32bit linux loads the bytecode generated by the 32bit linux game binary,, does NOT load the bytecode generated by the 64bit binary 64bit linux does not load either bytecode correctly. Does the bytecode depend on how the calls are registered? As some calls are wrapped (using the autowrapper) on x86_64 linux only. (they use Native calling on all other platforms). This is to work around the passing and returning of certain structs by value.
  4. problem with GLSL and arrays

    Quote:Original post by furrymaster Why dont u do this as in cpp?(its the same construction and it works always) const float vMul[] = {0.05, 0.1, 0.25, 0.3, 0.1, 0.3, 0.25, 0.1, 0.05}; That is not valid GLSL syntax so it doesn't work. the OP has the correct syntax for doing a initialized const float variable. From the OpenGL GLSL 1.20 documentation.. (Which apple's Drivers advertise as supporting). This is a bug in their drivers and I know of no clean workaround other than initializing the array in main(). I have filed a bug with Apple (in july of 2009!!!) with no response from apple. the Bug ID is 7031205 if you case to reference it in new bug. (Please file a new bug with apple at bugreport.apple.com. maybe if other's bug them they might actually fix something). 5.4.4 Array Constructors Array types can also be used as constructor names, which can then be used in expressions or initializers. For example, const float c[3] = float[3](5.0, 7.2, 1.1); const float d[3] = float[](5.0, 7.2, 1.1); float g; ... float a[5] = float[5](g, 1, g, 2.3, g); float b[3]; b = float[3](g, g + 1.0, g + 2.0); There must be exactly the same number of arguments as the size of the array being constructed. If no size is present in the constructor, then the array is explicitly sized to the number of arguments provided. The arguments are assigned in order, starting at element 0, to the elements of the constructed array. Each argument must be the same type as the element type of the array, or be a type that can be converted to the element type of the array according to Section 4.1.10 “Implicit Conversions.”
  5. angelscript and xcode 2.4

    Quote:Original post by WitchLord I'm pleased to announce that AngelScript is now fully working on Linux/PPC (rev 71). All of the tests pass successfully in compatibility mode. Hopefully it should be working on Mac OS X/PPC as well. Let me know if there's something that still doesn't work. Swwetness. I'll be testing this later tonight to make sure things didn't break Quote: I discovered yet another compiler difference yesterday, it turns out that on the Linux/PPC that I was testing on the 'char' type was unsigned by default. I had to add some 'signed char' type casts due to it, where I normally use just 'char'. I'll have to add some safeguards against this as well. OK, that is REALLY odd.. i mean REALLY.. Quote: Hopefully we'll also have support for native calling conventions on PPC soon. But I think I'll leave that for Edward Rudd, or whoever else want to give it a try, as I would like to get back to implementing the coming features. I have a functional native calling procedure working right now. (except for double parameters and I haven't actually tested it with more than two parameters right now.. but it *should* work) I will be throwing more tests at it and then integrate it into angelscript. Though i did find an article documenting the differences between the ABI of Linux/PPC versus Mac OS X/PPC so, as it stands this will ONLY work on OS X/PPC. Once FC6 is released (scheduled next week) I'm going to try and install it on my Macmini and start testing/learning the ABI.
  6. angelscript and xcode 2.4

    Quote:Original post by WitchLord Do you have access to Linux on a PPC machine? I'm guessing the assembly routines have to be different for Linux and Mac OS X, at least slightly, due to different ABIs. Right now, no I don't. I may try getting either FC5 or FC6 when it is released installed on my MacMini. I'm hoping the bootcamp CD will boot and run on a PPC so that I can use the file system resizing utility on there so I don't have to reinstall everything on the Mini (not a fun thing to look forward to unfortunately). Though I have a feeling from reading through the ABI for Mac OS X that it is more how the architecture (PPC) does calling and that it would be the same calling conventions for Linux PPC as well. I'll have to do some more research. Quote: Anyway, I'm happy you have the patience to really look into this. It's really appreciated. No problem. It gets it so I can use the scripting engine in the game that I'm porting (which will have some income, so consider that the game is funding the work on angelscript). And it betters angelscript overall. As you saw from my website I'm a big supporter of Open Source software and have contributed to a LOT of projects out there. And this will get Code::Blocks working on the PPC too:-D I still need to get around to playing with that on my Linux box. Ahh the search for a good IDE. Haven't seen on of those in a LONG time.
  7. angelscript and xcode 2.4

    Sweet.. I'll update my copy and test out the new changes. I'm still chuging away at the Native calling code, getting a feel for the differences in assembly between x86 and PPC and I think I have the problems with the existing implementation nailed down and am working through re-implementing it. I should have a patch for that soon.
  8. angelscript and xcode 2.4

    Quote:Original post by WitchLord I've updated the SVN with your latest changes. And also made the size of bool configurable, so that it is now correct on MacOSX with PPC. I also ran some tests on a couple of different systems (thanks to SourceForge.net's compile farm). Windows x86 with MSVC -- all tests passed Linux AMD64 with gnuc -- all tests passed Linux PPC with gnuc -- test_conversion and test_switch failed, the rest passed I didn't have time to check out exactly why the test_conversion failed. But it is likely due to the mix of datatypes, which still needs to be fixed. In test_switch it is the _switch2 that fails, much as you reported. Did test_conversion work for you, or did you comment out some part of it? Yes, test_conversion worked for me without any changes.. hmm. I'll have to log into the compile farm myself and test it. I guess the next step for me is to disable the MAX PORTABILITY option and try and get native calling working..
  9. angelscript and xcode 2.4

    Quote:Original post by WitchLord There were a couple of errors though: case BC_INCi: - ++(*(int*)(size_t)register1); + ++(*(int*)(size_t*)& register1); l_bc++; break; case BC_DECi: - --(*(int*)(size_t)register1); + --(*(int*)(size_t*)& register1); l_bc++; break; You forgot to dereference the pointer before casting to (int*) in these two changes. But you probably already noticed that. I noticed that already and it's fixed in the last update you have. Quote:Original post by WitchLord I added a couple of new asserts in the asCreateScriptEngine() function so that we can validate the assumptions taken in the library code. If what you're saying, that sizeof(bool) is 4 then the assert will fail, which means that I'll have to adopt the code for this. PPC has a 4 byte bool (no clue why but it does), thus it fails the assert. hmm.. excerpt from the Apple manual Quote: A long double is 16 bytes on both architectures, but only 80 bits are significant in long double data types on Intel-based Macintosh computers. A bool data type is a single byte on an x86 system, but four bytes on a PowerPC architecture. This size difference can cause alignment problems. You should use fixed-size data types to avoid alignment problems. (The bool data type is not the Carbon Boolean type, which is a fixed size of 1 byte.) And you can't rely on the fact that the PPC has a 4 byte bool either.. AS there is a compiler option to turn it into a one byte bool. However the likelyhood of that setting being enabled is very rare as it can introduce binary compatability problems with other libraries. Oh and an interesting bit of random information from the Apple manual Quote: The terms big-endian and little-endian come from Jonathan Swift’s eighteenth-century satire Gulliver’s Travels. The subjects of the empire of Blefuscu were divided into two factions: those who ate eggs starting from the big end and those who ate eggs starting from the little end.
  10. angelscript and xcode 2.4

    I've updated my site w/ the latest patches. http://www.outoforder.cc/downloads/patches/ PPCfix3.diff is the difference from current trunk to my changes angelscript-2006-10-09.zip is the entire local WC. Every test is working in AS_MAX_PORTABILITY except for the _switch2() function and the uint8 problem. all instructions seem to be working fine except for the INCi8 which assumes an 8bit variable where as w/ the case of the switch you are using a 32bit var on the l_fp being treated as an 8bit. And I can not just change the INCi8 to assume it's a 32bit (and cast it) as if a real native 8bit variable were to be incremented it would not work. correct me if I'm wrong, however. As a nice simple fix would be case BC_INCi8: ((char)(**(asDWORD**)®ister1))++ thus treating it as a word and only casting as a char, so it would increment correctly in both environments. Right now I'm at a standstill until we figure how to resolve these byte conversions. I may try making some more tests to test other crazy scenarios. Oh, BTW. All my changes work perfectly on my linux x86 box in AS_MAX_PORTABILITY mode. (have not tested regular mode).
  11. angelscript and xcode 2.4

    Got past TestReturn. now up to TestSwitch. The fix for TestReturn is in asCDataType::GetSizeInMemoryBytes(). a Bool is not one byte in size but rather 4. (at least on the PPC) and so when the return value of "1" (or true) is set under the assumption of a byte it fails to pass the !returned as apparently !16777216 is not false, only !1. (this is the same issue I had when the Assert calls were pointing to a CDECL implementation of ASSERT and thus returned a pointer instead of 1 in the bool value)
  12. angelscript and xcode 2.4

    I've uploaded my updated code. http://www.outoforder.cc/downloads/patches/PPCFix2.diff (just the diff from SVN) http://www.outoforder.cc/downloads/patches/angelscript-2006-10-08.zip (full export from SVN w/ my changes) I now have tests working down to TestReturn (current one that doesn't work) skipping TestAny, Testinterface, TestScriptStruct, TestScriptString, TestRefArgument, TestSuspend (and several others are not working as they state *I do not work in max portability mode* ) You'll see where I have commented out the tests that do not work in main.cpp I took #2 option as if you store all variables as 32bit internally then using casts of the DWORD value (instead of casting the pointer to a byte) seems to work. We shall see if that blows up when arrays start being used:) but things are progressing. also, can you svn:eol-style native all of the test source code?
  13. angelscript and xcode 2.4

    I just got back from a camping trip this weekend. I'll update my SVN WC and look through your comments and start implementing and testing the ideas in your posts and see where I get. I'll try to get a zip of the code up on my site later tonight or tomorrow. (have some other work I have to tend to first tonight that shouldn't take TOO long....) Thanks for all of your help so far.
  14. angelscript and xcode 2.4

    Still working through the tests.. I have been just disabling some test as I go through and get the simpler ones working.. The following tests are ones that currently aren't working. TestCaseOp TestSinlgeton TestAny TestInterface TestScriptStruct TestScriptString TestRefArgument TestSuspend Currently I am going through TestConversion and fixing instructions as I go. I also had to go through all the tests and remove their private Assert() implementations and make sure they were all using the GENERIC call version of the Assert in utils.cpp. OK.. for the Conversions I've run into a nice snag that looks like a problem with the building of the instructions. test_conversion.cpp line 354 (this is after removing the local Assert function) d = 12.3; engine->ExecuteString(0, "i8 = int8(d);"); if( i8 != 12 ) fail = true; the generated sequence of byte code (pertenant sequence that is) is. dTOi 3 2 LDG 6 WRTV1 3 which dTOi correctly converts the double to the integer and stores it in the l_fp the LDG is correctly pulling the address of the int8 global variable into register1 Now, the choice of WRTV1 is where it all blows up. and I'm not sure how the *correct* way of fixing this is.. Either change the instructions being used OR change the WRTV1 instruction. This decoding of the DWORD stored in l_fp - 3 (in big endian is 00 00 00 0c and little 0c 00 00 00) *(asBYTE*)(l_fp - SWORDARG0(l_bc)); is causing the Low memory byte to be sent over to i8 (which in big endian is 00) where it should be either pulling the full dword and just casting it to an int8 or a different instruction used.
  15. angelscript and xcode 2.4

    svn:eol-style (and all properties) are settings done by the client ON the files. so, you would do the following (command line) in the angelcode/source directory svn propset svn:eol-style native *.cpp *.h And that would set the svn:eol-tyle property to native on all of the source files in the directory. Make sure they are consistently CR-LF on your windows system before committing though. Then when I update my end, the svn client will know that "this is a text file, so when I check it out I'll put just a LF at the end of each line, as that's the unix standard" This is similar to the -K setting you specified on files in CVS to specify which were binary and which were text. Just done a LOT cleaner. read the svn book about properties, there's several more including how you set the ignore property on directories (the replacement for .cvsignore from CVS) http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html the top half is about how properties work, then under "Special Properties" explains the svn: prefixed properties that the Subversion client itself pays attention to.