Posts for Warepire

Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
For splitting hexadecimal values in Lua, you need to apply some bit math, such as this library: http://bitop.luajit.org/ (Which is already part of BizHawk, so you may have used it already). Decimal, hexadecimal, binary, the values are all the same internally, so if you know the conversion operations you can split them with bit math. Here's a good introduction if you need it: https://playground.arduino.cc/Code/BitMath (C++ oriented, but it should be very easy adapt it to the above suggested Lua library) The variant of bit math you're looking for in this case is called "bit masking".
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
You need to be aware of how it works internally anyway, otherwise you'll be really surprised later on, and possibly really confused. That the standard library and language itself has a lot of tools that help you manage memory in many ways is great, but it does not relieve you of being aware of how the language works.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Warp wrote:
Warepire wrote:
Unlike the previous languages you have been exploring, C/C++ does not perform memory management for you
Well, yes and no. If you use standard containers like std::vector and std::map, they are going to manage their memory without you having to do anything about it. You can also create similar classes yourself (although this requires a bit advanced knowledge of the language.) In general, if you can avoid new and delete you ought to be mostly fine in terms of memory management. The main problem becomes things like accessing arrays out of bounds and other such errors.
I was referring to things like this: https://docs.oracle.com/javase/tutorial/java/javaOO/objectcreation.html
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
It's not trivial showing a window with graphics with C++. Follow feos advice and start small. Inclusion in C/C++ works entirely different from what you are most likely used to from Java and Javascript. Unlike the previous languages you have been exploring, C/C++ does not perform memory management for you, so you are going to encounter many new concepts, but once you understand them, they are not that difficult to handle. So, start small, really small, like "Hello World" in various forms. This will allow you to ease into the concepts and how inclusions work. Once you have the basics, you're free to try again with a small game. EDIT: mugg, feel free to ping me on IRC if you want more hands on help. If I am at the computer, I will respond.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
There is an over-representation of bees for this category in the screen shot, it's starting to come off as "this is the only thing that happens in the TAS", while that is clearly not the case. There has to be something else we can use for the screen shot? I spotted quite a lot of action packed frames, at least early on.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
EZGames69 wrote:
Still a bit early to call but I recommend starring [3873] GC The Legend of Zelda: Twilight Princess by gymnast86 in 2:44:46.77.
Being somewhat unfamiliar with the game I need the commented encode to fully enjoy this TAS, because otherwise I cannot appreciate all the tricks.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
A vote to use as many darkness glitches as necessary. The darkness isn't too dark for me, I can still see fine.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Good work. I was entertained. Yes vote.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
From IRC:
09:24 <FatRatKnight> In any case, I am aware that along with A9 for boost speed, you missed the sub-boost speed at AA.
09:24 <FatRatKnight> Or boost subspeed, I guess.
09:24 <FatRatKnight> Somewhere a sub should be.
09:24 <Warepire> Interesting.
09:25 <FatRatKnight> The fractional value is mostly pertinent for riding apples, as enemies generally have a lovely zero for their subspeed.
09:26 <Warepire> That means we also missed the subpixel boost value in the enemy data structures
09:26 <FatRatKnight> My notes claim that would be 058B, along with the following 7 addresses.
09:30 <Warepire> May I paste relevant bits in the topic later?
09:31 <FatRatKnight> Go ahead.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Addr 0x4C:
  High byte of camera position of end of current level?

Addr 0xC7:
  Buttons read from joypad 1 (this frame)

Addr 0xC8:
  Last frame's buttons. Copied from 0xC7 before 0xC7 is refilled

Addr 0xCA:
  Value to write to PPUCTRL (0x2000)

Addr 0xCE:
  Y screen position (low?) (pixels)

Addr 0xCC/0xCD:
  X screen position (pixels)

Addr 0xEC:
  Screen mode?
  0x01 = Title screen
  0x02 = Title screen idle animation
  0x03 = Title screen -> First level
  0x04 = Filler/between screens
  0x05 = Playable level

Addr 0x617/0x618:
  X position of the character on the whole stage (pixels)

