Talk:Oni engine patches (Mac PPC)

From OniGalore
Revision as of 02:02, 7 October 2008 by Iritscen (talk | contribs) (responding to my part; also, ergo is a good word, although whoever used it in this sentence, http://carnage.bungie.org/oniforum/oni.forum.pl?read=19866, should be severely PUNished)
Jump to navigation Jump to search

Just tested the upgrade for 1024x1024 and Oni crashed. First of all OniSplit works fine with a 1024x1024 targa image, I can import and export.

When I imported a 1024x1024 image (delorean.tga) I got the level 4 splash screen, but then I got a black screen, I had to force quit Oni. So no crash report. Next I did the same image at 512x512, same result, except this time I got Oni's crash report. Here it is:

Process: Oni (1.0 (Mac OS X) (v1.36) (01/28/03))
exception = 0x00000001, code = 0x00063328;0x00000001;0x88428882;

5 threads:
Thread 0:
srr0: 0x9000b348  srr1: 0x0000d030   cr: 0x24022024  xer: 0x00000000  lr: 0x9000b29c ctr: 0x9000b340
r0: 0xffffffe1  r8: 0x00000000  r16: 0x00000000  r24: 0xf0182840
r1: 0xf0182770  r9: 0x00000000  r17: 0x00000000  r25: 0x00000450
r2: 0xa1b1c1d3  r10: 0x91444fa8  r18: 0x00006803  r26: 0x00006603
r3: 0xf0182840  r11: 0xa0006a28  r19: 0x00000000  r27: 0x00000000
r4: 0x03000006  r12: 0x9000b340  r20: 0x05c8046a  r28: 0x00000000
r5: 0x00000000  r13: 0x00000000  r21: 0x177348d1  r29: 0x03000006
r6: 0x00000450  r14: 0x00000000  r22: 0x0063e7b8  r30: 0x03000006
r7: 0x00006603  r15: 0x00000001  r23: 0x00000000  r31: 0x907de670
   0 -- 0x9000b348 -- _mach_msg_trap
   1 -- 0x9000b29c -- _mach_msg
   2 -- 0x907de998 -- ___CFRunLoopRun
   3 -- 0x907de29c -- _CFRunLoopRunSpecific
   4 -- 0x91458524 -- __ZN10HALRunLoop9OwnThreadEPv
   5 -- 0x914582c4 -- __ZN9CAPThread5EntryEPS_
   6 -- 0x9002bd08 -- __pthread_body

Thread 1:
srr0: 0x00063328  srr1: 0x0000f030   cr: 0x84000248  xer: 0x00000004  lr: 0x0012aec8 ctr: 0x0b127490
r0: 0x0012aec8  r8: 0x00186418  r16: 0x00000000  r24: 0x00000000
r1: 0xbffff9e0  r9: 0x88428842  r17: 0x00000000  r25: 0x00195f6d
r2: 0x0b207498  r10: 0x0b127498  r18: 0x00000000  r26: 0x00000000
r3: 0x00000000  r11: 0x0187de20  r19: 0x00000000  r27: 0x00000000
r4: 0x000003fc  r12: 0x00063300  r20: 0x00000000  r28: 0xbffffb28
r5: 0x000003fc  r13: 0x00000000  r21: 0x00000000  r29: 0x001910bc
r6: 0x0019624c  r14: 0x00000000  r22: 0x00000000  r30: 0x00218c3c
r7: 0x43300000  r15: 0x00000000  r23: 0x00000000  r31: 0x0012afb4
   0 -- 0x00063328 -- _ONrGameState_GetEnvironment
   1 -- 0x0012aec8 -- _P3iDisplayDecals
   2 -- 0x0012afc4 -- _P3rDisplayStaticDecals
   3 -- 0x00062b38 -- _ONiGameState_Display_Reflectable
   4 -- 0x00062d20 -- _ONrGameState_Display
   5 -- 0x00003d48 -- _ONiRunGame
   6 -- 0x00004610 -- _ONiMain
   7 -- 0x0000470c -- _main
   8 -- 0x00002b40 -- __start
   9 -- 0x00002970 -- start

Thread 2:
srr0: 0x90054388  srr1: 0x0200f030   cr: 0x24008244  xer: 0x00000000  lr: 0x90070be8 ctr: 0x90054380
r0: 0xffffffd9  r8: 0x91468918  r16: 0x00000000  r24: 0x00000000
r1: 0xf0284b00  r9: 0xa0001fac  r17: 0x00000000  r25: 0xa00009dc
r2: 0x00000001  r10: 0x00acc0d9  r18: 0x00000000  r26: 0x0063ff94
r3: 0x00000031  r11: 0xa0006be0  r19: 0x00000000  r27: 0x0063ffc0
r4: 0x00002f03  r12: 0x90054380  r20: 0x00000000  r28: 0xf0284bb0
r5: 0x00000000  r13: 0x00000000  r21: 0x00000000  r29: 0xa0001fac
r6: 0x00acc0d9  r14: 0x00000000  r22: 0x00000000  r30: 0xa0001fac
r7: 0xf0284d58  r15: 0x00000000  r23: 0x00000000  r31: 0x900709dc
   0 -- 0x90054388 -- _semaphore_timedwait_signal_trap
   1 -- 0x90070be8 -- _pthread_cond_timedwait_relative_np
   2 -- 0x914696ac -- __ZN7CAGuard7WaitForEy
   3 -- 0x914695bc -- __ZN7CAGuard9WaitUntilEy
   4 -- 0x91467800 -- __ZN11HP_IOThread8WorkLoopEv
   5 -- 0x91467498 -- __ZN11HP_IOThread11ThreadEntryEPS_
   6 -- 0x914582c4 -- __ZN9CAPThread5EntryEPS_
   7 -- 0x9002bd08 -- __pthread_body

Thread 3:
srr0: 0x9003288c  srr1: 0x0000d030   cr: 0x82000002  xer: 0x00000000  lr: 0x33332814 ctr: 0x90032880
r0: 0x00000007  r8: 0x00000000  r16: 0x00000000  r24: 0x00000000
r1: 0xf00807d0  r9: 0xa0010204  r17: 0x00000000  r25: 0x00000000
r2: 0x000000d9  r10: 0x90032824  r18: 0x00000000  r26: 0xf0080bec
r3: 0x00005997  r11: 0x42000008  r19: 0x00000000  r27: 0x00063328
r4: 0x00000000  r12: 0x90032880  r20: 0x00000000  r28: 0x00000001
r5: 0x00000000  r13: 0x00000000  r21: 0x00000000  r29: 0x00005997
r6: 0x00000000  r14: 0x00000000  r22: 0x00000000  r30: 0x00000002
r7: 0x00000000  r15: 0x00000000  r23: 0x00000000  r31: 0x333325c8
   0 -- 0x9003288c -- _wait4
   1 -- 0x33332814 -- _OCCHandleException
   2 -- 0x33331e34 -- _OCCExc_catch_exception_raise_state_identity
   3 -- 0x333329cc -- __Xexception_raise_state_identity
   4 -- 0x33332adc -- _OCCExc_server
   5 -- 0x33331ee0 -- +[OCCCrashCatcher(MachPrivate) _handleExceptions]
   6 -- 0x92bf6118 -- _forkThreadForFunction
   7 -- 0x9002bd08 -- __pthread_body

Thread 4:
srr0: 0x9002c3c8  srr1: 0x0000f030   cr: 0x24000084  xer: 0x00000000  lr: 0x90030eac ctr: 0x9002c3c0
r0: 0xffffffdb  r8: 0xf0101a00  r16: 0x00000000  r24: 0x00000000
r1: 0xf0101c80  r9: 0xa0001fac  r17: 0x00000000  r25: 0x00000000
r2: 0x00000001  r10: 0x90a3f628  r18: 0x00000000  r26: 0xa0000cdc
r3: 0x00003003  r11: 0xa0006bf4  r19: 0x00000000  r27: 0x00627168
r4: 0x00002d03  r12: 0x9002c3c0  r20: 0x00000000  r28: 0xa0001fac
r5: 0x000003e8  r13: 0x00000000  r21: 0x00000000  r29: 0x00627194
r6: 0xffffffff  r14: 0x00000000  r22: 0x00000000  r30: 0xa0001fac
r7: 0x000000ff  r15: 0x00000000  r23: 0x00000000  r31: 0x90030cdc
   0 -- 0x9002c3c8 -- _semaphore_wait_signal_trap
   1 -- 0x90030eac -- _pthread_cond_wait
   2 -- 0x92bfd284 -- -[NSConditionLock lockWhenCondition:]
   3 -- 0x001548a4 -- -[SoundChannelProcessor(Private) _processQueue]
   4 -- 0x0015483c -- -[SoundChannelProcessor processQueueForever:]
   5 -- 0x92bf6118 -- _forkThreadForFunction
   6 -- 0x9002bd08 -- __pthread_body
Ed
Hm, I didn't notice you had tried 512x512 before and still got a crash. Oh well... "the truth is somewhere completely different". Sorry.
geyser 11:40, 13 August 2008 (CEST)
Maybe this will be a clue, when using the new hex of 10, I was able to start level 4. Oni only crashed when the delorean (Using the new 512x512 texture) came into view. Previously, with the hex at 40, Oni crashed right after the splash screen. EdT 15:49, 13 August 2008 (CEST)
I have tested some more on my side and it turned out that the mysterious crash for 1024x1024 textures was some kind of user error (like forgetting to save or something equally stupid). So 1024x1024 works just fine on PC now, and there is thus no similarity between our cases anymore. Also, the crash right after the splashscreen (which one, BTW? intro splashscreen of a level?) seems very suspicious. So, could you please: 1) double-check that you're changing stuff at the right address; 2) let us have a look at the engine after you patched it. --geyser 21:48, 13 August 2008 (CEST)
I tried the 512 patch on a fresh unpatched version of Oni. Same result. I can start level 4, move around, but when I turn to look at the Delorean, Oni crashes. I'm using the files you provided with the new M3GM and OBAN files. However, if I change TXMPdelorean to 256x256, no crash. When I used the previous patch of 40, then Oni would crash after the splash screen for level 4. Note: in both cases, I had imported the TXMPdelorean file into level4 not level0. Here is the patched engine: http://edt.oni2.net/files/Oni512.zip EdT 01:14, 14 August 2008 (CEST)
Sorry for the late reply. Let's run a clean experiment on your side while we double-check OMNI's engine:
  1. Try and import another large texture than the DeLorean's (a skybox, a poster, Master Chief, anything) and test this other large texture without involving the DeLorean at all. Make sure that you rule out everything else that may make Oni crash (e.g., an old M3GM).
  2. As for the DeLorean, make sure its M3GM was imported with a recent version of OniSplit: it could be that it suffers from the same issue as the one that used to plague early TRBS import (i.e., it may be missing extra storage space at the end of the TXCA).
