Any Brigandine (PSX) fans?

[Prevch]

Thanks for the fast reply. It's always fun to hear similar stories in terms of being introduced to Brigandine. I didn't have a lot of money for games either, so buying one was a big risk. I paid $13 for Brigandine, try buying a copy for that now.

You're right on the money with teaching college, students who don't want to be in class, just don't come. Sooooooooooooo much better.

In terms of my mod, I actually think writing a function to figure out the odds of a spell or attack hitting would be fun. I don't know the formula for that, but I'm assuming that with a little experimentation and number crunching, I could figure it out.

As you mentioned, they already has to be a function built-in to the game that returns the % chance of a spell or attack succeeding. In GE, I'm assuming it's a value returning function and that the result is being assigned to a variable which is then being passed to the text drawing function.

It seems like, according to your post, the hard part is going to be finding those functions and tapping in to them.

I'm not familiar with the Playstation assembler language, do you have any documentation on it?

I also have never used a Playstation debugger, so maybe I will check out the psx 1.13 debugger and see what I can figure out.

It sounds like this could be quite an undertaking. Maybe it would be easier to just write custom functions, but either way, I'd have to find the variables that hold combatants various statistics.

This could get crazy........

I appreciate your help. If anyone one the forums has some good resources for tutorials on psx assembly or debuggers, shoot the links my way!

I will hit Google and see what I can find.

Thanks!

Update: I just played some LOF last night and became aware of a another potential hiccup for my mod. In GE, when a player selects a unit to attack or cast a spell on, two screens pop up that give an overview of the attacking unit and the unit being attacked along with the % chance that either unit will hit. Those two screens that pop up are frozen until the user hits the "O" button to confirm they want to perform the attack. In LOF, two screens also pop up, but they do not display the % chance of hitting, nor do they freeze and wait for the player to confirm the action, they simply pop up for a second or two and then the previously selected action is carried out. In other words, in order for this mod to replicate GE, I would have to do the following:

