*ALL PHYSICAL COPIES ARE SOLD OUT*: REALMS OF QUEST V (Digital version is available)

[Mike]

In another matter: normally, the exterior border colour doubles as one of the multi-colour colour sources, as you know. That means you'd been "forced" to use yellow (or whatever border colour you might choose otherwise) as one of the colours in the upper left portion. The background colour shares the same issue - it is forced to black.

When you have settled on a given screen layout, I can provide you with a raster routine, which changes the VIC register to another combination of background and border colour, just within that upper left section. It will slow down execution of the main program a little bit, but you get some extra flexibility for the colours.

I assume the auxiliary colour will only be used within that upper left frame, so it shouldn't require that treatment (it wouldn't anyhow be possible to change two registers at once).

PAL and NTSC require different register settings for the VIC registers of horizontal and vertical alignment, also the routine needs to take both TV systems into account.

[Ghislain]

In another matter: normally, the exterior border colour doubles as one of the multi-colour colour sources, as you know. That means you'd been "forced" to use yellow (or whatever border colour you might choose otherwise) as one of the colours in the upper left portion. The background colour shares the same issue - it is forced to black.

When you have settled on a given screen layout, I can provide you with a raster routine, which changes the VIC register to another combination of background and border colour, just within that upper left section. It will slow down execution of the main program a little bit, but you get some extra flexibility for the colours.

I assume the auxiliary colour will only be used within that upper left frame, so it shouldn't require that treatment (it wouldn't anyhow be possible to change two registers at once).

PAL and NTSC require different register settings for the VIC registers of horizontal and vertical alignment, also the routine needs to take both TV systems into account.

That sounds like a great idea. The image would occupy the 11*11 screen corner at the top left of the screen -- which is 44*88 multicolor pixels. So would your routine effectively only work for the first 11 chars at the top left for 88 scan lines? You're also changing the background color back to black after beam passes the 11th character, right?

I also plan to put music in the game -- will this raster routine still allow me to play music in the background?

Anyway, since I've already decided on the screen layout, I attach a D64 image where I quickly created basic programs (for both NTSC and PAL layouts) where the screen is resized to 23*26 characters (as well as repositioning the screen) along with displaying multicolor information (using ASCII character 166) at the top left corner of the screen. I explain everything in the REM statements.

Though the screen layout programs are written in BASIC, my intention is to write the game in ML.

Here is the D64 file containing my screen layout programs. You should make sure to run them with at least 8K expansion or more in the emulator.

https://sites.google.com/site/gdbsite50 ... 175e34baff

Thank you very much for offering to do this. I've always wanted to see how code for modifying VIC-I registers on the fly actually works.

[Mike]

So would your routine effectively only work for the first 11 chars at the top left for 88 scan lines? You're also changing the background color back to black after beam passes the 11th character, right?

Exactly. Although, it will be necessary to make a small change to the screen *memory* layout, which however won't affect the visuals:

The changes to the VIC colour registers come into effect a single hires pixel delayed with respect to half-char boundaries. Without any precautions, that means the left-most pixel column of the top-left window still would appear with black as background and yellow as exterior border colour source. The (also delayed) change from the new colours back to black/yellow can easily be hidden by the border coloured frame characters in the middle.

To get rid of the single wrong-coloured pixel column, you can add another character column to the left, which is also filled with the frame characters. That character column then hides the change of the VIC register.

Effectively the screen would be 24x26, of which you'd use 23x26 as you planned, and the left-most character column helps to hide the delay within the VIC chip. It might also be helpful to simply the addressing within the text screen.

Just tell me, if you're o.k. with that and I will go and implement the routine with the adapted screen layout.

BTW - the frame character should be done in hires, with yellow as foreground colour - otherwise if done in multi-colour with %01010101 it would just inherit the same one-hires-pixel delay for the exterior border colour, and we would be no better off. If you plan to do effects with changing/flickering border and want the frame characters to follow suit, at least the 11 characters to the left and right of the top-left window need separate handling.

I also plan to put music in the game -- will this raster routine still allow me to play music in the background?

Yes. It's always possible to put an extra routine at the end of the raster processing. Note, however, the IRQ will be called 60 times per second on NTSC and 50 times per second on PAL, so the music routine needs to take that into account.

[Ghislain]