Let us know if it still crashes for the "clean experiment" (just a texture replaced with a large one). And oh, if it crashes, send us the TXMP, just in case.
geyser 15:33, 21 August 2008 (CEST)
hmmm, time for a stupid question, what is the option in OniSplit to create a 512x512 TXMP? I just tried to import a 512x512 texture, but when I exported that file it was 256x256. I imported these files: http://edt.oni2.net/AE_Files/TXMPAIR_FLOOR002.tga and http://edt.oni2.net/AE_Files/TXMPPOSTER1.tga for the Airport lobby floor and posterEdT 23:52, 21 August 2008 (CEST)
So you mean that all this time you were in fact letting OniSplit downsample your textures to 256x256? Then I really don't understand what about the texture may have caused the crashes you reported. The option for disabling the auto-downsampling (and thus retaining the native size of your picture) is -large, e.g.: OniSplit.exe -create:txmp TXMPcreated -format:bgr32 -large TXMPPOSTER1.tga --geyser 00:24, 22 August 2008 (CEST)
No, that's not the case. The first account with the 1024x1024, I used the "-large" option (But today I forgot about that command) With the Delorean crash I used your TXMP .oni file which was 512x512. Anyways, now I used the -large option and imported the file TXMPAIR_FLOOR002.tga as brg555. As Oni was in the process of loading level 4, it crashed. I replaced that with a 256x256 version, no crash. Next I imported TXMPPOSTER1.tga as brg32, Oni crashed as it was loading level 4, replaced with 256x256, back to normal. EdT 01:01, 22 August 2008 (CEST)

