Javanaise/mrboom-libretro

asm2c problems

Closed this issue · 13 comments

I made edits to Resources/asm.h and Sources/Nodes.swift for cross-platform support (unaligned casts, libretro, msvc). Then tried to compile p.asm from https://github.com/bparker06/mrboom30.

Converted file paths from '\' to '/'. Then got stuck on this.

bomb.inc

;utilise Esi par rapport a truc2 pour gauche/droite.
bruit2 9 34 BLOW_WHAT2 ;bruit du bonus tri bombe.


asm2c

line 1 macroError("Error macro: <bruit2> 3 args [\"9\", \"34\", \"BLOW_WHAT2\"] but  2 expected Line:<bruit2 9 34 BLOW_WHAT2 > MACRO:<name: bruit2(a,b) \n\n\n\n\npush ebp\npush eax\npush esi\npush ebx\nmov al,a\n\n\n\nsub esi,offset truc2\nand esi,011111B\n\nmov bl,byte ptr [panning2+esi]\nshl ebx,4\n\nor  al,bl \n\nmov ebp,[last_voice]\nadd [last_voice],2\ncmp [last_voice],14*2\njne op\nmov [last_voice],0\nop:\n\nmov byte ptr [BLOW_WHAT2+ebp],al   \n                               \nmov eax,[changement]\nand eax,010B\nadd eax,b\n\nmov byte ptr [BLOW_WHAT2+ebp+1],al \n\npop ebx\npop esi\npop eax\npop ebp\n\n> [\"a\", \"b\"]")

Tried removing BLOW_WHAT2 and got this new one.

ERROR: evaluateExpr:  m.nb_dyna

Fatal error: Can't form Range with upperBound < lowerBound: file /Library/Caches/com.apple.xbs/Binaries/SwiftPrebuiltSDKModules_macOS/install/TempContent/Objects/EmbeddedProjects/CrossTrain_macOS_SDK/macOS_SDK/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/swift/Swift.swiftmodule/x86_64.swiftinterface, line 4781

Cosmic alien language to me.

I have a conversion script and a modified version from https://github.com/bparker06/mrboom30 will push it soon.

@SimpleTease I just pushed, make sure you also pull asm2c.

Works correctly. I'll start playing around with merging the asm and see where I go.

Have to fix binary dumper for msvc. Then we should be done here.

Is mrboom.heap still the same values as mrboom_data.c? Because then I can copy-paste the msvc fixed version.

This is the value for the heap variable
db heap[HEAP_SIZE];
It's a hack and asm2c uses the heap file as a default for that variable.
I ran the sdl2 version that does some unzipping/decrunching in the first frame, then dumped the heap value and used it for the retrolib version so it doesn't need to have temporary files, since that was an issue for android.

Maybe a debug option to compile the SDL2 version so that it dumps the graphics data would be nice.

I ran the sdl2 version that does some unzipping/decrunching in the first frame, then dumped the heap value and used it for the retrolib version

Okay. So the heap value hasn't changed in awhile, since this commit?
e074baf

I'll need to patch sdl2 heap dumper for msvc compatible.

Maybe a debug option to compile the SDL2 version so that it dumps the graphics data would be nice.

That would make sense.

I don't think it ever changed since it was introduced, the assembly code is not moving much.

Dumping graphics data means raw indexed values + palette table?

I meant the heap variable value, the palettes are not on the heap. there is only raw pixels and recorded games files. (for the demo mode)

BTW be careful with movsx, I remember there was a bug and it's not the the most tested instruction since I wasn't using it much.