111 replies to this topic

[Atarius Maximus]

I started out making a little Visual Basic Program to aid me in coding new Mazes for Adventure, and well, it started expanding a little bit. As it stands right now, it allows you to visually click on and change Mazes, Sprites, Colors, and object room placement in adventure, and when you're done, the application will export the changes to a source text file, and gives the option to compile it automatically if you have DASM installed.

You can also use any map window to write a map screen, just cut & paste the hex values into the source code directly using a text editor. That's what I originally wrote this for. This program is freely distributable, I didn't make it with the intention of making a profit.

Below is a screenshot, a download link for the application, and a download link for the bin file created with the map screens you see in the screenshot.

EDIT: I will be updating the first post in this thread with updated versions.

Revision History:
-------------------

v0.13: Added the ability to edit the Top Entry Room. Fixed major bug in 0.12 (sorry to those who downloaded that revision), it makes uncompilable source. I screwed up on the shared lines of code in the Invisible Maze and Red maze. Sorry about that.

v0.14: Added the ability to edit all of the rooms with the exception of the Black Castle Maze. Added an additional .exe to this, I made the maze guides a separate application, due to memory limitations I'm running into in the main app.

v0.16: Now you can modify every map screen in the game, including the black castle Maze. I also created a new form that lets you visually click choose the location of DASM and the location that you'd like to save the BIN and Source. Guide Maps are now back into the main app, as I've cleared up the memory errors.

v0.17: Added the ability to change all 3 Dragon Sprites (normal, attacking, and dead), the ability to minimize all of the windows, and some VB code optimizations.

v0.18: All Sprites can now be edited with the exception of the 1-2-3 numbers in the level select screen. The sprite editing maps are preloaded with the default hex values from the original adventure. This will be added to all maps in a future revision. Create Source/Binary screen updated so you can choose different drive letter.

v0.19: All forms are now preloaded with the default hex values from the original adventure game, eliminating the need to click on 'calculate' on every window before you compile the source. If you don't edit a window, you get the default adventure screen. Map & Sprite windows can now be closed and then re-opened with menu drop-downs. If you close and reopen a window, it will re-load it with the default hex values. All windows MUST be open when you compile!

v0.20: I'm beginning to test the Save/Load Function. A bare bones save/load is in this build, but I would'nt recommend using it yet, and it only saves the Blue Castle Maze Entry Map right now anyway. The main reason for this update is a bug fix, there was a problem with the Playfield Editing control array on the Castles Map Editor window.

v0.21: Save/Load Feature is complete. Menu options "Maps" and "Sprites" will now open window AND bring them to the foreground if they're already open. Bug Fixes: Bridge sprite had a hex conversion bug, and default values for the 'Below Yellow Castle' screen were incorrect. Both were fixed.

v0.21b: Cosmetic Changes only. Sprite Windows changed, Create Source/Binary Window Changed.

v0.22: Error handling routines are now included. The app will no longer crash if you choose an invalid path for DASM or the save files. Also, a world map is now included, and allows you to click on a map and be taken to the corresponding edit window.

v0.23: You now have the ability to modify the colors for almost all of the game screens and sprites. You cannot change the orange color of the invisible mazes.

v0.24: Unreleased

v0.25: 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.

v0.26: Minor Update. Added ability to modify the color of the invisible mazes, as well as the castle gates.

v0.27: Minor Update. You can now change the Blue Maze and Red Castle Maze to be invisible. Also, the app is now downloadable as both an exe and a setup package. Use the setup package if you get runtime errors when using the EXE only. Please note, the setup package does install several OCX and DLL files and registers them in the Windows Registry. Use the install package at your own risk, I take no responsibility if it causes problems on your PC. The specific dependency files loaded are posted in a thread on page 4.

v0.28: You can now change all of the map rooms to invisible with the following exceptions: Castles: If they're invisible, you can't tell what color they are, and the Level Select (Number) Room: Not used in gameplay. Invisible Room options will now be saved when you hoose "File"/"Save".
World Map will now restore each window to a normal state when you click on a map.

v0.29: Ability to change room locations and X/Y coordinates of objects added. Bug fixed: You can now make a call to DASM with a path that includes spaces. Help option screen updated. This is the final "new feature" release. All releases from here on out will be for bug fixes, usability improvements, or help file changes.

v0.30: Bug fixes. Save file "Colors.dat" no longer compatible with new version.

v0.31: More bug fixes. Bridge & Dragon Attacking sprites not loading correctly. Level Select Screen was not being saved. New save file added, Map23.dat. In order to keep using old save files, make a copy of Map1.dat and rename it to Map23.dat. The load routine will fail unless it can find a "Map23.dat" with this version.