1. Find the variable or the function call that holds/produces the chance to hit for each unit
2. Find a way to display the % chance on the two pop up screens
3. Freeze the pop up screens in place until the user confirms that the action they selected is the action that they want to carry out by hitting the "X" button (since this is LOF USA it will use "X" instead of "O"). I'm assuming there is a function similar to thread.sleep built in that can do this, but it will require further investigation.
4. Give the user an opportunity to cancel the selected action by hitting the ^ (that's supposed to be a triangle) button
5. Figure out what to do if they cancel. I mean, I logically know what I want to happen, but I need to make sure that the code understands what I want. (go back to the battle overview screen)

It's too bad we can't load a .EXE into Visual Studio and have the code show up as JAVA, or C#, or C++ or something, that would make this way easier. What would be REALLY cool is if someone took all the cool things from GE and put them into LOF....now that would be a project!

Ok, so, "cut my teeth" on the debugger. Here we go! Maybe I can change Coel's starting class to ninja master or something, that seems way easier!

[dmpdesign]

I had a pristine copy, and a stupid friend borrowed it and lost my map/class change guide that came with it.

Now I am a very very sad man ever on the lookout at my local game stores fora complete copy...since of course one on ebay goes for a ton of cash.

[Prevch]

I had a pristine copy, and a stupid friend borrowed it and lost my map/class change guide that came with it.

Now I am a very very sad man ever on the lookout at my local game stores fora complete copy...since of course one on ebay goes for a ton of cash.

Total bummer. You might be able to find the map and class change guide online and just print them out? I know it's not the same, but better than nothing!

[HwitVlf]

Grrrr, that sort of thing happened to me a couple time too so I stopped loaning games out. ‎ 

Some info about Playstation assembly.
The PS1 uses a MIPS processor with 32 registers for most of the work. If you don't know, a register is just a "slot" in a CPU where a number is stored. ‎  Most operations that a CPU does will add,subtract,move a number between registers or load/store a number from a register to RAM.
The PS1 has 2,048,000 bytes (2MB) RAM and memory location are 32 bits long usually with an "80" added as the first byte. So 0x8000f800 would be 0xf800 in RAM.
The Playstation exe is loaded verbatim into RAM starting at 0xf800.

HERE is a reference that covers most of the MIPS op codes you will see in the debugger.
That page may seem a bit intimidating if you're just starting out, but you don't really have to understand it to get started.

Just to avoid confusion, I'll mention that the 32 registers have two different naming conventions. The first numbers them in order 1-31, but the second divides them into numbered categories based on what the counter is used for.

Code:

r0     zero
r1    at
r2    v0
r3    v1
r4    a0
r5    a1
r6    a2
r7    a3
r8    t0
r9    t1
r10    t2
r11    t3
r12    t4
r13    t5
r14    t6
r15    t7
r16    s0
r17    s1
r18    s2
r19    s3
r20    s4
r21    s5
r22    s6
r23    s7
r24    t8
r25    t9
r26    k0
r27    k1
r28    gp
r29    sp
r30    s8
r31    ra

You shouldn't need this info, but HERE is a link to some technical info on how the registers are used.

Some other helpful things,
MIPS op codes list the destination register first, followed by the values that will be used in the computation:
‎  ‎  ‎  For example "addiu r2, r3,0x10" (an add command) will write to r2 the sum of r3+0x10.

An "Immediate" is just a number that is provided in the current op code (as opposed to read from a register). It is abbreviated as "i" in the op tag.
‎  ‎  In the example above, addiu means Add Immediate Unsigned and 0x10 is the "Immediate" value.

Hex numbers are set up like an old car odometer, meaning they "roll over" when they reach their max. So subtraction is usually carried out as an ADD operation. If you see an op code like "addiu r3, r3, 0xffff" It is actually subtracting 1 from the number in r3. "addiu r3, r3, 0xfffe" would be -2 and so on. I think the 0x7fff is the cut off for where it stops adding and begins actually subtracting: so "addiu r5, r5, 0x7000" would be +0x7000.

The PS1 requires "aligned" memory reads and writes. In other words, if you use the lw (Load Word) op code which loads 4 bytes from RAM into a register, the RAM location that is being read from or written to must be divisible by 4. So the read/write locations will always ‎  end in 0x0, 0x4, 0x8 or 0xC when using LW/SW (load/store word). If you don't follow this rule, ‎  your changes may play on an emulator, but will crash on actual hardware.

The MIPS architecture has a delay after certain op codes are enacted. So if you use any Load or Store operation, you have to wait one cycle (1 op code) before you can use the loaded/stored data. You will sometimes see a LW op followed by a "nop" (no Operation) rest because of this. You don't have to waste this cycle, you just can't use the data in the Loaded/Stored location till the next cycle.

On Branch or Jump operations, there is a 1 cycle delay as well. So the Op following the Branch or Jump will be enacted before the jump/branch happens.

Cheat codes can be very useful when tracking down data locations. Codes usually contain the memory location where the game stores the data. In this case, a cheat code for editing a unit's AGI stat should give you the location where that stat is stored in RAM. Once you know that, you can set a break (in the debugger) that will pause the game when that area in RAM is accessed. When the game stops, it should be near/in the function that uses AGI to calculate hit odds.

When using a break in Psx debugger, it stops on the op code AFTER the break was triggered.

In Psx debugger, Ctrl+G lets you go jump to locations. in memory.
‎  F7 executes one op at a time (used after a break is triggered)
‎  F8 executes one op at a time, but speeds past called functions. A called function will have a JAL op code. The function is still run,just doesn't show you the steps.
‎  You can set up break conditions using a tag such as "r5==0x32"

When you get ready to write new code and inject it, a complier program called armips is the one you will want to use. It will convert your op tags to machine code and inject them into the PSX exe. I can help you set up armips if you get that far.

[Prevch]

Thanks HwitVlf,
That was incredibly helpful. Just from reading your description, I can tell that I have a lot of experimentation to do in order to learn this stuff, but thank you for taking the time to offer up some examples.

I can tell that you have learned a lot from your translation project.

Per your suggestion, I am going to start small. I think I will try to change a character's stats in some way or do something along those lines just to get a feel for the process.

I understand programming high level programming languages, but this stuff is brand new to me and, as of this writing, a little outside my comfort zone.

I did find this though https://www.amazon.com/Guide-RISC-Proces...+processor

It's a book about RISC processors. Do you think this would be helpful? I know that the playstation processor instruction set are hardware dependent, but I thought this book might be a good reference.

I teach full time, and several side projects through work and am currently in school myself, so my time is somewhat limited. If anyone is watching this thread and really interested in my mod (I'm probably the only person, lol!) It's going to be a very SLOW project ‎ 

Thanks again for all your help.

BTW, it did not know that monsters had descriptions in GE that is so awesome. I can't wait to read your work!

[HwitVlf]

I would NOT recommend such a book as it would be waaay more technical information that you need to accomplish what you want. The "tangle" of info I posted above is about 90% of the info you need, it probably just sounds complicated because it jumps right in the middle instead of working it's way up.

I will post a simple example here soon that might make it clearer.

Being familiar with programming will help a lot. It just takes a little experience to figure out how a high-level code operation is reduced to a handful of these assembly operations. ‎ 

[Prevch]

That's awesome. Thank you so much for your help.

Unrelated question - Do you know why the multiplayer aspect of Brigandine GE only uses one controller? I'd love to play GE over Kaillera using EPSXE, but it only works if game supports a second player through controller port 2. ‎ 

[Hellborn]

Hello, Prevch. I found some documentation for the code in PS. Maybe it will help you understand.
https://www.zophar.net/fileuploads/2/107...tation.htm

[Prevch]

Thanks Hellborn I really appreciate it! ‎ 

[HwitVlf]

As far as why GE uses a single controller? Not sure. Since multiplayer can have from 1-6 players, maybe they thought 2 controllers would confuse things. Changing it to use both controllers would probably be hard, but I haven't worked in that area much so I don't know for sure.

Anyways, I checked into some of the basics of the hit/mis routine and made some notes which are attached. I'm not sure the notes will be of any help what so ever; they may even confuse you more than ever ‎  It also includes a savestate from the pSX emulator in order to follow along with the notes.

You know what would be ultimate cool? Finding a way to transfer the LoF 3D scenes into Grand Edition. I'm sure that would be quite a lot of work, but wouldn't it be neat?!!

Edit: Attachment moved to next post