Denial

Ghislain wrote:I understand this part. My question was along the lines of if I want to turn off this interrupt routine, say like this:

Code: Select all

verify_display_flag:
     LDA flag_display_routine					// How many CPU cycles will be used
     BNE modify_display_registers				// for these
     JMP play_music							// 3 lines?
     
modify_display_registers:
     // Do the background + border raster interrupt routine here
     // This I presume will be performed 88 times for all of the raster lines needed
     
play_music:
     // Play the music here
     
     RTS

Just wondering where the raster beam will be placed when "verify_display_flag" will be performed? Perhaps it will be well before it reaches the edge of the border of the first raster line anyhow.

Ah, ok.

We're just talking about something like 8 cycles here - the test would be included in the interrupt routine (i.e. it will and should remain always active). The raster beam itself is at the very top of the display screen, when the test is performed - and I will have to include the test in the interrupt routine for myself - otherwise the cycle-exactness couldn't be guaranteed. You can then change the flag from the foreground process - that then will determine whether you want the extra colours (at the expense of some CPU power) or don't want/need them. The music routine will continue to work anyhow, at the same pace with or without the raster routine.

Will PM you my e-mail.

Mike, I updated my D64 to take into account the 24*26 layout here:

https://sites.google.com/site/gdbsite50 ... ects=0&d=1

Also, PM me if you want me to email you this file.

If you weren't aware this may also compliment your toolset. I have just updated it...

Ghislain wrote: I am also hoping to delegate the graphics, music and even story writing tasks to others so I can completely focus on the aspects of programming and designing the game.

Give me a few days and I can send a few tracker files your way to see if you think they'll work for your game. I enjoy the Realms ofor Quests series and I would be honored to have the opportunity to compose music for one.
Do you have any preference between using Vic Tracker or Fisichella files or any spec prefreferences or needs in terms of limitations on memory size or song length?
Is there any certain atmosphere or ambiance that you would like the music to project?

Here are a couple of audio tracks that I created with the vic.

Nut (vic tracker)

Exoskeletal (vic tracker)

Save:Run/Stop (.seq music played from disk)

DM (fisichella)

These samples may not be the best for a rpg but they provide a sample of my work with the vic.

Here is a .d64 image containing a vic tracker file with 4 songs ( 0-3). This is an album that I started working on a little while back. I think that these tracks could make some great game music.

rzo4demos.d64

load "4demos" from vic tracker.

beamrider wrote:If you weren't aware this may also compliment your toolset. I have just updated it...

Thank you for this. I did check it out and it looks very useful!

R'zo wrote:Here is a .d64 image containing a vic tracker file with 4 songs ( 0-3). This is an album that I started working on a little while back. I think that these tracks could make some great game music.

rzo4demos.d64

load "4demos" from vic tracker.

Thank you so much for offering to make music for the game. I will definitely check these out as soon as I'm able to. I will PM you about this in a day or two.

Meanwhile, I spent most of the day yesterday working on the graphics for the title menu screen. While it might be a bit premature to do graphics before possibly getting a graphic artist, I always like to get a title menu screen ready in order to create a mood while I am playtesting.

Good luck with this.

I have always prefered adventures & arcade games to RPGs and the only VIC-RPG I have really got into is Tomb of Drewan, but I am definitely tempted to give others a chance.

Wow man already getting excited looking at this...

Since the last update I've worked on the title screen. You'll note that the game logo is quite a bit bigger than the one that I've used in Realms 1-4. One of the features will be that the game will support up to 2 disk drives (to reduce disk swapping). Of course, the game will work best on an SD card reader.

I streamlined my dev environment so that there is less steps involved in compiling the source code. (It was very tedious to transfer the compiled code to the D64 every time I made a minor change).

I also redesigned the title screen and removed the function key options -- I will try as much as possible to get the user to use the cursor to select options. Normally pressing the function keys on a real VIC-20 is fine, but it is not as quite an elegant as doing it on a PC keyboard via emulation.

Here is a rough idea of how the memory map of the game will be like:

673-767 - Temp memory location
828-1023 - Temp memory location
4096-4719 - Screen memory (for a display of 23*26, but effectively resized for 24*26 in order to handle video raster interrupts) (624 bytes)
4720-5119 - Module Disk Loader (400 bytes)
5120-7167 - Reserved for graphics display (2K)
7168-19455 - GAME MODULE (12K)
19456-32767 - CORE ENGINE (13K) - game data will also be stored here.
40960-49151 - GAME MAP (8K)

Because my plan for the game will span a very large world (a land map of 270*270 tiles), multiple dungeons (10 floors of 25*25 rooms each), cities with townspeople to talk to, this will require a lot more memory than even the 32K expanded VIC-20 can handle. So portions of the game will be loaded on an on-needed basis.

So when you leave the Castle to travel on the world map, it will use the module disk loader to put the TRAVEL MAP program into the GAME MODULE memory and then execute it. But instead of reloading code that displays player and party information into the GAME MODULE portion of the memory, there will be a lot of shared code that the game modules will use that are stored in the CORE ENGINE. It will have routines that are mundane like displaying a number and printing text to ambitious ones like playing music, displaying graphics and item inventory management (I've probably said it a million times but the hardest part of programming an RPG is the inventory management aspect of it).

And GAME MAP is reserved for storing whatever game world data from disk that is needed at the time (like say a portion of the world map or the floor of a dungeon), image portraits of boss monsters and NPCs.

Right now, I'm just writing the game to run off the emulator and reading all of the files locally from the PC (as if running on an SD card reader). I will program the disk loading and disk swapping portions once the game is completed.

Ghislain wrote:If pressed for time, I might just make it into another Dungeon crawler.

The great thing about this platform is that one can wait until a project is fully realized. No one's in a hurry. No marketing concerns. Anyway, I look forward to seeing this.

Me too

Jeff-20 wrote:

Ghislain wrote:If pressed for time, I might just make it into another Dungeon crawler.

The great thing about this platform is that one can wait until a project is fully realized. No one's in a hurry. No marketing concerns. Anyway, I look forward to seeing this.

I won't stress out myself too much, of course.

Today, I've been mostly planning out how to store the party stats and the overall data storage of the game:

DISK SiDE 1 - BOOT, GAME ENGINE, CASTLE (create characters), LAND data
DISK SIDE 2 - DUNGEON data
DISK SIDE 3 = MONSTER graphics data
DISK SIDE 4 = CITY data

Ideally, the player will use an emulator or an SD card reader on a real machine so the game only concerns itself with effectively one (very big) disk side. In the case where the player is using a single floppy disk drive on a real machine, there will be quite a bit of disk swapping. But if a player has two disk drives, drive 8 will be used to flip between sides 1 + 2 while drive 9 will be used to flip between sides 3 + 4.

Each player character will have stats that comprise of 33 bytes:
One additional feature of Realms 5 that it will have over it's predecessors is that each player can have a companion which can be either a summoned or controlled monster or even a traveling NPC. So along with the 10 player characters that your party can have, you can have up to 10 NPC/summon companions effectively giving you a party of 20 members (though only the 10 main player characters are shown on the main screen). Realms 4 had a feature where you could control or summon a monster but this only lasted for the duration of a battle. This time, you can keep using your NPC/summon for as long as you like or until they die.