I worked out a hack-ish way of passing strings OUT of the vm to the owning application by also passing a reference to the vm into the service function, and supplying the vm with a Text(int Address) method that returns a std::string copy of the null-terminated string in the vm's text segment, so in the script you can cast the address of a string to an int and put it in a register, then use the register and the Text() method in the service function to get a copy of the string.
I'd really like (not for Udo, but for future use of my scripting system) to be able to pass strings in as well, but the trouble is that since the vm has no concept of a heap and all string data is effectively static, this is not so straightforward.
There are two possible approaches I can see, both of which would require a significant re-write, so probably better be a new scripting engine not for use in Udo:
1) Give the vm a heap, and some instructions for manipulating it. This has some advantages in that the scripting language could then support pointers, concatenation of strings and all the other dynamic stuff. The disadvantage would be that the vm would then have to manage its heap, either by manual deletes or by a gc. I could probably find ways to combat fragmentation but it would all be quite complicated.
2) Use a memory mapping system so that as well as accessing its own memory (basically a big char array), the vm could also access other system memory directly, but transparently so that the vm thought any additionally registered memory was part of its own, and have a memory mapper layer built in to all the internals of the vm that access its memory. This would have all the advantages of the above, while pushing the memory management back out to the OS and the C++ runtime, but would be a lot harder to implement efficiently.
[EDIT - that second idea is stupid]
The first idea has some merit. If the vm had its own heap as well as its current program, data, text and stack segments, it would vastly increase the flexibility of the system and seems less complex than the second option.
Ho hum.
Udo
Anyway, now that's done I'm at the horrible point in the game cycle where the main thing that Udo needs is lots of levels designed and lots of graphics, which is where I generally start to tail off a bit.
My map editor makes it fairly easy to put levels together, but not exactly a breeze since Udo has multiple map layers to worry about, plus now a scripting system as well.
I need to just keep my head down and push forward with this since the only criticism anyone made of my last game was that it was too short. I reckon I need to just keep believing in the project and hammer out like a level a night or something for a couple of weeks.
Times like this make me really respect Stompy999 for the plethora of BlockyMan levels.
