Kuribo64
Views: 32,887,125 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search 		03-12-26 04:24 AM
Guest:

0 users reading Editor development | 1 bot

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

Pages: 1 2 3 4 5 6 7 ... 27 28 29 30 31
Skelux
Posted on 01-06-13 10:06 AM Link | #3980
Banned

Level: 28

Posts: 31/148
EXP: 125428
Next: 5910

Since: 11-27-12

Last post: 4308 days ago
Last view: 2767 days ago
Posted by Fiachra
Posted by Skelux
Could you paste me the line of code that writes 0 as the collision? Considering the size of my levels, it would be faster for me to just find an appropriate collision and set it for every plane in the level on import.

It's in ObjToKcl.cs - Line 198:
kcl.Write16(pos + 14, (ushort)0);

Just change that 0 to the collision type you want.


Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

Fiachra
Posted on 01-06-13 02:25 PM (rev. 2 of 01-06-13 08:24 PM) Link | #4053
Local moderator

Level: 66
avatar
Posts: 31/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago
Posted by Skelux
Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

I've added the option to use the old method when importing a model (rev. 27) and some other changes - see second post.

Posted by Skelux
Adding Y-offset options would allow you to place the level down near the death floor. From memory, about -8000 was how much it needed.

Most (if not all) levels have a collision type for the death floor - you can use the KCL editor to set the lower faces of your level to be the death floor

Skelux
Posted on 01-07-13 02:19 AM Link | #4330
Banned

Level: 28

Posts: 32/148
EXP: 125428
Next: 5910

Since: 11-27-12

Last post: 4308 days ago
Last view: 2767 days ago
Posted by Fiachra
Posted by Skelux
Thanks, It doesn't seem to be the problem though, the invisible slowness barrier is still there. Tomorrow I'll try the earlier revision.

I've added the option to use the old method when importing a model (rev. 27) and some other changes - see second post.

Posted by Skelux
Adding Y-offset options would allow you to place the level down near the death floor. From memory, about -8000 was how much it needed.

Most (if not all) levels have a collision type for the death floor - you can use the KCL editor to set the lower faces of your level to be the death floor


That's the faulty collision with all the horrible gaps.
As I thought, rev 23 has near perfect collision with no problems on any hills. Something changed between r23 and r27 has caused random hill problems.

Fiachra
Posted on 01-07-13 07:15 AM (rev. 5 of 01-07-13 08:19 PM) Link | #4362
Local moderator

Level: 66
avatar
Posts: 32/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago 		The changes between rev. 23 and 24 were:

This line: if (cross(v.sub(u), w.sub(u)).norm_sq() < 0.001) { continue; } //#TODO: find a better solution

was removed as it was getting rid of very small faces.

Also sometimes num_buckets could be equal to zero if there were fewer than 256 triangles in the model

int result = (int)(ix*this.magic_x + iy*this.magic_y + iz*this.magic_z) % this.num_buckets;

so this has been fixed to set num_buckets = 1 not 0 if there are fewer than 256 faces.

Edit: I have now added the first line back in but you can now configure the value it uses - 0 to keep all faces, default value is original 0.001. For your Bob-Omb Islands model the value 0.0005 seems to sort out both the hill and the raised bumps around the roof of the floating fort.

Please see second post (revision 29 07/01/2013).

shibboleet
Posted on 01-15-13 07:05 PM Link | #6265

Fire Mario
DROP TABLE users;

Level: 126

Posts: 554/4661
EXP: 22491213
Next: 592891

Since: 07-07-12

Last post: 2034 days ago
Last view: 1047 days ago 		Wow, this is actually going great!

So SM64DS hacking has resurrected from the dead :D

____________________
a

Fiachra
Posted on 01-15-13 07:39 PM Link | #6277
Local moderator

Level: 66
avatar
Posts: 33/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago 		Yeap :)

I haven't been working on it as much though this past week as I'm working on porting a level from Super Mario Sunshine to SM64DS. So far I've finished simplifying the model from over 16000 faces to 3750 (the maximum the DS can handle, a lot higher than I previously thought) and I'm nearly done with the re-texturing.

I'm currently adding an interface for the texture collision data which hopefully will allow adding and removing from selected areas and renaming the material to use as well as the scale, rotation and translation values.

ray
Posted on 01-15-13 07:43 PM Link | #6279
Normal user

Level: 26
avatar
Posts: 80/119
EXP: 91750
Next: 10525

Since: 07-07-12
From: In front of my PC

Last post: 3431 days ago
Last view: 3221 days ago
Posted by Fiachra
So far I've finished simplifying the model from over 16000 faces to 3750 (the maximum the DS can handle, a lot higher than I previously thought)


As soon as my model hits more than 2048 faces, the game freezes. How the hell can you use a 3750-model? o0

