 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread |
New poll |  | Thread closed |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
proffessor_gad Red Koopa                  Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
| Even better- In version 2, you can place objects into the room by moving the mouse to where you want the object to be, and clicking. I know of one script that can convert screen coordinates into 3d coordinates.... | |||
Skreename Giant Red Paratroopa   Since: 11-18-05 Last post: 6301 days Last view: 6294 days |
| ||
| Actually, that could be a bit confusing to try to do, since a single mouse coordinate could map to several 3d ones. | |||
|
proffessor_gad Red Koopa Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
| It might be challenging, but fully possible. It would convert the screen x, y, coordinates into game x,y,z(as 0) coordinates and then change the z into what it should be according to the terrain found in that x,y position. The only problem would be overlapped terrain.... | |||
VL-Tone Paratroopa   Since: 11-18-05 Last post: 6485 days Last view: 6485 days |
| ||
| The Joypad option could be interesting, there's probably a plug-in to use those with Director... I'll have to check that.
I thought about placing/moving objects with the mouse before, and from what I concluded it would be too confusing... And setting the Z value according to the terrain would probably lead to many bugs/problems. I may add a "drop to ground" button so that you can easily put something on the ground, but I wouldn't base a mouse interface on this... By the way, my Castle 64 online demo is currently being dugg at a furious rate... http://digg.com/gaming/Online_3D_Viewer_for_Mario_64_Peach_s_Castle You should see the visitors log updating... I currently get multiple hits per second! I had to put it at the place of Metroid Cubed (which is on my isp 5 megs host) because it was being served with my Cable modem with a 150K/s maximum upload rate. (edited by VL-Tone on 05-01-06 12:49 AM) |
|||
Shiryu Gungun  Since: 02-24-06 Last post: 6296 days Last view: 6294 days |
| ||
| It's cool, but it has some bugs... for example in big boo haunt, in the room with the red bars and conects the firts floors, there's something like a black wall... | |||
|
proffessor_gad Red Koopa Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
| Well, since you think that mouse-oriented creation of objects is so hard... Perhaps I should create an exe demonstrating the technique (yes, it will include terrain) ? | |||
|
Chainlink1061 Paratroopa  Since: 02-01-06 From: Salinas, California Last post: 6298 days Last view: 6300 days |
| ||
| Professor Gad: Sorry if it's any bother, but I was wondering: How long have you been ROM hacking? | |||
|
proffessor_gad Red Koopa Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
| I am rather new to Rom Hacking. But I have had previous experience in creating/designing 3d/2d games from scratch. I am not a professional, I am still learning, but I can do some pretty basic things. Currently I am studying the mapping of terrain based purely from triangle drawing codes. If all goes well I will be able to write out a script for triangle terrain detection that could be implemented into this editor, as well as 3d games. | |||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6485 days Last view: 6485 days |
| ||
| proffessor_gad: actually, I may implement your proposed feature after all, but as an option, not as the main way to put objects in levels. This feature is useful, but imposes limitations on where you can put or move objects.
I wasn't sure of what you meant at first. What you want is to be able to click on the 3D viewport, and place/move an object at the point on the polygon surface under the cursor? That would also mean that you could stick things to walls just by clicking there, which is not a bad side effect at all. Maybe I underestimate you, but I'm not sure you realize all the implications of calculating this point. It's not simply about calculating the intersection between a vector and triangles. Did you take into account perspective? Objects that are farther away are smaller so their relation to a mouse click is on a different scale. The rays coming out of the camera are not parallel. So you have to calculate the angle in relation to the camera field of view angle. You also have to take into account the size of the 3d viewport. Far from impossible, but not straightforward. Anyway thanks for proposing the code example, but I don't think I'll need it, as Shockwave 3d commands takes care of this whole process with only a few commands. Here is an excerpt from a Director/Shockwave website:
So I'll use some similar code in my editor. tRay will contain a normalized direction vector pointing in the direction of the 3d point where the object should be placed. It could then be multiplied by a high number, lets say 10000, to create a line that will intersect with polygons To find the actual coordinate, I'll have to use the modelsUnderRay command, which can return a list of all the 3d models in a scene that intersect a given ray, and how what proportion of that ray is outside the model(s). Multiplying that number with the length of tRay (10000) and adding the camera position will return the coordinate we're looking for, which is the point where the line going forward under the cursor meets with the closest visible polygon in that line of sight. But anyhow that will be a neat option, if it works well. But to place objects that float in the air, and have complete control of their positions some more traditional X,Y,Z controls would be needed. And for multiple selection and polygon vertex editing anyway, it would be required. For now though, I still have some work to do on rewriting the basic structure of the editor, I'm not into rewriting the 3d part yet. |
|||
Raccoon Sam Boomerang Brother Custom Title  Since: 11-20-05 From: Correct Last post: 6294 days Last view: 6294 days |
| ||
| Heh, interesting but yet amusing..
Are you going to release a "You can do stuff but can't see anything in 3D" -version first? I mean, you wouldn't have to code the 3D-part. |
|||
|
proffessor_gad Red Koopa Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
Well, my way didn't use rays, it used vectors. The only problem the code had was camera angles(you have stated this already). The code relied on the room(level's)width and height and put that into the calculating formula. But rays would work better in this case because of the "terrain" collissions. The vector detection was meant primarily for flat surfaces, and sometimes had division by zero errors  . But it is nice to know that you will implement mouse-oriented object creation in future versions. Hope everything goes well. Signing off, Proffessor_gad |
|||
Guy Perfect Since: 11-18-05 Last post: 6296 days Last view: 6295 days |
| ||
What I did for the F-Zero X editor was have a "click and drag" setup in a different part of the program where you could use the mouse to move control points without dealing with fancy 3D junk. In the picture below, the green rectangles are "click and drag" areas, where they will change the approperate values when you... well, when you click and drag.
 |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6485 days Last view: 6485 days |
