Kuribo64
Views: 11,108,809 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
08-13-20 12:57 PM
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 13 ... 27 28 29 30 31
Arisotura
Posted on 05-10-13 09:08 PM Link | #22221
A note about high-res textures: with the DS's GPU, texcoords don't work like they do with OpenGL. 1.0 in texcoord units equals one pixel. Meaning that if you replace a texture with a larger one (or a smaller one), you'll also need to update the texcoords accordingly. Unless you can somehow get texture scaling to work.

This also worsens the texcoord overflow problem. A lot. The bigger the texture is and the less it can repeat across a polygon.

To give an example: texcoords are stored as 12:4 fixed point, that is: 1bit sign, 11bit integer part, 4bit fractional part. They range from -32768 to 32767, that is, from -2048.0 to ~2047.9.

If your texture is 16x16, it can repeat at most 127 times. If it repeats more, texture coordinates will overflow, resulting in visually wrong results.

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Crashdance22
Posted on 05-19-13 09:43 AM (rev. 2 of 05-19-13 01:28 PM) Link | #22855
Replacing tree textures still corrupts the US ROM. Also, replacing a texture with the same name as another texture in the same level corrupts other textures using that name. And considering I've been running into so many texture issues, can you configure the editor to not commit texture changes until you click save? This will allow me to verify importing a texture doesn't break the ROM (often it appears blocky/corrupted in the preview) before I save the file and have to go back and do a restore.

Fiachra
Posted on 05-19-13 02:43 PM Link | #22900
Posted by Crashdance22
Replacing tree textures still corrupts the US ROM. Also, replacing a texture with the same name as another texture in the same level corrupts other textures using that name.

They're probably using the same palette and you're overwriting it when you import a new texture. I'll change it to create a new palette entry.
And considering I've been running into so many texture issues, can you configure the editor to not commit texture changes until you click save? This will allow me to verify importing a texture doesn't break the ROM (often it appears blocky/corrupted in the preview) before I save the file and have to go back and do a restore.

Have done.

Crashdance22
Posted on 05-20-13 09:09 PM Link | #23010
Nope, tree still corrupts the ROM. Do you have a US ROM to test with?

Fiachra
Posted on 05-21-13 04:20 AM (rev. 2 of 05-21-13 04:44 AM) Link | #23019
Posted by Crashdance22
Nope, tree still corrupts the ROM. Do you have a US ROM to test with?

I know it's still corrupting and yes, I have all 5 versions but I haven't had any time recently - I'm in the middle of exams. Is there a reason you can't just use the EUR ROM until it's fixed?

Can you try with some other models stored in archives?

Crashdance22
Posted on 05-21-13 08:03 AM Link | #23022
Must have misunderstood what you said about the palettes, you must be talking about the duplicate name issue. Just tested that and it's still happening as well. Take your time there is no rush at all, I'm just poking around testing stuff. :)

Crashdance22
Posted on 06-22-13 12:47 PM Link | #26396
Are there scale properties for these objects?

Fiachra
Posted on 06-22-13 02:00 PM Link | #26401
Most of them don't but you should be able to change the value in the first 4 bytes of the BMD file to increase the scale, 0 = normal, 1 = 2x bigger, 2 = 4x bigger etc.
You could export and re-import for more precise control but you'd have to fix the textures manually.

Fiachra
Posted on 06-30-13 05:12 AM (rev. 2 of 06-30-13 01:27 PM) Link | #26662
I had nearly gotten the levels displaying properly in the editor's Java port but I just tried building the latest version of the editor in Mono and it turns out that it does actually work under Linux!

[image]
It seems upgrading the project from VS2008/.NET 3.5 to VS2010/.NET 4.0 has made it more compatible with Mono.

Crashdance22
Posted on 06-30-13 12:13 PM Link | #26689
Screenshot doesn't work, but that's awesome! Does this mean just about any OS running Java can run this?

Fiachra
Posted on 06-30-13 12:25 PM (rev. 2 of 06-30-13 01:28 PM) Link | #26696
That's not the Java version, that's it running running in Linux under Mono. It means it can run in Windows, Linux and Mac.

Fixed image in above post.

Tahcryon
Posted on 06-30-13 01:06 PM Link | #26700
Oh my god oh my god oh my god. Fiachra, have I ever told you how awesome you were?! Really awesome work :)

____________________


[04/15/2018]gridatttack: I still think the whole smg2.5 team are still in middle school lol
[04/15/2018]gridatttack: and they are 14yrs old
__________

cosmological: There's no one in Russia who doesn't agree with Putin, probably because his ideas are that great



MK7tester
Posted on 06-30-13 01:11 PM Link | #26701
That looks great Fiachra! Nice work! :yum:

mariogalaxythree
Posted on 06-30-13 01:13 PM Link | #26702
Wow, you are the god of SM64ds hacking Fiachra! Way to make the best use of an underrated game!

____________________
-MG3- IS HERE


Arisotura
Posted on 06-30-13 06:03 PM Link | #26728
Posted by Fiachra
I had nearly gotten the levels displaying properly in the editor's Java port but I just tried building the latest version of the editor in Mono and it turns out that it does actually work under Linux!

[image]
It seems upgrading the project from VS2008/.NET 3.5 to VS2010/.NET 4.0 has made it more compatible with Mono.

Ah? From what I remember, it was nothing but pain. It wouldn't work with .NET 4.0 because of something that wasn't implemented in Mono, and the 3D would work rather randomly...

Anyway, if that removes the requirement of making a Java port, it's all good :)

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Fiachra
Posted on 07-01-13 01:54 AM Link | #26755
It would give an error when trying to cast certain Form objects such as SplitPaneContainer to ISupportInitialize which wasn't supported in Mono but you don't actually need to have it, it can be safely removed and then it works. I'm going to add keyboard navigation to make the 3D easier to use.

Arisotura
Posted on 07-04-13 03:33 PM Link | #27111
Bleh, I wish I had found out earlier. It'd have saved me a ton of trouble.

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Fiachra
Posted on 07-29-13 03:01 PM Link | #29256
Committed Mono changes (should've done that a few weeks ago). You should be able to check it out as it is and have it compile/run in Mono without any modification. Doesn't affect how it works in VS2010.
bin/ folder also updated with newest versions, so people stop asking how to compile it.

Arisotura
Posted on 07-29-13 08:11 PM Link | #29285
Nice! However, does the change that makes it work on Linux, alter autogenerated code? If yes, we might need something to keep VS2010 from generating that, or something, dunno...

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Fiachra
Posted on 07-30-13 02:37 PM (rev. 2 of 07-30-13 02:38 PM) Link | #29322
When you make a change to a form, eg. adding a button, these two lines get re-added (they prevent most of the forms working):
((System.ComponentModel.ISupportInitialize)(this.splitContainer1)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.splitContainer1)).EndInit();

As long as you remove these, it should be fine in Mono. I've been able to switch between VS2010 and Mono without any problems.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development New reply

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