**New Release** REALMS OF QUEST 3 (available for order!)

Discussion, Reviews & High-scores

Moderator: Moderators

Post Reply
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

**New Release** REALMS OF QUEST 3 (available for order!)

Post by Ghislain »

Well, I only really started this morning, but I was thinking of a concept for a sequel to Dunjon II for some time. So after a few minutes I came up with the following mock-up screen:

Image

(**edit: moved original mockup screen from picpaste to imagehosting)

This is not final but will be a loose basis of how the finished game will look like. The upper left section shows the maze from a first-person perspective (ala Wizardry). You also see the monsters that you encounter (up to 16 of them), with the first letter of the monster name representing the individual ones The upper right section shows the party members. The middle right section shows the active/selected player's statistics and items. The middle left section shows the party's common items and supplies (gold, healing potions, ammunition and a group-wide spell or curse that is affecting everyone in the party). The bottom section will be for scrolling text.

As with the first 2 versions of Dunjon, this is going to be a "generic RPG" where there's no specific quest--you pretty much wander in the dungeon hunting for some orc and to find some cool magic items. And like it's predecessors, your characters tend to die a lot. But this time, you will adventure as a group so if someone does die, you just create a new character to replace him or her.

I will work within the following parameters:

-will be a game for the unexpanded VIC-20
-only PETSCII graphics
-save game feature
-lots of ML to speed up the display

Maybe I shouldn't put this out there only because 70% of the projects at this stage never actually get finished, but hopefully by making this announcement, it will give me motivation to see this through the end.
Last edited by Ghislain on Mon Nov 02, 2009 5:53 am, edited 7 times in total.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
orion70
VICtalian
Posts: 4337
Joined: Thu Feb 02, 2006 4:45 am
Location: Piacenza, Italy
Occupation: Biologist

Post by orion70 »

:D VERY WELL! I'm eager to try it- so please don't leave this project in the drawer.

The type of display reminds me of Ultima: escape from Mt. Drash.
That one was for 16K VIC, and probably yours will end up to be far less expensive :wink: .
User avatar
ral-clan
plays wooden flutes
Posts: 3702
Joined: Thu Jan 26, 2006 2:01 pm
Location: Canada

Post by ral-clan »

This looks great. I like the fact it's going to be for the unexpanded VIC.

Since it is PETSCII, could you please allow users to define the screen colours? I would love to run this game with a black background, black border and green text. It would feel like I was running it on a PET.
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

ral-clan wrote:This looks great. I like the fact it's going to be for the unexpanded VIC.

Since it is PETSCII, could you please allow users to define the screen colours? I would love to run this game with a black background, black border and green text. It would feel like I was running it on a PET.
Actually, the color schemes that I came up with are pretty close: black background, green border and white text.

I'm working on it now as we speak.

I'm trying to use as much ML as possible.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

Yesterday I got as far as preparing the display and created a routine that will clear a section of the screen (by passing coordinates, location, etc).

The next thing that I will work on is displaying the player stats. I've never done arithmetic in machine language before (aside from 1-byte numbers) and my RPG games have always involved a lot of numbers.

I was planning on using _some_ ML for this and I could take the easy way out by using BASIC, but I want the game to run as quickly as possible, especially when it comes to the display aspect of it.

So I'm not sure which one to use--BCD or standard hexadecimal. Both have their strong points and weak points. I'll probably use a combination of both.

I'm also thinking of changing the number of characters in a party from 6 to 4 -- only because I can save on memory as well as display space on the screen. As well, with 4 characters, I can easily fit them in one contiguous memory space between 828-1023 and thus save the game to and from disk.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Kweepa
Vic 20 Scientist
Posts: 1314
Joined: Fri Jan 04, 2008 5:11 pm
Location: Austin, Texas
Occupation: Game maker

Post by Kweepa »

I would choose non-BCD for a larger project. BCD is good when you want to optimise the number printing routine for space, but the savings slowly disappear when you have a lot of operations on different numbers, as you have to sed and cld around each operation.
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

If you don't fancy writing your own routines to convert a "hexadecimal" number to ASCII, there are some routines in the Basic ROM you can use with certain limitations (i.e. converting it to FAC FLPT format). See the sticky thread about ROM calls. I believe I used one of those when displaying the six digit score in Jewels.
Anders Carlsson

Image Image Image Image Image
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

Kweepa wrote:I would choose non-BCD for a larger project. BCD is good when you want to optimise the number printing routine for space, but the savings slowly disappear when you have a lot of operations on different numbers, as you have to sed and cld around each operation.
Are there kernel routines that I can borrow where I can just pass parameters to them and then it prints the values to the screen according to what is being passed? I just jotted down a routine on a piece of scrap paper that will print out a BCD value:

Code: Select all

;PRINT BCD VALUE
;parameters to pass: mem locations 1+2 start of memory where BCD resides
;mem location 3, length (in bytes) of number
;bcd flags turned off to convert numbers to printable ASCII chars

     ldy #0
loop1
     lda (1),y
     and #15
     clc
     ror
     ror
     ror
     ror
     adc (to a printable ASCII character)
     jsr $ffd2
     lda (1),y
     and #240
     adc (to a printable ASCII character)
     jsr $ffd2
     iny
     cpy $3 (compare mem location 3)
     bne loop1
     rts
I haven't typed this into the assembler yet and there's probably bugs in it, but you get the idea. It would probably be good to add some more code that takes out the leading zeros as well.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