| ||
Originally posted by Raccoon Sam It's possible that I'll release a non-3d version before June, but rest assured, I got the 3d working on the older version, it's only a matter of rewriting a better version. proffessor_gad: Rays are pretty much synonymous with vectors in that context. BGNG: Very interesting interface elements... May I steal the basic concept? I already thought of a click-and-drag approach for the angle interface widget, though it was with a round control, and the angle formed from a line rotating around the center. Holding shift would give you 15 degrees steps. Anyway, maybe a picture would help 
I would use the widget for the coordinates, but use it differently. I would put a cross in the middle of the middle of the square, and make it look like some graph paper or radar, with the X and Y axis labeled as such. Clicking on the center wouldn't move the object, but as you drag away from the center it would start to move, and faster as you drag away from the center. The Z axis (vertical widget) would work much the same way, but with an horizontal line in the middle to show the zero point. I'll also put options to swap axis so the square could control the X/Z coordinates while the vertical slider would be used for the X, and maybe options to invert coordinates. I got my "parameter bar "system working, though what you can see now is the "raw" version. 
My design include ways to insert control widgets of any type to the right of each value. Angles could have specific rotary controls, other values up/down arrows etc. Each element on the bar is resized to take the control buttons into acount. The 3d controls though would be outside of the bar interface. Also, each value could display a description label that describes the current value. A pop-up menu control will enable you to use some pre-defined values, with their labels. Also I'm working on including extra parameters that would control multiple values at the same time. I'll call these "presets". That will be very useful to pair sprite types and behaviors, or behaviors and their 2 parameters. It could be also useful to pair banks and offsets values, which are linked together. Here is a property list I made to define how most types of values are displayed and edited in the interface: actvalue,Act,8,binstars,0,1 objtype,Sprite Type,3,popmenu,40,0 xPos,X Pos,5,coord,0,1 yPos,Y Pos,5,coord,0,1 zPos,Z Pos,5,coord,0,1 xRot,X Rot,3,angle,0,1 yRot,Y Rot,3,angle,0,1 zRot,Z Rot,3,angle,0,1 behav,Behav,6,popmenu,40,0 param1,Param 1,3,none,0,1 param2,Param 2,3,none,0,1 objid,Type ID,3,none,0,1 banknum,Bank ID,2,popmenu,20,0 geolayout,Object Layout Pointer,6,popmenu,20,0 bankstart,Bank Offset,8,none,0,0 bankend,Bank Offset End,8,none,0,0 warpid,Warp ID,3,popmenu,0,0 destlevel,Destination Level,2,popmenu,25,0 destarea,Destination Area,1,areanum,0,0 destwarp,Destination Warp ID,popmenu,0,0 musictrack,Music Track,3,popmenu,25,0 solidoffset,Solidity Data Offset,6,none,0,0 macroobject,Macro Sprites Offset,6,none,0,0 LevelID,Level ID,3,popmenu,25,0 jumpoffset,Level Script Offset,6,popmenu,25,0 The first item is the symbol used to label this parameter internally. The second is the human readable description that will replace labels you see on the screenshot. The third item, is the number of char in the displayed value. It will be used to determine the width of the value fields (currently it's based on the length of the content, so it's narrower with 0 than 100). The fourth item is the name of the control widget to be shown at the right of the value field. The fifth item determines if there is a value description label. If not, it equals 0, if yes it equals the number of characters shown by the label. The last item is a boolean to say if the text field for this value is editable or not. Many won't be editable by default, but I'll include a way to make any value directly editable if you feel adventurous and/or do things like creating and loading new MIO0 banks. But these field will be locked by default for a reason: menus and presets will be able to provide all the valid values, that don't crash the game. You may try to hunt for beta stuff I didn't found, but you'll most likely crash the game for any value you manually enter unless you really know what you are doing. Behavior parameters (param1 and param2) though will be editable because their meaning depend on which behavior is used. Param 1 and Param 2 editing will be not that easy to implement because of that. Also, sometimes the two params are used as a 16-bit number, I'll have to make the interface switch accordingly depending on with behavior is used. I'll also add a way to have custom labels like "star number" appear instead of param1, for the star behavior. Some of these labels and description may be missing when the editor is released, Behaviors in particular, don't always have obvious uses, but it should be found quickly with many people editing the game. Users will be able to contribute in adding more descriptions and labels, and sending them to me via a small text file so I can include them in the editor. (Edit: edit frenzy!!) (edited by VL-Tone on 05-05-06 02:32 AM) (edited by VL-Tone on 05-05-06 02:35 AM) (edited by VL-Tone on 05-05-06 02:37 AM) (edited by VL-Tone on 05-05-06 02:40 AM) (edited by VL-Tone on 05-05-06 02:51 AM) |
|||
|
proffessor_gad Red Koopa Since: 01-27-06 From: Mars Last post: 6325 days Last view: 6325 days |
| ||
| x,y,z rotations? Nice!
P.S.- Wouldn't zrot be pretty much equivilent to the direction in which the object is pointing? |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6296 days Last view: 6295 days |
| ||
| Go ahead and use the click-and-drag, VL-Tone.
The vertical control in the Coordinates frame in that screenshot I posted is actually the Y modifier and the big square is XZ. The default camera angle for the editor is a top-down approach, so that makes it more similar to what appears to move on-screen. If I understand you correctly, your idea for coordinates is the same as the camera rotations in your fly-by demo... where it moves faster the farther from the center it is. I highly discourage doing things this way, as I've found with the fly-by demo that it's a real nasty thing when you're trying to do precision things. I recommend having the dragging motion itself move the coordinates. And if you're not dragging, there's no movement... and so forth. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6295 days Last view: 6295 days |
| ||
| I like that click and drag idea too. Instead of a small box in a dialog, though, why not use the whole window? Ctrl+click and drag anywhere on the window to move the object. When you hold Shift, moving the mouse up and down affects Z instead of Y. You could choose whether to use relative movement (the farther the mouse is from the center, the faster the object moves) or absolute (if you click at the far left, it jumps to the lowest X coord). The mouse wheel could also be used to adjust Z position.
Also, to save room, you can use "Ptr" instead of "Pointer" on the dialog itself. It's important to consider the size of your dialog; many programs have huge windows that require a very high resolution. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6485 days Last view: 6485 days |
| ||
Originally posted by BGNG Well I guess I'll put a simple option to switch between absolute and relative controls, because I like the "relative" control better. Both have their inconvenients. The fly-by demo is far from ideal as there is no obvious center and neutral-zones where it doesn't rotate. The click-and drag control would have the center, axis and neutral-zones well defined graphically, and I don't think the camera control in the fly-by demo really equates moving objects over X, Y and Z planes. There will be a speed slider that for both control methods, much like the drag speed value you have in your editor. HyperMackerel, I considered the idea but it wouldn't be obvious in which direction the object would move on the screen relative to the mouse dragging, and moving it relative to the camera would cause the object to move at unwanted angles. But I think I'll implement a Top Bottom Left Right Front Back camera setup, and that could enable easy drag and drop of objects using some Shockwave 3d commands I described in another post, without the camera angles problems. It would work like most 3D design programs, which is certainly not a bad thing. The top view would be the most useful, to move objects horizontally, parallel to the ground. I guess that a feature to keep the object on the ground or wall could be very useful too, with a TBLRFB camera. About the interface size... my current working project has a width of 1024 pixels... which I guess is too much? I won't go lower than supporting 800x600 that's for sure. As for using Pointer instead of ptr, its not a problem since this parameter is part of a short command that only has three params. The 0x24 commands are the longest, and it'll be worse with Sprite and behavior labels. I taken that into account when making the parameter bar generator code. It works like word wrapping , there are 3 bars in my prototype, each one representing a "line". If there are too many parameter items on the first line, they'll wrap on the second line etc. That may look a little awkward when parameters don't use all the space on a line, but the advantages will be a very flexible interface. For example, I could add a little button to show and hide description labels for specific parameters and the bar would resize accordingly. Also, for example, the "expert" mode would show you more parameters, or a raw hex mode could be implemented in a snap without having to worry about creating a new interface layout. It's not that creating interface layouts is so hard, but this kind of modularity makes it easier to experiment and make changes. (edited by VL-Tone on 05-06-06 03:24 AM) |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6295 days Last view: 6295 days |
| ||
| Ah, that sounds nice. As for width I'd say 950px max, and if you can get under 800, that's even better. IIRC, 800x600 is the default size on Windows XP (even though it looks like crap), so if it doesn't fit on that you'll probably get a number of complaints. (Besides, there's not really any reason for an editor to be that big. Lunar Magic does it nicely, putting most things in separate windows, although those separate windows are huge, but that's another topic.)
I'm not sure what you mean about the object moving at unwanted angles. If you're looking at it from the +X side, then dragging left and right would move down and up the Z axis respectively, and dragging up and down would move up and down the Y axis. This may be hard to implement depending how much of the work Director does for you - I never got it to work in C++ - but it shouldn't be too hard to use. Hey, and if I may suggest something: Add an axes object, which isn't actually in the game, and allow the user to move it around. Then allow the use of polar coordinates using that axes as the center when moving the camera (moving left/right/up/down moves the camera around the axes in a horizontal/vertical circle, and moving forward/backward moves toward or away from the axes). It's kinda neat, and would provide a nice way to pan around an area to make sure it looks good from every angle. Or was it just my stupid school that had 800x600 as the default?  (edited by HyperMackerel on 05-06-06 05:47 AM) |
|||
Rusty Hackleford Micro-Goomba  Since: 05-08-06 From: ret ard iao Last post: 6499 days Last view: 6499 days |
| ||
| Inside, outside, and courtyard of the castle are stored in seperate levels aren't they.
So I could have 2 different things occupying the "same" space thread was on my search, ive skimmed it and can't wait for the editor |
|||
|
Skreename Giant Red Paratroopa Since: 11-18-05 Last post: 6301 days Last view: 6294 days |
| ||
| If you said what I think you said, I think you can do that. It's something similar to how the outside of the castle would in NO way fit the inside of the castle... and the back of the outside of the castle doesn't actually include the garden.
I think 800x600 is the default for a lot of things... As long as it's supported. Of course, if your computer can't handle 800x600, there's no reason to be running the editor... Otherwise, that whole axes thing sounds rather cool, if it would work out... But I don't know how the camera angles would be worked, anyway. 3D things tend to be a bit annoying about that in general. EDIT: Why is it that this thread will have an extra blank page at certain thresholds? (edited by Skreename on 05-08-06 11:47 PM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - General Super Mario 64 hacking / TT64 Progress thread |
| Thread closed |