Addr 0x84 and 0x87:
  Integers indicating the cardinal direction joypad 1's dpad is being held. 0x84 will only show U/D/L/R and 0x87 will only show U/D/L/R/UR/UL/DR/DL.
  0x84:
    1 = Up
    2 = Down
    3 = Left
    4 = Right
    0 = Direction not listed above

  0x87:
    1 = Up
    2 = Down
    3 = Left
    4 = Right
    5 = Up + Left
    6 = Up + Right
    7 = Down + Left
    8 = Down + Right
    0 = Direction not listed above

Addr 0x91/0x92:
  X position of the character on the screen (sub-pixels)

Addr 0xA9:
  Speed gained from riding an enemy/apple
  Fetched from [0x583 + enemy_slot_id]

Addr 0x98/0x99:
  Speed (sub-pixels)

Addr 0x9A:
  Effective speed (pixels). This is the sum of the whole pixel speed and any boost

Addr 0xA9:
  Speed boost added to the regular speed.

It looks like speed can be pretty well optimized by keeping a close eye on the effective speed in 0x9A and trying to keep it high.
You have a running speed (holding B) of 2 pixels per frame and can get a boost of 2 more from bomb jumping.

Address 0x53:
  For level 1, starts at 0x08, gets changed to 0when screen scroll X becomes 0x0808
  Maybe some kind of switch to load other level data?

Address 0xA8:
  Seems to be flags
  0x80 = Being hit?
  0x20 = riding enemy?
  0x01 = On ground?

Addr 0x4ED:
  Seems to be a counter of how many enemies have been seen? Seems like the high 6 bytes are also used to compare against the high byte for the player position (ish).

Addr 0x4F1:
  Enemy slot ID that hit you

Addr 0x4F3-0x4FA (8 slots):
  0x00 = Slot empty
  0x02 = Enemy is on screen
  0x03 = Enemy is off screen

Addr 0x4FB-0x500 (6 slots):
  Seems like enemy type ID
  Only related to enemies (not apples, range is 0-5)
  if value is 0x15 a section of code doesn't run
  Other values checked for: 0x13, 0x10, 0x39, 0x3B, 0x3C, 0x3F, 0x44, 0x46, 0x00, 0x16

Addr 0x501-0x508 (8 slots):
  ? Related to enemies
  compared == 0x0D at 0xE8FF

Addr 0x51B-0x520 (6 slots):
  An offset into a pointer table for animation data for this specific enemy
  Seems to choose what animation this enemy should perform (move vertically upwards, oscillate up and down/left and right, etc)
  Used at D507 to get an address in bank 3 (A9B2 + value * 2)

Addr 0x521-0x526 (6 slots):
  ? Related to enemies
  Looks like a counter for this enemy, probably used to determine where in the animation cycle the enemy is
  Used as an offset to the address fetched via the above value
  [(bank 3)A9B2 + [0x51B + enemy_slot_id * 2]] + [0x521 + enemy_slot_id * 2] * 4 = addr of the start of some data for enemy
  Entries in the data are probably 4 bytes, and this value is used to get the data for the current frame.
  If the first value in the next entry is 0x80 this counter restarts (and 0x515 + enemy_slot_id is incremented)


Addr 0x527-0x52E (8 slots):
  ? Related to enemies
  Flags
  0x40 - might indicate enemy is dying? Seems like you can't be damaged by them if it is set.
  0x80 - is often cleared when updating/checking enemies
         might indicate player is riding this enemy?
  0x08 - ? if set you can't get hit by it? you also can't ride it
  0x04 - ? if set you can't get hit by it?

Addr 0x535-0x53C (8 slots):
  ? Related to enemies
  compared < 0x04 at 0xE906
    if true, sets 0x40 in flags 0xA8

Addr 0x543-0x54A (8 slots):
  Enemy X position (high)

Addr 0x54B-0x552 (8 slots):
  Enemy X position (low)

Addr $0563-0x56A (8 slots):
  Enemy Y position

Addr 0x573-0x57A (8 slots):
  ? Related to enemies
  Might be hitbox horizontal size

Addr 0x57B-0x582 (8 slots):
  ? Related to enemies
  Might be hitbox vertical size

