may I do 64 bit in blitz plus?
BlitzPlus Forums/BlitzPlus Beginners Area/may I do 64 bit in blitz plus?
| ||
| Hi, With the changes to 64 bit coming I wonder if I can just put "64" behind (1024,768,64) in the graphics call? Would it work or not. I cannot play 64 bit myself (xp, 128mb NVidia 32 bit) but I wonder if it would work on a completed program with that (64) being the only change? Any input? I see on wiki that most 64 play 32 by default. Any input? Gerald |
| ||
| No. the 32 in 1024x768,32 means that it uses 32-bit colors (8 shades of green, red, blue and alpha, = 4.2 billion colors. You can use ,16 to use 16 bit (=65536 colors), but those are the only two options. Pretty much all modern video adapters support 32 bit color, while really old ones may be limited to 16-bit colors. Pretty much no computer will support more than 32-bit colors. the graphic statement has absolutely nothing to do with making something a 64-bit program. There are some inherent differences between 32-bit and 64-bit programs, most notably that a 32-bit program can address 2^32 bytes of memory (=4GB max) while a 64-bit program can address 2^64 bytes of memory (billions of gigabytes, essentially limitless). there are some other minor differences with regards to some optimizations and CPU registers, but for the most part they remain very similar. To create a 64-bit program, you need a 64-bit aware compiler. There are a lot of 'behind the scenes' changes necessary for a program to be able to make use of the 64-bit fetures, and blitzplus is NOT aware of any of those. You can only create 32-bit programs. given Blitzplus' age and lack of ongoing development, it's extremely unlikely that a 64-bit compiler will ever be released. (For that matter, Blitz3D and Blitzmax are both also limited to 32-bit executables) |
| ||
| There are a few distinct parts to the answer to this question: 1) No. BlitzPlus does not support 64-bit in any capacity and this is not going to change in the near future (would require a compiler rewrite). It doesn't even support 64-bit math. 2) The above isn't actually a problem: 64-bit CPUs can run 32-bit code on the metal anyway, and 64-bit Windows provides a 32-bit emulation layer, and will continue to do so for at least the next ten years. (Other OSen are not so reliable with the backwards-compatibility, but since BlitzPlus is Windows-only you don't need to care about them.) 3) The part of the code that you're looking at has nothing whatsoever to do with 64-bit computing. It refers simply to colour depth, i.e. the number of colours the screen can display. Since 32-bit colour depth already exceeds the precision of the human eye, it is highly unlikely that anyone will ever build a 64-bit screen, because it wouldn't achieve anything. The fact that the code is 32-bit and the colour depth of the graphics layer is also 32-bit is actually more or less a coincidence (it's a nice round number). The truth is that the "jump to 64-bit" is something that you probably want to avoid thinking about for the most part. If you write code that's heavily abstracted away from the machine level (e.g. JavaScript, which isn't allowed to know whether it's running on a 32- or 64-bit machine), you can just trust the compiler or interpreter to do its job and use whatever is best. BlitzPlus in turn relies on the OS to handle that. If you do want to think about it, you should be aware that it requires you to know about how things work at the machine level, and also that if your code isn't so high-level that it can port itself, it will likely need to be rewritten. e.g. A lot of existing Blitz code relies heavily on the assumption that machine pointers and 32-bit integers are completely interchangeable; this would need to be rewritten manually to have any hope of working properly when compiled for 64-bit. |
| ||
| Hi, Thanks for the input. I see I am off base on the meaning of the 32's and 64's. Color depth, not bits. Gerald |
   |