New features for version 1.0.0

[ughman]

Not really sure where to post anything, so here it goes.

I've had a fair amount of work done on CrashEdit locally which hasn't been pushed (apparently the version on here is from december of last year? ancient).

I intend to release 1.0.0 at some point, I think this versioning scheme is much better than what I was doing before. I'll probably make a small post on xentax once it's out, but then I'll switch to hpzr.proboards.com to start a thread and announce any further work there. There are certain features I want in before I publish 1.0.0:

• (done) Reworked graphical interface. This should have a rather small user impact, the interface should be mostly the same because I think it works well for what it is. The entire code within to implement this, though, is going to be majorly modified. This is what's been holding back some other changes I want to make.
• Reimplement old features for new UI and undo/redo system #58 An undo/redo system. This is absolutely critical. I never made one because I didn't think I could pull it off but now I have some ideas and I'm going to roll with them.
• Chunk free space detection/reporting #11 A system that will show exactly how much free space is left in a chunk so you can see how much space you need to free. This is really important in solving packing errors.
• "Delete Entity" option #14 The ability to delete entities.
• Rename "T11 Entry" to "Script Entry" #18 Rename T11Entry to CodeEntry, and EntityEntry to ZoneEntry. I believe there was another renaming I wanted as well. This one is rather minor.
• New 3D backend #21 Moving OBJ and COLLADA export code into the 3d renderer (or at least all in one place). The model export code suffers from all the different model types having essentially duplicated export code.
• CVTX / T20 entry support for Crash 1 #22 Support for the other "animation entries" in crash 1 which have a mysteriously different type id. The format is actually identical, or so it seems, so this should be no problem.
• Better crash 3 scenery entry support #24 Better support for crash 3. The object scale issue is already fixed locally, but the scenery code will need to be duplicated and changed to support crash 3's (very slightly) different scenery entry format.

Some other things I want but probably won't make it into this version:

• Zone collision octree rendering #10 Visualizing the collidable parts of a level. I actually already have this implemented locally (though uncommitted) but the performance is absolute garbage.
• (?) A 3d renderer which can use newer OpenGL features when they're available. It's important that I keep good OpenGL compatibility for pre-2.0, but there are serious performance advantages in using some new features such a VBOs, so those features should be used if they are available. I also fear rendering textures on models may necessitate the use of shaders, and I'm not opposed to requiring shaders for textures and falling back to an inferior quality image if shaders are unavailable. Box and pickup types still need to be differentiatable, though.
• Recompute drawlists and loadlists #17 Automatic regeneration of "draw lists" and "load lists". The game utilizes "draw lists" to detemine which game objects should be present and running. Along each section of a given camera rail is a list of which objects to spawn and despawn when the camera hits the associated points on the rail. These lists need to be regenerated based on where objects are placed in the level. This would also enable box stacking to be implicit rather than careful and complex. Similarly, the "load lists" determine which entries need to be preloaded for upcoming areas. If the data isn't present at the time it's required, the game does a blocking read for the chunk data (waits until it's fully read). On a CD this is extremely slow (could be over a second long without PS2 FDS, unacceptable). __This change would also facilitate an "add entity" command which wouldn't require an object to already exist within the zone (entity entry), and could also allow moving entities between zones.
• Import/Export Entry #27 An actually functional "import entry" option. This is necessary for, for example, placing a mask box in Crash Dash or utilizing wireframe boxes in Spaced Out.
• GOOL entry support #29 A GOOL disassembler and editor. This is a pretty big undertaking, but very powerful in the right hands. This is the kind of thing that will allow (sufficiently experienced) people to make their own box types, for example. This would also make it much easier to figure out more on how GOOL works. A debugger would also be nice.
• Crash 1 zone entry support #30 Support for crash 1 zone entries. These have a completely different format from the ones in crash 2 and 3, which is why there's no support for them right now.
• MIDI import #34 Support for importing music directly from standard MIDI files. Right now importing music involves programs to convert MIDI to SEQ before importing, all of which seem to be proprietary and DOS or Windows only.
• Simple SEQ or MIDI editor #32 A barebones MIDI editor built-in. The code to convert MIDI to SEQ will pretty much perfectly match the non-UI code needed for this anyways, and this would be pretty handy.

