ptitSeb
Serial Porter
"Stay a while and listen"
That's great. Well done @notaz !
That's great. Well done @notaz !
no stretching... I don't need fat adventurers.^ and make the game fill/stretch the entire Pandora screen
So do I, but I'd still rather have black bars than a distorted image.I hate to see spaces on the sides not get used
I have a few ways to deal with this, one is annotating the disassembly to give hints for the translator, which also allows limited form of patching. The other thing is copying some functions away to another .c file for more extensive changes and annotating the same function in disassembly so that the translator skips it. As for renaming things, I do that in the disassembly itself, which may make the "manual" functions out of date, yeah, so I leave those for final stages of the project.@notaz What is your current strategy for working on this; more specifically: you have taken the x86 binary, and ultimately reversed it into C code. You then are making some tweaks to the C code to fix issues. Is it the case that sometimes you are making improvements/fixes to the x86 binary -> C phase, and when that happens do you have to keep reapplying your fixes to the C code? Or is the x86 binary -> C phase stable, and it is purely C code changes you are currently making? I half imagine that as you look at the C code and identify what things do, perhaps you are renaming some functions/variables/etc. and losing that if the x86 binary -> C phase changes would be quite annoying.
I don't want to do that, it's still their code after all. And yes functions are in huge .c files, one file for each exe/dll that takes upto several minutes to compile. Each "huge .c" is regenerated when I build the project, and "manual" functions (which are not many) sit in their own .c file.Related to the above, are the C files (I am guessing there are multiple files, split per DLL/exe? or perhaps split further based on some logic?) something that could ultimately be shared on GitHub? Or do you feel this would cause too many problems with Blizzard?
Yes that could be done, if you can think of a good way to identify the offending code. With the mouse/touchscreen problem it wasn't too hard, just a matter of finding the window procedure (found through RegisterClass() call), and then reading the x86 disassembly and sprinkling some printfs in translated code and doing some trial-and-error runs to help identify the exact code responsible for handling clicks in various situations.And last but not least, if we wanted to make any tweaks to the game, how 'possible' would that be given access to the C code? For example, I often found that it was almost impossible to find rings that had dropped onto the floor. In the end I had to just slowly move my cursor across the entire screen to find it. I was wondering whether with an afternoon/day looking over the code, a competent programmer would be able to identify where rings are being drawn, and find a way to get a label to be printed next to it.
It's more problematic that it looks, I'd need to rework wine to use the scaler layers (or scale manually) and redo input for touchscreen scaling too. Maybe the hd mod (linked earlier in this thread) will release their source someday, then you can have it.^ and make the game fill/stretch the entire Pandora screen
Yeah that's one of several menu problems I mentioned.One minor bug i found...on main menu selecting replay intro... the video is played fine but out of the border is visible parts of main menu graphics....but it's not very important.
Many thanks for that, you once more achieved something great!
You're all welcome, I'm also happy to finally have it working.Big thank notaz!!