Enjoy this footage so you can see just what you're letting yourselves in for... heh-heh-heh.
News and updates about the Crash Bandicoot 2: Cortex Strikes Back game mod: Crash Bandicoot 2 Master Quest.
Showing posts with label News. Show all posts
Showing posts with label News. Show all posts
Saturday, 27 April 2013
A video is worth a thousand pictures
And I really was considering creating a thousand pictures to make one huge panoramic view of the Snow Go death route so I could show off the whole thing, but that proved impractical almost immediately, so I decided that a video is surely a much better method!
Enjoy this footage so you can see just what you're letting yourselves in for... heh-heh-heh.
Enjoy this footage so you can see just what you're letting yourselves in for... heh-heh-heh.
Friday, 4 May 2012
Video, Video~
So, it's been way too long since my last post! And I'm pleased to say that my time has now cleared up and I can resume the modding effort of Crash Bandicoot 2: Cortex Strikes Back.
To celebrate this, here is a video showing off some of the screenshots you have seen so far in action :)
As ever, stay tuned for updates and more to come hopefully soon. Thanks for sticking with me through the delays!
To celebrate this, here is a video showing off some of the screenshots you have seen so far in action :)
As ever, stay tuned for updates and more to come hopefully soon. Thanks for sticking with me through the delays!
Tuesday, 3 April 2012
Slow progress
I must apologise for the lack of updates of recent. Unfortunately, my time is being consumed by more projects than I suspected it would be; as such this one's progress has had to take a hit.
The next updates may be some time next month, or if I get anything done in the meantime, I'll make a post about it. Sorry about all of the delays...
The next updates may be some time next month, or if I get anything done in the meantime, I'll make a post about it. Sorry about all of the delays...
Saturday, 10 March 2012
The making of the mod thus far...
Since I'm having absolutely no luck with resolving the issue of infinitely spawning objects, and it's even affecting boxes too now, I have no new section designs to show today. This problem is not one I can solve easily and will probably have to wait for my brother to return from his university so we can both knock our heads together to come up with a solution; that will occur approximately one week from now, so it's not too far away.
In the meantime, I've taken some screenshots of the program that I am currently writing to mod Crash 2, and this program is how I have built all my sections thus far. I recommend clicking on the images so you can actually see what all the text is about.
Crash 2's levels are broken down into 64KB chunks, and these are broken down further in a small file tree structure. Entries within have a type identifier. The one I mod are ones of type 7, which contain the objects among other things.
Every single object within Crash 2, and the same goes for Crash 3, has a standard, very readable, English name, left behind by the developers. They usually go along the lines of "obj_(type)_(variant)_(number)". You can tell which objects I have named, as they do not follow this convention. Each object can be uniquely identified by its name, however there is no need for the names to be different at all; the PlayStation doesn't use these names to reference objects, they're just for the developers, as far as I'm aware.
Position data speaks for itself; this is where the object sits in the level. X is left-right, Y is up-down, and Z is depth, though interestingly the higher Z is, the closer to the screen the object appears. Values in here are relative to the section in which the object resides. If an object has more than one position, it's usually a wandering enemy, and the positions indicate where it'll walk to.
Object ID is a unique identifier of the object, and is used for rendering purposes and for the game to have a reliable method of tracking whether an object has been collected/destroyed or not.
Object Type dictates what the object is, and if there are lots of types of said object (e.g. a box), variant determines which one.
The General Settings contain numbers for specific tasks; e.g. when it comes to boxes, setting the first number to be 97 makes the box always produce a life. Setting the second number to 4 with left bitshift turned off makes the box give you its fruit/contents automatically upon breaking so you don't have to pick it up. You can also use these to dictate if a box is wireframe or not, and which box solidifies next in the sequence when the ! box is hit, if it is. These settings are also used in enemies to dictate their movement speed, or other various properties.
The "Destroys x objects" list usually applies to the Nitro detonation crate. Any ID listed here will be destroyed when the detonator is hit. Yes, it can destroy almost anything, including things that aren't Nitros, or even boxes. TNTs also have this value set sometimes and it's used if you go off-screen before the TNT blows up to ensure it destroys the objects it is supposed to.
The other settings you see do random things, some of which I don't know yet. The configuration for the "obj_checkpoint_emergency" I have shown above is for a ? box that turns into a Checkpoint if you die too many times. The "5" in the 0x288 box identifies which previous Checkpoint it is linked to (the related Checkpoint will also have a 5 in this field). The 3072 seems to dictate what kind of box it is before it turns into a Checkpoint.
This following section is currently incomplete and contains the infamous draw lists that I like to complain about. Draw List 1 indicates when objects should stop drawing, and Draw List 2 indicates when they should start. If you examine the hex, they indicate at what camera position the object will be going off/coming back onto the screen, so they can be used to make rendering VERY efficient by rendering EXACTLY what needs to be rendered only at any given time. The "positions" field shown is actually the route that the camera follows through the level and is directly related to the draw lists.
If space becomes an issue in the tiny 64KB sections, the program can reorder things to generate more room with the "Move this..." button at the top. Adding totally new objects is done on the button right next to it, and the program does its best to seek out the draw lists and add the object to them, though it is not always totally successful; sometimes the object spawned is not totally off-screen before vanishing and whatnot, and at that point the hex editor needs to come out to fix the issue. I've even had one draw list freeze the game for reasons unknown.
All of Crash 2's NSF files have a checksum on them, and changing any data means the checksum needs recalculating. Chadderz, my younger brother, was the one who cracked the checksum; the program updates it upon saving. The "Rehash a file" button has the same functionality, only you don't have to load the file into the editor if you use that button. It's useful if you've been messing with things in a hex editor and want to quickly get things tested.
And that is how I am doing my work! If it becomes stable, I may release it at some point. Currently it's buggy and a little sluggish, but I'll keep on working on it.
It's nicknamed the "NSF Modifier - Ripoff Edition". Why? ...Because my brother made a program called the "SZS Modifier" for Mario Kart Wii. And this program in some ways looks verrrrry similar to his work :P
Well then, have a great evening everyone.
In the meantime, I've taken some screenshots of the program that I am currently writing to mod Crash 2, and this program is how I have built all my sections thus far. I recommend clicking on the images so you can actually see what all the text is about.
Crash 2's levels are broken down into 64KB chunks, and these are broken down further in a small file tree structure. Entries within have a type identifier. The one I mod are ones of type 7, which contain the objects among other things.
This interface is what you see upon selecting an object. |
Every single object within Crash 2, and the same goes for Crash 3, has a standard, very readable, English name, left behind by the developers. They usually go along the lines of "obj_(type)_(variant)_(number)". You can tell which objects I have named, as they do not follow this convention. Each object can be uniquely identified by its name, however there is no need for the names to be different at all; the PlayStation doesn't use these names to reference objects, they're just for the developers, as far as I'm aware.
Position data speaks for itself; this is where the object sits in the level. X is left-right, Y is up-down, and Z is depth, though interestingly the higher Z is, the closer to the screen the object appears. Values in here are relative to the section in which the object resides. If an object has more than one position, it's usually a wandering enemy, and the positions indicate where it'll walk to.
Object ID is a unique identifier of the object, and is used for rendering purposes and for the game to have a reliable method of tracking whether an object has been collected/destroyed or not.
Object Type dictates what the object is, and if there are lots of types of said object (e.g. a box), variant determines which one.
The General Settings contain numbers for specific tasks; e.g. when it comes to boxes, setting the first number to be 97 makes the box always produce a life. Setting the second number to 4 with left bitshift turned off makes the box give you its fruit/contents automatically upon breaking so you don't have to pick it up. You can also use these to dictate if a box is wireframe or not, and which box solidifies next in the sequence when the ! box is hit, if it is. These settings are also used in enemies to dictate their movement speed, or other various properties.
The "Destroys x objects" list usually applies to the Nitro detonation crate. Any ID listed here will be destroyed when the detonator is hit. Yes, it can destroy almost anything, including things that aren't Nitros, or even boxes. TNTs also have this value set sometimes and it's used if you go off-screen before the TNT blows up to ensure it destroys the objects it is supposed to.
The other settings you see do random things, some of which I don't know yet. The configuration for the "obj_checkpoint_emergency" I have shown above is for a ? box that turns into a Checkpoint if you die too many times. The "5" in the 0x288 box identifies which previous Checkpoint it is linked to (the related Checkpoint will also have a 5 in this field). The 3072 seems to dictate what kind of box it is before it turns into a Checkpoint.
This interface is what you see upon selecting the files that seem to handle the information that renders objects. |
This following section is currently incomplete and contains the infamous draw lists that I like to complain about. Draw List 1 indicates when objects should stop drawing, and Draw List 2 indicates when they should start. If you examine the hex, they indicate at what camera position the object will be going off/coming back onto the screen, so they can be used to make rendering VERY efficient by rendering EXACTLY what needs to be rendered only at any given time. The "positions" field shown is actually the route that the camera follows through the level and is directly related to the draw lists.
If space becomes an issue in the tiny 64KB sections, the program can reorder things to generate more room with the "Move this..." button at the top. Adding totally new objects is done on the button right next to it, and the program does its best to seek out the draw lists and add the object to them, though it is not always totally successful; sometimes the object spawned is not totally off-screen before vanishing and whatnot, and at that point the hex editor needs to come out to fix the issue. I've even had one draw list freeze the game for reasons unknown.
All of Crash 2's NSF files have a checksum on them, and changing any data means the checksum needs recalculating. Chadderz, my younger brother, was the one who cracked the checksum; the program updates it upon saving. The "Rehash a file" button has the same functionality, only you don't have to load the file into the editor if you use that button. It's useful if you've been messing with things in a hex editor and want to quickly get things tested.
And that is how I am doing my work! If it becomes stable, I may release it at some point. Currently it's buggy and a little sluggish, but I'll keep on working on it.
It's nicknamed the "NSF Modifier - Ripoff Edition". Why? ...Because my brother made a program called the "SZS Modifier" for Mario Kart Wii. And this program in some ways looks verrrrry similar to his work :P
Well then, have a great evening everyone.
Thursday, 8 March 2012
Do you want wumpa fruit with that?
I thought everything was going a little too well somehow, however a nice curveball has arrived to make life complicated.
Currently I have run into a little problem which causes the cloning of certain objects if you visit an area multiple times. I am unsure of the cause, however I get the sneakiest of suspicions that it's the draw list doing it as usual.
Ironicly, the objects that get cloned are originals, not the objects that I have added (which you would expect to be more glitchy, but evidently the game thinks otherwise). And as you might have suspected, as more and more objects clone, the game rapidly becomes unplayable.
As such, I need to overcome this problem before I can continue level design. So, may be slow progress for a little while, though I hope I can get this resolved quickly.
Currently I have run into a little problem which causes the cloning of certain objects if you visit an area multiple times. I am unsure of the cause, however I get the sneakiest of suspicions that it's the draw list doing it as usual.
That's a lot of wumpa fruit right there. It also rarely clones penguins. |
Ironicly, the objects that get cloned are originals, not the objects that I have added (which you would expect to be more glitchy, but evidently the game thinks otherwise). And as you might have suspected, as more and more objects clone, the game rapidly becomes unplayable.
As such, I need to overcome this problem before I can continue level design. So, may be slow progress for a little while, though I hope I can get this resolved quickly.
Monday, 5 March 2012
What is this all about...?
If you've just stumbled upon this place at random, you may not be aware of what you've just come across.
This is the blog for the first ever Crash Bandicoot 2 modding fan project; Crash Bandicoot 2: Master Quest. There are no rewards for guessing where that name comes from.
The aim of this project is to go through the 27 levels of Crash 2 and make them harder, significantly harder. At this stage, alterations to the main game's models are not planned, as I do not know how they work. However, moving objects and adding new objects is possible, and can be used to create brand new puzzles and challenges; and that is the ultimate goal. A very good knowledge of Crash's controls will be required to complete the game.
By the by, this isn't just some random fan ranting about what he wishes he could do.
This has been confirmed to work on a real PlayStation console as well.
Keep an eye on this blog and my YouTube for updates. I'll also release demos for testing and feedback purposes along the way.
I hope you all enjoy playing this as much as I enjoy creating it! Please also keep in mind that the process of modding the game is slow. As I get more used to doing it, it should speed up, however I will need time. Have fun, Crash fans!
This is the blog for the first ever Crash Bandicoot 2 modding fan project; Crash Bandicoot 2: Master Quest. There are no rewards for guessing where that name comes from.
The aim of this project is to go through the 27 levels of Crash 2 and make them harder, significantly harder. At this stage, alterations to the main game's models are not planned, as I do not know how they work. However, moving objects and adding new objects is possible, and can be used to create brand new puzzles and challenges; and that is the ultimate goal. A very good knowledge of Crash's controls will be required to complete the game.
By the by, this isn't just some random fan ranting about what he wishes he could do.
![]() |
Initial Snow Go designs in action! (By the way, yes, it is possible to break all of the boxes minus Nitros without taking damage). |
This has been confirmed to work on a real PlayStation console as well.
Keep an eye on this blog and my YouTube for updates. I'll also release demos for testing and feedback purposes along the way.
I hope you all enjoy playing this as much as I enjoy creating it! Please also keep in mind that the process of modding the game is slow. As I get more used to doing it, it should speed up, however I will need time. Have fun, Crash fans!
Subscribe to:
Posts (Atom)