Function 0xE994
  Seems to check player against enemy position.
  hitbox_h = [0x573 + enemy_slot_id] + 0x07
  hitbox_w = [0x57b + enemy_slot_id] + 0x0F

  This function checks if the follow are all true:
  player_y < (enemy_y + hitbox_h)
    Make sure player is not too low
  (enemy_x - hitbox_w) < (screen_scroll_X + player_onscreen_x)
    Make sure player is not too far left
  (screen_scroll_X + player_onscreen_x) < (enemy_x + hitbox_w)
    Make sure player is not too far right
  (enemy_y - hitbox_h) < player_y
    Make sure player is not too high

  (enemy_y - hitbox_h) - player_y is stored to 0x0006
  This value must be negative to fit the condition above
  If this value -1 to -8 the game considers you as riding the enemy

Bank 3:

Starting at 0xB1AA is an array of addresses
B1CE - level 00 (??)
BB16 - level 01
B1CE - level 02
B648 - level 03
B822 - level 04
B94E - level 05
B32A - level 06
B4AA - level 07
B9F6 - level 08
B744 - level 09
B3E4 - level 10
BA68 - level 11
BBE8 - level 12
B1CE - level 13 (??)
B1CE - level 14 (??)
B1CE - level 15 (??)
B1CE - level 16 (??)
B1CE - level 17 (??)

These addresses point to a data for the powerup boxes in each level.
Each entry in those arrays is 6 bytes long:
[0] - X screen pos (high)
[1] - X screen pos (low)
[2] - ?
[3] - X pos on screen
[4] - Y pos
[5] - Type

Seems like this list of boxes is terminated with 0xFF in [0] and [1]

Known types:
1 -> Extra life
2 -> ?
3 -> Burger
4 -> Heart
5 -> Apple


Function F176:
This function runs level specific code. Using the level ID (address 0x51) it looks up an address:
  0xF19B + (level_id * 2)
  0xF19A + (level_id * 2)

It then uses the section ID (address 0x52) to get a function address
  addr + (section_id * 2)

The value fetched is pushed to the stack, then an RTS instruction is issued. RTS pushes the (16 bit value from stack + 1) to PC, so the addresses stored in the rom are 1 off from the start of the function

Most levels have more than one function pointer in this area. The function is usually to handle moving to the next section or world, or to determine when you have finished the world (usually the last section handler)

(Function addresses in this table have already had 1 added to them)
                         Section
                         0      1      2      3      4      5      6      7      8      9      10     11     12     13     14     15     16     17     18     19     20     21     22
Level 00 (???)  [F1C0]   F23C
Level 01        [F1C2]   F243   F287
Level 02        [F1C6]   F294   F2AB
Level 03        [F1CA]   F2B8   F2D7   F330
Level 04        [F1D0]   F337   F362   F3A0
Level 05        [F1D6]   F3AC   F3DD
Level 06        [F1DA]   F40A   F40A   F40A   F433   F458
Level 07        [F1E4]   F468   F4D4
Level 08        [F1E8]   F4E1   F4F8
Level 09        [F1EC]   F505   F505   F505   F505   F505   F521   F540   F576
Level 10        [F1FA]   F58B   F5B2   F5E8
Level 11        [F200]   F5F8   F60F
Level 12        [F204]   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F61C   F713   F733

World 1 section 0 (F243):
  Handles the "Good luck" guy
  When the screen scroll reaches 0x0808 addr 0x53 is changed from 0x08 to 0x00
  If Screen scroll X == 0x0BXX, level section is increased (boss is triggered)
World 1 section 1 (F287):
  Waits for 0x4F3 (Object enabled) to become 0

World 2 section 0 (F294):
  If Screen scroll X == 0x17XX, level section is increased (boss is triggered)
World 2 section 1 (F2AB):
  Waits for 0x4F3 (Object enabled) to become 0

World 3 section 0 (F2B8):
  If Screen scroll X == 0x16XX, level section is increased (boss is triggered?)
World 3 section 1 (F2D7):
  ???
  if 0xE2 >= 5, move to section 2
World 3 section 2 (F330):
  Seems to be hard coded to move to the next world.

World 4 section 0 (F337):
  If Screen scroll X == 0x0FXX, level section is increased (boss is triggered?)
World 4 section 1 (F362):
  ??? Similar to W3S1
World 4 section 2 (F3A0):
  ??? Similar to W3S2

World 5 section 0 (F3AC):
  If block player is in front of (0x615) == 0x79, level section is increased (move to boss room)
World 5 section 1 (F3DD):
  ???

