Page 1 of 50

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

Posted: Sun Feb 08, 2009 8:04 am
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.

Posted: Sun Feb 08, 2009 10:01 am
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: .

Posted: Sun Feb 08, 2009 11:49 am
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.

Posted: Sun Feb 08, 2009 11:52 am
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.

Posted: Mon Feb 09, 2009 6:57 am
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.

Posted: Mon Feb 09, 2009 8:27 am
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.

Posted: Mon Feb 09, 2009 8:41 am
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.

Posted: Mon Feb 09, 2009 8:58 am
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.

Posted: Mon Feb 09, 2009 9:03 am
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.

Posted: Mon Feb 09, 2009 10:41 am
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

Posted: Mon Feb 09, 2009 11:16 am
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?

Posted: Mon Feb 09, 2009 12:32 pm
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!

Posted: Mon Feb 09, 2009 1:00 pm
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

Posted: Mon Feb 09, 2009 2:35 pm
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?

Posted: Mon Feb 09, 2009 6:49 pm
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;