Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

TheLoneSurvivor

Members
  • Content count

    60
  • Joined

  • Last visited

1 Follower

About TheLoneSurvivor

  • Rank
    Registered just to bump a seven year old thread

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. TheLoneSurvivor

    Doom SNES Unused Status Bar faces

    I found the offset in WRAM that controls the status bar face. With this offset, I found all the values that worked. Note: If you use a value that is not listed below you will just see pixel garbage as you status bar face. Here is a video showing the unused faces: https://www.youtube.com/watch?v=rZpJs7Z6aRg&feature=youtu.be Here is the offset in WRAM: 0x704 Values: Dead = 00 God Mode = 02 Grinning Face = 04 [ Damaged = 06 Badly Damaged = 08 ] "Annoyed" Face = 10 [ Damaged = 12 Badly Damaged = 14 Almost Dead = 16 ] Ouch Face = 18 [ Damaged = 20 ] Looking Right = 22 [ Damaged = 28 Badly Damaged = 34 ] Looking Center = 24 [ Damaged = 30 Badly Damaged = 36 ] Looking Left = 26 [ Damaged = 32 Badly Damaged = 38 ]
  2. TheLoneSurvivor

    Doom SNES player data in RAM

    So, if there is a 16-bit variable at 6F6-6F7 for strafing and turning speed, it would theoretically be possible to make them into 2 8-bit variables, modify the code to use 8-bit variables, make some adjustments to compensate for there being only 255 values rather than 65535, store the strafing speed at 6F6, and store the turning speed at 6F7. This would save 2 bytes of space (barely anything, but you can at least make another 16-bit variable or 2 8-bit variables), but the only problem is that it might lead to problems, because you would have to reprogram the game to store those variables as 8-bit, but even if you compensate for it, it might lead to the reduced turning resolution problem while recording demos vanilla doom had, on a lesser or greater level depending on how well you compensate for it. I'm not sure how well it would work, but if done right it could work. I honestly go way too far when it comes to this kind of thing.
  3. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    Only 2 damn people are working on it, me and mopoz, so what do you expect. He was actually making a Doom SNES editor, and it looked extremely legit, even more so with all he has discovered. He says he wants it to work on real hardware, so that is a major drawback in terms of time and limitations.
  4. TheLoneSurvivor

    Strange Doom SNES graphic compression. (SOLVED!)

    What makes you say that? Anyways, the guy I was talking to was mopoz. He told me everything uses RLE compression, which I thought from the start but now I know for sure. Here is a direct quote from him. Yo dude! It uses RLE compression. Compression on different textures and sprites. $1b0000-$1b007C - poiters on texture $1b007e+ pointer - discription texture Y,X, pointers on vertical line*Y One poiter - one vertical line. HEX: XX YY Y1 Y2 ... if XX<0x80 then take new color XX times YY Y1 Y2 ... and so on. if XX>0x80 then Copy one color YY 0x100-XX times
  5. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    Soon... If you look at my thread about the Doom SNES level data, you may change that (Unlikely) :D to (I need new underwear) :0 Let's just say, get your hopes up because it is likely. So basically the CPU is severely bottlenecked by the RAM.
  6. TheLoneSurvivor

    Strange Doom SNES graphic compression. (SOLVED!)

    I realized there is a guy who figured out the sprite and texture compression that I've been talking to for a year, because he has done some astronomically hard things. He was even working on a Doom SNES editor.
  7. TheLoneSurvivor

    Doom SNES player data in RAM

    So, I took the liberty of going into Geiger's SNES9X Debugger and opening the Doom SNES ROM (I used Geiger's SNES9X Debugger because doing memory editing/viewing is alot easier and potentially more reliable than with BSNES-Plus.) I went to around 0x6F0 in memory, and started moving. I noticed some bytes that were not changing changed. I let go of the button and the byte went back to default. I pressed the same button again, and it changed. I paid close attention to detail, and paid attention to synchronization of byte changing to stuff happening on screen. I managed to find some stuff out. 1. Near the beginning of RAM, there is a slowly changing byte. Because I was curious, I changed it, and the screen did something weird. It cut off the right part of the screen (about 40% I would say) and moved it to the left, it is hard to explain. It made it awkward to control, and often you would run into walls. 2. I know it is pretty obvious, but some confirmation. Weapon bobbing is not tied to how long you go forward, but tied to speed. 3. For some things, there is 2 or more locations in RAM that all change to the same byte at the same time, which leads me to believe that this might slightly impair ROM hacking for these things, as it may cause some confusion and a bit of searching 4. The most important and wondered of all, I found out why circle strafing is not possible and I will go into a short amount of detail that should speak for itself. There appears to be 2 bytes in RAM that hold what button is being pressed. The first one (I think it is the first but might be the second) holds whether you are pressing up, down, left, or right, and the second holds whether you are pressing A, B, X, or Y. You have one guess as to where whether you are pressing L or R is held. If you guessed the one for up, down, left and right, you are right! This seems to imply that unlike the Doom wiki says about circlestrafing in SNES Doom to be removed due to the lack of monster infighting, it simply appears that it is because if you are circlestrafing, you will be using up both bytes because of the fact you are moving and strafing, which is 2 inputs it has to handle. As such, since there would be nowhere to hold if you are shooting, they just decided to put L and R with the byte that handles up, down, left and right. Think about it. If you can't shoot while circlestrafing, that completely destroys the purpose. 5. There is only 16 movement speeds for the player. While doing the movement test, when going at max speed it was only 16 bytes higher than the default. 6. I found something funny. At a certain point in RAM, there is a byte that if you change, then press something on the controller it won't work. Naturally, I got intrested and just started going nuts on all the buttons, then I changed it back to the byte it was before, and I literally did everything I pressed all at once. Because of this, I will name it the Doomguy Seizure Byte. Now, here is the offsets for any of you nerds. NOTE: I might accidentally be one byte off for most of them, try going one byte back if it doesn't work. 0x710 in the BSNES-Plus debugger (S-CPU bus) 0x7E0710 in RAM It goes up every time you move, and when you slow down and/or stop it goes back. It appears to be a speedometer, and if you manually set it in the ram you will start getting weapon bobbing 0x6F7-6F8 in the BSNES-Plus debugger (S-CPU bus) 0x7E06F7 - 0x7E06F8 in RAM Changes when you turn, changing them will make you turn 0x6BC in the BSNES-Plus debugger (S-CPU bus) 0x7E06BC in RAM Goes up everytime you press a button on the controller. Change this hex value, spam the controller, and then set it back to the default value and you will do everything you pressed at once 0x6E6 and 0x705 and in the BSNES-Plus debugger (S-CPU bus) 0x7E06E6 and 0x7E0705 in RAM Controls the status bar face. 22 is looking left, 24 is looking at the center, 26 is looking right 0x02B in the BSNES-Plus debugger (S-CPU bus) 0x7E002B in RAM Not exactly player data, but kind of. Changing this to 00 will split your screen and swap it a bit. Hard to explain. I'm still not as good at ROM hacking as that mopoz guy who figured out all the level data on his own. P.S. I can't figure out how to freeze a byte in RAM, because sometimes it makes the emulator crash or doesn't work (I do a breakpoint, and boom it crashes. Any SNES nerds please tell me how I do a proper breakpoint that can't be written to but can be read from.)
  8. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    Did it really take 21 years to do this? 21 YEARS, let that sink in. I swear to god people know the internals of every single SNES game and can make comments on every single line of code, but not this one. Anyways, with that aside, the king of Doom SNES hacking has brought me this... Nodes E1M1 original Code: [Select] Adr X Y ChenX ChenY Right BOX Left BOX RCHILD LCHILD [00] $0000: 0B48 EF00 0000 0020 0B600B48EF00EFC0 0B480B28EF00EFC0 8001 8002 [01] $001C: 0B60 EF00 FFE8 0000 0B600B28EF00EFC0 0B600B28EE40EEE0 0000 8003 [02] $0038: 0B28 EFC0 0000 FF40 0B280A80EE40EFE0 0B600B28EE40EFC0 8000 0001 [03] $0054: 0B60 EFC0 00C0 0000 0C200B60EF00EFC0 0C200B60EFC0EFE0 8004 8005 [04] $0070: 0C20 EF00 FF40 0000 0C200B60EF00EFE0 0C200B60EE40EF00 0003 8006 [05] $008C: 0C38 EF20 0000 FFE0 0C380C20EF00EFC0 0C580C38EF00EFC0 8008 8009 [06] $00A8: 0C58 EF00 FFE0 0000 0C580C20EF00EFC0 0C580C20EE40EEE0 0005 800A [07] $00C4: 0C58 EF00 0000 00C0 0D000C58EE40EFE0 0C580C20EE40EFC0 8007 0006 [08] $00E0: 0C20 EFE0 0000 FFE0 0C200B60EE40EFE0 0D000C20EE40EFE0 0004 0007 [09] $00FC: 0B60 EFE0 0000 FFE0 0B600A80EE40EFE0 0D000B60EE40EFE0 0002 0008 [0A] $0118: 0BB0 ED18 0000 FFF8 0BB00B60ED10ED18 0BD00BB0ED10ED18 800E 800F [0B] $0134: 0BB0 ED10 0020 0000 0BD00B60ED00ED10 0BD00B60ED10ED18 800D 000A [0C] $0150: 0BD0 ED10 0000 0008 0C200BD0ED00ED18 0BD00B60ED00ED18 800C 000B --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- [DD] $182C: FD80 F480 02C0 0080 0040FD80F1C0F500 0040FD80F480F500 00DC 80E0 [DE] $1848: 0040 F1C0 FD40 0080 0040FD80F1C0F500 0040FD80F1C0F240 00DD 80E1 [DF] $1864: FD80 F240 0000 0240 0040FD80F1C0F500 FD80FD00F1C0F500 00DE 80E2 [E0] $1880: 0040 F2C0 0040 0080 00800040F280F340 00800040F2C0F400 80E4 80E5 [E1] $189C: 0080 F380 FFC0 0080 00800040F380F440 00800040F280F400 80E3 00E0 [E2] $18B8: 0040 F500 0000 FF80 0040FD00F1C0F500 00800040F280F440 00DF 00E1 [E3] $18D4: 0080 F340 0000 0040 02C00080F280F440 0080FD00F1C0F500 00C1 00E2 [E4] $18F0: 02C0 F220 0000 00C0 0EE002C0ED00F800 02C0FD00F1C0F500 00A7 00E3 SNES Code: [Select] Address X Y ChenX ChenY Right BOX RCHILD Left BOX LCHILD [00] $189ED4: F1C0 FF40 0B80 0040 0B800B80F1ABF1C0 8008 0B800AC0F1C0F230 8004 [01] $189EF0: F230 FF40 0B80 FFD0 0B800AC0F1ABF230 0000 0B800AC0F200F2E0 8000 [02] $189F0C: F1F8 0000 0D18 0018 0D190D18F1EFF1F8 8018 0D180D18F1F8F210 8014 [03] $189F28: F210 FFA8 0D18 FFD0 0D190D18F1EFF210 0038 0D180C20F1E0F2D6 8010 [04] $189F44: F240 FFA0 0D78 FFD0 0D780D18F210F240 8028 0D900CF0F210F298 8024 [05] $189F60: F298 FFA0 0D50 FFC0 0D900CF0F210F298 0070 0D500CF0F258F298 8020 [06] $189F7C: F298 FFC0 0D90 0000 0D900CF0F210F298 008C 0D900CAAF298F3A9 801C [07] $189F98: F258 0028 0CF0 FFB8 0D900CAAF210F3A9 00A8 0D190C20F1E0F2D6 0054 [08] $189FB4: F1E0 FF60 0CC0 0040 0CC00BE7F1C0F220 802C 0D900C20F1E0F3A9 00C4 [09] $189FD0: F240 0028 0D90 FFCA 0E600DE0F211F2E2 8034 0DB80D78F20AF240 8030 [0A] $189FEC: F298 FFE8 0D90 FFA8 0E600D78F20AF2E2 00FC 0D900BE7F1C0F3A9 00E0 [0B] $18A008: F2E0 FF58 0C28 FF50 0C8F0B80F1D6F2E0 803C 0C280AC0F230F37C 8038 [0C] $18A024: F418 00E0 0AC0 FFE8 0C100AC0F400F49A 8044 0BA00AC0F360F418 8040 [0D] $18A040: F380 0098 0BA8 0080 0C400B47F380F400 804C 0D490BA8F308F420 8048 [0E] $18A05C: F400 00A8 0C40 0020 0CE80B7AF3DBF471 8050 0D490B47F308F420 016C [0F] $18A078: F308 FED8 0CD0 0078 0CD00B00F2B4F3A8 8054 0D490B47F308F471 0188 --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- [DD] $18B700: F3C0 0000 0140 0040 01400100F3C0F440 1810 01F00140F3C0F440 8384 [DE] $18B71C: F3C0 0040 0100 0000 01F00100F3C0F440 182C 01F00100F280F3C0 17F4 [DF] $18B738: F318 0000 01F0 0090 01F00100F280F440 1848 02C001F0F2E0F3E0 1730 [E0] $18B754: F3E0 0000 02C0 00A0 02C00100F280F440 1864 056002C0F1A0F657 1714 [E1] $18B770: F400 0000 0100 FFC0 05600100F1A0F657 1880 0100FD00F1C0F500 14AC [E2] $18B78C: F380 0000 0560 0060 0560FD00F1A0F657 189C 0EE00560ED00F800 1030 If Left Child or Right Child > $7FFF then to go SideBase+$37A8 (analog Subsector+Segs) Exemple [04] $189F44: F240 FFA0 0D78 FFD0 0D780D18F210F240 8028 0D900CF0F210F298 8024 $8028+$37a8 = $B7D0 or ($b7a8 + ($8028-$8000)/4) Code: [Select] $5F/3144 BD 4A 33 LDA $334A,x[$5F:334A] A:18B8 X:0000 Y:0001 P:envmxdIzc $5F/3147 8F 82 00 70 STA $700082[$70:0082] A:37A8 Looking $18B7d0 01 F2 00 58 01 - visible SDEFS on sector SideBase #10 Sidedefs visible: 01 Sidedefs Offset: 00F2 ($18D95E =$18D86C+ $00F2) Sector Numb: 58 Code: [Select] $5F/316E BD 8E 34 LDA $348E,x[$5F:348E] A:D861 X:0000 Y:0001 P:eNvmxdIzc $5F/3171 8F 8A 00 70 STA $70008A[$70:008A] A:D86B siddefs D86B+1=D86C If Left Child or Right Child < $8000 then to go Nodes+$9ed4 exemple [03] $189F28: F210 FFA8 0D18 FFD0 0D190D18F1EFF210 0038 0D180C20F1E0F2D6 8010 $189ed4+$0038= $189F0C (N line = $0038\$1C=2) Code: [Select] $5F/31CB BD A8 32 LDA $32A8,x[$5F:32A8] A:0000 X:0000 Y:0001 P:envmxdIZc $5F/31CE 8F 7C 00 70 STA $70007C[$70:007C] A:9ED4 [02] $189F0C: F1F8 0000 0D18 0018 0D190D18F1EFF1F8 8018 0D180D18F1F8F210 8014 So there is NODES. Remember, there is no REJECT and BLOCKMAP equivalents in Doom SNES, so keep that in mind while we count. That node explanation was given to me on January 20, 2016 but I only saw it now. What about the floor/ceiling colour index? Quote You are legendary bro. May you please post the sector colour index, and how to use textures on linedefs? 256 colors for the floor and ceiling. BTW, color $FF -> F_Sky So this brings us with NODES, and a part of SECTORS. That was from October 18, 2015. What about these pointers/asm code for level loading? Code: [Select] $5F/FAF2 22 2E 31 5F JSL $5F312E[$5F:312E] load map $5F/312E AD D1 06 LDA $06D1 [$3F:06D1] map number $5F/3131 48 PHA A:0000 X:2806 Y:0001 P:envmxdIZc $5F/3132 0A ASL A A:0000 X:2806 Y:0001 P:envmxdIZc $5F/3133 AA TAX A:0000 X:2806 Y:0001 P:envmxdIZc $5F/3134 4B PHK A:0000 X:0000 Y:0001 P:envmxdIZc $5F/3135 AB PLB A:0000 X:0000 Y:0001 P:envmxdIZc $5F/3136 BD 82 37 LDA $3782,x[$5F:3782] A:0000 X:0000 Y:0001 P:envmxdIzc $5F/3139 8F BF 06 00 STA $0006BF[$00:06BF] A:0402 X:0000 Y:0001 P:envmxdIzc $5F/313D BD 14 33 LDA $3314,x[$5F:3314] A:0402 X:0000 Y:0001 P:envmxdIzc $5F/3140 8F 80 00 70 STA $700080[$70:0080] A:18B8 X:0000 Y:0001 P:envmxdIzc $5F/3144 BD 4A 33 LDA $334A,x[$5F:334A] A:18B8 X:0000 Y:0001 P:envmxdIzc $5F/3147 8F 82 00 70 STA $700082[$70:0082] A:37A8 X:0000 Y:0001 P:envmxdIzc $5F/314B BD 80 33 LDA $3380,x[$5F:3380] A:37A8 X:0000 Y:0001 P:envmxdIzc $5F/314E 8F 84 00 70 STA $700084[$70:0084] A:7F82 vertex add $5F/3152 BD B6 33 LDA $33B6,x[$5F:33B6] A:7F82 X:0000 Y:0001 P:envmxdIzc $5F/3155 8F 8E 00 70 STA $70008E[$70:008E] A:01CE vertex value $5F/3159 BD EC 33 LDA $33EC,x[$5F:33EC] A:01CE X:0000 Y:0001 P:envmxdIzc $5F/315C 8F 86 00 70 STA $700086[$70:0086] A:C270 linedefs $5F/3160 BD 22 34 LDA $3422,x[$5F:3422] A:C270 $5F/3163 8F 90 00 70 STA $700090[$70:0090] A:01D5 lindefs value $5F/3167 BD 58 34 LDA $3458,x[$5F:3458] A:01D5 X:0000 Y:0001 P:envmxdIzc $5F/316A 8F 88 00 70 STA $700088[$70:0088] A:D861 X:0000 Y:0001 P:eNvmxdIzc $5F/316E BD 8E 34 LDA $348E,x[$5F:348E] A:D861 X:0000 Y:0001 P:eNvmxdIzc $5F/3171 8F 8A 00 70 STA $70008A[$70:008A] A:D86B siddefs D86B+1; $5F/3175 BD FA 34 LDA $34FA,x[$5F:34FA] A:D86B X:0000 Y:0001 P:eNvmxdIzc $5F/3178 8F 8C 00 70 STA $70008C[$70:008C] A:F746 X:0000 Y:0001 P:eNvmxdIzc $5F/317C BD 30 35 LDA $3530,x[$5F:3530] A:F746 X:0000 Y:0001 P:eNvmxdIzc $5F/317F 8F 94 00 70 STA $700094[$70:0094] A:FACE Texture $5F/3183 BD C4 34 LDA $34C4,x[$5F:34C4] A:FACE X:0000 Y:0001 P:eNvmxdIzc $5F/3186 8F 92 00 70 STA $700092[$70:0092] A:02CE texture value $5F/318A BD D2 35 LDA $35D2,x[$5F:35D2] A:02CE X:0000 Y:0001 P:envmxdIzc $5F/318D 8F 9A 00 70 STA $70009A[$70:009A] A:0055 X:0000 Y:0001 P:envmxdIzc $5F/3191 BD 08 36 LDA $3608,x[$5F:3608] A:0055 thing numb (thing) $5F/3194 8F 9C 00 70 STA $70009C[$70:009C] A:EBC2 X:0000 Y:0001 P:eNvmxdIzc $5F/3198 BD 3E 36 LDA $363E,x[$5F:363E] A:EBC2 things $5F/319B 85 00 STA $00 [$00:0000] A:EEEE $5F/319D 18 CLC A:EEEE X:0000 Y:0001 P:eNvmxdIzc $5F/319E 69 06 00 ADC #$0006 A:EEEE X:0000 Y:0001 P:eNvmxdIzc $5F/31A1 8F 9E 00 70 STA $70009E[$70:009E] A:EEF4 X:0000 Y:0001 P:eNvmxdIzc $5F/31A5 BD 74 36 LDA $3674,x[$5F:3674] A:EEF4 X:0000 Y:0001 P:eNvmxdIzc $5F/31A8 8F A0 00 70 STA $7000A0[$70:00A0] A:FE42 $5F/31AC BD AA 36 LDA $36AA,x[$5F:36AA] A:FE42 X:0000 Y:0001 P:eNvmxdIzc $5F/31AF 8F A4 00 70 STA $7000A4[$70:00A4] A:FE83 X:0000 Y:0001 P:eNvmxdIzc $5F/31B3 BD E0 36 LDA $36E0,x[$5F:36E0] A:FE83 X:0000 Y:0001 P:eNvmxdIzc $5F/31B6 8F A6 00 70 STA $7000A6[$70:00A6] A:FE8E X:0000 Y:0001 P:eNvmxdIzc $5F/31BA BD 16 37 LDA $3716,x[$5F:3716] A:FE8E X:0000 Y:0001 P:eNvmxdIzc $5F/31BD 8F A2 00 70 STA $7000A2[$70:00A2] A:FE83 X:0000 Y:0001 P:eNvmxdIzc $5F/31C1 BD 4C 37 LDA $374C,x[$5F:374C] A:FE83 X:0000 Y:0001 P:eNvmxdIzc $5F/31C4 8F A8 00 70 STA $7000A8[$70:00A8] A:FE8E X:0000 Y:0001 P:eNvmxdIzc $5F/31C8 8A TXA A:FE8E X:0000 Y:0001 P:eNvmxdIzc $5F/31C9 0A ASL A A:0000 X:0000 Y:0001 P:envmxdIZc $5F/31CA AA TAX A:0000 X:0000 Y:0001 P:envmxdIZc $5F/31CB BD A8 32 LDA $32A8,x[$5F:32A8] A:0000 X:0000 Y:0001 P:envmxdIZc $5F/31CE 8F 7C 00 70 STA $70007C[$70:007C] A:9ED4 nodes $5F/31D2 BD AA 32 LDA $32AA,x[$5F:32AA] A:9ED4 X:0000 Y:0001 P:eNvmxdIzc $5F/31D5 8F 7E 00 70 STA $70007E[$70:007E] A:0058 X:0000 Y:0001 P:envmxdIzc $5F/31D9 BD 66 35 LDA $3566,x[$5F:3566] A:0058 Bank 2 $5F/31DC 8F 96 00 70 STA $700096[$70:0096] A:E86E sectors (end $524c - stop bytes) $5F/31E0 BD 68 35 LDA $3568,x[$5F:3568] A:E86E X:0000 Y:0001 P:eNvmxdIzc $5F/31E3 8F 98 00 70 STA $700098[$70:0098] A:005B Bank for adress $5F/31E7 85 02 STA $02 [$00:0002] A:005B X:0000 Y:0001 P:envmxdIzc thing #0 - #5 (1 - 4 spawn, 5 - teleport) = 8 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y; 16 bit - angle) {Player} things_name[$00]:='Player 1 start'; things_name[$01]:='Player 2 start'; things_name[$02]:='Player 3 start'; things_name[$03]:='Player 4 start'; things_name[$04]:='Player Deathmatch start'; {Teleport} things_name[$05]:='Teleport Destination'; thing #6-#$3F - 6 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y) ============================================ Sector 10 byte settings 0 = sector_special; (sector_special shr 2) 1 = bright_room 2 = sector_bright_flash; 3-4 = sector_floor_height; 5-6 = sector_ceil_height 7 = sector_floor_color 8 = sector_ceil_color 9 = sector_tag ============================================ Lindefs 16 bytes settings 0-1 = linedefs_vertx_strt 2-3 = linedefs_vertx_end 4-5 = linedefs_type 6-7 = linedefs_angle 8-9 = linedefs_texture_offset 10 = linedefs_action 11 = linedefs_tag ======================================== SideDefs 12 byte 0-1 = sidedefs_vertx_strt 2-3 = sidedefs_vertx_end 4 = sidedefs_flags 5 = sidedefs_horizontal_scroll 6 = sidedefs_vertical_scroll 7-8 = sidedefs_texture_offset 9-10 = sidedefs_linedf_number 11 = sidedefs_sector_number That was from October 16, 2015. We basically have NODES, SECTORS, LINEDEFS, SIDEDEFS, THINGS, SUBSECTORS (was apart of the node explanation), SEGS (was apart of the node explanation) I found the VERTICES data too, it is really close to the PC data, with some differences (because of no transparent midtextures I think, and some other reason too.) If you don't understand what this means, this means we have all the level data. If you don't understand what the fact we have the level data means, it means TIME FOR SOME SNES WADS! I can't wait to play NUTS.WAD on a SNES... (I'm crazy)
  9. I was looking in Tile Molester for graphics, and I remembered I found the textures before. I used all the settings I need to make sure the textures are visible. The sky textures are perfectly uncompressed, but... http://imgur.com/gallery/cYRGu/ Notice how the sky textures are uncompressed, but the textures are weirdly distorted/warped and have coloured dots on them. If anyone here has SNES knowledge please tell me what compression method this is. Edit: When I first saw the textures, I thought they were RLE compression, and I was right, because another Doom SNES hacker told me.
  10. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    So basically the system RAM is totally full (well you said not much benefit, which implies there is some room but not alot). You have to remember mostly routines will be replaced, and that space plus whatever left over space in the system RAM can be used for a routine replacement. I see what you mean though, and I will check the average kilobyte usage of system RAM in BSNES-Plus, and take note of peak usage, and will then figure out how much useful routines can be added without the system RAM overflowing in certain situations. I don't know if what I am saying will work, but math can bring you a long way when it comes to these kinds of things. But I do take what you are saying seriously, because you know what you are talking about (you contributed a fair amount to BSNES-Plus, and making a SNES debugger is difficult I can imagine.) So the theoretical 5 times speed increase when using a SA-1 is actually lower? (by that I mean 2.68MHz 65816 + 10.74MHz SA-1 = 13.42MHz total [slightly more than 2.68MHz X 5, which would be 13.4, but the difference is so tiny that it doesn't matter] because there is slowdown? How much slowdown? I also just learned the CPU in the SNES has a 21MHz clockspeed, but it is reduced to 2.68MHz and 3.58MHz (I think there is also a hilariously low 1.79MHz mode), I can only imagine how much potential the SNES could have had if they used that 21MHz. Think about it, if the SNES CPU used that 21MHz, and since the Super FX is also 21MHz, they could've made a straight Doom port (I think the recommended PC was a 33MHz 386, but here we have a 21MHz CPU with a 21MHz co-processor doing the graphics, meaning you were effectively running Doom at 42MHz, which is 9MHz more than the 386) I had a SNES when I was a little kid (even though I am a near-mid 2000's kid) and I can only imagine playing much better games on it, because the SNES was really what I played games on.
  11. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    Well, if it causes many limitations, then why would they design it like that, because they should've known. I also realized that's why BSNES-Plus has the Game Pak RAM Access rapidly switching from CPU to Super FX.
  12. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    I really need to learn how the SNES works. I know this is next step after impossible, but if you were able to run doom on an SA-1 and Super FX at the same time, that would be awesome
  13. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    I don't know.
  14. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    As for the drawing distance, I think Doom SNES uses double column rendering so everything is stretched by 1 pixel horizontally, plus the border meaning these are the main causes of severe pixellation in SNES Doom. The FPS issue can be helped by well optimized code and pushing the Super FX to always be processing at max capacity. It might run outside an emulator. The chances of user made levels are kind of high, as we know a bit on how SNES Doom levels work. Also even if it does run outside an emulator, the SNES will be under heavy load and may crash/overheat. 2.68MHz is not a lot to work with.
  15. TheLoneSurvivor

    Doom SNES Hacking Guide/Documentation

    Ok, for the sake of simplicity lets just call the first 2MB the lower ROM and the last 6MB the upper ROM. Normally, there is only 2MB in a Super FX ROM, and naturally the bigger the game the more space it takes up. Since Doom is a large game, there is only around 60 bytes of free space, or to be clear, essentially nothing. Since there is alot of code on the 65816 side, and typically a 65816 instruction in hex is around 2 to 4 bytes, think about how much code it takes to do everything that is not done on the SPC700 or Super FX. Basically, every line of code not for rendering or sound (Super FX and SPC700). That's quite a considerable amount of code, probably takes up over at least 25kb 25KB is alot more than you think for the SNES, due to the amount of compression everything uses. Just google how much compression the SNES uses, and you will realize you can cram a reasonable amount of data in there (Maps, Graphics, Sounds, and Super FX code [If you want to modify some Super FX routines or add some for whatever reason]) The reason you would want this free space in the lower ROM is because the Super FX should be able to address the graphics and levels [I think the Super FX addresses the levels but I am unsure]. Basically, you turn the lower ROM into a 2MB section for data, some 65816 code, and some Super FX code. You then turn the upper half into a 6MB section for 65816 ASM. You maybe wondering, why so much space? Because, 8MB takes up little space on modern hard drives, and you can basically add/modify routines as much as you desire, as there is enough space in lower ROM to add/modify Super FX routines, and way more than enough space in upper ROM to add/modify 65816 routines. Examples of routines that would be 65816 side: -Better Player Code (fixes for movement bugs/limitations such as adding circlestrafing, fixing the sticky walls glitch (based on my experience it is more vertices you get stuck on, not linedefs most of the time) -Better Weapon Code (add a decrease in damage based on distance like PC Doom, add weapon spread, make your weapon automatically switch when you run out of ammo) -Better AI (more intelligent demons, maybe make them retreat when at low health and have them be more unpredictable) -Add Sound Propagation (The reason they did not add it is many people think it was to conserve processing power, but who cares if the CPU is under more load, most people won't be using flashcarts to play on a SNES anyways, and people probably would keep an eye out for their SNES overheating, but the SNES can do surprisingly well under load, IIRC. I don't think it would use too much processing if done carefully and correctly. This and the Better AI routine would be nice together.) BTW: The lack of sound propagation in SNES Doom is why enemies are deaf, incase you did not know Examples of Super FX side routines: -Better Rendering Engine (Due to the lack of space in the ROM, they probably wrote a more basic rendering engine (probably has little optimization) to save space, but with a better one you can write a more advanced one written to push the Super FX to it's limits to get better speed, and write more optimized code to get even better speed.) -Floor and Ceiling Textures (Self explanatory, would also need the Better rendering engine routine, and you would put your floor and ceiling textures in the new free space in the lower ROM) -Textured automap (Would be pretty cool, since the Super FX does the automap too, it would have pretty good texture mapping, and would need the Better Rendering Engine and Floor and Ceiling Textures routines) So personally if I had the ability to do this right now, I'd be getting straight to work. SMW on a Super FX ROM is really, REALLY stupid. I can understand using the SA-1 but, really the Super FX?
×