World 6 section 0-2 (F40A):
  If block player is in front of (0x615) == 0x38, level section is increased (causes a screen transition?)
  If Screen scroll X == 0x13XX, level section is increased
World 6 section 3 (F433):
  ???
World 6 section 4 (F458):
  Waits for 0x4F3 (Object enabled) to become 0

World 7 section 0 (F468):
  ?complex stuff?
  If Screen scroll X == 0x16XX, level section is increased
World 7 section 1 (F4D4):
  Waits for 0x4F3 (Object enabled) to become 0

World 8 section 0 (F4E1):
  If Screen scroll X == 0x0BXX, level section is increased
World 8 section 1 (F4F8):
  Waits for 0x4F3 (Object enabled) to become 0

World 9 section 0-4 (F505):
  If block player is in front of (0x615) == 0x30, level section is increased (causes a screen transition?)
  If block player is in front of (0x615) == 0x83, level section is increased (causes a screen transition?)
World 9 section 5 (F521):
  If Screen scroll X == 0x20XX, level section is increased
World 9 section 6 (F540):
  ??? Similar to W3S1
World 9 section 7 (F576):
  ???

World 10 section 0 (F58B):
  If Screen scroll X == 0x0FXX, level section is increased
World 10 section 1 (F5B2):
  Monitors 0x4F3 and 0x4F4
  ???
World 10 section 2 (F5E8):
  Waits for 0x4F3 (Object enabled) to become 0

World 11 section 0 (F5F8):
  If Screen scroll X == 0x0BXX, level section is increased
World 11 section 1 (F60F):
  Waits for 0x4F3 (Object enabled) to become 0

World 12 section 0-20 (F61C):
  ???
  There is a table at 0xF781 used to compare the block the player is in front of, and to decide where to warp the player:
    Block ID      Map section
          BF  --  01
          7A  --  0F
          C0  --  00
          C1  --  10
          30  --  11
          BD  --  12
          BE  --  13
  ???
World 12 section 21 (F713):
  Waits for 0x4F3 (Object enabled) to become 0
World 12 section 22 (F733):
  Waits for 0x4F3 (Object enabled) to become 0

Movement when riding an enemy:
Your final movement speed is calculated from a number of different sources
0xA9 is probably the horizontal speed gained from riding an enemy

Skipping shop:
  at 0xF7B0 the burger count (0x61E) is compared to 0 which skips a function that likely starts the shop routine.

Title screen:
  Address 0x22 is a counter for the start button. It is reset to 4 and counts down when the start button is held. When the counter reaches 0 the game advances to the next screen/into the game.

Level timer length:
  There is table at 0xC3D6 which specifies the timer length per level:
  Level 00? -  0xC3D6  =  24792 ???
  Level 01  -  0xC3D8  =  300
  Level 02  -  0xC3D8  =  300
  Level 03  -  0xC3D8  =  400
  Level 04  -  0xC3D8  =  400
  Level 05  -  0xC3D8  =  300
  Level 06  -  0xC3D8  =  400
  Level 07  -  0xC3D8  =  400
  Level 08  -  0xC3D8  =  300
  Level 09  -  0xC3D8  =  500
  Level 10  -  0xC3D8  =  300
  Level 11  -  0xC3D8  =  200
  Level 12  -  0xC3D8  =  500

Castle:
  Section 0x02 has two doors. The left door warps you to section 00 (entrance to the castle).

  The right door warps you to the left side of section 0x10, which looks identical to section 0x02. Going back through the door in section 0x10 brings you to section 0x0F, which is also identical to 0x02 and 0x10.

  Seems like 0x02 starts from the elevator down, 0x10 starts from the room on the left, and 0x0F starts from the door on the right.

  Ending level 11 on a 0x30 block ID wrong warps you to section 0x11 which looks like a hidden shop. Taking the elevator up takes you to section 0x08 which is identical to 0x0C. This is around halfway through the castle.

  Section 0x12 and 0x13 start from falling out of the ceiling on section 0x03.

  Section 0x05 is 0x03 coming down from the elevator from section 0x04.

  Section 0x07 is 0x03 on the elevator back from 0x06.

  Section 0x0D is 0x03 coming down from the elevator from section 0x0C

  Section 0x14 is the same as 0x15 (final boss room).

  Section 0x16 is a glitched version of 0x00 and 0x01 combined.

