 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
Register - Login |
||
|
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - Posts by Ratchetfan19 |
| Pages: 1 2 3 |
| Ratchetfan19 Member Level: 16      Posts: 25/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Glad to know the bug's fixed! Oh, and might I suggest stickying this thread? After all, it is the most significant advancement in Super Mario 64 hacking. |
| Ratchetfan19 Member Level: 16 Posts: 26/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Possibly. But moving data around the ROM to use space at the end of the ROM would be more conventional. |
| Ratchetfan19 Member Level: 16 Posts: 27/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
Originally posted by Stevoisiak The warp doors close quickly code you have there is actually the bounce off walls code. However, it may affect doors directly anyway because the values are so close together. As for the texture codes, these types of codes seem to only affect what texture set is mapped to the level geometry. I'm guessing it changes values in the level script. If you change a value, it will either map another texture set or will map "garbage bytes" (the random colors, sometimes flashing if variable RAM values are mapped). If only minute changes are made to the value, textures are still mapped in blocks and no garbage bytes are seen between textures. If you find those textures in the ROM it's likely you will see garbage bytes, proving that a stream of data from a starting location to an ending location isn't mapped. Whatever system this code modifies seems to know where to start and stop mapping textures. |
| Ratchetfan19 Member Level: 16 Posts: 28/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| VL-Tone, did you change any music sequences in the game, or was the music in your video music you mixed in with the capture? |
| Ratchetfan19 Member Level: 16 Posts: 29/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| I recently found this... http://www.youtube.com/watch?v=0_j4hL2rBFw Notice in the video that Mario's head geometry seems to be altered (from my standpoint), as polygons have been shifted. I asked papermario47 about the code, and I should get an answer soon. If I do get it, I'll let yoshiman look into it, since he's so good with RAM-related hacking. Edit: It does work in Project 64, but it looks nothing like it does in the video. I'm not sure what caused it to look so different on the N64, considering most color codes don't work on the N64 anyway. So here's the code. It's probably nothing special; I just found it interesting that it turned out that way. 8107EC20 5000 8107EC22 0000 8107EC2A 0000 8107EC40 FFFF 8107EC38 5050 8107EC93 6623 |
| Ratchetfan19 Member Level: 16 Posts: 30/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| No, it's not his TV. I tried the code myself and got the same shocking results... some pics: tinyshit/2iqn4o7.png tinyshit/efkj9k.png tinyshit/2pq84rb.png At first it actually looked like his geometry had been changed, but it's evident that the gradient angle/mganitude is different on each polygon, making Mario's polygon edges very noticeable. I don't know what causes the N64 to shade Mario this way, especially since the conventional dual shading method is used to shade Mario with his original RGB values. |
| Ratchetfan19 Member Level: 16 Posts: 31/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Sorry about the pictures, but there's really no other way to get screenshots from a real N64. |
| Ratchetfan19 Member Level: 16 Posts: 32/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
Originally posted by Metal_Man88 o.0 D'oh, silly me. I'll try to get some screens via a capture device then. Edit: Sorry, it doesn't work for me. My cap device doesn't handle composite video correctly for some reason. It may be because the input video is 320x240 and it expects 640x480, I don't know. |
| Ratchetfan19 Member Level: 16 Posts: 33/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| What's going on in RAM? And I don't visit these forums every day, so give me some time to respond. |
| Ratchetfan19 Member Level: 16 Posts: 34/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Well, it obviously changes RGB shading values for Mario's geometry. Here are known RAM offsets for shading data, according to the Super Mario 64 Color Code Tutorial... 8107EC40 8107EC42 8107EC38 8107EC3A 8107EC20 8107EC22 8107EC28 8107EC2A 8107EC50 8107EC52 8107EC58 8107EC5A 8107EC70 8107EC72 8107EC68 8107EC6A 8107EC80 8107EC82 8107EC88 8107EC8A 8107ECA0 8107ECA2 8107EC98 8107EC9A Sorry for the annoyingly long list. You can go to one of these locations with your RAM viewer and see how everything is arranged. Check the video description to see which values represent which shade. The only location out of the ordinary with this code is 8107EC93. It probably either changes the gradient angle, magnitude, or direction. I don't see where this parameter is actually used in-game. Maybe it's something related to special effects that Nintendo didn't use? You might want to look into this, VL-Tone. Who knows, maybe this parameter could be used in Toad's Tool someday! |
| Ratchetfan19 Member Level: 16 Posts: 35/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
Originally posted by Reimu Hakurei There's an alpha layer? Well I guess there has to be, seeing that Mario turns transparent when entering and leaving a warp. Someone should check those values when Mario warps, if possible. If they're changed, maybe we can find the command that enables the alpha layer. |
| Ratchetfan19 Member Level: 16 Posts: 36/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| So you're saying opacity is a parameter, after all? And a useful one, at that? |
| Ratchetfan19 Member Level: 16 Posts: 37/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
Originally posted by messiaen Wow, you can do that? Is this the actual polygon data for the SM64 logo? If it is then maybe we can reverse-engineer it. VL-Tone seems to know a lot about the model format since he converted them for use in the Shockwave player on his website and in Toad's Tool 64. Is there an object that calls this model, or is it just ASM? Maybe looking into this data can allow us to understand more of the model format used in SM64. |
| Ratchetfan19 Member Level: 16 Posts: 38/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| VL-Tone, do you have an idea of how many polygons/vertices the graphics engine can handle without slowing the game down? Actually, you might as well code a generic limit because if the game runs fine one moment, it could slow down another depending on what's currently loaded. But that raises another question. Now it's obvious that any graphics engine has its limits, but why does the game slow down when it approaches the 240 object limit? For example, I can create 200 objects in Flatworld with no sprites and no behavior, and the game would still slow down. Is it a result of "external" coding that runs in the background for each object? |
| Ratchetfan19 Member Level: 16 Posts: 39/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Congratulations messiaen! You've created the official Super Mario 64 test level! Also, how did you shade the mushroom and the text where the SM64 logo should be? And speaking of the logo, can anything be done with that yet as far as making it an object and creating a collision map for it? |
| Ratchetfan19 Member Level: 16 Posts: 40/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| So the empty behavior loads or unloads the object depending on how close or far away Mario is from it? But I thought the level script did that. |
| Ratchetfan19 Member Level: 16 Posts: 41/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| You could make a level that consists only of the logo! But you're right, collision would be hard to apply to that model accurately. But you never know. I suggest giving it a shot anyway and see how it turns out. Actually, I think there was a level in Super Monkey Ball Deluxe that was Sega's logo that you rolled around on. That's what reminded me of this idea. |
| Ratchetfan19 Member Level: 16 Posts: 42/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| If we do get around to having a model importer, say, if it has to many polygons/vertices/faces, would TT64 fix it up or would it have to be appropriately drawn in 3DS max or a similar program? Edit: And that reminds me, if you want to take an exisiting level geometry, like Delfino Plaza from Super Mario Sunshine for instance, would it be possible to slim down its polygon count to a reasonable number by "reducing" its quality in a 3D modeling program? |
| Ratchetfan19 Member Level: 16 Posts: 43/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Yes, I'm actually hacking away at this game. Been messing around with the bmd files and palettes and such, here's what I have so far. Working with castle_tree.bmd, found the palette at the end of the file. I exported from the first 15 bit BGR pixel to the end of the palette with a hex editor, determining the starting pixel with Tinke. The resulting file was too big at 544 bytes so I trimmed off the last 32 bytes to bring it down to the standard 512 byte size. Then I converted it to RIFF format using ImPalEd. I opened the bmd file in Tile Molester alternate and imported the palette. I seem to be close, but the colors are incorrect. Using the really old clock tower map example I got that to work considering the palette was a seperate file, but am having no luck here. Are my TM settings at the bottom correct?  |
| Ratchetfan19 Member Level: 16 Posts: 44/50 EXP: 17755 For next: 2501 Since: 11-20-07 Since last post: 531 days Last activity: 406 days |
|
||
| Thanks for the links MM and everything you have contributed to this game! I just downloaded the latest build of SM64DSe, it's really coming along nicely even after you abandoned the project. Considering the map tiles are uncompressed I assumed all textures were uncompressed given the fact that I can sort of make out the tree shape in TM. I'm not a programmer, script kiddie at best. I suggested the addition of a texture editor to SM64DSe but not optimistic on that ever happening. Swapping textures from bitmaps/jpegs/pngs would be ideal though. Are there currently any tools I can use to edit DS bmd textures? |
| Pages: 1 2 3 |
| Jul - Posts by Ratchetfan19 |
 |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.224748 seconds |
| Script execution time: | 0.080117 seconds |
| Total render time: | 0.304864 seconds |