This doesn't mean 1.0.0 is coming soon, but it is something I intend to happen.

[ughman]

More features I want for this version:

• Separate camera entities from non-camera entities #12 Camera entities should be specifically labeled as such, and separated in the list from the non-camera entities.
• Use a different icon for entity-less zones #35 Zones with no non-camera entities should have a different icon in the tree view. Thanks @ManDude

Until the 1.0.0 release, I'll add features here rather than creating new issues.

[ManDude]

This looks like a huge (good) step forward. I am looking so forward to it. Though I have some more suggestions (should not be in first priority):

• "Rename Entry" option #37 Renaming entries. I suppose these are encoded like when you use the "decoder" during the hex view.
• WAV import for sound and speech entries #48 Sound effect importing. An ability to import sound entries from a WAV file (gets converted to the right format in the process of course).
• Misc Crash 2/3 property support #90 Further Crash 3 compatibility. The editor should be able to detect "hidden settings". Right now the only hiden settings I know is the max box count in the bonus and the crate in which a crate gets transformed when on Time Trial (can provide more information if needed).
• GOOL entry support #29 Text string viewer. I haven't found in what entry the text strings are stored, but the purpose of this feature is to show text strings in the game and edit them. It should also show variables, switches (on off things), and other riff raff like the volume things.
• Misc Crash 2/3 property support #90 Victims list for Nitro Detonators. It could show a list of the IDs of the crate objects to destroy (a warning should pop up if the target ID is not a box object for safety). Note that this can be used to destroy not nitros, but pretty much any destroyable box.
• (?) Write a tutorial for this thing after its release? It could also give some useful information about certain object types and subtypes (such as boxes, collectibles, and maybe platforms - I actually think I can do this part).

And that is about it. Ended up being way larger than I thought.

ughman edit: added issue id refs for each bullet point

[ughman]

Those all look good, except for the text string viewer, not sure what you mean there. If you mean editing text like NEW GAME and such, that would be part of the GOOL thing since those are in those entries. No idea what you mean by variables and switches though.

[ManDude]

Ah so they are in the code entries? Cool that saves me off some work. :)

Also the switches are the things like MONO and STEREO and VIBRATION ON and VIBRATION OFF. The variables are like the number of crystals. They seem to be mostly %'s and something else, I will try to fiddle around with these when I can.

[ughman]

Some more features I want in:

• "Save As" #93 Save As.
• (?) Another file format without chunk size restrictions. The idea is if you run into a packing error you can still save your work as another format and reload that later. The game itself wouldn't be able to support this format, though, so this doesn't magic away the chunk issue. I'm thinking just a simple RIFF format, since it's a simple and standard format, the code for exporting these is already present for WAVE/MIDI, and the import code is already needed by WAVE/MIDI import anyway.
• More streamlined NSF loading and saving #41 Multi-threaded chunk processing. Processing individual chunks when the NSF is loaded could be done in parallel very easily, the only issue would be getting error reporting to work properly. This should make loading NSF files faster on multicore systems, particularly when the I/O is fast because of caching, SSD, ramdisk, etc. Saving could be made similarly parallel.
• More streamlined NSF loading and saving #41 Processing chunks while still reading from the NSF, and similarly saving while "unprocessing" later chunks. This ties in with the feature above. Currently, the code is written in such a way that the entire NSF file must be read before any chunks can be processed, wasting CPU time during IO. Instead, the program should read one chunk at a time and begin processing chunks as soon as they arrive in memory, and similarly write chunks as soon as they've been "unprocessed". This can seriously reduce load and save times on slower systems, and potentially reduce memory usage during load and save operations as well.

Some more features but probably post-1.0.0:

