Create Your Own Adventure! - Final Version Released

[Nukey Shay]

Currently labelling the rest of the program, so that more objects can be added (there's 19 free bytes of ram so far). That should work well for adding additional castles or movable objects, but working with AI-controlled objects (like the bat, dragons, and to a smaller extent - the magnet), might not be possible...due to the additional processor time needed to update their routines (I think that blue dragon in Avalon was the cause of that hack to glitch occasionally). Most movable objects only require 3 bytes of ram...4 bytes for a key/gate pair.

 

 

Question for the gurus:

When cross-assembling with Dasm, is it necessary to use the -s switch to build a text file that can be pasted into the other half's assembly...or is there a shorter way? Currently, I'm...

 

dasm a1.asm -f3 -sEQ.TXT -oa1.bin

...and then pasting the contents of EQ.TXT to the second assembly file

[ATARI TROLL]

@Nukey & Atarius I haven't posted anything but I just wanted to say this blows the roof off any hack editors out there! It's awesome to see the progress of this so far! Look forward to more! I think goes without saying but you guys never cease to amaze most of us!

 

Cheers

[Greg Zumwalt]

Hello. I've really been enjoing this tool. Very nice job!

 

Several minor points, hope they were not already mentioned...

 

1. When editing, all edit colours are red. It would be nice if they reflected the colour of the rooms/items you are editing.

 

2. The default path is C: Would be nice to define it.

 

3. If dASM is not found when compiling the program crashes losing all work

 

Here is a better map:

[+Atarius Maximus]

Hello. I've really been enjoing this tool. Very nice job!  

 

Several minor points, hope they were not already mentioned...  

 

1. When editing, all edit colours are red. It would be nice if they reflected the colour of the rooms/items you are editing.  

 

2. The default path is C: Would be nice to define it.  

 

3. If dASM is not found when compiling the program crashes losing all work  

 

Greg, thank you for your feedback. Hearing comments like this lets me know people are using the application, and motivates me to keep working on it.

 

1. I agree that would be a nice feature. Not every map is red though, I know I set up the blue maze with blue fields, and the invsible mazes with orange fields. After that, I think most map editing forms are either orange or red. When I get everything working, changing the colors to more closely match the map your editing will be one of the last things I go through and change.

 

2. I updated the Save screen so that you can select a different drive letter. It works much better now, thanks for the suggestion.

 

3. I realize that is a problem. I placed a warning message on the save screen a few revisions back to inform people to make sure they choose the correct dasm directory before clicking on the button to create the binary. I'm working on figuring out an error checking routine to verify if DASM is installed in the selected directory so the program won't crash, but it's been kind of difficult to figure out. I'll get it in there before the program reaches it's final release.

 

I'm aware of the map you provided, I used it to create the small screenshots you see throughout CYOA. I suppose I should probably include the entire map in the application, so you can see how EVERY room connects visually. I'll include that in a future revision.

 

I have a new build to release this afternoon. You now have the ability to edit all of the sprite graphics in the game with the exception of the numbers 1-2-3 that are used in the level select screen. They're not important for gameplay, so I'll likely leave those out. I also included the default hex values into the sprite editing screens, so that if you don't hit the calculate button, the default sprites from the original game will be written into the source. I plan on adding that to every map window, so you can choose to NOT edit a particular screen if you don't want to, and you'll just get the screen from the original adventure game when you compile.

 

Everyone: If you're using this app, please give me some feedback about features or problems, especially if you find a bug. There are now many thousands of lines of code in this app, so the chances of there being a bug are very likely. It's hard not to make a typo every once in a while when you're entering so much data. If anyone receives a "Runtime Error 7: Out of Memory", please let me know.

 

I'll be updating the first post in this thread with v0.18 this afternoon.

[Greg Zumwalt]

Excellent!

 

That's good to hear.

I was going to mention that it would be nice to click a button, have a window pop up and ask, do you want the default data loaded for the window being edited.

It would make alteration, and alignment of the "halls" so much simpler

 

I am eagerly awaiting your next release and happy to see suggestions being taken and used

 

Another suggestion, a loading feature that would read saved data back into memory.

I myself like to save edits often and test them in the emulator for appearence and functionality.

I'm sure you're already working on such a routine... but just in case

 

As the author of VaderMatic, the tool used to alter Space Invaders, much as your tool alters Adventure, I'd just like to say you've done an excellent job on this

[+Atarius Maximus]

I'm nearing completion of the Save/Load routine in CYOA! It's working great so far in my testing. I still need to include the sprites in the save game files, so I'm not ready to release it yet, but it should be released here sometime this weekend. It was WAAAYYYY more work to get the Save/Load function into this game than I thought, I'm learning a lot about VB in the process of writing this app.

 

I'd just like to say you've done an excellent job on this

 

THANK YOU!!! Your compliment is much appreciated. I had much more time to work on this during my business trip this week than I thought. It included several nights of staying up until 3-4AM in my hotel room working on it. This has been a tremendous amount of work, I'm glad to know it's being used and enjoyed.

[ATARI TROLL]

Greg Zumwalt wrote:

I'd just like to say you've done an excellent job on this

 

I second that. I also have to thank Nukey for the demo and stan for his comments on it as well!

[+Atarius Maximus]

The Save/Load feature is finished! This was a big update, and added about 1.5MB to the size of the application. Here's how it works:

 

Each Map and Sprite window is saved as an individual ".dat" file. The files are saved as "Map1.dat", "Map2.dat", etc., and "Sprite1.dat", "Sprite2.dat", etc. You may choose to save the files in different directories if you want to save multiple revisions of a game, but do not change the names of the files or they will not re-load. Simply choose the "Save" function from the File Menu, and a window will pop up prompting you for the directory in which you would like to save the files. The same goes for the Load function, simply choose the directory where the files are located, and click on "load".

 

Important Note about Sprite editing: The sprites MUST be continuous, in that there can be no blank lines at the top or in the middle. As soon as a blank line is reached (hex $00), Adventure will stop rendering the image. I may add this bit of information as a text field at the top of each sprite window in a future revision, as I'm sure not everyone is going to read every message in this thread before they download CYOA.

 

Another update: The "Maps" and "Sprites" menu choices have two functions now. If you click on a particular map in the "maps" menu (or a sprite in the "sprites" menu), it will open the window if you've closed it, but it will also bring that window to the foreground if it is already open. It's a good way to navigate through the many windows without searching through them all manually.

 

My next update will include an improved map guide for the castle mazes, as well as a map of the entire Adventure world, so you can see how all of the various map rooms connect. I'd also like to change the colors of the editing fields to match the original room you are editing. The program will still crash if you attempt to create the binary and choose an invalid path to DASM. I'm still working on fixing that problem. EDIT: I just noticed that the program will also crash if you attempt to load saved files from an invalid directory. It's the same problem, as soon as I figure out how to write the error handling routine, I can use it in both places. For now, just be careful.

 

Once again, please let me know if you find any bugs in the application. I've taken so much time creating the code, that I haven't had much time to actually do bug testing and USE the application.

 

I found two bugs in the previous revision. One line in the bridge sprite editor was converting to hex incorrectly, and the default map load for the 'below yellow castle' screen was incorrect. Both have been fixed.

 

Today is my son's 2nd birthday (party tonight!) and tomorrow's Easter, so I probably won't be posting any more updates this weekend. After I post this thread, I'll go back and add the new version to the first post.

 

Enjoy!

[+Atarius Maximus]

1. When editing, all edit colours are red. It would be nice if they reflected the colour of the rooms/items you are editing.

I started looking into adding this feature, and realized that it's not going to be very useful because of all the shared code between the rooms. All three Castle Screens use the same code, All 3 Dragons use the same code, etc, so the color of the playfield editor "blocks" can't really match the room/sprite you're editing in many cases. If you would like to request a different color on specifc edit windows, though, I'd be happy to oblige.

 

The color issue would be more relevant if I was using the optimized code, which I have yet to implement. I've put so much time and effort into the application as it stands now, that I may not implement the revised code. It would require significant changes to the Save/Load feature, the edit windows, and of course, the source creation routine. Besides, it's pretty cool as it is, right?

 

I spent about 30 minutes tonight and added a "World Map" screen that shows all of the rooms, and allows you to click on a room to jump to it's corresponding edit window. This should help in understanding which rooms use shared code. I haven't compiled it and tested it yet, I'll probably release it tomorrow afternoon or Monday morning.

 

The only main feature that I was thinking about adding that I haven't yet put in is the ability to change the color of the rooms to a few pre-defined choices. It would raise a few issues, as you'd have to be careful to change the color of the keys to match it's appropriate Castle, and I wouldn't be able to test the results of color changes on a real TV, some choices could end up looking horrible if a bin was ever burned to a cart. I'd love to hear some feedback on this issue, as I'm thinking that I will not add it as a feature. Is this important to anyone? If not, I'm thinking that this app is really close to it's final "Version 1.0" release.

[+Atarius Maximus]

I released a new version yesterday that fixes the application crash problem when choosing a path for DASM or the save files. It also includes a new world map, which shows every room in the game, and allows you to click on a room and jump to it's corresponding edit window.

 

EDIT: I just posted the latest version to the first page. You now have the ability to edit almost all of the colors of the game rooms and sprites. You cannot change the orange color of the invisible mazes. I seem to remember having difficulty with that when I was working on Adventure Plus. Nukey, if you can help me figure out which value(s) to change to allow this without causing problems, I'd appreciate it.

 

Now that I've got pretty much everything in place that I wanted to include in the app, I think I'll start working on making some new Adventure Hacks with this program. I'll post them here when I'm done, along with the CYOA ".dat" files so they can be edited and changed again if you like.

 

I'm thinking now that once I'm sure there are no bugs with this version, It will be released independantly from an additional app that includes extras made possible with the optimized code, which I have yet to start on. I kind of like the idea of having two, as this app lets you make maps using limitations imposed by the original code. It's a little more challenging to make the maps with the shared lines, and forces you to be a little more creative. :wink:

 

Is anyone using this? Please post your experiences, or any suggestions for changes or improvements. I haven't gotten much feedback here lately.

[KrawDaddy]

Wonderful app! Ive just started using the app and its alot of fun, Ive been keeping up with your progress and have a two sugestions.

 

-It would be nice to have the option of auto loading the world map or maze map instead of each individual sprite and room. Its soo slow to boot, I dont know if each room needs to be open the create a .bin file but I dont think so. I just close the rooms out that Iam not using anyway. Id rather just select each room as I want to edit it.

 

-Is it possible to place a button within the editing boxes to reinsert the original hex values. A blank calculate inserts zeros, otherwise you have to close the box and reopen it.

 

Kind Regards

 

KrawDaddy :wink:

[+Atarius Maximus]

Welcome to AA KrawDaddy! I see it's your first post. I hope you stick around, there's some great people here. I'm also very glad you're enjoying the CYOA application.

 

It would be nice to have the option of auto loading the world map or maze map instead of each individual sprite and room. Its soo slow to boot, I dont know if each room needs to be open the create a .bin file but I dont think so. I just close the rooms out that Iam not using anyway. Id rather just select each room as I want to edit it.

 

Unfortunately, all map windows do need to be open when you click on the "Create Source" button. The application reads from the Hex fields on each map window, and then inserts them into the source. If one of the windows is not open, it won't be able to read the hex table and will create bad source code. Actually, i was thinking of disabling the ability to close the windows to avoid that problem. I could Minimize all of the windows by default, that should speed up the load time. You can then pull them back up easily using the "Maps" or "sprites" menu, which gives the map you choose active focus, so you can easily pick it out from the multitude of minimized windows at the bottom.

 

-Is it possible to place a button within the editing boxes to reinsert the original hex values. A blank calculate inserts zeros, otherwise you have to close the box and reopen it.

 

You'll be glad to know that this feature, along with many more, are going to be included in the next release. Each map window now has a "Load Default Hex" button on it, so you can reload the default Adventure data into a map or sprite easily, without having to close and reopen the window. In addition to this, you'll now be able to click on "Calculate" on every window all at once with a menu selection, minimize all windows with one menu choice and return all windows to a normal state with a menu choice. And finally, last but not least, my favorite new feature. You can now turn off the title bar on each window, and drag the window by clicking and holding the mouse button down on any gray area of the window. It frees up all of the wasted space taken up by the title bar, and makes it much easier to line up the map windows to match up exits and entrances. You can toggle the title bar on or off from each window individually, or all at once from a menu choice.

 

I should have the new version ready for release later this evening. Thank you for posting, keep the feedback coming!

 

Cheers!

 

AM

[KrawDaddy]

Hi

 

Thanks for the quick reply.

 

I not a programmer but why can't the program automatically insert default hex values into the source for all windows that are not open? Also, why cant the program create the source file automatically as a step to creating the .bin?

 

Kind Regards

 

KrawDaddy

[+Atarius Maximus]

I not a programmer but why can't the program automatically insert default hex values into the source for all windows that are not open?

 

Well, I wouldn't necessarily say it can't be done, but that's how the program currently works. If the window is closed, you can't make a call to that window to retrieve the hex values from the table because the table isn't there. I may be able to figure out a way to get around it, but I can't promise anything.

 

Also, why cant the program create the source file automatically as a step to creating the .bin?

 

Well, there is a reason for that. Because I'm using an external program (DASM) to create the binary file, the source has to already exist before a call can be made to DASM to process the file, hence the two step process.

I'm not sure I'll be able to get around that, but I'll look into it since you mentioned it.

 

AM

[+Atarius Maximus]

Well, I've got a new version ready. I still have to compile it, which takes about 15 minutes (!), so I'll post it within the hour.

 

The new version, 0.25, includes the following new features and changes:

 

All windows can now have their title bar toggled on or off. this can be done from the menu for all windows at once, or on each window individually.

 

All windows now start in a minimized state, which greatly reduced the load time of the application. You can reopen them as needed from the menus.

 

All windows may now be minimized and restored all at once from the menu, as well as individually.

 

You can now run the "calculate" function on all of the windows at once from a menu command.

 

The 'X' close button has been disabled on all of the map and sprite windows so they remain open to create a valid source file. If I can figure out a way to store the variables when the windows are closed, I will remove this, but it's likely going to remain.

 

Possible future Enhancements:

 

Create a custom set of .dat save files that load the original adventure maps. I could include this in the zip file. Anyone want to volunteer to help with this?

 

Changing the color of the edit fields to match the original color of the screen you're editing, as long as that screen doesn't alter multiple game map screens (that leaves many of them out!). I may also be able to allow you to choose the color of the edit field...but this may complicate the code unnecessarily. Currently, the binary fields are created by examining the specific color of each square, if I change that, I'd have to significantly alter how the code creates the binary table.

 

Using the optimized code. That would require a huge amount of work at this point. It would definitely be a completely different application, released separately.

 

I've included a screenshot below of what it looks like when you turn off the title bars and line up the map screens. Pretty Cool.

[KrawDaddy]

-Is it possible to add the ability to hold the mouse button and drag over the edit sprite box and fill in all the boxes the cursor passes over? I beleive it would be a time savor and less tedius.

 

Kind Regards

 

Ben Krall

[+Atarius Maximus]

-Is it possible to add the ability to hold the mouse button and drag over the edit sprite box and fill in all the boxes the cursor passes over? I beleive it would be a time savor and less tedius.  

 

 

That's a great idea. I'll see what I can do!

 

[Nukey Shay]

EDIT:  I just posted the latest version to the first page.  You now have the ability to edit almost all of the colors of the game rooms and sprites.  You cannot change the orange color of the invisible mazes.  I seem to remember having difficulty with that when I was working on Adventure Plus.  Nukey, if you can help me figure out which value(s) to change to allow this without causing problems, I'd appreciate it.

 

The invisible surround is just an object - it's the first one in the table as a matter of fact. Each object uses 9 bytes in the original game, the colors are the 7th and 8th byte (color/b&w), and the size of it is the 9th. This table is right at the end of the binary in the original game IIRC. Only the bridge and the surround use a size value of 7 (all the rest are 0), so it makes it easy to spot.

[+Atarius Maximus]

the colors are the 7th and 8th byte

 

Thanks Nukey. After thinking about it a little more, I think the problem I had last year with the invisible maze in Adv+ was trying to make normal mazes invisible, not a problem changing the color of the original invisible maze. It's hard to remember everything perfectly now, I'm getting old.

 

I'll add the ability to change the colors in the invisble mazes in the next revision.

[Nukey Shay]

To make the normal mazes invisible, you need to change the room's color to $08, and set bit 2 (+$04) in the playfield control byte (both found in the room data line...on the 3rd and 5th bytes respectively).

[+Atarius Maximus]

To make the normal mazes invisible, you need to change the room's color to $08, and set bit 2 (+$04) in the playfield control byte (both found in the room data line...on the 3rd and 5th bytes respectively).

 

Cool! Another feature to add to the app. Now all of the mazes can be made invisible.

[Nukey Shay]

Normally that playfield control byte is $21 (for regular visible screens). If you want left or right barriers, turn on the high bits (+$80 & +$40)

[+Atarius Maximus]

Is it possible to add the ability to hold the mouse button and drag over the edit sprite box

 

I've been looking into adding the "drag to edit" feature, and it's looking like it's not possible. I've been searching through code samples at planet-source-code.com, and browsing VB forums, and I can't find anything close to what I'm trying to do. If anyone here that knows VB wants to offer up a suggestion I'd appreciate it.

 

I changed the Color editing window to include the ability to change the color of the Invisible Mazes. Changing the color affects all of rooms in the black castle maze, as well as the "catacombs" maze. I also added the ability to change the color of the castle gates on all three Castles. It's not noted in the dissassembly which one is which, so for now they're just labeled Castle Gate #1, #2, and #3. It's a very minor update, nothing else was changed.

 

Look to the first post soon for v0.26.

[+Atarius Maximus]

Thanks to Nukey Shay, I've got one more feature working. On the color editing window, there are now checkboxes next to the Blue Maze Color and the White Castle (Red) Maze Color. If they're checked, it will make the mazes invisible. All invisble mazes have to be the same color, which can be changed in the "All Invisble Mazes" color box. I could add the capability to make all of the rooms invisible, or at least the ones that make sense (i.e., why make the level select room invisble?)

 

No new version yet, I'm going to get the invisible maze options finished before I compile again.

 

AM

[Brad2600]

Downloaded V0.26 and I got a run-time error:

 

"Run Time error 339:

 

Component MSCOMCTL.OCX or one of its dependencies not correctly registered; A file is missing or invalid"

 

Something I did? I'd like to check out the program.