@ slightly different memory space: Yes, a register typo, causing a read-from address diviation of about slightly
12 million bytes... But the bug itself was no problem (intel project is finished
), just the strange behavior deviation due to filename is confusing.
@intel project: great to hear
@strange behaviour: don't be too much confused. That kinda weird results can happen if you access an unallocated memory space.
Depending on the memory location the game gets loaded to, you access a different place in ram memory. And depending on the filename, windows probably loads the exe to a different location.
So it's probably just bad luck naming it "trek.exe" crashed the game (or good you detected the bug).
You might find other names that result in crashes as well. And when you reload your system things might change.
windows os internals are a hidden secret with strange windings, not that I know more on linux internals.
QuasarDonkey wrote:maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
Checking such things (before posting/asking) is self-evident and base for any conversation.
So a clear no.
Well, talking to genious Tribble that might be, but remember us 'normal brains' one time might conceal to tell you of a major importance cause we got wrong in assuming it would be self-evident to you.
In other words, it doesn't harm to mention, does it?
Spocks-cuddly-tribble wrote:The conclusion from the incident (for my PC) is always naming the newest test version trek.exe, since maybe some sort of OS error correction trial (sometimes mentioned by OllyDbg?) unveiled a serious bug which otherwise remained undetected (i.e. much more work later).
Do so, but as a programmer I've to say that it would withdraw from any plausible logic to me, if naming it 'trek.exe' would be more error detective than other names.
An unrelated/unimportant question wrt recource consumption (*mul/*div):
I just skimmed through a few links like the following, but couldn't find hints if there is a mentionable difference between integer arithmetics & FPU?
Also these nerds show a visceral antagonism to come short and clear to the point, worse than a sewing circle^^. Any hints on how to set this sort of folks back on the right path... treating with a pair of pliers and a blow torch?
Depends on cpu design, but commonly integer arithmetic is faster than floatingpoint and multiplication normally is faster than division. To get a factor I'd have to set up some tests, dunno. But if the calculation isn't done a million times it shouldn't make too much of a difference. To improve general speed you do better in trying some performance profiling to identify code causing slowdowns.
P.S. @nerds forum: what, are you interested in mmx coding now?
I pretty much understand nothing from what they write over there and have no motivation for it either.