Endianness conversion calls #361
Comments
|
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. |
|
Most systems now is little-endian, so this macro does nothing. I have tested big-endian support on qemu and mips router. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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
<#361 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADEJgeyW82CXFFMnT1I2hfw09LB-eFfKks5tc8p8gaJpZM4SdvXs>
.
|
|
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.
The text was updated successfully, but these errors were encountered: