Release Starcraft


btw, why is it necessary to go to C first (why not go from x86 asm -> arm asm)??
 
@Exophase -


Sorry without Issues... happens when I type fast.
 
Last edited by a moderator:
I had a crash, mission 1 Protoss campaign. 1GHz, I was sending my group at south. Brightness and gamespeed to max. Seems i attack-clicked in the fog, but can't really tell what triggered the bug.

Here's the log:

Code:
couldn't load main module (2)
Unhandled exception: page fault on read access to 0x0000011d in 32-bit code (0x40e93a7c).
Register dump:
ARM User Mode
 Pc:40e93a7c Sp:4125fb90 Lr:40dcf4a0 Cpsr:a0000010(N-C-)
 r0:00000041 r1:00000005 r2:ffffffff r3:ffffffff
 r4:ffffffff r5:40f61aa0 r6:00000041 r7:00000005
 r8:4107de18 r9:00004944 r10:00004478 Fp:4125fcc8 Ip:405105cc
Stack dump:
0x4125fb90:  00004478 ffffffff 00000005 40e93a3c
0x4125fba0:  00000005 40f61aa0 4125fbf0 40dcf4a0
0x4125fbb0:  41126ee4 40dc0000 00000041 00000041
0x4125fbc0:  40dcf360 40f61aa0 41126de8 4125fbf0
0x4125fbd0:  4125fc34 40d93264 410f60f8 00000005
0x4125fbe0:  40f61aa0 00000af0 4125fc10 40dc15b0
Backtrace:
=>0 0x40e93a7c (0x4125fcc8)
  1 0x40dcf4a0 (0x4125fcc8)
0x40e93a7c: 
	ldr	r3, [r6, #220]
Modules:
Module	Address			Debug info	Name (29 modules)
PE	400d0000-400d4000	Deferred        version
PE	40480000-40484000	Deferred        ntdll
PE	40a50000-40bec000	Deferred        kernel32
PE	41270000-412ab000	Deferred        user32
PE	413a0000-413a7000	Deferred        gdi32
PE	414a0000-414a4000	Deferred        advapi32
PE	41500000-41504000	Deferred        imm32
PE	41540000-41544000	Deferred        msvcrt
PE	415c0000-41636000	Deferred        winmm
PE	41690000-41698000	Deferred        ole32
PE	41780000-41784000	Deferred        rpcrt4
PE	41800000-41809000	Deferred        msacm32
PE	41830000-4198e000	Deferred        shell32
PE	41a50000-41a58000	Deferred        shlwapi
PE	41ab0000-41b48000	Deferred        comdlg32
PE	41ba0000-41bcf000	Deferred        comctl32
PE	41c80000-41c8a000	Deferred        winspool
PE	41dc0000-41dc4000	Deferred        winex11
PE	420b0000-420b4000	Deferred        uxtheme
PE	42620000-42624000	Deferred        psapi
PE	42800000-42804000	Deferred        ddraw
PE	42870000-42874000	Deferred        wined3d
PE	429b0000-429b4000	Deferred        opengl32
PE	42be0000-42be4000	Deferred        dsound
PE	42c20000-42c24000	Deferred        mmdevapi
PE	42c60000-42c68000	Deferred        oleaut32
PE	42d50000-42d53000	Deferred        winealsa
PE	45230000-45233000	Deferred        tapi32
PE	45a80000-45a84000	Deferred        dbghelp
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Z:\mnt\utmp\starcraft\libscr_sa_arm.exe
	00000025    2
	00000024    0
	00000023   15
	00000022    0
	00000021    1
	00000009    0 <==
0000000e services.exe
	0000001c    0
	0000001b    0
	00000014    0
	00000010    0
	0000000f    0
00000012 winedevice.exe
	00000018    0
	00000017    0
	00000013    0
00000019 plugplay.exe
	0000001e    0
	0000001d    0
	0000001a    0
0000001f explorer.exe
	00000020    0
System information:
    Wine build: wine-1.7.13-15-g7349586
    Platform: arm
    Host system: Linux
    Host version: 3.2.53
 
Last edited by a moderator:
btw, why is it necessary to go to C first (why not go from x86 asm -> arm asm)??
It has several advantages. First one is debugging, it just makes debugging a lot easier by compiling back to x86. This allows to do work in small increments by combining original asm code pieces with recompiled C, which allows isolating recompiler bugs rather quickly. Another is convenience and perhaps performance, you get things like ARM calling conventions taken care of by the C compiler, it also makes use of all ARM registers (with direct conversion you'd have half of them unused as IA32 only has 8), cortex-a8 dual issuing and so on. C compiler warnings are also helpful and often point to recompiler bugs.
I had a crash, mission 1 Protoss campaign. 1GHz, I was sending my group at south. Brightness and gamespeed to max. Seems i attack-clicked in the fog, but can't really tell what triggered the bug.
Do you have full pndrun*.out?
 
Last edited by a moderator:
Arh, i relaunched the game after the crash, i even halted my OP, so no :/ .

I'll think about it from now on.
 
Max Payne please :)
Again this is lots of manual work, not "just" (which is still a lot of work) changing some code in the source file and compile.
 
Shenmue you prick, how dare you making jokes in such a serious thread? Go back to what ever hell that spawned you, you are condemned. :p
 
I'm going to check this on my work computer.... but aren't scvs supposed to auto repair when parked next to a building that's taking damage?

My scvs don't do anything unless you tell them... maybe I'm just getting confused with SC2.

That's the only possible bug i've found, and yes I had to check myself... landing a building does indeed crash the game, even on 1.15.2
 
Don't recall SCV'S doing anything automatic like that.
 
He, actually, I just looked and you can buy the game in Germany for 3,90 EUR online :)

http://www.gameliebe.com/starcraft-broodwar-download-online-kaufen.html

That's simply a key for StarCraft + Broodwar on battle.net, so  yay, pretty neat price :D
I've got myself this one at the release of StarCraft 2 when it was still cheaper:

http://www.amazon.de/Activision-Blizzard-StarCraft-inkl-Broodwar/dp/B00005LZX3/ref=sr_1_1?ie=UTF8&qid=1394094711&sr=8-1&keywords=starcraft+gold
 
Last edited by a moderator:
My scvs don't do anything unless you tell them... maybe I'm just getting confused with SC2
I can't remember with SC1 pretty sure you can't. In SC2 you still have to right-click the repair icon to activate autorepair, it's not automatically enabled
 
Back
Top