Hmm, about the Shift key not being 'accessible'... I actually never noticed before that one cannot type capital letters on the command line, and if I did notice it I would have assumed the PC version was the same. So, one point and one question:

  • It's not exactly true that the Shift key is not accessible or not recognized, because I can type important characters like the underscore and parentheses. It's merely that uppercase letters cannot be typed.
  • Is the lack of access to uppercase letters an issue? This is total news to me, so naturally I am curious as to whether this has been a problem on the Mac side of things that I never knew about. --Iritscen 03:04, 7 October 2008 (CEST)


The PC command line has no major issues: uppercase letters can be entered both on PC and PC demo. There are occasional glitches with autocompletion and some inconsistencies with multithreading (i.e., "fork"ing may not work as expected when launched from the console). Also, the command line is not displayed properly or at all at large resolutions.
Thanks for the disambiguation about the Shift key. Ed didn't make it clear how exactly it didn't work. Do you confirm that the only characters that can't be entered are uppercase letters? Also, Ed, how long have your 3 "known issues" been around? Right from the moment when the Dev Mode was unlocked?
The original variables and functions (preset of scripted) are all lowercase, but team names are capitalized, and many AI names contain uppercase letters as well. So lowercase-only input can be frustrating. The obvious workaround is to use scripts more, so that all command line statements can be lowercase.
geyser 03:36, 7 October 2008 (CEST)
Just confirmed it to make sure; only a-z cannot be modified by the Shift key, i.e., become uppercase. All other characters that require Shift can be typed. And thanks for the answer on what uses uppercase, the team names and AI names slipped my mind. I tested that as well, hoping that the Mac would ignore case, but alas; the console indeed does not recognize any team names without the uppercase letters. --Iritscen 04:02, 7 October 2008 (CEST)