Grabs the first SEQ (or second, maybe there should be an option for this), VAB and "merges them together", so you'll get the SEQ as if it was in the game (but doesn't loop). This should also include in-game effects such as reverb and echo and whatever.

Since the Crash engine glitches out the music if they use Note Off events, CrashEdit should transform them to Note On w/ velocity 0 on export/import.

Opening an NSD should make CrashEdit show its content similar to the way it shows NSFs: Instead of chunks you got chunk index, spawn point index, etc. and inside those are the EIDs and CIDs (and spawn point garbage in the spawn point section, this is made in a weird way though)

Should also force user to add it to the draw lists.

When saving (or before, technically), CrashEdit should detect whether a type on a non-camera entity exists by checking the code entries. Additionally (but possibly only available in the far future), CrashEdit should also detect if animations and models by EID for all of the subtypes in the level and if data for them exists too. If any of these is not available, an error should pop up with an appropriate description i.e. "Type {Type} for object with ID {ID} does not exist.", "Subtype {Subtype} (in object with ID {ID}) does not have a model/an animation/available code." (this last one is picked accordingly).

CrashEdit should support a default-off toggleable option to render the collidable geometry used in zones.

I already have an uncommitted implementation of this using immediate mode, with terrible performance. GL display lists help this somewhat, but not enough to be very useful. VBO's may be able to get much better performance, and non-VBO-capable hardware is not going to be powerful enough to get even one FPS on immediate mode anyway.

I'd also like to look into ways of using fragment shaders. Perhaps a quad could be rendered across the entire screen, and a fragment shader could do the octree walk for each fragment? Not sure about the math involved or the potential performance issues, since the kind of conditional execution it will take might be pretty bad on GPU hardware. We'll see.

The backend needs a real MIDI parser which can parse the MIDI event stream as well as save it back out.

This will be needed for MIDI import as well as MIDI editing, and also to fix the broken MIDI export tempo problem

Duplicating entities can cause packing errors, but because there's no way to delete them again, these errors can be difficult to solve. To rectify this, a "delete entity" option should be added.

The error messages for packing errors are unhelpful, notably:

• _Which_ chunk the error occurred in is not reported at all.
• How much excess space is used is not reported either.
• If there is more than one packing error, only the first is reported.
• The error message does not describe what a packing error is.

The entire system should be redesigned. Preferrably, it should show entry sizes and remaining chunk-space live as the entries are modified. One possible design is this:

• Controllers gain the ability to invalidate themselves and their parents.
• Invalidated controllers have their names recalculated, and EntryChunkControllers recalculate their size minus capacity.
• Entries should have an EstimateSize method which returns their size in bytes. This method should be efficient so it can run every time a minor change is made to an entry's editor control. By default, it could return Save().Length as a slow default.

This setup would also have the side-benefit of having entity names updated in the tree view as their names are modified in the control.

"Import" adds another texture chunk, but the user is prompted to choose a texture image (which format? I dunno), "Change" replaces the current texture image with another one.

Should be easy.

CrashEdit should be able to import MIDI files and convert them to SEQ with the necessary conversions:

• 100%/127% volume check
• Note Off -> Note On 0% Volume
• MIDI Tempo -> SEQ Tempo
• Check for other unsupported metaevents

Needs #15

I already have an icon for this but I need to make the UI actually use it.

Self-explanatory. Should also update the drawlists appropriately.

Depends on issue #12

This should support some batch actions such as:

• Shifting all notes on a channel or program by some amount
• Correcting the 100%/127% volume issue
• Batch program change number replacement

This should make it easier to just jam in external midis and try them out, although playback would help with that as well.

Needs issue #15

