ms3d (milkshape 3d) loader fail on BIG_ENDIAN

[kas1e]

@CuteAlien

So we fix ms3dmesh loader to be big-endian and "align" aware. At least, on PPC it works for sure, dunno about ARM or other endian and/or alignment agnostic ones. Should be fine too probably. We add some "pads" to structures, and a little bit modify code (a very little bit). So everything will works and on x86 as before and so on (should be at least).

In other words, there is no DIFF, but just whole new file which you can use (but firstly, if you have time, check if on x86 all fine still):

http://kas1e.mikendezign.com/aos4/irrli ... _fixed.cpp

[CuteAlien]

Thanks, I'll check it when I'm through with my current todo.

[CuteAlien]

OK, I've added it in svn trunk r5948. Thanks for the patch!

I made a few minor changes. On little endian systems the get_unaligned_le_float didn't compile like that. Could probably have fixed it with some casts, but I haven no milkshake models for testing, so I didn't dare playing around. So I just copy the float there - unless we run into a little endian system which neeeds the floats aligned we should be fine.
Also kicked out a few comments and and out-commented stuff.
And kicked out some "struct"'s in sizeof calls which looked unnecessary.

If you have a model for testing and can run it once more on PC, that would be cool.

[kas1e]

Thanks !

Yes, i will test it on both big-endian and little-endianes today. Also a comment above the structures could have been added to explain the reason for padding, but if you do not want to loose time on , its all already good enough

Now i will try to fix latest mesh loader which probabaly the latest from all irrlicht loaders which do not have big-endian changes: .mdl (CAnimatedMeshHalfLife).

ps. Is there some plane for 1.9.0 release time ? I mean, i can help with beta-testing before release, etc. Also do you plan to add SDL2 support and merge ogles2 in for 1.9.0 too ?

[CuteAlien]

I considered adding a comment about padding, but the variable name already mentions it so it's fine.

My hope for 1.9 is end of year, but I will likely have to kick out a few more todo's to have a chance for that. And even then it'll be hard.
Sadly I had to drop merging OGL ES, because I realized I'd have to add another year for that (way to many open todo's for that one and I won't have that much time for Irrlicht next year as I have right now).
SDL2 support is for now still in the 1.9 plan, but it's the last point on my todo-list, so also big chance to get moved to beyond 1.9.
The main problem is that I got several todo's left where I don't know yet how hard they will be (like my todo for today is checking if multi render targets still work. I never used them, so I have to figure out first how to use them. I suspect they might be broken in which case this might turn out to be a week or more work. Or they still work, in which case I'm fine once I've figure how to use them.
edit: Turned out they were completely trivial to use and they still work correct. Sometimes I get lucky ^_^).

The hardest open task is probably figuring out the blending changes which have caused a bunch of open problems. And those are all in code areas with which I'm not that super familiar.

[kas1e]

Just says when you will be about to made prereleases , so i can help with betatesting before release And for SDL2 support i have already pleminar one, it should be easy to integrate and then fix if something wrong or unimplemented.

that commit is integration to irrlicht (so to have usuall define in config for SDL2, etc, pure software rendering) : https://github.com/kas1e/Irrlicht/commi ... f6d79af7b8
that commit is adding of opengl support to sdl2 as well : https://github.com/kas1e/Irrlicht/commi ... 8dec7b2c6e

All of course very basic, but it works, speed is as expected (and not slower on 50% as with other SDL2 patches flying there around) and from that all can be fixed/impoved

[CuteAlien]

"it should be easy" is a famous way to curse to coders :-)
(like in this case - it involves testing on different OS, adding to all the project files and testing with different compilers - that stuff often takes longer than coding the things. Even with a fully working/perfect implementation this won't be something that's done in a hour. And new stuff rarely passes all testing immediately, so I quickly end up spending 1-2 days - which depending on my spare-time can mean it's really 1-2 weeks and by that time I get 3 new reports about other stuff which are more urgent, etc).

But thanks! I will certainly take a look at it when I'm adding it to Irrlicht. So even if it doesn't make Irrlicht 1.9, I don't plan to spend another 7 years on Irrlicht 1.10 (not that we planned that back then... )