![]() | ||
Views: 24,256,395 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
03-18-25 05:30 PM |
Guest: |
0 users reading Editor development | 1 bot |
Main - General SM64DS hacking - Editor development | Hide post layouts | New reply |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 8/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
Awesome! I'll try it out! By the way, I ran into "out of bounds" errors when trying to import larger textures, specifically a texture of double size. I only tried it with one texture and figured that isn't fully supported.
Edit: How to access Mario's model/filesystem stuff? |
Fiachra |
| ||
Local moderator Level: 65 Posts: 118/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
Open a level, 3D Model>Import other model
I think Mario's model is in a folder called Player but I can't remember where. The other 3 players' models are in /ARCHIVE/arc0.narc |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 9/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
The game crashes after selecting a file (white screen) when I try to swap the tree texture for the trees used outside the castle. The replacement image seems to be causing a corrupt block to form in the compressed image. There is a square of gray pixels with solid colors surrounding it. Possibly a buffer overflow? Is the image converter/compressor buggy? Because I've also noticed that if I export a texture and re-import it again, the image quality degrades and compression artifacts/blocks form that weren't previous present. |
Fiachra |
| ||
Local moderator Level: 65 Posts: 119/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
Are you sure you've checked out the latest revision? It's working fine for me:
When you're importing images they should be indexed, if you don't you'll get the problems you mentioned with the colours being wrong. Use Photoshop, GIMP or some other image editing program to set the image's Mode to Indexed. It should have no more than 256 colours. Also, when importing textures, try to stick to 8, 16, 32, 64... sized images, you'll get a translucent border using, eg. 48x24. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 10/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
I'm using indexed images and round numbers for dimensions on a clean ROM using the latest R51. I've tried several images to replace the trees, including Peach's portrait, and it's still corrupting my ROM. It loads fine in the editor. Want me to send you the file? |
Fiachra |
| ||
Local moderator Level: 65 Posts: 120/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
The error only happens in the US ROM but not the EUR one. There seems to be a problem with accessing files by name from the US ROM because the EUR one has different NARC files. Seems to be because I changed:
string[] narcs = { "arc0", "ar1" }; to: string[] narcs = { "ar1", "arc0", "c2d", "cee", "cef", "ceg", "cei", "ces", "en1", "vs1", "vs2", "vs3", "vs4" }; in NitroROM.cs to allow you to open any file in the Minimap Editor. I'll try getting this to work for both versions, the JAP ROM is the same as the US one. Also, Crashdance22 - xdelta produces much smaller patches than PPF-o-matic ![]() Edit: Changing the above lines allow any file to be opened correctly in any version but they're still becoming corrupt in the US version when they're saved. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 11/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
Do you think this issue is related to this phenomenon? I didn't realize the editor uses NitroExplorer functions.
https://kuribo64.net/?page=thread&id=740 |
Fiachra |
| ||
Local moderator Level: 65 Posts: 121/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
No, those swaps don't work because you're modifying the game while it's open in 2 different programs and then saving again without reloading the new data, so things like offsets are completely different. You shouldn't edit ROMs in 2 programs at once. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 12/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
I think you misread the thread. What I was doing was actually "fixing" a corrupt ROM. Swapping wrong model/animation/collision files in NitroExplorer breaks the ROM as expected, but if I save in the editor following the swap it boots. Didn't know if the bug had anything to do with it or not, very strange. |
Fiachra |
| ||
Local moderator Level: 65 Posts: 122/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
Use NSMBe for swapping files - it doesn't corrupt the ROM.
Rev. 52 Fixed a bug in minimap editor where the images weren't being de/compressed or it tried to do it more than once. Made wording more clear. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 13/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
I frequently get "Index was outside the bounds of the array" when trying to swap higher resolution textures. You said you managed to replace several in one level. Judging by the results I'm guessing this is a ROM limitation...
![]() |
Fiachra |
| ||
Local moderator Level: 65 Posts: 123/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
If they look messed up in the editor, then it's a problem with my code for replacing them.
Does this happen only in-game or is this how they appear in the editor? If it's only in the game this happens, then you're using too high resolution images. It does look very cool though! |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 14/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
The editor crashes when I load the ROM after doing this. It still saves and messes up the ROM despite the error message. In this case I tried swapping out the two 64x64 castle wall textures with 128x128 replacements. The thing is it threw the error on the first try, surely replacing one texture in a clean unedited ROM wouldn't cause issues? |
Fiachra |
| ||
Local moderator Level: 65 Posts: 124/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
There's a problem with the code for replacing the BMD's textures, probably missed an offset somewhere. I'll try and fix it tomorrow.
I'm also going to get multiple minimap importing working properly, specifically the different map files. EDIT: It should be fixed now. The problem was I forgot about "For compressed (type 5) textures, the size of the texture data doesn't count the palette index data. The texture data is then directly followed by (size/2) of palette index data." and I was calculating the original size using m_Textures[index].m_Data.Length which I thought was the same as the data size value in the texture's header. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 15/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
Nice, everything seems to work now. One side effect of importing higher res textures I noticed, for tiled/repeated textures the pixel density doesn't change, the texture just consumes more space on the plane and repeats less often. I'd like to try some cool stuff with wall textures, grass, etc. but I would need to use at least double resolution textures for those. Is there any way to configure the texture mapping to draw the texture in the same space on the plane? Or at least for imported high res textures? |
Fiachra |
| ||
Local moderator Level: 65 Posts: 125/1065 EXP: 2325217 Next: 10411 Since: 12-15-12 From: Ireland Last post: 2487 days ago Last view: 436 days ago |
I'm not sure if that's possible. There's a texture scale value for each material but I think (not sure) Mega-Mario found that this only worked in emulators.
If that's the case, you'd have to export the model and re-import it. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 16/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
I found the materials section. Unfortunately the texture S and texture T scale values are ignored. I tried halving the values, doubling them, and even setting them to zero. Didn't notice a single change in appearance.
Mega-Mario do you know anything about these values? |
Arisotura |
| ||
![]() Star Mario in this room you have a pile of apple pies Level: 165 ![]() Posts: 1303/9055 EXP: 58704651 Next: 231030 Since: 07-03-12 From: in a box ![]() Last post: 22 days ago Last view: 37 min. ago |
I don't know if they're actually used or not, now that you're bringing it.
All I know is that my attempt at using them to get rid of the texture repeat count limitation failed miserably, either because of that or because texture coordinates always have the same shitty precision that always causes them to overflow no matter what you do. ____________________ NSMBHD - Kafuka - Jul melonDS the most fruity DS emulator there is zafkflzdasd |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 17/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
Ok, well thanks anyway. |
Crashdance22 |
| ||
Normal user Level: 24 Posts: 18/112 EXP: 78056 Next: 69 Since: 05-04-13 Last post: 3219 days ago Last view: 2462 days ago |
Well I suppose there's no point in supporting high res textures at all, does the same freaking thing even with non-tiled textures...
![]() ![]() |
Main - General SM64DS hacking - Editor development | Hide post layouts | New reply |
Page rendered in 0.044 seconds. (2048KB of memory used) MySQL - queries: 26, rows: 230/230, time: 0.028 seconds. ![]() © 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |