 |
| 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 |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 |
| User | Post | ||
VL-Tone Paratroopa                   Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
I'm happy to see that you guys can now hack Super Mario 64 
I'll get back at reworking the level editor. The thing is, in case you didn't know, I decided to rewrite a good part of the editor, so you won't see much of it until I get back to where I am with the current version. I decided that I'll try to make it possible to insert new objects in levels, and that in version 1.0. And I don't mean new polygons, just new objects. It'll be only possible for x24 objects, but you'll be able to put much every type of objects available in the level, including objects displayed with the 0x39 macro object command (which are referring to parameter presets that can also be used in a 0x24 command). In my rewrite, I'm considering building a basic polygon editor, but nothing fancy like I plan for version 2.0. One thing I decided that will probably make it in version 1.0 is the possibility of editing which colors and textures are used by each polygon mesh parts. The real problem with editing the level mesh is that the collision map also has to be edited in much the same way. But remember, version 1.0 will be mainly about moving and swapping objects around in levels, editing text and textures. Still it should be plenty of fun for all |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Bane King Someone was working on finding the sound samples, but I have no news about it... Personally, I would love to be able to decompress the compressed midi files inside Mario 64. Nintendo had a command line tool called midicomp to take care of this, but obviously its nowhere to be found. Xenesis: cool to see there is more than two of us here |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| I'm %99 sure that it's midi. This is what n64lib use and Mario 64 is using it. The main problem is that it's compressed using a Nintendo format. I never checked in RAM though... maybe they are there uncompressed?
It's clear to me that Dire Dire Docks was played by a human on a standard pressure sensitive midi keyboard (I would guess, Koji Kondo himself?). |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Racoon Sam:
I recommend that you use the command-line version of UIPS for OS X, at: http://www.kyngchaos.com/software/ since I had trouble with the GUI version. But if you still want to try the GUI version, the first file is supposed to be the original unmodifed file, and the second the modified version. Magic_Vampire_Joe: As for a music editor, like I said before, it's compressed MIDI. I'm not sure I feel like writing a complete MIDI editor while hundreds already exists. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| What you stumbled upon is the ABI (Audio Binary Interface) commands. These control the MIDI player, assign instruments to tracks, add loops and override various other things that can be already part of the MIDI data. As described in the some n64 doc: "The N64 Audio Lib supports the play of musical sequence that conform to the Standard MIDI Files 1.0 spec for Type 0 MIDI files." And then they refer to the "Standard MIDI Files 1.0" specification. Nothing is said about having a special modified MIDI file. I don't know why they would have bothered to do otherwise.
The only thing is that Nintendo uses its own compression format to compress the actual midi data. What you found refers to what's inside the compressed MIDI files. There are two ways of playing MIDI files using the n64 lib. One is using the compressed MIDI music player which will play music by itself, and the other using some ABI commands to go step by step in the MIDI file. I guess for Mario 64 it's the latter, but still it's supposed to refer to standard MIDI files. Music on the NES was first only possible through Nintendo's own limited musical tools on the NES devkit. Hirokazu "Hip" Tanaka built his own tools, and did a lot of audio programming on paper  Other companies may have built their own tools. While at some point, some NES development tools may have imported MIDI files, the NES and devkit itself never played MIDI files directly and was not made with MIDI in mind. To make a NES tune sound good and with a distinctive tone, you had to have much more than just notes, it required a lot of tricks.
But do you know what keyboard was probably used to compose some of the most famous NES tunes? It's called the "Casio VL-Tone"
The SNES had a powerful sound chip that was also best harnessed by custom tools and was not necessarily built to fit the MIDI spec. Again, MIDI imports were probably feasible, but intermediary formats were probably used to fit the sound chip capabilities better. The n64 has no sound chip, Nintendo decided to build a software MIDI player instead of inventing yet another format for music. Nintendo didn't produce a music editing program for the n64, how do you expect developers to produce music if like you say it's non-standard MIDI? I guess that somehow we are both right or both wrong
So where did you found all that data? Any addresses? |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Magic_Vampire_Joe, somehow, the music editing discussion is now in this thread: http://board.acmlm.org/thread.php?id=4310&page=1
I started to work again on the editor, I'm still at basic stages of rewriting, but this is because many important structure design decisions had to be taken. Things about the basic structure of the format are mostly finalized now. I decided that I'll add some jump points in the level scripts to be able to add objects after the script instead of inserting them. The new version can now load and decode all level scripts in a fraction of a second. I will release version 1.5 of the ROM extender soon. It will repoint the uncompressed level script segments too, and add more space between segments. The text editor will still work on both extended formats, but be aware that your other patches may not work with the new format. I'll try to never do that again Version 1.5 will be the "final" version of the extended ROM format. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| I know that if the original data is edited it won't change size when uncompressed. There are only a few texture-only MIO0, the rest is a combination of both inside the same file. There's plenty of empty space at the end of the ROM anyway. Even for texture-only MIO0's I'd like to leave some space... what if an advanced hacker wants to add a texture? | |||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| I didn't know that about the SNES devkit... interesting
Still I don't think SNES carts contained actual MIDI files, even compressed, but my point though is that on the N64 it's different. I don't know any valid reason why they wouldn't use standard MIDI, as Nintendo wrote their N64 music player entirely in software. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Shyguy Ehmm... I actually emailed this guy to tell him about the editor and now he's crediting me... His site is the best and biggest SM64 tricks/cheat site on the web, he's certainly not an imposter
But anyway... Thanks for caring about that |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| evilryu: The answer is NO. Please stop asking for it, not even beta testers have a copy of my level editor, as it's currently being rewritten and is non-functionnal. If I could share it I would, I'm not keeping it for myself for the sake of it. It would be pointless to release the original project, it would create confusion, especially if it gets on p2p networks.
Here are some clarifications for everyone that just joined, and others too: I reverse-engineered most of the level and polygon format with the help of some people here. I built a program that helped me in this task, and that program evolved into a level editor as I discovered new things. You can find screenshots of this unfinished editor in the thread. I never released it, since it was buggy/unfinished and much too slow at decoding levels and textures. Because this program evolved at the same time of my knowledge of the format, many parts of the code were patched to accommodate new findings, and the overall structure of it is not very modular. Since I got to the point where I knew enough about the format, I decided to rewrite it from scratch, but doing a lot more planning that I couldn't have done on the original version, since I didn't find much about the format at first. Some updates about what the heck is happening with that elusive Super Mario 64 level editor: I'm currently rewriting the basic code that will read and parse level script commands into a standard internal format in arrays variable. This part is essentially finished, and the program can load and decode level script from all segments that contains them in a fraction of a second. This array list contains sub lists for each segment, and each segment list contains all level script commands as read sequentially from start to finish. Each level script command item is itself a "property list" that contains parsed parameter values from each command I made a routine that outputs this list as some human readable text, you can take a look at all level scripts segments parsed and decoded in the zipped text file I attached. Note that these don't take account of the jump commands and all, it just list the commands sequentially as they are found in the ROM. I'll keep this sequential list as a basis for the editor. A routine (that I'm working on now) will read the content of the array list, then produce a new list that takes jumps into account. This new list will contain reference pointers to the sequential level script list and will be ordered just like the game decodes it. That way I can work on the original sequence of commands (to insert commands for example) while having another ordered list representing how the level is decoded by the game. From this point, it's "just" a matter of building a user interface to edit the content of these lists. I also have to rewrite the polygon decoding routine, and work on a new system for selecting 3D objects. I'm doing a lot of planning these days, and that's why it doesn't seem to evolve rapidly (that and some "I do have a life" reasons). But once I'll have made all the basic design decisions, re-building the new interface should be relatively quick. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Marioman64 Yes, eventually, though maybe not in version 1.0b. I'm aiming at making my editor usable even by the clueless, though it will feature an expert mode. Originally posted by BGNG Yeah most of it will be a snap but still, with Super Mario 64, there is a little more to it. For example I have to build a sub-menu system to be used with some parameters (3d sprite type, behavior type and behavior params). These have to take into account what are the possible values depending on which segment is loaded in this particular level, and provide only usable values. I have to build a structure to accommodate the "description label" of each of these possible values and tools to edit/add labels. As I've said before, the first release will miss some labels, and I'll ask beta testers to add them through a built-in interface and sending me back a little .txt file. There are many safeguards I have to implement since most of these values are not just X, Y and Z, and some commands depend on the occurrence of a previous command (like warps). The interface for warps requires me to find all behaviors that use warp objects, and maps it's parameters to a list defined by previous commands. And these are just examples. Each of these issues are not that hard to deal with, but there is a lot of them, and I'm trying to build a uniform, modular interface structure to encompass all of it. Anyway, overall, it won't be that hard to pull off a very fun and usable SM 64 level editor before the summer... So today, out of nowhere, I'm announcing the official release date for Toad's Tool 64 v1.0 beta : June 21st 2006.
|
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Raccoon Sam: What I wrote is that the June 21st release will be beta. The testing phase will probably begin about 2 weeks before.
As for the name, Teresa Obake is cool, but it's too obscure. I want a name that convey the use of the program. For Toad's Tool 64, I can imagine a splash screen where Toad is seen operating a crane to move an box in Bob-omb's Battlefield. Actually it would be fun to actually integrate a virtual crane in the editor
I also thought about Carpenter 64 or Mario 64 Carpenter Tool, but later found that in english the word is more restrictive than I thought (and then went on a crazy theory about Mario really being a "Charpentier".) I don't know yet how water regions are defined, they are probably among the special objects found after the solidity data, or maybe in the solidity data itself (there are many types of solidity polygons, some of which I didn't really figured out yet). I'm not sure if you can only put one water region in an area, but that may well be that way. I think that somewhere, a "sea level" is defined so these kind of pools would be impossible. I can imagine that it would be very cpu intensive to calculate if Mario is inside or outside a complex 3d region like that, usually this kind of detection is made using boxes, not complex polygons. A SMB 1 level in Mario 64, is that what you meant? 
I did that a while ago... The "?" boxes and bricks are all "!" boxes with new textures. These boxes have a tendency to explode when hit from the side, and also, they are too big. The level was built using a custom program that takes the actual level data from SMB1 and creates a list of 3d sprite commands, that I then inserted back in that level. It's very hard to play, you have to be very careful not to fall down. Also, at the place I put this level, the Lakitu Cam had limited movement. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Chainlink1061:
Yes. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Marioman64, you got tough questions  I'm really sorry, I don't have the answer for any of your questions, though some may be answered eventually.
Update progress... The rewritten editor now loads level scripts in order taking jump command into account. It also builds a list with all commands, classified by command number. That list of list is used by the interface described below. Here is a preliminary prototype interface. 
Clicking on the top "menu" selects the level (and area). Then you can select which type of command you want to be listed in the orange menu. Selecting a command will list all occurrences of a particular command in that particular area, or commands that are shared by all areas inside a level. Each line in the list contains an item number, and all parameters found, converted to the appropriate format. The "inlevel" means that this particular command is found in the level script itself. Other values can be "shared" or "xternal". The former means that this command is found outside the level script, inside a chunk of commands that are shared by two or more levels. While "xternal" means much the same thing, but this time it means this chunk is only used by this level. Most of these shared and external scripts are found inside the script segment at 2ABCA0 in the ROM. This segment and two others (2A6120 and 269EA0) are not level scripts, their commands are shared amongst all or some levels. 2ABCA0, at its start, contains commands that are first executed each time you load a level. So the shared scripts are referred using the 0x06 command (jump to address) from inside each level scripts. The 0x07 commands inside the shared script then jumps back into the level script. There are 19 of these sub-segments that are referred by the level scripts. The scripts usually contain 0x22, 0x26 and 0x24 commands. 0x24 commands (3D sprites) are never shared but sometimes external. I wanted to make the 0x22 commands editable, but editing shared commands could lead to unexpected results. The 0x22 command determines which number is associated with a particular polygon sprite. This number can be used by all 0x24 commands to refer to this polygon sprite. If you change one that is shared by 10 levels, you'll have to keep track of all the possible changes. Maybe I'll only make the "inlevel" or "xternal" commands editable. But there is a solution around this problem. Since we have much more space in the ROM, maybe the level scripts could be recompiled to remove the need for jump commands, by duplicating and inserting the corresponding external or shared data where those jump commands are. The process would add something like 100k of data and would enable more control over which objects are useable in which level. For now, I'm building a program that's able to edit every type of commands. But editing the 1B command would be pointless since it's always 1B 04 00 00. I'll make a beginner mode where only the main and simplest commands are displayed in the blue menu. Then an expert mode will show more commands, including those that can easily crash the game if you don't know how it works. Maybe an intermediary level could be a good idea too. At the bottom of the screenshot, you see a non functional editor interface for the selected command. This is what I'm currently working on, a routine that automatically generates this kind of parameter editing bar, for any kind of command. It will create a second or third row if it needs too. A pop up menu will be available for most of these commands, containing valid values, and each item in the menu will have an optional text description. So for example, the "destlevel" popup menu would contain a list of all usable level ID numbers, with their names. In the released version the text description for the current parameter value will be displayed on the right of the value on the editing bar. The descriptions will be editable, or you'll be able to add new ones if they are missing. It looks simple from that point, but like I tried to explain, there are many subtleties that don't make the rest as straightforward as you might think. Hopefully, I have a lot of it already planned out. After/while working on the editing bar generator code, I'm planning to build a list of pointers for all possible polygon sprites found in the game, and each of their mesh parts pointers. The descriptions labels will be attached to items in this mega list. The 0x22 and 0x24 commands will have to refer to this mega polygon pointer list to find the text label associated with this geometry layout pointer or type byte. There is no 3d in this new editor yet... But as soon as I build this comprehensive database of geometry layout and polygon pointers, I'll start rewriting the polygon loading command. I'll build some basic model viewer that enables you to browse through all objects found in the game, optionally selecting only sub-parts. Then, when I get a "good enough" model viewer, I'll start to write and build a vertex editing interface. At each vertex, a sphere will appear, you'll be able to select multiple vertices and move them around, rotate or scale them. I will try to build this part in a modular way so that the same routines will be used to deal with multiple 3D sprite selections in levels. The editing bar will also deal with multiple selection, so that values that are the same across all selected objects are displayed. This will for example enable you to assign sprite types or coordinates to multiple objects at the same time. If a param value is different in at least one object, the value will be displayed as "--", but if you change the -- to some other value, this value will apply to all selected objects. I designed some very cool camera controls in the other unfinished version, and I intend to re-implement them in the new version. It's an optional mode where the camera follows the selected object at a 45 deg top down view, you can rotate the camera around the selected object, zoom in and out. The camera moves with the object if you displace it. I guess with multiple objects I'll have to find use center point (I don't know how to do that... by averaging 3d vectors?). OMG! I just realized the length of this post! Ouch, maybe I'll beat a new record
Poor you that had to read all of it  (edited by VL-Tone on 04-29-06 02:11 AM) (edited by VL-Tone on 04-29-06 02:20 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 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) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 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. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 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) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 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) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| BGNG, there are two main reasons why I won't use external windows for version 1.0b. First I don't have much experience in dealing with external windows in Director. Actually, external windows are other Director movies (projects) that can be controlled by the main movie. Director can only edit one project at a time so it can be a pain to switch back and forth between projects.
Anyway the second reason is that I like the idea of using a single window interface. External windows are not bad by themselves, but they don't necessarily save screen space. I find that I usually spend to much time just trying to find a layout where they don't overlap while having no wasted space. I won't cram everything in the window at the same time, some less often used interface elements will slide into view when needed. The only thing is that that single window won't be resizable, at least not in version 1.0b Cellar Dweller, I didn't notice that about the 0x13 command yet, I'll look into it since I'm about to rewrite the "geometry layout" data reader that contains those 0x13 commands. Director has a few commands that could help me do the "drag objects around from the 3d viewpoint" part. I described how I could do it a few posts earlier, and the math behind it is probably not so far from how Super Mario Galaxy uses the star cursor to point at things. BooUrns: Thank you for the kind comment Yes there will be a page about it, but remember it will be released as a beta, not as a mainstream app. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Rusty Hackleford Hmmm this one post did show
Some of the things you plan to do may not be possible, at least not in the first version. Moving Bowser to other levels for example, or entering the sub. |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
