Denial Forum Index Denial
The Commodore Vic 20 Forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

**New Release** REALMS OF QUEST 3 (available for order!)
Goto page 1, 2, 3 ... 48, 49, 50  Next
 
Post new topic   Reply to topic    Denial Forum Index -> Games
View previous topic :: View next topic  
Author Message
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Sun Feb 08, 2009 8:04 am    Post subject: **New Release** REALMS OF QUEST 3 (available for order!) Reply with quote

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
View user's profile Send private message Visit poster's website
orion70
Vic 20 Guru


Joined: 02 Feb 2006
Posts: 1502
Location: Italy

PostPosted: Sun Feb 08, 2009 10:01 am    Post subject: Reply with quote

Very Happy 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 .
Back to top
View user's profile Send private message
ral-clan
plays wooden flutes


Joined: 26 Jan 2006
Posts: 2948
Location: Ontario, Canada

PostPosted: Sun Feb 08, 2009 11:49 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Sun Feb 08, 2009 11:52 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Mon Feb 09, 2009 6:57 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Kweepa
Vic 20 Devotee


Joined: 04 Jan 2008
Posts: 297
Location: Austin, Texas

PostPosted: Mon Feb 09, 2009 8:27 am    Post subject: Reply with quote

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
View user's profile Send private message
carlsson
Class of '6502


Joined: 10 Mar 2004
Posts: 5522
Location: Västerås, Sweden

PostPosted: Mon Feb 09, 2009 8:41 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Mon Feb 09, 2009 8:58 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Mon Feb 09, 2009 9:03 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
carlsson
Class of '6502


Joined: 10 Mar 2004
Posts: 5522
Location: Västerås, Sweden

PostPosted: Mon Feb 09, 2009 10:41 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Mon Feb 09, 2009 11:16 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Royas
Vic 20 Amateur


Joined: 30 Jan 2009
Posts: 66
Location: North Carolina (USA)

PostPosted: Mon Feb 09, 2009 12:32 pm    Post subject: Reply with quote

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.

Cool

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
View user's profile Send private message
rhurst
Omega Star Commander


Joined: 31 Jan 2008
Posts: 690
Location: Providence, RI

PostPosted: Mon Feb 09, 2009 1:00 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Ghislain
Realms of Quest


Joined: 08 Aug 2004
Posts: 471
Location: Calgary, Alberta, Canada

PostPosted: Mon Feb 09, 2009 2:35 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
rhurst
Omega Star Commander


Joined: 31 Jan 2008
Posts: 690
Location: Providence, RI

PostPosted: Mon Feb 09, 2009 6:49 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Denial Forum Index -> Games All times are GMT - 6 Hours
Goto page 1, 2, 3 ... 48, 49, 50  Next
Page 1 of 50

 
Jump to:  
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