carlsson wrote:If you don't fancy writing your own routines to convert a "hexadecimal" number to ASCII, there are some routines in the Basic ROM you can use with certain limitations (i.e. converting it to FAC FLPT format). See the sticky thread about ROM calls. I believe I used one of those when displaying the six digit score in Jewels.
Thanks for the tip ("ROM calls and other tricks"). I really should read these sticky threads more often.

There's no sense in me re-inventing the wheel so to speak. I just briefly glanced at the thread and I find the concept of a floating point accumulator very ingenious.

I'm a little bit behind in my ML programming skillz, I must admit.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

Assuming you simply want to print something to screen:

Code: Select all

   LDA score ; high byte
   LDY score+1 ; low byte
   JSR $D391
   JSR $DDD7
   RTS

score: .byte 7,208 ; 7 * 256 + 208 = 2000 points
It can't be much simpler than that.. only drawback is that $D391 will only accept values 0 - 32767 while your mockup uses values up to 99999.

Code: Select all

  3 * 256 + 232 =  1000
  7 * 256 + 208 =  2000
 15 * 256 + 160 =  4000
 31 * 256 +  64 =  8000
 62 * 256 + 128 = 16000
125 * 256 +   0 = 32000
Anders Carlsson

Image Image Image Image Image
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

carlsson wrote:It can't be much simpler than that.. only drawback is that $D391 will only accept values 0 - 32767 while your mockup uses values up to 99999.
Oh I plan on having values that go up to 999,999,999 (experience points). For that, I'll be using floating accumulators.

But being able to use 16 bit numbers will be very useful to print out almost everything else (STR, INT, WIS, hit points, etc).

After reading the sticky on those routines, I'm seriously considering making it all in ML. I'll have to dis-assemble some of the other routines such "Perform [exp]" at $DFED (source: http://www.zimmers.net/cbmpics/cbm/vic/rommap.txt) to figure out what needs to be passed to it, but I should be able to do it.

Making it in pure ML will probably take me 10 times as long as it normally would with BASIC but the end result will be worth it.

I've been using Turbo Assembler in a Commodore 64 emulator and then running the executable afterwards on a VIC-20 emulator. Rather than use a c64 emulator with TASS, is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
Royas
Vic 20 Amateur
Posts: 66
Joined: Fri Jan 30, 2009 6:22 pm

Post by Royas »

This looks awesome.

I wouldn't mind seeing user definable fore/background colors myself, since I like blue on green , and ... I dont think anyone else does.

8)

How will the character system be? Lots of classes/races?

and, I agree 4 characters should be good, and will be a different approach than the typical 6 in every CRPG ever made!
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
I swear by the cross-assembler in the cc65.org project. I currently use it on both Vista64 and Linux. On Linux, I don't even bother to compile the source, I just run the included win32 binaries using wine!

From the source, http://robert.hurst-ri.us/files/quikman2k8.s

Code: Select all

ca65.exe --cpu 6502 --listing quikman2k8.s
ld65.exe -C doc/vic20.cfg -o quikman2k8.prg quikman2k8.o
User avatar
Ghislain
Realms of Quest
Posts: 1279
Joined: Sun Aug 08, 2004 12:54 am

Post by Ghislain »

rhurst wrote:
is there a cross-compiler I can use in Linux that will create a .prg file that can then be loaded into a VIC-20 emulator?
I swear by the cross-assembler in the cc65.org project. I currently use it on both Vista64 and Linux. On Linux, I don't even bother to compile the source, I just run the included win32 binaries using wine!

From the source, http://robert.hurst-ri.us/files/quikman2k8.s

Code: Select all

ca65.exe --cpu 6502 --listing quikman2k8.s
ld65.exe -C doc/vic20.cfg -o quikman2k8.prg quikman2k8.o
I get the following error when I run ld65:

ld65: Error: vic20.cfg(6): Type expected

How does your vic20.cfg file look like?
"A slave is one who waits for someone to come and free him." -- Ezra Pound
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

You did not d/l the doc archive and unpack it? It includes the necessary doc/vic20.cfg (listed below) to assist in assigning memory:

Code: Select all

MEMORY {
    ZP: start =  $0002, size = $001A, type = rw, define = yes;
    RAM: start = $0FFF, size = $0E01, define = yes, file = %O;
}
SEGMENTS {
    STARTUP:  load = RAM, type = ro;
    LOWCODE:  load = RAM, type = ro,               optional = yes;
    INIT:     load = RAM, type = ro, define = yes, optional = yes;
    CODE:     load = RAM, type = ro;
    RODATA:   load = RAM, type = ro;
    DATA:     load = RAM, type = rw;
    BSS:      load = RAM, type = bss, define = yes;
    HEAP:     load = RAM, type = bss, optional = yes; # must sit just below stack
    ZEROPAGE: load = ZP,  type = zp;
}
FEATURES {
    CONDES: segment = INIT,
	    type = constructor,
	    label = __CONSTRUCTOR_TABLE__,
	    count = __CONSTRUCTOR_COUNT__;
    CONDES: segment = RODATA,
	    type = destructor,
	    label = __DESTRUCTOR_TABLE__,
	    count = __DESTRUCTOR_COUNT__;
    CONDES: segment = RODATA,
	    type = interruptor,
	    label = __INTERRUPTOR_TABLE__,
	    count = __INTERRUPTOR_COUNT__;
}
SYMBOLS {
    __STACKSIZE__ = $400;	# 1K stack
}
I modified this later when relocating my unexpanded code into $A000 to make a game cartridge out of it. I added this CART memory segment:

Code: Select all

    CART: start = $A000, size = $4000, type = ro, define = yes;
Post Reply