• Model and scenery color changer #54 Scenery recoloring. Potentially a window which shows the list of vertex colors used in a scene, and the colors could be individually modified or given batch filter operations such as desaturate, invert, etc.
• Model and scenery color changer #54 Model recoloring. Similar to the above. Although not enough of the crash 2 and 3 model formats is known to render any models in the editor, the location and format of the color list in each model is well-known.
• Option to change zone music #55 Changing zone->music associations. There should be an option to switch which music entry is used for a given zone.

[ManDude]

How do those zone-music associations work anyway? Is the target music entry/SEQ specified inside the zone entries (maybe in one of the first two items) or is it somewhere else?

[ughman]

Yeah the entry ID is one of the values in the first item.

[ManDude]

Also how about exporting entries too? (The format should be the same format as the entry) Currently the best you can do is unprocess entries and export their items and then replace them, wich takes a tedious amount of time.

[ughman]

Oh yeah that's a good one too

• Import/Export Entry #27 Entry import and export. This should also add the imported entry to the index in the NSD.

[ManDude]

And something I forgot in my last post (GitHub mobile wont allow editing) was a Reverse Path option for objects, it simply swaps the first position with the last, second with the second-to-last, etc. This could be particularly useful for duplicating moving enemies or platforms.

How would the autoregenerating drawlists work with multiple-position objects though? Will it also count the other positions? That is like, the best feature this could give as it would cause freezings/crashes to disappear (or be much less common) and also fixing weird drawing bugs when modding!

ughman edit:

• More entity/camera path options #91 Reverse Path option

[ughman]

Yeah that's good, here's another:

• More entity/camera path options #91 Batch position moves. There should be a way to just move all of an object's positions at once rather than moving each one individually.
• More entity/camera path options #91 Interpolating object positions. The user should be able to give an object two positions and then use a command to generate some number of positions between the two, potentially with more density in position placement near the two ends of the line to give an acceleration and deceleration effect like how most crash 2 gem/death/bonus platforms work. An even better option would be if the user could also give more than 2 points and the program would compute a smooth curve through or near them.

As for drawlist regeneration, using all of the positions instead of just one shouldn't be much harder. The hard part is actually figuring out how the camera knows where it is and where it's facing as well as making an algorithm that can figure out if an object has any positions within that viewing area or not. This is going to involve some 3d math which I'm not good at, so that's a challenge that lies ahead.

[ManDude]

I see. But another fear of mine is that it could mess up some of the drawing in Crash 3, take Tomb Time for example: near the end of the level where the purple gem path reconnects, if you slowly start backtracking the stuff will disappear while still perfectly visible. When regenerated the drawing should be fixed, but it could make the game crash due to too many stuff being on the screen at the time (no guarantee though, my modding capabilities on this game are limited due to the scaling issue and the different scenery).

[ManDude]

Oh and 1 thing that bothers me when I test my modding is the depth of the objects. Is it specified anywhere? It could be extremely useful (but probably extremely complicated) to like, hide crates behind a platform or put nitros under the floor to troll the player in 3D sections (hey this seems like a good idea actually), because if you do this without editing depth, the crates will look like they are above the platform.

[ManDude]

Here are some I came up with:

• (?) Model info. Somewhere in the model viewer (or in a seperate tab) could be some some info and editable stuff like what texture chunk(s) the textures from the model are from.
• Import/Change texture chunk #47 Texture chunk import/export. Since making texture chunks is currently impossible, a way to import/export would be cool. (Note that what I'm saying is replacing texture chunks with exported ones.) Also on the subject of texture chunks, is it possible to see them with alpha too?
• Change how sound box looks #60 Better sound playback. The sound entry player could have a sliding pointer that determines the frequency at which the sound plays with some preset buttons like 22050Hz or 44100Hz. And the export button would export at tge curently selected value.

Also can you post a screenshot of the current GUI (or a mockup of it)? Just to see if there is something I can suggest (also helps me organizing my ideas a bit more).

