Closed noodlecollie closed 6 years ago
mittorn
commented
6 years ago Xash3D reads data from files and network. Half-Life files and Xash3D protocol is little-endian so data should be always read like little-endian even if system is big endian. Quake already have this calls, but Unkle Mike removed big endian support in early xash3d versions.
mittorn
commented
6 years ago Most systems now is little-endian, so this macro does nothing. I have tested big-endian support on qemu and mips router.
noodlecollie
commented
6 years ago Do you think writing a little-endian preprocessing step for BSPs would be worth doing? I'll probably need to do it for my own branch anyway to simplify how I'm processing the map data, so it wouldn't be much extra work to just contribute it to the engine in the first place.
noodlecollie
commented
6 years ago I've done something of an implementation, which cleans up the model loading code a little (though not as much as I'd ideally hoped). I decided not to go full-on and convert the entire file in the conversion module because I wanted to avoid the module needing to know about validating data within the file (eg. lump lengths).
If you think it'd be useful for the engine I'll create a pull request, otherwise I'll leave it in my own fork.
a1batross
commented
6 years ago Your just loader seems to be just more readable. :)
Xash3D 1.0 will have a polymorphic loader, which is alot easier than any other, as it more generic for a wide range of different BSP formats. You just define a lump info table and pass it to generic loader. I think, 0.19.x branch will not get it. As Xash3D 1.0 releases, we will most likely reboot our fork.
noodlecollie
commented
6 years ago Is there any more info about what's planned for 1.0? If it means major changes, I'll just hold off with my own stuff until 1.0 comes along and deal with everything then.
a1batross
commented
6 years ago I even don't know when it will be ready and how we should deal with fork.
Unkle Mike says he will not release 1.0 in April. It may be released even in December. :)
https://cs-mapping.com.ua/forum/showthread.php?t=38780&page=1&pp=20 This is a thread about 1.0 in Russian. The main feature for fork is the new stable prorocol and interfaces.
10 мар. 2018 г. 15:43 пользователь "Jonathan Poncelet" < notifications@github.com> написал:
Is there any more info about what's planned for 1.0? If it means major changes, I'll just hold off with my own stuff until 1.0 comes along and deal with everything then.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/361#issuecomment-372026988, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgeyW82CXFFMnT1I2hfw09LB-eFfKks5tc8p8gaJpZM4SdvXs .
noodlecollie
commented
6 years ago That's useful, thanks. It's probably gonna be best for me to hold off for now and I'll see how things develop.
Can anyone give me some background the way/reasons why endianness conversion has been implemented? I've been trying to bring a branch in my fork up to date today as it was pretty far behind, and I've noticed a lot of calls to functions/macros like
LittleLong()have been added. I'm aware of what endianness is, but not why the conversions have recently (ie. within the last 6 months) been introduced.The somewhat ad-hoc nature of the conversions is causing me a little bit of a headache, as none of my existing code uses them and I'd have to track down everywhere I think they should be used. I'm feeling like it'd be more worth my time writing in a small endianness conversion helper framework, so that we could pass it some resource file (eg. a BSP), perform little-endian conversions in-place on that data, and then the rest of the code would never have to even care about endianness again. It'd keep all of the endianness conversions in one place instead of littering them throughout all the source files, which I'm worried will end up making things more difficult to maintain.