Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 19,994,356 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-19-24 12:12 PM |
| Guest: | ||
| Main - Posts by StarPants |
| StarPants |
| ||
 Red Koopa Normal user Level: 24 
Posts: 61/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
SSL is really well done, I especially liked the haunted pyramid. Too bad it lags significantly on R4 (i tried playing it with my DS lite, 3DS and "new" 3DS XL and there isn't a big difference). I think that's mainly because of Boos. Speaking of which, why don't you try to make Yoshi able to defeat Boos? |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 62/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Imo it's much more fun and challenging to not have coins in the aquarium. SM64DS is too easy anyway. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 63/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
How can i use static libraries? What is that offset i need to enter?
Also, if i want to run some code every frame and call functions from my static or dynamic libraries or spawn actors, am i forced to make hooks with NSMBe or is there some other way around? Edit: unrelatedly, does anyone know the actor id of Yoshi's egg?  |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 64/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
You made a custom boss? Cool! |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 65/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
I wonder how Nintendo chooses which projects it wants to take down. I have an impression that they just attack stuff they randomly see on youtube. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 66/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
This is extremely awesome. Keep up the great work! |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 67/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Version 0.1 relesed!
Download: Patch + source code ------------------------------------- ORIGINAL POST: I thought it would be better to move this to its own thread so.. I'm currently working on a first person view hack. I will be posting my progress and/or problems here. I will also explain some details about what I exactly do to make this happen 
Progress/Diary: At first i did something like this (i don't remember the exact values): #include "SM64DS_2.h"
void hook_020e50ac() { CAMERA->pos = Vector3 {0x0_f, 0x0_f, 0x50000_f}.RotateYAndTranslate (PLAYER_ARR[0]->pos, PLAYER_ARR[0]->ang.y); CAMERA->angle = PLAYER_ARR[0]->ang; } This however, made the camera go totally crazy because its position is apparently updated somewhere between my code and rendering. The game doesn't like it when the camera is in front of the player but looks away from the player. Then i took a clean rom (patched with the editor though) and used no$gba's read/write breaks to find out where the camera's position is updated. I changed the instructions in the following addresses to "nop": 0203B710 0203B760 0203B1AC 0203B1C8 0203B1E8 0203B1F4 0205288C 020528A0 020528C4 020528D4 020528F8 02052908 After this the camera no longer moved, only rotated, as expected. As a side effect, any objects weren't visible to the camera, except player's shadow. Also, the players position on the minimap didn't match with the shadows position. The camera was pointing towards the shadow though. I have no idea why this happened since i only removed instructions that write to CAMERA->pos. So, any ideas why all objects became invisible? Is removing instructions all around the game's code worth it or should i just find a better address to hook my code? Does anyone happen to know the address of the rendering function? |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 68/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Yeah all the objects were invisible, and the camera wasn't even in the players position yet. It was fixed in one place on purpose. I wanted to remove all the instructions that write to CAMERA->pos so that the games own code doesn't mess things up.
I'm not planning to put the camera in front of the player really. If I just did this void hook_020e50ac() {
CAMERA->pos = PLAYER_ARR[0]->pos; } the camera would stare at players butt, which is not what I want. I want the camera as close to the players eyes as possible. I'll try that "Objects Always Visible" patch to see if it changes anything. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 69/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Actually i didn't try the patch thing yet because
a) i found out that it was very probably one of the first three instructions in the previous list that was causing the invisibility of all objects (i suppose str is a safe instruction to remove, is that the case with stmia, stmib, streq, etc? (I don't know the ARM instruction set that well yet) b) I changed my plan so that i will not delete any of the games own instructions, since that apparently makes things unstable. Instead, i will find out where the general rendering code is, and hook my code just before that. This way (hopefully) i can overwrite any changes to camera made by the original code. I changed the camera behavior of all materials to "Normal" and camera-go-through to true to make things simpler. I found out that touching to CAMERA->angle was causing most of my problems and i should use CAMERA->lookAt instead. It's not a unit vector that tells the cameras orientation as I stupidly first thought, but a point (vector from origin) the camera looks at. My current approach for the code is to put the camera to the same place as the player's head bone, with an offset vector. This is because i want the camera to follow the player's head movements. For example, when eating with Yoshi, it would be stupid if the camera didn't go down with his head. I also want that when the player does flips, the camera flips too. ..and i completely forgot that such thing as views existed in this game lol. I might want to just delete them all |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 70/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Ok that explains a lot |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 71/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
In the right side of my post, you see "Quote"
Click that. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 72/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
They mean you can not just post a plan of your hack, you need to show actual progress or people won't like it. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 73/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Posted by dy The first thing i did was printing the memory addresses of the x, y and z coordinates of the camera. fpv.h: #include "SM64DS_2.h"
extern "C" { /* This function is defined in print.s from ASM Hack Template v1, possibly written by Fiachra or Dirbaio. */ void nocashPrint(const char* txt); } void HexPrint(unsigned int value, char *result); fpv.cpp: #include "FPV.h"
void HexPrint(unsigned int value, char *result) // This is also from the ASM hack template v1 { byte i = 0; byte current = 0xFF; while (i < 8) { current = (byte)((value >> i * 4) & 0x0F); result[7 - i] = (char)(current + ((current < 10) ? 48 : 55)); i++; } } void hook_020e50ac() { char string[8]; HexPrint ((int)&(CAMERA->pos.x), string); nocashPrint (string); HexPrint ((int)&(CAMERA->pos.y), string); nocashPrint (string); HexPrint ((int)&(CAMERA->pos.z), string); nocashPrint (string); } I don't know how much you know C++ but in this case & works as an address-of operator, which is pretty handy for our purposes imo. Now it should repeatedly print three consecutive addresses to the TTY Debug window. In my case, they are 0218638C, 02186390 and 02186394. Use Desmume's RAM Watch and you'll see that the values in these addresses change accordingly to the cameras position. (Desmume can also display debug messages with its console but it can be glitchy) I think Desmume's RAM Watch is much better for certain things than No$gba's data window. Then i made a membreak like this: [0218638C..02186394]!! This way, it breaks even if the new value is the same as the old one because there were two exclamation marks. If you see no correlation between these membreaks and cameras position, make sure you have just one exclamation mark. Even then, you won't necessarily be able to see any changes since the position might be changing only 1/4096 fxu per frame. Also, the instructions in the addresses in the first post are not the only instructions that write to CAMERA->pos. For me, nop'ing them worked as i expected though. Surely there were some side effects but that was kinda expected too since i was nop'ing instructions i didn't exactly know. I guess i didn't expect a reduced instruction set computer to be able to write to multiple mem addresses at once. By the way, any clue of the rendering code? |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 74/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Thanks a lot for that address. When i was using the old address the cameras position changed once or twice during the opening cutscene but that doesn't happen anymore, which is good. The camera is now more overall stable, too. So, no need to nop anything anymore.
I also found it quite disorienting to play with "L pressed down" but believe me, it feels much better when the camera is up close because the camera will actually not move as quickly (I have tried it already). I know that wall jumping will be harder but that's ok. I don't really care that much if Luigi's backflips become impossible to control because they're too op anyway. I've already succeeded with attaching the camera to the player's head bone. Here's the code if you want to try it out: #include "SM64DS_2.h"
extern "C" { void nocashPrint(const char* txt); } void HexPrint(unsigned int value, char *result); #include "FPV.h"
void HexPrint(unsigned int value, char *result) // Credits to Dirbaio or Fiachra for the printing code { byte i = 0; byte current = 0xFF; while (i < 8) { current = (byte)((value >> i * 4) & 0x0F); result[7 - i] = (char)(current + ((current < 10) ? 48 : 55)); i++; } } void hook_0200da0c() { constexpr u8 supposedlyYoshi = 3; Matrix4x3* transform; transform = PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->data.transforms; Vector3 playerXaxis = Vector3 { PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r0c0, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r1c0, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r2c0 }; Vector3 playerYaxis = Vector3 { PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r0c1, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r1c1, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r2c1 }; Vector3 playerZaxis = Vector3 { PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r0c2, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r1c2, PLAYER_ARR[0]->bodyModels[supposedlyYoshi]->mat4x3.r2c2 }; Vector3 x_axis = playerXaxis * transform[15].r0c0 // X and not Z axis because reasons + playerYaxis * transform[15].r1c0 + playerZaxis * transform[15].r2c0; Vector3 pos = playerXaxis * transform[15].r0c3 + playerYaxis * transform[15].r1c3 + playerZaxis * transform[15].r2c3; CAMERA->pos = PLAYER_ARR[0]->pos + (pos << 3); CAMERA->lookAt = CAMERA->pos + x_axis; char* string; HexPrint ((int)&x_axis, string); nocashPrint (string); } This code only works with Yoshi. There isn't an offset vector yet so the camera is somewhere in the player's neck but that will be changed later. If you try it you'll know that attaching the camera to player's head bone isn't exactly optimal, but i have plans how this could be improved drastically. I needed to be able to read bone matrices in order to attach the camera to the bone. It was kinda confusing that there aren't matrices in the Bone struct in SM64DS_2.h. I mean, here it is: struct Bone
{ unsigned unk00; unsigned unk04; unsigned unk08; Vector3 scale; uint16_t unk18; Vector3_16 rot; Vector3 pos; unsigned unk2c; unsigned unk30; }; I thought that one of those unknown variables could be a pointer to a matrix, but ended up never experimenting them in ram watch because I found a pointer to the bone matrix elsewhere. It was actually pointed by 'transforms' in the ModelComponents struct: struct ModelComponents
{ char* modelFile; Material* materials; Bone* bones; Matrix4x3* transforms; char* unk10; void UpdateBones(char* animFile, int frame); void UpdateVertsUsingBones(); }; That's pretty weird i think. Maybe it points to the same place as one of the unknown variables in Bone struct but i dunno, haven't tried. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 75/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Nice! How did you discover Yoshi's secret abilities in the first place? |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 76/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
It is very surprising that it doesn't crash. Maybe Yoshi was intended to be able to punch but this ability was removed in the last minute. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 77/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
I got asked if I could make a custom CLPS behavior. So, here it is.
Doing this was relatively simple thanks to mibts' header files. Here's the code: #include "SM64DS_2.h"
void hook_0200da0c() // This address found by dy is called every frame just before rendering { if (PLAYER_ARR[0]->wmClsn.sphere.floorResult.clps.BehaviorID() == 0x1E && !PLAYER_ARR[0]->isInAir) { PLAYER_ARR[0]->speed.y = 0x40000_f; } } It basically checks if the triangle in which the player is standing on has behavior type of 0x1E (30 in decimal) and sets player's y speed to 64 fxu/frame. To make your own CLPS behavior, just change the code inside that if-block. Edit: Oh I forgot the xdelta |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 78/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Ok thanks. Btw i absolutely love your header files |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 79/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
Indeed, "L held down" feels better when the camera is closer. However, that's not what I want for this hack because this is kinda inspired by Kaze's sm64 first person and I want this to be similiar, only better and more enjoyable. Also, when the camera was more stable (when it didn't follow the head bone yet) jumping felt like I was playing a first person shooter and I like that.
I have plenty of tricks to stabilize the camera such as locking/reducing its orientation in relation to player's root bone while walking/running. I'm also going to limit player's turning speed because turning 180° in one frame is disorienting enough in third person. I'm starting to think that programming different camera behaviors for most common animation states might be worth it in order to make this more playable. |
| StarPants |
| ||
|
Red Koopa Normal user Level: 24
Posts: 80/124 EXP: 74729 Next: 3396 Since: 04-12-16 Last post: 1364 days ago Last view: 5 days ago |
| Main - Posts by StarPants |
|
Page rendered in 0.127 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 228/228, time: 0.016 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |