Kuribo64
Views: 19,851,303 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
03-28-24 04:06 PM
Guest:

0 users reading Editor development | 2 bots

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

Pages: 1 2 3 4 5 ... 17 18 19 20 21 22 23 24 25 ... 27 28 29 30 31
Fiachra
Posted on 04-23-14 10:42 PM Link | #40538
It is an issue, I and others have come across it before. It doesn't happen with all translucent textures, some work fine, some cause all textures to be glitches and others crash the level.

Greatmystic
Posted on 04-27-14 12:48 PM Link | #40647
How do I post ppictures on here?

Arisotura
Posted on 04-27-14 12:55 PM Link | #40651
Upload them to an image hosting site such as imgur. Then use [img] tags.

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

zafkflzdasd

skawo
Posted on 04-28-14 02:17 PM Link | #40699
https://dl.dropboxusercontent.com/u/4558852/whoops.png

This happened after copying a coin.

Fiachra
Posted on 04-28-14 04:55 PM Link | #40704
Yeah, that's that bug in the Model Cache. Just reopen the ROM, the original models aren't touched, it's just the renderer. I'll and fix it for the revision after the next one (currently busy working on a big new feature for the next revision).

skawo
Posted on 04-29-14 02:18 PM Link | #40727
Little patch for USv1

At x10fb4 BC to BB to make the star draw distance bigger

Cackletta
Posted on 04-29-14 05:46 PM Link | #40743
Do you mean 0x10FB49?

Fiachra, will there ever be a model replacer for mario? I don't know if its already in the editor.

____________________
Subscribe to my youtube channel
Follow me on twitter
My Modification's progress thread here

Fiachra
Posted on 04-29-14 06:37 PM Link | #40744
Posted by skawo
Little patch for USv1

At x10fb4 BC to BB to make the star draw distance bigger

Thanks, I'll add it to the next revision.
Posted by Cackletta
Do you mean 0x10FB49? ...

It looks it he's posted the right address, the value at 0x10FB4 is BC, whilst the value 0x10FB49 is 03. You could have checked that yourself.

Posted by Cackletta
... Fiachra, will there ever be a model replacer for mario? I don't know if its already in the editor.

It's currently possible to replace models with bones in a limited way by splitting OBJ models into different objects. I wouldn't bother with that though as the next revision will allow you to import properly rigged models (skeleton/joints and skinning) using the COLLADA format (I've actually already got that done).

skawo
Posted on 04-29-14 10:08 PM Link | #40749
By the way, I should mention that patch is sort of very rudimentary and if you have levels that are verging on the polycount limit, you probably shouldn't use it.

Skelux
Posted on 05-01-14 06:32 PM Link | #40795
This one will make all objects always visible from a distance.
0x110EC: 0A 00 00 EB

Causes a lot of lag, not practical if a hack contains any complex levels.

Cackletta
Posted on 05-01-14 06:49 PM Link | #40796
Lags like? I haven't noticed any since so far, I've also tested it in open levels, what kind of lags are you referring to we'd like to know. Your patch works great.

____________________
Subscribe to my youtube channel
Follow me on twitter
My Modification's progress thread here

Fiachra
Posted on 05-01-14 06:52 PM Link | #40797
Posted by Skelux
This one will make all objects always visible from a distance.
0x110EC: 0A 00 00 EB

Causes a lot of lag, not practical if a hack contains any complex levels.

Thanks, this'll be a very patch to have.

Posted by Cackletta
Lags like? I haven't noticed any since so far, I've also tested it in open levels, what kind of lags are you referring to we'd like to know. Your patch works great.

If there are lots of objects and your level has a high polygon count you'll notice a slowdown.

Skelux
Posted on 05-02-14 05:58 AM Link | #40828
Posted by Fiachra
Posted by Skelux
This one will make all objects always visible from a distance.
0x110EC: 0A 00 00 EB

Causes a lot of lag, not practical if a hack contains any complex levels.

Thanks, this'll be a very patch to have.

Posted by Cackletta
Lags like? I haven't noticed any since so far, I've also tested it in open levels, what kind of lags are you referring to we'd like to know. Your patch works great.

If there are lots of objects and your level has a high polygon count you'll notice a slowdown.


ie, ds Mad Musical Mess has about 5000 polygons and 100 objects.

skawo
Posted on 05-02-14 07:03 AM Link | #40830
This lag and polygon disappearance mostly applies to the DS hardware too, as it'll be most noticeable there.

skawo
Posted on 05-11-14 04:36 PM Link | #41147
Collision importing on objects doesn't work properly.

Fiachra
Posted on 05-11-14 05:13 PM Link | #41152
When reporting an issue you need to give more detail, your post gives no details regarding what is actually wrong or how to reproduce it. If you don't provide that, how am I supposed to work out what's wrong?

The problem I'm guessing you're referring to is holes in the collision, this is because the objects' model and their collision maps are usually 125 times larger than you see in the editor and the game - the problem is actually with creating collision maps with huge faces - if you subdivide the large faces in your model the collision map will be fine. If not that, you're probably importing them with the wrong scale.

skawo
Posted on 05-11-14 07:12 PM (rev. 6 of 05-11-14 07:17 PM) Link | #41156
Clearly, you already knew what the issue was. This would be pretty hard to miss. Besides, there's nothing more to this; it just does not work properly. End of story.

@explanation: If there is an issue, why won't fix it? You do realise dividing the model like that would just make each single import object model super high poly for no reason, right? Like, if there's some impossibility in importing large faces, why not do something to work around this? I don't know, import them normal, then scale?

I mean, clearly, it's not impossible to have collision that big. Nintendo somehow managed it, afterall.

Jesse
Posted on 05-11-14 08:32 PM Link | #41158
I have an issue with scrolling textures. the issue is that you don't have control over which direction the texture is scrolling too. skawo allready told me that I could fix it with the rotation tab, but I figured out that it has the same effect when you rotate the texture while mapping it.

No I talk about that the texture translation is now saying to the texture that it must shift from the upper right pixel to the down left pixel. with seamless textures it won't be that bad but with non seamless textures it looks like horror.

could you please add control over the direction from which its scrolling?

Fiachra
Posted on 05-12-14 07:14 PM Link | #41189
skawo: I had just never gotten round to fixing it, turns out it's a very simple bug, I was casting a very large value used to calculate the triangle's vertices to an int when it should have been a long. It'll be fixed in the next revision.

jjess064: skawo is right, you change the rotation value used. This does not have have the same effect as simply rotating the texture, if you change the texture animation in Castle Grounds for the waterfall to have a rotation of 90 degrees, the waterfall's texture will scroll from right to left.

Jesse
Posted on 05-13-14 10:27 AM (rev. 2 of 05-13-14 11:12 AM) Link | #41202
yeah but its not an seamless texture. If I do that it will look very ugly.

Here is a gif of it
[image]
Pages: 1 2 3 4 5 ... 17 18 19 20 21 22 23 24 25 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

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