The changes to the VIC colour registers come into effect a single hires pixel delayed with respect to half-char boundaries. Without any precautions, that means the left-most pixel column of the top-left window still would appear with black as background and yellow as exterior border colour source. The (also delayed) change from the new colours back to black/yellow can easily be hidden by the border coloured frame characters in the middle.

To get rid of the single wrong-coloured pixel column, you can add another character column to the left, which is also filled with the frame characters. That character column then hides the change of the VIC register.

Effectively the screen would be 24x26, of which you'd use 23x26 as you planned, and the left-most character column helps to hide the delay within the VIC chip. It might also be helpful to simply the addressing within the text screen.

Just tell me, if you're o.k. with that and I will go and implement the routine with the adapted screen layout.

That sounds great, let's go with that. Using the border frame characters (non-multicolor foreground block chars), you can hide the playing with the raster beam.

Questions:

1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left (thus increasing the screen size to 25*26) ?

2. Did you want me to rewrite my screen layout programs to include the border character padding?

[Mike]

1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left?

No, that's not the reason for the extra character - I suppose I have to elaborate further:

As I wrote - the colour change happens one hires pixel late with respect to half-character boundaries. Without any precautions, that'd mean I'd place the store to the VIC register $900F so, that the change is supposed to happen at the boundary of border to screen window. Alas, that will come into effect one pixel late - thus the left-most pixel column still appears with black as background and yellow as multi-colour colour source from the exterior border colour.

If I place the write to the colour register one CPU cycle earlier, it happens in the border. This solves the problem for a changed background colour, however now 3 hires pixels within the border will assume the new border colour, which originally was intended for use within the screen window only. (1 CPU cycle corresponds to 4 hires pixels)

That's the reason the colour change needs to be hidden by extra frame characters to the left of the top-left window. On the right, the frame characters already solve the issue for the change back to black as background and yellow as border.

At least those 11 frame characters to the left and to the right of the top-left window must be done in hires, with the "real" border colour as their foreground colour.

All other frame characters could be done in multi-colour and thus will inherit any change of the exterior border automatically *), in case you want to do effects with a flickering/changing border colour (say: red for danger). However, the foreground colour of the 2x11 characters to the left and right of the top-left window need to be changed manually along with the border colour.


To recap on this one: "This interrupt would be turned on and turned off as needed." - yes, you need use this routine only as necessary. Especially, during disk drive access, the raster routine might have problems keeping up a stable raster, and it should be deactivated during that time. The music routine should still be there - and while it might suffer from a few delays by the KERNAL I/O, it can remain active and keep the difference between 50 Hz on PAL and 60 Hz on NTSC.

2. Did you want me to rewrite my screen layout programs to include the border character padding?

You'll need take that new addressing into account at least.

Unfortunately, google requires a login, thus I'm anyway not able ATM, to download your disk image. It doesn't pose any problem though for me to write an own version of the screen layout - that will also feature the handling of the two types of frame character.


*) BTW - that's exactly how MINIPAINT produces the three windows in the main screen "floating" within the border colour.

[Ghislain]

1. Obviously this routine will only be used when displaying a portrait of a character, monster or a scene. This interrupt would be turned on and turned off as needed. Will verifying for this require more CPU cycles and thus you might need an extra border character of padding on the left?

No, that's not the reason for the extra character - I suppose I have to elaborate further:

As I wrote - the colour change happens one hires pixel late with respect to half-character boundaries. Without any precautions, that'd mean I'd place the store to the VIC register $900F so, that the change is supposed to happen at the boundary of border to screen window. Alas, that will come into effect one pixel late - thus the left-most pixel column still appears with black as background and yellow as multi-colour color source from the exterior border colour.

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.

2. Did you want me to rewrite my screen layout programs to include the border character padding?

You'll need take that new addressing into account at least.

Unfortunately, google requires a login, thus I'm anyway not able ATM, to download your disk image. It doesn't pose any problem though for me to write an own version of the screen layout - that will also feature the handling of the two types of frame character.


*) BTW - that's exactly how MINIPAINT produces the three windows in the main screen "floating" within the border colour.

Just PM me your email address, and I can send you the D64 file. It's no problem for me to rewrite the screen layout program so you can jump right ahead to the really important stuff!

You are the VIC-I raster master!

[Mike]

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.

[Ghislain]

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.

[beamrider]

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

[R'zo]

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.

[R'zo]

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.

[Ghislain]

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!

[Ghislain]

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.

[hasseapa]

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.

[darkatx]

Wow man already getting excited looking at this...