Gosh guys, I'm fucking telling you that I am specifically talking about reads from procedures that can read unaligned data. If your game only uses asm/thumb, it is always going to be word-aligned. However, many games use ingame scripting and crazy tables that do not necessarily need to be word aligned because of the nature of the data stored. It would be silly to have an ingame scripting engine that only has four byte long opcodes just because then pointers would be aligned!

Also, it sounded like it might be such a case when he already found odd offsets, at least that's what I got from the posts.

cYa,

Tauwasser

There's something wrong if you think you need text conversions to swap bytes.

i can say this -- my code for doing similar stuff is in C/C++. i'm using Borland C++ 5.0 to compile, which for whatever reason seems to yield much faster-running code than visual studio. (i probably don't know which checkboxes to check to remove debug, optimize for speed, etc. -- also, i'm comparing a SUPER OLD compiler for DOS command line to a recent compiler that may not care THAT much about speed )

i also don't load the file into RAM. i'm not actually sure i should change it to do so, because the way it works now, the program runs separately for each file inserted. (and then quits, and then is run again, etc. using command line scripting.) *each time* a string is inserted, it searches an area of the ROM for relevant pointers -- this relevant area can be anywhere from 50k or so to about a meg. (yeah, it would probably make more sense to record these pointer locations so you only have to do it once, but i'll revise it to work that way once atlas is updated to have the features i want (KLARTH!) ) while the process is pretty darn slow, it's not THAT slow... inserting a crapload of game text (probably like 70% of it, rough estimate? like 300k or so?), doing probably thousands of pointer searches, takes maybe a few minutes, total, on my core 2 duo 2 ghz system.

so i guess my point is, between your choice of language and your coding style, there is probably some SERIOUS inefficiency   glancing at your code, i can see the following:
- i assume that those App.DoEvents in the middle of the loops passes control to the windows application to let it do its thing, like increment the progress bar and check to see if any events have been triggered. having that execute EVERY TIME will slow things down like crazy. either get rid of it (no progress bar, sorry), or do it every so often, or something.
- there's no point in forming the full pointer and then string comparing it to the pointer you're looking for, or whatever. compare them byte by byte in nested if statements (which looks a bit messier but would be faster... the way it's written right now i doubt the compiler can manage to optimize it well). it would look something like:

if first byte matches then
{
  if second byte matches then
  {
    if third byte matches then
    {
      found = true, etc.
    }
  }
}

Why do you compare it like that? BRPXQZME already posted an example where you just get the pointer as long and compare those two then. Of course then you can just do the math on your own and times the pointer you are comparing by 0x100 (and with 0xFFFFFFFF when necessary) and then ORing the next byte of the stream and so on. Those are all bit-operations so they should be pretty fast, too! Also, like I said, you could even use a little heuristic and look if the MSB is 0x08 or even 0x09 if your rom is really big. That way you don't even look at all the stuff in there.

cYa,

Tauwasser