This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - willrandship
Pages: 1 ... 9 10 [11] 12 13 ... 208
151
« on: November 25, 2013, 01:29:40 pm »
On my end, an i5 with a haswell core is >$200 USD. The FX series starts at around $120.
152
« on: November 25, 2013, 12:05:06 pm »
@Street I find it odd that you acknowledge the price/perf advantage on AMD/Nvidia, but not on AMD/Intel.
153
« on: November 22, 2013, 08:49:58 pm »
Caleb, Lua is all text, so you should be able to just open up the files and read the source.
I'm not saying you should just use his code without permission, but if you need a reference, it's there.
154
« on: November 21, 2013, 06:29:17 am »
That's still better than the HP Prime format DJ was talking about, though. Pixels as raw bitmaps aren't that bad, especially in a sprite-based engine.
155
« on: November 21, 2013, 04:26:17 am »
UTF-8 has the full range of characters that UTF-16 provides. Special characters are larger, but normal Latin characters are only 1 byte each. UTF-16 is almost always 2 bytes per character, with only the most obscure character sets taking more. UTF-32 is ALWAYS 4 bytes.
All 3 have the same base character range, 4 bytes worth of individual characters. However, the worst case sizes are:
UTF-8: 4 or 6, depending on the standard used. (6 if using the pre-2003 standard, but 4 reduces the theoretical size)
UTF-16: 4 bytes, but the implementation makes this 4 have more chars available
UTF-32: 4 bytes (exact)
The best case, on the other hand, is much more telling:
UTF-8: 1 byte
UTF-16: 2 bytes
UTF-32: 4 bytes
Keep in mind, the unicode character set is far from full. The set is laid out sparsely, with several large gaps. The slight lackings in UTF-8 fall in these areas, giving it full access to all characters.
UTF-8 is used when dealing with memory constraints, and also when using common sense. It's also the newest standard. The primary disadvantages lie in problems with measuring length.
UTF-16 is the "old" way, having been around the longest of any Unicode standard, in many forms.
UTF-32 is nice for slow 32 bit systems, since it is straightforward to interpret. However, usually memory constraints outweigh this.
156
« on: November 21, 2013, 03:57:13 am »
That gives a nice convenience tradeoff, though. The only reasonable change I can think of for that without making some kind of converter would be to switch to UTF-8 or plain ASCII.
157
« on: November 20, 2013, 10:00:41 pm »
The thing about Intel's GPUs is that, while they aren't so good, the drivers for linux support them fully. The GPUs in the newer ones aren't THAT bad, and they have great linux support with open source drivers.
159
« on: November 20, 2013, 07:06:13 am »
People always say you can't get high-res consoles because of the lack of KMS, but in my case at least, the default resolution is native. I think nvidia provided its own method for text-mode resizing, since AFAIK the KMS issue has not yet been addressed.
160
« on: November 19, 2013, 02:42:07 am »
There's no semicolons. Even if it was a one-liner, it couldn't be C++, Java, or any other language that requires them after every statement.
161
« on: November 18, 2013, 11:57:45 pm »
Juju, that's what's called an infinity mirror.
You place two mirrors, one translucent, close to each other, and mount LEDs in the gap.
162
« on: November 18, 2013, 11:56:56 pm »
It makes sense to have a system set of variables that can be transferred from program to program, but it would also be nice to have local-program variables. It seems like having both should be an option.
163
« on: November 18, 2013, 11:19:55 pm »
That is not C++. It looks a little like perl, but it's definitely NOT c++.
164
« on: November 18, 2013, 04:10:32 pm »
quitte, they do it that way because it's much easier on the OS's end. No namespacing, no reserving room for a growing set of variables, no tracking data and reassigning it. I'm not saying it's ideal, but it's much faster. In a compiled language like C, all this work is done before the program ever launches. The same is true for most of the other languages, like Java or Python. They consolidate all the memory storage before they run. However, this is a completely interpreted language, so these calculations would have to be done in real time, every time you want to enter a new variable namespace.
On an embedded environment like this, the CPU time and RAM used for this process are not negligible.
Also, DJ_O, your point about compatibility is very important.
If you want a better variable stack, just implement a better language and ignore the on-calc programming.
165
« on: November 18, 2013, 03:59:20 pm »
Actually Win CE can run as low as 1 MB for the kernel alone. The gizmondo ran it, with only marginally better specs than the nspire. http://en.wikipedia.org/wiki/GizmondoKeep in mind there is no ARM version of win 95/98/XP/etc. The only ARM windows that would be suitable is CE, outside emulation. If you really want emulation, keep in mind the ~6x performance penalty. That would reduce the 150 on the nspire to less than the 33 MHz standard used by most DOS computers.
Pages: 1 ... 9 10 [11] 12 13 ... 208
|
Show Posts