Level data ROM bank:
  The table at 0xC5AD says what bank each level's data is in:
  Level 01 - 3
  Level 02 - 3
  Level 03 - 0
  Level 04 - 0
  Level 05 - 1
  Level 06 - 2
  Level 07 - 0
  Level 08 - 1
  Level 09 - 3
  Level 10 - 1
  Level 11 - 2
  Level 12 - 3

Address 0x4f-0x50
  This address is filled from a table at 0xD102. The address fetched is then incremented by 3 before being stored to 0x4F and 0x50

  Level 01 - 8000 + 3 = 8003
  Level 02 - 8000 + 3 = 8003
  Level 03 - 90b7 + 3 = 90BA
  Level 04 - 8000 + 3 = 8003
  Level 05 - 8000 + 3 = 8003
  Level 06 - a0b4 + 3 = A0B7
  Level 07 - 9133 + 3 = 9136
  Level 08 - 8953 + 3 = 8956
  Level 09 - a0ee + 3 = A0F1
  Level 10 - 90d3 + 3 = 90D6
  Level 11 - 930c + 3 = 930F
  Level 12 - a206 + 3 = A209

Address 0x54-0x55
  This address is filled from a table at 0xCD9F.

  Level 01 - 9c0a
  Level 02 - 800f
  Level 03 - 801b
  Level 04 - 90d2
  Level 05 - 8013
  Level 06 - 8013
  Level 07 - a0cb
  Level 08 - 914e
  Level 09 - 8962
  Level 10 - a112
  Level 11 - 90e6
  Level 12 - 931b

Fetching level data:
  All accesses are in the bank for thr level. See the table above to find that bank.

  The address in 0x54-0x55 is for the level data.
  The address in 0x4F-0x50 is for a table of offsets into the level data. Each offset is 208 bytes long.

  To fetch level data:
  Take the high byte of the position
  Use that as an offset into the table from 0x4F-0x50 and fetch a byte value
  Take the value, multiple it by 208, and add it to the address in 0x54-0x55
  The resulting address is the beginning of that segment of data.

Enemy data
  Table in bank 5 at 0xAF63, add level_id * 2

  Level 01 - b9d7
  Level 02 - af87
  Level 03 - b507
  Level 04 - b697
  Level 05 - baa7
  Level 06 - b117
  Level 07 - b377
  Level 08 - bbb7
  Level 09 - b7a7
  Level 10 - b267
  Level 11 - bc87
  Level 12 - bd57

  That address points to another table, entries are 4 bytes long. Game fetches 0x4ED, multiplies it by 4, and adds it to get an address. Note: this addition (0xD24F) seems wrong and may have issues with bit overflow if the lower byte would overflow. Might be abusable for something?

  [0].b - Enemy position (low byte)
  [1].b - Enemy Y position?
  [2].b - Enemy type?
  [3].b - ???

  0x4ED seems to have room for 4 enemies per high position byte. If any of those are unused the data is all 0 in the above table.