____________________
Check out my Patreon Page if you want to support me :)



Arisotura
Posted on 01-15-13 07:46 PM Link | #6280

Star Mario
hax

Level: 167
avatar
Posts: 807/9105
EXP: 61434569
Next: 24005

Since: 07-03-12
From: in a box :D

Last post: 58 days ago
Last view: 9 hours ago
I guess it depends on how many objects and stuff you have in your level.

It's like for texture size: there's no absolute limit, but you can tell that past a certain number, things tend to become unstable (like textures getting glitched or freezes).

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

zafkflzdasd

Gericom
Posted on 01-16-13 01:04 PM Link | #6368
Member
Normal user

Level: 16
avatar
Posts: 31/40
EXP: 17880
Next: 2376

Since: 07-07-12

Last post: 4548 days ago
Last view: 4391 days ago
Posted by Mega-Mario
I guess it depends on how many objects and stuff you have in your level.

It's like for texture size: there's no absolute limit, but you can tell that past a certain number, things tend to become unstable (like textures getting glitched or freezes).

The limit is the available ram on the nintendo ds.

Dirbaio
Posted on 01-16-13 10:56 PM Link | #6437
Retired staff

Level: 31
avatar
Posts: 161/184
EXP: 176411
Next: 8952

Since: 07-07-12
From: Spain

Last post: 4432 days ago
Last view: 2830 days ago 		The DS's hardware can handle maximum 2048 triangles or 1536 quads. (It has Vertex Ram for 6144 vertices).
Polygons that are completely outside the viewing volume are not stored at all in the Vertex RAM. This is why it's possible to put models with more than 2048 triangles. As long as not all of them are visible at the same time, it will work fine.

When the Vertex or Polygon RAM is full, any new polygons will fail to display. I'm not sure if it actually freezes the 3D hardware. GBATek says nothing, and I've never personally tested it. But I *think* it doesn't freeze, it just ignores new polygons.

____________________
Cool Stuff: Dirbaio.net (my boring site) - The NSMB Hacking Domain - Kuribo64 - ABXD DevBoard

Gericom
Posted on 01-17-13 01:13 PM Link | #6564
Member
Normal user

Level: 16
avatar
Posts: 32/40
EXP: 17880
Next: 2376

Since: 07-07-12

Last post: 4548 days ago
Last view: 4391 days ago
Posted by Dirbaio
The DS's hardware can handle maximum 2048 triangles or 1536 quads. (It has Vertex Ram for 6144 vertices).
Polygons that are completely outside the viewing volume are not stored at all in the Vertex RAM. This is why it's possible to put models with more than 2048 triangles. As long as not all of them are visible at the same time, it will work fine.

When the Vertex or Polygon RAM is full, any new polygons will fail to display. I'm not sure if it actually freezes the 3D hardware. GBATek says nothing, and I've never personally tested it. But I *think* it doesn't freeze, it just ignores new polygons.

With my mkdd models in mkds it always happens. It just doesn't display the remaining polygons.

Dirbaio
Posted on 01-17-13 09:09 PM Link | #6655
Retired staff

Level: 31
avatar
Posts: 162/184
EXP: 176411
Next: 8952

Since: 07-07-12
From: Spain

Last post: 4432 days ago
Last view: 2830 days ago 		Great, then the models are crashing for some other reason we don't know...
I have no idea...

____________________
Cool Stuff: Dirbaio.net (my boring site) - The NSMB Hacking Domain - Kuribo64 - ABXD DevBoard

Fiachra
(post deleted) #6735

Fiachra
Posted on 01-19-13 06:20 PM (rev. 3 of 01-19-13 06:29 PM) Link | #7391
Local moderator

Level: 66
avatar
Posts: 35/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago 		Has anyone worked out the texture animation data, specifically the last values at offset 0x18 (below)?
The documentation says the last value is 4 bytes but it's actually 2 ushort values. For most texture animations they're the same as the translation values table start index and amount of values but then in others it's just 1, 0 and then in others it seems to be the total length of the translation values table.
I'm trying to allow you to remove a specific texture animation from an area but I think this is causing problems. If no one knows, I'll just leave it as editing existing values - adding/removing scale, rotation and translation values and setting the name (can resize) or removing all of them.

Animation data: 28 bytes per entry.

Offset Size Desc
00 4 ???
04 4 Address of the name of the material with the texture to animate (null-terminated ascii string)
08 4 ???
0C 2 Number of scale values
0E 2 Start offset in dwords in the scale values table
10 2 Number of rotation values
12 2 Start offset in words in the rotation values table
14 2 Number of translation values
16 2 Start offset in dwords in the translation values table
18 4 ???

[image]

Edit: Changing doesn't seem to do anything at all. I can delete individual texture animations if it not the first one, otherwise it deletes the first one but the ones after it just appear as noise in their main colour even though their values appear to be fine when read by the editor.
Edit: Finally got that working, now I need to try and allow adding new texture animations.