ughman edit: added issue id refs for each bullet point

[ughman]

It looks pretty much the same, most of the change is rewriting a lot of code so the UI gets updated automatically when changes happen to the objects in the backend.

[ManDude]

Oh cool. I like the color coding right there. Also I noticed a CrashEdit tab, does it have like general settings? Anyway it looks good.

[ManDude]

Been thinking a bit, and I thought of some stuff that could be useful:

• "Show Entire Level" option #39 "Show All Entities" button. Simple, opens a pop-up (undocked) window showing only entities, all of them.
• "Show Entire Level" option #39 "Show All Scenery" button. Self-explanatory, opens an undocked window showing only and all scenery in the file, this should be easier than showing entities because scenery is in absolute coordinates and not ones relative to an entry.
• "Show Entire Level" option #39 "Show All Entities and Scenery" button. The two above but together!
• Crash 2/3 camera support #89 Ability to show camera rails. This would work like a multi-pathed entity, except it needs no name/ID to appear in the 3D view, the squares/dots should be colored differently too, like yellow instead of red.
• 3D view "lock to camera rails" mode #92 Move by camera rail. Locks the camera (by pressing, say, W while on the 3D view, pressing W again unlocks) onto the first camera position, pressing Q would make it move forward 1 camera position, whilst pressing E (the hotkeys are an example) would make it go back one position, nothing happens if there is no position after/before the current one. Could be useful along with the draw list modifications. This might need the camera angle though.

Edit: Is it possible to force a "textured scenery" view (shows the scenery exactly like if it was in the game)? That could come in handy in Bee levels because when you see the scenery it is all grey/white and indistinguishable (except for the warp in/out parts).

ughman edit: added issue id refs for each bullet point

[ManDude]

I feel this could be used for some fast, easier, and quick edits:

• Individual item unprocessing. This unprocesses just the selected entity (or frames like in Crash 1, etc.). This is particularly useful when making minor edits (that can't be done while processed) in larger entries.

[ughman]

Actually, I think condensing all of the issues into just this one has overcomplicated things for me, I'm going to split them all out into separate issues.

Even though that's the exact opposite of what I did at the start, heh.

[DeividAndreola]

Any updates?

[ughman]

Pretty much not really.

I'm legitimately considering starting up a new branch and rewriting from scratch in C. If I were to do this, I would specifically target features not already in CrashEdit so I'm not just wasting time redoing the same stuff over (crash 1 zones sound like a good start, instantly makes the program useful). There are upsides and downsides to this:

1. Less memory usage
2. Faster
3. Less big dependencies (.NET and Mono)
4. Easier to build and run outside of windows
5. Harder to build on windows
6. Can't use already-existing CrashEdit code verbatim
7. New backend could potentially modify game data in-place instead of processing/deprocessing all the time (faster load/save)
8. No extra overhead on GL calls, plus OpenGL is natively a C API
9. C is "harder", could be a barrier of entry to contributing

Point number 6 isn't actually as bad as it seems. A lot of stuff in CrashEdit already needs to be rewritten to be undo/redoable. Point 9 could be eased by integrating a scripting language of some kind, especially if undo/redo support was implicit and automatic.

Another point, though, is that I'm currently more interested in an approach like this than the current system. Every time I open the C# crashedit project I feel like closing it and doing something else. Since I'm pretty much the one main developer, that means nothing happens. That said, if someone else wants to take over the C# project, I'm perfectly willing to commit and push all of my private changes, which are a mismash of random broken features, as well as provide any information online whenever. Just don't be surprised to see there's no big undo/redo action system in there.

[ManDude]

I could use that (I even have fully functional Crash 1 entity and camera editors programmed right in so that ain't a problem to me).

[ughman]

Ignore that C project comment, decided to stick with CrashEdit instead.

I've added references to the relevant issues to all of the bullet points here. I've put in "(?)" for the ones I couldn't find issues for. Will close this as duplicate once all of them are posted.