v1.00 (Build 32) - Final Version: There is now a toolbar that you can use to access some of the most used functions of the application. There is now a preferences menu to turn the toolbar and status bar on and off. The editing colors on all of the windows have changed, many now match the color of the original adventure screen that you are editing. This causes problems with old save files, which is in a thread on page 5. Some menu items have been slightly rearranged to make selection of items more intuitive. The help file was given it's final update. A new section in "help" allows you to read the original Adventure Instruction Manual, some history on the game, and shows pictures of the original game cartridge and box. A consistent color theme was given to all the windows. I attempted to choose a color scheme that would be easy on the eyes. New buttons with "!" on them were placed as informational buttons on windows that are non -standard in some way (asymmetric playfield, shared lines, etc). This replaces the text boxes that previously provided this info, which cluttered up the windows.

Download Link for full setup package:
http://www.atariage....CYOA1.00.32.zip

Attached Thumbnails

• 

Attached Files

•  cyoa1.00.32.zip   1007.71K   266 downloads
•  cyoa_bin.zip   3.07K   374 downloads

[Albert]

Very nice! I look forward to seeing this evolve a bit, such as adding the ability to create binaries directly from within the app. I wonder how many people are running 1600x1200, though. I have several LCD displays and none of them go up to 1600x1200 (the closest is 1680x1050, but that's on one of my Macs).

..Al

[Atarius Maximus]

Albert said:

Very nice! I look forward to seeing this evolve a bit, such as adding the ability to create binaries directly from within the app. I wonder how many people are running 1600x1200, though. I have several LCD displays and none of them go up to 1600x1200 (the closest is 1680x1050, but that's on one of my Macs).

Thanks Al. I do plan on working on this a little more as time goes on and adding some enhancements. I could probably add a call to the command prompt to run DASM and compile the source automatically, but you'd still need a copy of DASM in the same directory as the application for it to work. I don't think I can do it any other way. As far as the resolution... well, it will still work fine at lower resolutions, you'll just be scrolling up and down on the screen a little bit more. I could probably make a Mac version of this too in RealBASIC, but I don't have a registered copy of it, and you'd still need to compile the source in DOS.

If you get some time, download it and let me know if it works for you.

[Albert]

Atarius Maximus said:

I could probably make a Mac version of this too in RealBASIC, but I don't have a registered copy of it, and you'd still need to compile the source in DOS.

Ahh, yes, RealBASIC, that would be interesting if you could use that to "port" the app over to OS X. There is a version of DASM for OS X (and I have successfully used it), so that would not be a problem.

Quote

If you get some time, download it and let me know if it works for you.

Will do.

..Al

[kisrael]

That's very cool.

I'm doing something similar for Eric Ball's Lode Runner clone, Leprechaun: http://alienbill.com...0/lep/edit.html
though a lot less ambitous, just a level editor that happens to
be online.

Isn't there someting just delightfully so right and yet so wrong about writing a program that writes another program?

[Nukey Shay]

Another enhancement would be the ability to change the screen links...there are 4 bytes for each screen that indicate which screen you will wrap to when you exit a room. These are found on the same lines that hold the color data and GFX pointers. As well as the ability to add in rooms...you can go up to 64 rooms using the current routines (memory being available).

[Atarius Maximus]

kisrael said:

Isn't there someting just delightfully so right and yet so wrong about writing a program that writes another program?

Yes. This has been a fun project.

Nukey Shay said:

Another enhancement would be the ability to change the screen links...there are 4 bytes for each screen that indicate which screen you will wrap to when you exit a room. These are found on the same lines that hold the color data and GFX pointers. As well as the ability to add in rooms...you can go up to 64 rooms using the current routines (memory being available).

Those are good suggestions, they're on my To Do list! I know I could easily add the ability to change room links, I did that in Adventure Plus. Adding rooms I've had a little trouble with, you're a little better at this stuff than me.

Anyone here a VB expert? I just tried incorporating a call to DASM to compile the source with this command:

Private Sub mnuDASM_Click()
call shell ("C:dasm.exe cyoa.txt -f3 -ocyoa.bin",vbNormalFocus)
End Sub

It doesn't work. The command window flashes briefly on the screen, and nothing compiles. I need to do a little googling for my answer, methinks.

AM

[Albert]

Atarius Maximus said:

Anyone here a VB expert?  I just tried incorporating a call to DASM to compile the source with this command:

Unfortunately, I've done a great deal of VB programming in the past.

Quote

Private Sub mnuDASM_Click()
call shell ("C:dasm.exe cyoa.txt -f3 -ocyoa.bin",vbNormalFocus)
End Sub

It doesn't work.  The command window flashes briefly on the screen, and nothing compiles.     I need to do a little googling for my answer, methinks.

This is most likely not working because dasm.exe cannot find the files it is looking for (do you really have it located in the root directory of your C: drive?) I have not used dasm too extensively, but you may need to prefix the filenames (cyoa.txt, cyoa.bin) with absolute file paths. When running dasm like this, the current working directory for your app is the directory your executable is located in. If prefixing the input and output filenames with a full path does not work, you may need to change the current directory to the directory where dasm.exe is located before you attempt to invoke it. If dasm.exe is looking for other files (such as a header file), you'll probably need to do the latter.

..Al

[Nukey Shay]

Adding in rooms is as easy as just pasting an existing data line to the assembly, then updating the room links for the others to include it (at a cost of 9 bytes per room). Note that you would also need to alter the random routines if you want those new rooms to be taken into account when the program is scrambling the objects at the start of game 3. This is found in the object matrix...each one has a high and low value that can be edited. If you also want to add in seperate GFX for the new room, it would also need another table for that (at an additional cost of 21 bytes per room). Note that the barriers can be added to any room...you can even have both of them in a room. This would cut down the amount of space needed if you just want to add in a lot of generic corridors.

[Nukey Shay]

Oops...also remember that the number of rooms you have is proportional to how easy the game is (the more you add in, the easier it gets...since the bats and dragons will have more places to roam). For that reason, try to limit added rooms to the insides of castles or something like that.

[Atarius Maximus]

Albert said:

Unfortunately, I've done a great deal of VB programming in the past.  

Are You implying that VB is not an ideal programming environment?

Albert said:

This is most likely not working because dasm.exe cannot find the files it is looking for (do you really have it located in the root directory of your C: drive?) I have not used dasm too extensively, but you may need to prefix the filenames (cyoa.txt, cyoa.bin) with absolute file paths. When running dasm like this, the current working directory for your app is the directory your executable is located in. If prefixing the input and output filenames with a full path does not work, you may need to change the current directory to the directory where dasm.exe is located before you attempt to invoke it. If dasm.exe is looking for other files (such as a header file), you'll probably need to do the latter.  

Yes, dasm is in the root of my C: drive, but that wasn't the problem. Thanks to your advice, I figured it out. This code works:

Private Sub mnuDASM_Click()
DASMLocation = InputBox("Please enter the path to DASM, Example: C:DASM")
RunDasm = DASMLocation + "dasm.exe c:cyoa.txt -f3 -oc:cyoa.bin"
Call Shell(RunDasm, vbNormalFocus)
End Sub

Now the program prompts you for where DASM is installed, and it works! The new version that includes this change is attached below. There are now two options in the File Menu, one to create the source (still to C:cyoa.txt), and one to compile it. Obviously, you must click on "Create Source" first.

Nukey Shay said:

Adding in rooms is as easy as just pasting an existing data line to the assembly, then updating the room links for the others to include it (at a cost of 9 bytes per room).  

Well, you're right, that doesn't sound very difficult. I didn't incorporate the optimized code into the VB program though , so it would take a little bit of work to add that. Adding the ability to change all of the rooms would be cool, however it has one major caveat; every room I add to the program HAS to be updated with something, or the app will write null values into the code. I may be able to write some error checking so default values are written in if the user entered values are null, but how much effort do I want to put into this? It's just for fun, really. The more I add to the program, the more laborious the process of creating a new BIN becomes.

AM

Attached Files

•  cyoa011.zip   228.33K   190 downloads

[Nukey Shay]

What I would do is just create a "template" bin. One that has a given number of rooms...most easily the maximum number of rooms that the optimized code will allow. Enable the optimizations, but keep the bitmap intact for the secret message (so people can use it or not use it), that would allow the addition of 7 more rooms (30 bytes each). During the VB program initialization, have it load in the default room data and bitmaps into it's matrices, and zero out the rest (so null values are no longer a problem - it will write zeros to those areas if left unused).
When editing the optimized code to include the space for the zeros, you might also want to make sure that the default room bitmaps no longer use shared data. There's only a few lines that do this. It's true that this will throw off your current values that you have for the byte locations...but better to do it now and get it over with Since each room will be using a set number of bytes (30 each...no deviation), mapping it should be easier this time around.
Give a yell if you need any help

[Atarius Maximus]

Quote

What I would do is just create a "template" bin. One that has a given number of rooms...most easily the maximum number of rooms that the optimized code will allow.

I'll send you a PM sometime tonight to discuss this and your other comments.

Quote

have it load in the default room data and bitmaps into it's matrices

That doesn't sound very hard. Duh. Why didn't I think of that? Heh, the only training I've ever had in BASIC was on the Commodore 64 in 1986 in a high school programming class. I didn't think anybody would want to use this program if I wrote it on my (still in use) C64, though. I picked up a free copy of Visual Basic 6.0 Enterprise from work a few years back, thought "hey, I know BASIC from way back, and this looks pretty cool", and just started messing around with it. That's the extent of my knowledge.

I can share the source code with you or just post it here, but I don't want to get attacked by all the experienced VB coders out there who will inevitably ridicule me for my spaghetti code. I'm sure my hundreds of lines of code could probably be reduced to about 10 by someone with more knowledge.

[Nukey Shay]

I was referring more about the optimized Adventure source. I never worked with VB programming What I meant was that I could slap together something that includes the zeroed-out areas when a bin is compiled, and help map it out to get the data you need for VB. I'm a total newbie for VB

[Atarius Maximus]

Nukey Shay said:

I was referring more about the optimized Adventure source. I never worked with VB programming  What I meant was that I could slap together something that includes the zeroed-out areas when a bin is compiled, and help map it out to get the data you need for VB. I'm a total newbie for VB  

Heh, yeah, I wasn't sure if you were referring to the Adventure code, VB, or both.

If I'm going to incorporate the optimized code and added rooms into this application, I'm going to need some help from you. I'm going to have time to get back to this in about an hour after I put my kids to bed. I'll post here again or send you a PM, If you're still online in an hour, we can talk about it.

AM

[Nukey Shay]

Okay...I'll start shifting the data tables around, so you can later add other aspects as well (like editing items that the dragons guard/afraid of, etc).

[Atarius Maximus]

Below are some examples of how I'm creating the source code in VB. I actually have a copy of the commented code that I downloaded from the Dig copied into the CYOA source. The sections of code that write the hex bytes to create the maps are replaced with the hex code variables inputted from the program, as you can see below. If it's not too much to ask, if you could set up and comment the code as to where the new rooms are, and where the room linking info is, it would make my job much easier. I could then just replace the entries with variables from the map forms in the VB code. I'd certainly give you credit in the "Help-About" screen for your assisstance. I'm not trying to "pass the buck" here, but you'd be able to do it much quicker and easier than me.

Map 6 Hex Code Table Example (Invisible Maze Entry Screen):

When you click on the "Calculate" button on each map screen, the playfield entries are converted to binary, then from binary to Hex, filling in the Table below. Currently, if you don't click on calculate, the values remain null, and are read into the source that way.

|-------------------------------------------------------------------------|

|                                  Hex                                    |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex1.Text  | frmMap6.txtHex2.Text   |  frmMap6.txtHex2.Text  |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex4.Text  | frmMap6.txtHex5.Text   |  frmMap6.txtHex6.Text  |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex7.Text  | frmMap6.txtHex8.Text   |  frmMap6.txtHex9.Text  |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex10.Text | frmMap6.txtHex11.Text  |  frmMap6.txtHex12.Text |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex13.Text | frmMap6.txtHex14.Text  |  frmMap6.txtHex15.Text |

|-----------------------|------------------------|------------------------|

| frmMap6.txtHex16.Text | frmMap6.txtHex17.Text  |  frmMap6.txtHex18.Text |

|-----------------------|------------------------|------------------------|

To get around the null value problem, I could do a series of If-Then statements before the source text file is created, and if the values are null, populate them with either $00 or a default map screen (like the 2 exit room).

Here is a snippet of the code that creates the source text file:

    Open "c:cyoa.txt" For Output As #1

    Print #1, "      processor 6502                 "

    Print #1, ";Default 2600 Constants set up by dissasembler..                 "

    Print #1, "VSYNC   =  $00                 "

    .

    .

    .

    Print #1, ";Invisible Maze Entry                 "

    Print #1, "      .byte " + frmMap6.txtHex1.Text + "," + frmMap6.txtHex2.Text + "," + frmMap6.txtHex2.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex4.Text + "," + frmMap6.txtHex5.Text + "," + frmMap6.txtHex6.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex7.Text + "," + frmMap6.txtHex8.Text + "," + frmMap6.txtHex9.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex10.Text + "," + frmMap6.txtHex11.Text + "," + frmMap6.txtHex12.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex13.Text + "," + frmMap6.txtHex14.Text + "," + frmMap6.txtHex15.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex16.Text + "," + frmMap6.txtHex17.Text + "," + frmMap6.txtHex18.Text; ""

    Print #1, "      .byte " + frmMap6.txtHex19.Text + "," + frmMap6.txtHex20.Text + "," + frmMap6.txtHex21.Text; ""

    Print #1, "                 "

    Print #1, ";Castle Definition                 "

    Print #1, "      .byte $F0,$FE,$15        ;XXXXXXXXXXX X X X      R R R RRRRRRRRRRR"

    Print #1, "      .byte $30,$03,$1F        ;XX        XXXXXXX      RRRRRRR        RR   "

    Print #1, "      .byte $30,$03,$FF        ;XX        XXXXXXXXXXRRRRRRRRRR        RR   "

    Print #1, "      .byte $30,$00,$FF        ;XX          XXXXXXXXRRRRRRRR          RR   "

    Print #1, "      .byte $30,$00,$3F        ;XX          XXXXXX    RRRRRR          RR   "

    Print #1, "      .byte $30,$00,$00        ;XX                                    RR   "

    Print #1, "      .byte $F0,$FF,$0F        ;XXXXXXXXXXXXXX            RRRRRRRRRRRRRR   "

    .

    .

    .

 

As you can see, the commented code made the job quite easy, I just locate the area of code that I want to change, and replace it with the variables from the application. Simple. If you could somehow make the optimized code that simple for me to change, it would make the development of this application much quicker. Let me know what you think.

[Atarius Maximus]

Here's my final update for the night. I've got a splitting headache, and I'm headed for bed.

I've included the ability to modify the White Castle (Red) Maze, and fixed a bug I found in the creation of the invisible maze.

-----

EDIT: I removed the attachment. Please go to the first message in this thread for the current download.

[Nukey Shay]

OK...here's the template. There are 3 files in the zip. The optimized assembly file that has all of the things moved around, the binary it creates (which should be used as the file that your VB program alters), and a disassembly of that...which details the specific byte locations that your VB program needs to alter. I added in comments of my own so you can see how the data works. By carefully shifting the tables around, I eliminated the screen glitch that previously appeared on virtually all optimized Adventure hacks (so you are on your own if you decide to shift the tables around and recompile it ). Also, since even the optimized code shared 6 full bitmaps, I was only able to add in 6 additional screens. The castle bitmap will still be shared between the 3 castles, and the very last bitmap will be shared for the game select screen. Bringing the total to 37 screens (34 unique).

Sorry I can't be much help for VB files, but I really am clueless for that.

Attached Files

•  adventure_templates.zip   43.2K   246 downloads

[Nukey Shay]

BTW I had a few bytes left over, so I increased each dragon's "liked/feared" matrix to have up to 6 objects (just like the green dragons'), and also zeroed out $FFF8 so this game should run on unmodded Superchargers.

If you play the binary as-is, you won't notice anything different (except that the secret message is a clone of the chalice). The extra rooms are not being accessed by any of the existing rooms. I'll leave that to you.

[Atarius Maximus]

Thanks Nukey, that's exactly what I needed. This is going to keep me busy for quite a while! I've got time today to work on it, but I'm travelling on business this week and after today, probably won't get back to this until next weekend.

[Atarius Maximus]

I just posted another revision in the first post of this thread. I shouldn't have been working on this late last night with a headache. The last revision (v0.12) created source that couldn't be compiled. I fixed that. The new revision also adds the ability to modify the top entry rooms.

I'm going to work on updating the VB code to add the ability to update all the rooms of the original Adventure source. when I'm done, I'll make another revision of the program that updates the Optimized code instead. Changing the Black Castle maze is going to require a little more work, as it uses assymetrical playfields instead of mirrored, so I'm going to have to modify the VB code to take that into account.

[Albert]

Atarius Maximus said:

I just posted another revision in the first post of this thread.  I shouldn't have been working on this late last night with a headache.     The last revision (v0.12) created source that couldn't be compiled.   I fixed that. The new revision also adds the ability to modify the top entry rooms.

Awesome, glad to see work progressing so quickly on this. I'm sure we'll see some pretty cool Adventure creations as a result. Hmmmm, maybe when the editor has evolved and matured a bit it might be time for a "Create Your Own Adventure" contest.

..Al

[Atarius Maximus]

Quote

Hmmmm, maybe when the editor has evolved and matured a bit it might be time for a "Create Your Own Adventure" contest.

That's exactly what I was thinking. It could be a while before I'm happy with the editor and can call it "finished", though.

[Nukey Shay]

With the larger map, you might want to edit the dragon matices so that each one "fears" at least one dragon. That will keep them active and from bunching up if they all find the chalice to guard. I would have liked to have added in a seperate link map, but I can't find enough space (so that dragons and the bat can't be locked in a castle). Perhaps the unused b&w bytes in the room data can be used for this? I'll check out the routine