Objects in Crash 1 (all versions) are significantly less complicated and are also way smaller. They have some sort of Int16 that pretty much says how they will show up (after 4 empty bytes with unknown purpose), then ID, then something that says that it's an object and not anything else, then 3 special settings (all of what I listed is in Int16, not sure if they're signed or not), then a byte for type followed by a subtype, then positions: Int16 for X, Y and then Z, followed by more positions if they exist. Note: there must be an extra empty (unsigned?) Int16 if an object has more than 1 position (so you'll have 2 empty Int16 instead of only 1). The editing box fro this should be pretty simple to code, but I don't know where the draw lists (or load lists for that matter, if they exist) are, so I guess there's not much that can be done.

Edit: Ninja'd by #30 I think.

It just resizes them to 32x32 automatically no matter the original size, this makes it impossible to properly add a crystal texture.

The scenery entry format for crash 3 is nearly identical, except one field was made unsigned instead of signed. Still thinking about how exactly I want to approach this, but it should be easy either way.

This encompasses a set of features:

• 3D rendering to the screen
• 3D rendering to OBJ file
• 3D rendering to DAE file
• 3D rendering to any future model export formats

Right now the code for this is all over the place, I want to design a common interface for all of the model formats, and then have a "renderer" for each output format or OpenGL feature-set which will use that one single interface.

The problem is, all of the model formats have varying and unusual requirements. We can ignore textures for now, the vertex and color scheme is complicated enough.

Crash 1 Objects

• SVTX or CVTX contains:
  • List of vertices (vec3 position, vec3 normal)
  • Reference to TGEO
• TGEO contains:
  • List of references to TPAG's
  • List of triangles (3 vertex indices, material index)
  • List of materials (vec3 color, texturepage index (from tpag ref list), some kind of texture-mapping data)

Crash 1 Scenery

• WGEO contains:
  • List of vertices (vec3 position, vec3 color, some kind of texture information)
  • List of texture information?

Crash 2 & 3 Objects

• per-vertex color...I think?
• SVTX has ref to TGEO in 2 but not in 3?
• Vertex or face colors are indexed from a list defined in the TGEO entry

Crash 2 & 3 Scenery

• WGEO contains:
  • List of vertices (vec3 position, color index)
  • List of triangles (3 vertex indices, material index, some other data???)
  • List of quads (4 vertex indices, material index, some other data???)
  • List of materials (???)
  • List of colors (vec3 color)

So the problem is too many different possibilities:

• Colors could be:
  • Per-material direct
  • Per-vertex direct
  • Per-vertex indexed
• Vertices could be:
  • Inside the same entry as the polygons and materials, with no normals
  • Inside a different entry from the polygons and materials, with normals
• Polygons could be:
  • Triangles only
  • Triangles and quads

I'm working on something now which I think might work for this, but we'll see.

Regenerating the SLST entries, needs issue #25. This is absolutely mandatory for some significant things:

• Moving scenery vertices
• Adding or removing scenery vertices or polygons
• Importing scenery from external models (damn this sounds really good)
• Significant changes in camera path position and pitch/rotation

I'll also need to reverse engineer the exact projection and rotation/scaling/etc the cameras use so I can do this accurately.

This will probably take quite a bit of processing power, so I'm considering OpenCL to allow computing on graphics cards and/or across multiple systems or processors. OpenCL supports CPU-only systems, supposedly, so that's good for compatibility. OpenTK already includes bindings for OpenCL.

This format is the same as the "Old Model Entry" format, or so it seems. Should be pretty simple to add.

Most advanced anti-virus programs (AVG, etc.) can detect CrashEdit as a virus, but the anti-virus programs don't delete CrashEdit, just block it from using other files (the DLLs), this causes CrashEdit.exe to just open a crash message whenever you try to open it. This can be fixed by adding the CrashEdit folder to the exceptions list (or disabling your anti-virus before starting it up).

Will need the RIFF code to support reading.

There should be some method for opening a 3D view of the entire level, similar to a normal zone viewer.

Chunks in the UI should show the amount of free space available within them, as well as indicate when they have been over-allocated. Entries should also indicate their size to give some idea of how the user might reorganize to fix packing errors.

Replaces or adds a VB file to the game. The appropriate number of chunks should also be automatically made and the wavebank entries should be named whatever the user wants. No more than 7 chunks should be created otherwise it should spit an error saying it's too big.

The SEQ tempo command is actually slightly different from the MIDI tempo command, so this is where this problem comes from. There's a good description on it here:
http://loveemu.hatenablog.com/entry/20060630/PSX_SEQ_Format

Needs issue #15 completed first

This would actually simplify a lot of code as well, especially the draw list handling and "duplicate entity" option.

This would also simplify some Entity backend code as well if the cameras were a different class.

CrashEdit is currently completely incompatible with:

• The VB S000003C.NSF in Crash 3. (Seems to be something with the VB itself maybe.)
• Speech files inside a Crash 3 level (see S000000B.NSF/Toad Village).

Haven't tested NTSC-J Crash 2, so I'm not aware of the problems in that one.

CrashEdit likes to eat memory, and uses a LOT of memory when seeing zones, and uses even more memory for each frame in an Old Animation Entry (instead of just using the animation that's already loaded). The program eventually crashes at around 350 MB of RAM usage no matter how much free space you've got.

A simple extra option to force the PS1 to draw it no matter what. This could fix a lot of failed editing, since adding anything a little bit off away from the original objects can make them unseeable and thus nonexistant.

A malformed entity entry (or a Crash 1-style entity entry) can crash the core Crash library with an OutOfMemoryException in Entity.cs. This issue may also apply to other areas where such allocations are made.

Texture/image (i.e. loading screen) in Crash 1, collision tree in Crash 2 and 3: "Vcol is a collision tree (crash used video collision). Imag is either a texture block or some kind of display image like the loading screens or other static screens"

Pretty simple. The real question is, should it also be able to go around and update all of the references to itself to use the new name? Potentially a search-and-replace EID's menu option could be added for that.

A warning should show up when saving in case a draw list (any) does not contain an object (with ID, name, at least 1 position, type and subtype). The warning prompts the user to either save anyway or go to draw list(s) in the same zone(s) as said object(s).

Double-clicking an NSF file while a CrashEdit instance is open caused it to open another CrashEdit instance (so you have 2 of them open), this should be optimized so it opens in the currently open exe. If you for some reason have 2 exes open, the last or first one that was initialized should be chosen to avoid confusion.

These are the GOOL scripts used by the game objects. Code is a decent enough name and some of them also contain MIPS machine code intermixed with the GOOL.

Minor cosmetic change.

"SLST" entries, already RE'd out by wurlitzerfox. I'll need to go over his docs in more detail to get a better understanding about how they work.

I'll probably call these Scene List Entries, or something similar to that.

Including a disassembler for the known opcodes, plus MIPS. This is a dependency for having a debugger and interpreter, the interpreter then being necessary for a bunch of other features.

The PAL Crash 2 game engine rejects modified game files.
NTSC Crash 2 & 3 both accept the modified game files regardless.

Simply turns textured mode on and off.

https://github.com/ughman/c2c

Given some more work on c2c, CrashEdit should be able to launch the (external) program directly into the currently opened level, and c2c would report when individual chunks are loaded or unloaded which could then be displayed in the editor.

The next step after this would be live application of level changes to the game while it runs, similar to editing memory in cheat engine, but with the editing capabilities of CrashEdit.

Clicking a music entry should show the contents in the first item, such as the location of the VH file and the wavebank entries used.

Some kind of thread pool should be used to parse and process chunks as soon as they're read. There's no point in waiting for the entire file read to complete before beginning parsing.

Same thing for saving, may as well start writing as soon as the first chunk is ready.

ErrorManager will need to be thread-safe for loading. Errors while processing should wait for all of the preceding chunks to finish before appearing, so they don't start showing up out-of-order.

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.
• #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.
• #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.
• #14 The ability to delete entities.
• #18 Rename T11Entry to CodeEntry, and EntityEntry to ZoneEntry. I believe there was another renaming I wanted as well. This one is rather minor.
• #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.
• #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.
• #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:

• #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.
• #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.
• #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.
• #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.
• #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.
• #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.
• #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.

Pretty significant, but also not too difficult, hopefully.

Import needs the rewritten NSD patcher from #23. Export isn't really useful without import.

The bug is simple to reproduce:

• Make a couple new chunks (any kind).
• "Overload" a different chunk (make it go over 64KB of data) that is already present (I recommend using big SEQ tracks so you know how much space they use). You won't be able to save (as expected).
• Move each entry to each chunk you created.
• You wont be able to save even though the chunk that was over 64KB of data has no entries in it, and the entries that were inside it are inside 1 chunk each (edit: obviusly I used a SEQ that was only about 23KB big).

I'm trying to change Cortex boss fight's music, but it's hard because there's Crash code in the same chunk (which is a big pile of code).

EDIT: This bug only happens when you cause the packing error.

There should be a music entry player as discussed in issue #32

Could potentially use c2c as the playback engine.

Needs #15