Floating point variable support in ram search/watch, and miscellaneous related changes

[GoogleCodeExporter]

Currently ram search and watch are not as useful in hourglass as they are in 
gens and other console emulators, because they do not support floating point 
variable types, and floating point variables are very common even in very 
simple indie PC games. Therefore, I think getting floating point variable 
support in these is fairly important to hourglass's usability as a TAS platform.

Because floating point variables commonly occur only in a few specific sizes, 
it seems like a good idea to merge "data size" and "data type" options to 
provide for a few types of pre-specified sizes. I'd recommend options for int8, 
int16, int32, int64, float32, float64, float128, and pointer. Pointers would 
display in hex and otherwise behave as int32s. For the other types, I'd 
recommend providing a checkbox to toggle signed/unsigned.

Original issue reported on code.google.com by Upth...@gmail.com on 7 Jun 2011 at 12:15

[GoogleCodeExporter]

Original comment by Upth...@gmail.com on 7 Jun 2011 at 12:30

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Also, I think RAM search only lets you search a very limited region of the 
address space used by the application, which makes it pretty useless in 
anything but Cave Story, and I can't tell it to simply search all of it because 
that has insane RAM requirements. A complete overhaul is probably required, 
since what worked well in Gens isn't as applicable here. For now maybe it's 
better to simply point people to MHS, which probably already does the job 
better.

Original comment by nitsuja-@hotmail.com on 7 Jun 2011 at 4:53

[GoogleCodeExporter]

Done in r56. Not quite how you recommended it:
- Data size and data type options remain separate, since that gives more 
flexibility.
- I've never heard of anyone using 128-bit primitives except to represent four 
32-bit items or two 64-bit items, and 80-bit "long double" is very rarely used 
(and often compiles to a 64-bit double anyway), so I didn't add float128.

Original comment by nitsuja-@hotmail.com on 17 Jul 2011 at 11:26

• Changed state: Fixed