Kuribo64
Views: 11,099,658 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
08-09-20 07:18 AM
Guest:

0 users reading Editor development | 1 bot

Main - General SM64DS hacking - Editor development New reply

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 27 28 29 30 31
Crashdance22
Posted on 05-05-13 03:59 PM (rev. 3 of 05-05-13 05:43 PM) Link | #22018
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
Posted on 05-05-13 06:02 PM (rev. 2 of 05-05-13 06:03 PM) Link | #22024
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
Posted on 05-05-13 08:39 PM (rev. 2 of 05-05-13 09:39 PM) Link | #22031
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
Posted on 05-06-13 04:57 AM Link | #22038
Are you sure you've checked out the latest revision? It's working fine for me:

[image]
Make sure you're using a clean ROM.

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
Posted on 05-06-13 10:22 AM (rev. 2 of 05-06-13 10:22 AM) Link | #22040
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
Posted on 05-06-13 12:00 PM (rev. 3 of 05-06-13 12:34 PM) Link | #22041
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
Posted on 05-06-13 04:23 PM (rev. 2 of 05-06-13 04:23 PM) Link | #22048
Do you think this issue is related to this phenomenon? I didn't realize the editor uses NitroExplorer functions.

http://kuribo64.net/?page=thread&id=740

Fiachra
Posted on 05-06-13 05:16 PM Link | #22049
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
Posted on 05-06-13 08:44 PM (rev. 3 of 05-06-13 08:45 PM) Link | #22052
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
Posted on 05-07-13 10:08 AM Link | #22058
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
Posted on 05-07-13 02:46 PM (rev. 2 of 05-07-13 02:51 PM) Link | #22061
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...

[image]

Fiachra
Posted on 05-07-13 03:03 PM Link | #22062
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
Posted on 05-07-13 03:15 PM Link | #22063
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
Posted on 05-07-13 04:29 PM (rev. 3 of 05-08-13 08:35 AM) Link | #22065
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.


If a level has just one 128x128 image, you have to import a 128x128 image to replace it. If it's got more than one area, you should import a 256x256 image split up like:
| 1 | 2 |
| 3 | 4 |
Or for 384x384
| 1 | 2 | 3 |
| 4 | 5 | 6 |
| 7 | 8 | 9 |
Multiple 256x256 maps aren't yet working properly. You can import one image for all areas and it now displays properly.

Crashdance22
Posted on 05-08-13 10:45 AM (rev. 3 of 05-08-13 10:47 AM) Link | #22089
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
Posted on 05-08-13 12:02 PM Link | #22091
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
Posted on 05-08-13 01:27 PM (rev. 38 of 05-08-13 09:23 PM) Link | #22092
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
Posted on 05-08-13 08:09 PM Link | #22116
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
Posted on 05-08-13 09:23 PM (rev. 3 of 05-08-13 09:25 PM) Link | #22122
Ok, well thanks anyway.

Crashdance22
Posted on 05-10-13 08:50 PM Link | #22213
Well I suppose there's no point in supporting high res textures at all, does the same freaking thing even with non-tiled textures...

[image]

[image]
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development New reply

Page rendered in 0.043 seconds. (2048KB of memory used)
MySQL - queries: 26, rows: 232/232, time: 0.033 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.