 |
Denial The Commodore Vic 20 Forum
|
| View previous topic :: View next topic |
| Author |
Message |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Sun Feb 08, 2009 8:04 am Post subject: **New Release** REALMS OF QUEST 3 (available for order!) |
|
|
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:
(**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. _________________ "A slave is one who waits for someone to come and free him." -- Ezra Pound
Last edited by Ghislain on Mon Nov 02, 2009 5:53 am; edited 7 times in total |
|
| Back to top |
|
 |
orion70 Vic 20 Guru

Joined: 02 Feb 2006 Posts: 1502 Location: Italy
|
Posted: Sun Feb 08, 2009 10:01 am Post subject: |
|
|
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 . |
|
| Back to top |
|
 |
ral-clan plays wooden flutes

Joined: 26 Jan 2006 Posts: 2948 Location: Ontario, Canada
|
Posted: Sun Feb 08, 2009 11:49 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Sun Feb 08, 2009 11:52 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Mon Feb 09, 2009 6:57 am Post subject: |
|
|
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 |
|
| Back to top |
|
 |
Kweepa Vic 20 Devotee

Joined: 04 Jan 2008 Posts: 297 Location: Austin, Texas
|
Posted: Mon Feb 09, 2009 8:27 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
carlsson Class of '6502

Joined: 10 Mar 2004 Posts: 5522 Location: Västerås, Sweden
|
Posted: Mon Feb 09, 2009 8:41 am Post subject: |
|
|
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
 |
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Mon Feb 09, 2009 8:58 am Post subject: |
|
|
| 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: | ;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 |
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Mon Feb 09, 2009 9:03 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
carlsson Class of '6502

Joined: 10 Mar 2004 Posts: 5522 Location: Västerås, Sweden
|
Posted: Mon Feb 09, 2009 10:41 am Post subject: |
|
|
Assuming you simply want to print something to screen:
| Code: | 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: | 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
 |
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Mon Feb 09, 2009 11:16 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
Royas Vic 20 Amateur

Joined: 30 Jan 2009 Posts: 66 Location: North Carolina (USA)
|
Posted: Mon Feb 09, 2009 12:32 pm Post subject: |
|
|
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.
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! |
|
| Back to top |
|
 |
rhurst Omega Star Commander

Joined: 31 Jan 2008 Posts: 690 Location: Providence, RI
|
Posted: Mon Feb 09, 2009 1:00 pm Post subject: |
|
|
| Quote: | | 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: | ca65.exe --cpu 6502 --listing quikman2k8.s
ld65.exe -C doc/vic20.cfg -o quikman2k8.prg quikman2k8.o
|
|
|
| Back to top |
|
 |
Ghislain Realms of Quest

Joined: 08 Aug 2004 Posts: 471 Location: Calgary, Alberta, Canada
|
Posted: Mon Feb 09, 2009 2:35 pm Post subject: |
|
|
| rhurst wrote: | | Quote: | | 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: | 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 |
|
| Back to top |
|
 |
rhurst Omega Star Commander

Joined: 31 Jan 2008 Posts: 690 Location: Providence, RI
|
Posted: Mon Feb 09, 2009 6:49 pm Post subject: |
|
|
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: | 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: | CART: start = $A000, size = $4000, type = ro, define = yes;
|
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|