0 Members and 1 Guest are viewing this topic.
Come back soon
Quote from: calc84maniac on December 03, 2011, 07:16:06 pmYou can draw stuff exactly like on the Prizm. The buffer is a 320x240 array of shorts, so you can read and store the pixels directly by array indexing. Basically if you have red value 0-31, green value 0-63, blue value 0-31, you get short color = (red << 11) | (blue << 5) | green;To get the buffer array, you might be able to do unsigned short buffer[320][240] = *(unsigned short**)0xC0000010; I'm not exactly sure of the correct syntax though.Wait, is it supposed to be short color = (red << 11) | (blue << 5) | green; or short color = (red << 11) | (green << 5) | blue;
You can draw stuff exactly like on the Prizm. The buffer is a 320x240 array of shorts, so you can read and store the pixels directly by array indexing. Basically if you have red value 0-31, green value 0-63, blue value 0-31, you get short color = (red << 11) | (blue << 5) | green;To get the buffer array, you might be able to do unsigned short buffer[320][240] = *(unsigned short**)0xC0000010; I'm not exactly sure of the correct syntax though.
Problem is though, I feel like if there are too many testers, the file may go public and others will dive for it..
That said, there is a fine line of balance to be found: too few testers increases the risk to release a product with at least one rough edge, while too many testers might be bad for the reasons stated above
QuoteProblem is though, I feel like if there are too many testers, the file may go public and others will dive for it..Yeah. Of course, anyone caught doing that would instantly become considered an unreliable jackass and be (morally) excluded from the community for leaking sensitive information and thereby helping all too quickly (*) TI work against our elementary rights as users (do what the heck we want with the hardware we own, because we bought it - for short, "freedom to tinker").Under no circumstances should an unpolished, unreliable version be leaked. It would be bad for the community's reputation, both in the open development community (users mistaking the unstable version for the real thing, and saying that it's no good) and TI (mostly, some of their pundits on official, or like-minded, communication channels, could easily blame the community for releasing unstable stuff).That's how it works in other open communities aiming at native code execution on their favorite platform, e.g. gaming consoles, and facing the same kind of manufacturer hostility as we do - and years of experience seem to show that it isn't a bad pattern That said, there is a fine line of balance to be found: too few testers increases the risk to release a product with at least one rough edge, while too many testers might be bad for the reasons stated above (*): the next OS version will certainly fix the holes, even if Ndless 3 is released shortly before the next OS version. TI is very serious about closing the holes, or even the possibility to interact with their calculators through clear-text formats, as they have shown in the past. But giving them more time to close the holes, by releasing raw exploits before there's a companion SDK, doesn't help programmers users in any way - it actually probably hinders them.
Author
Topic: Ndless 3 Alpha on Nspire CX CAS (photos + video) (Read 41160 times)