Finally finished the texture animation editor (rev. 30). You can edit or remove existing texture animations including their scale, rotation and translation values as well as adding new ones.


[image]

Also added option to change minimap co-ordinate scale.

Mega-Mario:
Is there anything else you think needs added?

Edit: Just merged above post.

Also, this is the level I was talking about, though the water looks better now than in the video.
http://www.youtube.com/watch?v=Llq53_P8Tow

Arisotura
Posted on 01-19-13 08:07 PM Link | #7473

Star Mario
hax

Level: 167
avatar
Posts: 850/9105
EXP: 61434569
Next: 24005

Since: 07-03-12
From: in a box :D

Last post: 58 days ago
Last view: 9 hours ago
Well, I can't think of anything to add right now, it should be okay :)

Also let me know when you think that all this stuff is ready for a release :)

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

zafkflzdasd

ray
Posted on 01-19-13 08:27 PM Link | #7490
Normal user

Level: 26
avatar
Posts: 81/119
EXP: 91750
Next: 10525

Since: 07-07-12
From: In front of my PC

Last post: 3431 days ago
Last view: 3221 days ago 		It would be nice, if you can add copy-pasting objects :) Or a "Select multiple objects" mode or something like this, which lets you move more objects at once, or delete or whatever. Maybe when holding CTRL or something.

____________________
Check out my Patreon Page if you want to support me :)



Arisotura
Posted on 01-19-13 09:13 PM (rev. 2 of 01-19-13 09:14 PM) Link | #7508

Star Mario
hax

Level: 167
avatar
Posts: 852/9105
EXP: 61434569
Next: 24005

Since: 07-03-12
From: in a box :D

Last post: 58 days ago
Last view: 9 hours ago
Multiple selection would definitely be possible, it'd just require a bit of work. Like, every time something is done to selectedObject, we'd have to instead iterate through a list and do the action to each object in that list.

Related detail: the standard Winforms treeview control doesn't support multiple selection. But since the one SM64DSe uses for its object list uses owner-drawing, we can use that to make lines look like they're selected.

Java's treeview implementation does support multiple selection, so when we port SM64DSe, that hack won't be needed anymore :)


Reminds me, on GUI and Linux: Dirbaio once mentioned that anchors cause GUIs to break under Mono. Perhaps that's the cause of our Linux problems, who knows. Another possible cause is owner-drawing, but then blarg and blarg.

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

zafkflzdasd

Fiachra
Posted on 01-19-13 09:27 PM Link | #7517
Local moderator

Level: 66
avatar
Posts: 36/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago 		The only thing that isn't fully working of the stuff I've added is model exporting - there seem to be problems with quads. I'll try and fix that tomorrow but if that doesn't work, I say just release it as it is, it's got plenty of other new features, most importantly the fixed collision :)

Fiachra
Posted on 01-24-13 10:52 AM (rev. 2 of 01-24-13 11:03 AM) Link | #9261
Local moderator

Level: 66
avatar
Posts: 38/1065
EXP: 2416532
Next: 45319

Since: 12-15-12
From: Ireland

Last post: 2845 days ago
Last view: 795 days ago 		Got model exporting working :) I made a mistake with working out the amount of faces in quadrilateral strips, messed up BODMAS. I had this:
4+(N-1)*2 vertices per N quads
((N/2)-4)+1 Quads. per N Vertices
instead of
4+(N-1)*2 vertices per N quads
((N-4)/2) + 1 Quads. per N Vertices

Some textures are upside down or repeated incorrectly but that's because the BMD format supports texture features that OBJ doesn't, that can't be helped. Also fixed the issue with exporting models that had a material without a texture that caused the textures to become swapped around.

Before:

After:
[image]

Code committed - rev. 31 24/01/2013

I had made improvements to the minimap editor that appeared to be working perfectly but it seems that resolution and other information about the minimaps is hardcoded into the game somewhere. Eg. just swapping playroom's minimap with Bob-Omb Battlefield's doesn't work. As Mega-Mario would say: Blarg!
The changes though should allow it to be used as a general 2D graphics editor with some changes.

shibboleet
Posted on 01-27-13 06:07 AM (rev. 2 of 01-27-13 06:16 AM) Link | #10246

Fire Mario
DROP TABLE users;

Level: 126

Posts: 856/4661
EXP: 22491213
Next: 592891

Since: 07-07-12

Last post: 2034 days ago
Last view: 1047 days ago 		Wow, this is amazing! :D
It's amazing on how fast this got revived :3
I'm really impressed with it! It might make a level...but I have no real knowledge of SM64DS hacking that much...

____________________
a
Pages: 1 2 3 4 5 6 7 ... 27 28 29 30 31

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

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