Enemy spawn:
  Starting at 0xD229
  0x4ED seems to hold the next(?) enemy id to load for the level. The following must be true for the enemy to spawn:
    Player's position high byte must be <= end of level (0x4C)
    (Player's position + 0x90) (high byte) == Enemy high position byte
    (Player's position + 0x90) (low byte) < Enemy low position byte
    (Player's position + 0x193) (high byte) >= Enemy high position byte
      if equal:
        (Player's position + 0x193) (low byte) > Enemy low position byte
  what this boils down to is that the game checks every half screen (0x80 pixels) and increments the counter if you are in the first 4 pixels.
  you can skip the spawns for that half screen by being at 5 speed at a point where you move the screen from 0x7F->0x84 or 0xFF->0x04

World/Section Min/Max:
  Table at 0xBC00 (bank 4), indexed by level_id * 2. These are pointers to data for each world:
  Level 01 - bc36
  Level 02 - bc56
  Level 03 - bc76
  Level 04 - bca6
  Level 05 - bcc6
  Level 06 - bce6
  Level 07 - bd16
  Level 08 - bd36
  Level 09 - bd56
  Level 10 - bdb6
  Level 11 - bdd6
  Level 12 - bdf6
  
  Fetch that address and add section_id * 16
  Data in that table:
  [5].b = Min camera position 
  [6].b = Max camera position
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
The scripts we used: Block map: http://tasvideos.org/userfiles/info/51685216242376410 Minimap: http://tasvideos.org/userfiles/info/51685242883649450 Generic hud: http://tasvideos.org/userfiles/info/51685255902414411 We completely overlooked that the blocks in the HUD part might be used, so our Block map does not try drawing them. The HUD contains basic speed info, hit boxes, basic enemy info, basic apple info.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
There's a python backend in progress: https://github.com/dolphin-emu/dolphin/pull/7064 Instead of starting over, perhaps help with that one?
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
pirate_sephiroth wrote:
EZGames69 wrote:
pirate_sephiroth wrote:
why not just enforce neshawk for the contest then?
Not everyone can run BizHawk on their computers. besides, FCEUX and BizHawk are not too far off in accuracy. some runs can sync between the two.
huh? who wouldn't be able to run it?
Anyone on Linux for example.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
ais523 wrote:
Tools like Hourglass and WINE are translating at the API level, not the ABI level. The ABI basically just says "if you have a function which takes X arguments and produces Y return value, here are the registers you use, here's how you have to set up the stack, etc.". Most notably, the ABI doesn't define anything about what individual functions do. An ABI translation would thus allow you to connect together programs and libraries which were compiled using different compilers (the best-known such incompatibility being MSVC versus mingw).
I stand corrected, I must have understood the API vs ABI differences when it was first explained to me.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I would say that if the DRM / copy protection causes desyncs that cannot be solved by measures that should be taken anyway to ensure sync, then, for those specific games, it may be in our interest to allow it. For me, even if the original disc is required (for disc based games) in order for the movie to sync due to DRM / copy protection, it should not automatically be allowed to use a cracked version.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
The name should reflect what it's doing, so it's definitely an "ABI wrapper". (APIs are for when you write code, the ABI is when it executes)
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
link_7777 will be joining me and ViGadeomes.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Warepire wrote:
ViGadeomes wrote:
Warepire wrote:
I'm in. Will mainly work with technical stuff (glitch research, Lua), and not so much input production. Looking for appropriate team.
We could also make a team if an 3rd person is alone. I don't even know the lua language for the moment so it's a good thing !
Might be into it, hit me up on IRC.
ViGadeomes and I will team up.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
ViGadeomes wrote:
Warepire wrote:
I'm in. Will mainly work with technical stuff (glitch research, Lua), and not so much input production. Looking for appropriate team.
We could also make a team if an 3rd person is alone. I don't even know the lua language for the moment so it's a good thing !
Might be into it, hit me up on IRC.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I'm in. Will mainly work with technical stuff (glitch research, Lua), and not so much input production. Looking for appropriate team. Note: Will only collaborate through IRC. No Discord, Skype, etc. PMs are too inefficient.
Post subject: Re: About the branch name (yo feos)
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
ThunderAxe31 wrote:
Wikipedia wrote:
SRAM exhibits data remanence,[1] but it is still volatile in the conventional sense that data is eventually lost when the memory is not powered.
While BizHawk does save the Memory Card files into a folder called PSX/SaveRAM, I have to note that the electronics of Memory Cards don't look like being battery backed. GB/C and SNES games instead feature a typical watch battery inside (not always for GBA games). My point is that while "SRAM glitch" is accurate for GB/C and SNES games, it is not for PlayStation in general. However, I'm still unsure about which one would be a more appropriate label... Maybe something like "Memory Card glitch" or "EEPROM glitch"?
I would like to argue here that calling something "SRAM glitch" would be identifying something that abuses properties of SRAM in consoles that contain it.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I would personally be fine with a ruling that allows generated data for these scenarios, as long as such data does not break any specifications. Meaning in this case if certain ToC bytes in a CD cannot be certain values, those certain values in those bytes makes the data illegitimate. Nor that the data is unreasonable, like in the discussions about RAM. If the metrics of these kinds of features are understood, there's no reason to play by the book, specially if it means easier playback.
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Link to current publication: http://tasvideos.org/1357M.html
Warepire
He/Him
Editor, Experienced Forum User
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I was quite entertained by this, great work. Voted yes.