2 ms·
Yeah, I think you mentioned that before on TUNES or somewhere else. If ints and bytes is the biggest problem, I don't see how that is a big deal - pull the int
by sedachv 16y ago
Yeah, I think you mentioned that before on TUNES or somewhere else. If ints and bytes is the biggest problem, I don't see how that is a big deal - pull the int out of the array and shift/mask it to get the byte. Or am I missing something here? What I was thinking was going to be hard was structs (although most C code tends not to abuse those too much because padding issues tend to be pretty visible disincentives, but then again there's tons of code that does stupid shit that's unknowingly targeted to GCC exclusively).
- ScottBurson 16y agopull the int out of the array and shift/mask it to get the byte The problem is, you would have to be prepared to do this anytime you're dereferencing a byte pointer. You wouldn't know at compile time whether the pointer points into byte-organized or word-organized memory. You're right about structs, too.
- sedachv 16y agoI still don't see what the problem is - you know the type of memory array you're referencing into (int, byte, whatever), you know the type of pointer you're dereferencing (byte). So is the problem going to be that it will be slow? In portable CL, yes, but there's always ways to get at the implementation's array-accessing internals and fake type-displaced arrays (esp. if you have control over the internals, as this hypothetical project would).
- ScottBurson 16y agoWell, that's a good point. In these days of high-quality open-source implementations, games can be played under the covers that would be impossible in portable CL.