Jump to content

Photo

Colossal Cave Adventure diary


243 replies to this topic

#51 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Mon Feb 6, 2012 12:58 PM

I have defined 14 new fonts :-)

I have attached the updated custom font file


what is still NOT WORKING is that If I add a tile I lost one more letter.... I can print only 23 custom chars... no matter what number I write in DEFINE_GRAM_BLOCK

for each new font I add I lost one letter at the end of the list...


Let me clarify something. Adding characters to the set means that you'll have to change the format word formula. Adding them at the top means you are offsetting the position of the "A" character (ASCII 65) down, which means that you have to add that number of cards to the base card.

Also, you'll need to change the total size of the GRAM block, so you need to alter the call to DEFINE_GRAM_BLOCK to include how many tiles you need.

Can you post the code that you use to define the GRAM block, to load it, and to display it? The "stats" seem to suggest that no GRAM is being used. That doesn't sound right, unless you are not loading the cards at the right point.

If you miss the VBLANK window, it may cause some of the data to not make it to GRAM. This is why it is important to do so in the initialization routines, while interrupts are disabled. There are even comments in the P-Machinery code suggesting what to do.

It'll be much easier if you posted some code. Also if you described the output or posted a screenshot of it.

-dZ.

Edited by DZ-Jay, Mon Feb 6, 2012 1:01 PM.


#52 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Mon Feb 6, 2012 1:33 PM

You referring to catsfolly post, not mine :-)
mine show 37 tiles used..

about code:

in p-match.asm
DEFINE_GRAM_BLOCK(font_belli, 37)

in st_title
LOAD_GRAM_BLOCK(LETTERS,font_belli)

in st_level
;; ======================================================================== ;;
;; LEVEL_TEST: show custom fonts ;;
;; ======================================================================== ;;
LEVEL_TEST PROC

BEGIN
CALL CLRSCR ; Clear the screen
CALL PRINT.FLS
DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200
STRING 'ABCDEFGHIJKLMNOPQRSTUVWXYZA'
DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $0250
STRING 'A@?=<;:9876543>'
BYTE 0
RETURN
ENDP



The 14 new fonts code is at the end of the post.
result is below: adding 14 custom tiles result in 14 chars disappearing (from J to Z)

even adding no new tiles, but just using DZj's 26 fonts from original LETTERS proc... I still write only 23 chars: X,Y and Z disappear!

Posted Image

;ASCII TO CUSTOM FONTS:
;@ = spazio OK
;? = ? OK
;> = > OK
;= = . OK
;< = , OK
;; = ] OK
;: = " OK
;9 = ' OK
;8 = ( OK
;7 = ) OK
;6 = / OK
;5 = 2 OK
;4 = 3 OK
;3 = disc OK

LETTERS PROC
@@data_start:

; Meant to represent Joypad DISC
; --------------------------------
; ........ - %00000000
DECLE $3C00 ; ..####.. - %01111100
; .######. - %11000110
DECLE $7E7E ; .######. - %11000110
; .######. - %11000110
DECLE $3C7E ; ..####.. - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; --------------------------------

; --------------------------------
; ........ - %00000000
DECLE $3C00 ; ..####.. - %01111100
; .....#.. - %11000110
DECLE $1C04 ; ...###.. - %11000110
; .....#.. - %11000110
DECLE $3C04 ; ..####.. - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; --------------------------------

; --------------------------------
; ........ - %00000000
DECLE $3C00 ; ..####.. - %01111100
; .....#.. - %11000110
DECLE $1C04 ; ...###.. - %11000110
; ..#..... - %11000110
DECLE $3C20 ; ..####.. - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; --------------------------------


; --------------------------------
; ........ - %00000000
DECLE $0400 ; .....#.. - %01111100
; ....#... - %11000110
DECLE $1008 ; ...#.... - %11000000
; ..#..... - %11000110
DECLE $4020 ; .#...... - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000


; --------------------------------
; ........ - %00000000
DECLE $0800 ; ....#... - %01111100
; .....#.. - %11000110
DECLE $0404 ; .....#.. - %11000000
; .....#.. - %11000110
DECLE $0804 ; ....#... - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000



; --------------------------------
; ........ - %00000000
DECLE $1000 ; ...#.... - %01111100
; ..#..... - %11000110
DECLE $2020 ; ..#..... - %11000000
; ..#..... - %11000110
DECLE $1020 ; ...#.... - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000


; --------------------------------
; ........ - %00000000
DECLE $1000 ; ...#.... - %11111100
; ...#.... - %11000110
DECLE $0010 ; ........ - %11111100
; ........ - %11000110
DECLE $0000 ; ........ - %11111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000

; --------------------------------
; ........ - %00000000
DECLE $2800 ; ..#.#... - %11111100
; ..#.#... - %11000110
DECLE $0028 ; ........ - %11111100
; ........ - %11000110
DECLE $0000 ; ........ - %11111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000



; --------------------------------
; ####.... - %00000000
DECLE $30F0 ; ..##.... - %01111100
; ..##.... - %11000110
DECLE $3030 ; ..##.... - %11000110
; ..##.... - %11000110
DECLE $F030 ; ####.... - %01111100
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; --------------------------------


; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ...##... - %00000000
DECLE $1818 ; ...##... - %00000000
; ....#... - %00000000
DECLE $0008 ; ........ - %00000000



; --------------------------------
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ...##... - %00000000
DECLE $1818 ; ...##... - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000

; --------------------------------
; ..#..... - %00000000
DECLE $3020 ; ..##.... - %00000000
; ..###... - %00000000
DECLE $3C38 ; ..####.. - %00000000
; ..###... - %00000000
DECLE $3038 ; ..##.... - %00000000
; ..#..... - %00000000
DECLE $0020 ; ........ - %00000000

; --------------------------------
; ..###... - %00000000
DECLE $4438 ; .#...#.. - %00000000
; ....##.. - %00000000
DECLE $100C ; ...#.... - %00000000
; ........ - %00000000
DECLE $1000 ; ...#.... - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000

; --------------------------------
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; ........ - %00000000
DECLE $0000 ; ........ - %00000000


@@A: ; GRAM Tile: 0
; --------------------------------
; ........ - %00000000
DECLE $3800 ; ..###... - %00111000
; .##.##.. - %01101100
DECLE $C66C ; ##...##. - %11000110
; #######. - %11111110
DECLE $C6FE ; ##...##. - %11000110
; ........ - %00000000
DECLE $0000 ; ........ - %00000000
; --------------------------------

etc...
etc...

Edited by vprette, Mon Feb 6, 2012 1:59 PM.


#53 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Mon Feb 6, 2012 1:56 PM

You referring to catsfolly post, not mine :-)
mine show 37 tiles used..


Oops! Sorry.

I'll check it when I get home from work tonight.

-dZ.

#54 catsfolly OFFLINE  

catsfolly

    Moonsweeper

  • 494 posts
  • Location:Japan

Posted Mon Feb 6, 2012 3:48 PM

You referring to catsfolly post, not mine :-)
mine show 37 tiles used..

about code:

in p-match.asm
DEFINE_GRAM_BLOCK(font_belli, 37)

in st_title
LOAD_GRAM_BLOCK(LETTERS,font_belli)

in st_level
;; ======================================================================== ;;
;; LEVEL_TEST: show custom fonts ;;
;; ======================================================================== ;;
LEVEL_TEST PROC

BEGIN
CALL CLRSCR ; Clear the screen
CALL PRINT.FLS
DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200
STRING 'ABCDEFGHIJKLMNOPQRSTUVWXYZA'
DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $0250
STRING 'A@?=<;:9876543>'
BYTE 0
RETURN
ENDP



The 14 new fonts code is at the end of the post.
result is below: adding 14 custom tiles result in 14 chars disappearing (from J to Z)

even adding no new tiles, but just using DZj's 26 fonts from original LETTERS proc... I still write only 23 chars: X,Y and Z disappear!

Posted Image

;ASCII TO CUSTOM FONTS:
;@ = spazio OK
;? = ? OK
;> = > OK
;= = . OK
;< = , OK
;; = ] OK
;: = " OK
;9 = ' OK
;8 = ( OK
;7 = ) OK
;6 = / OK
;5 = 2 OK
;4 = 3 OK
;3 = disc OK


I tried this and got similar results.
I found that if I moved the "LOAD_GRAM_BLOCK" to ST_LVL_INIT, it started to work...

			   CALL	STOPALLTASKS					;   1. Stop all tasks
				CALL	RESET_CTRL.Force				;   2. Reset Input Controller values
				CALL	RESET_STIC					  ;   3. Reset the STIC (clone) registers
				CALL	CLRSCR						  ;   4. Clear the screen

		   LOAD_GRAM_BLOCK(LETTERS,font_belli)

				CLRR	R0
				MVII	#PLAYER_INFO.Score,	 R4
...



But I don't know why this made a difference...

shot0000.gif

catsfolly

#55 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Mon Feb 6, 2012 4:11 PM

I tried this and got similar results.
I found that if I moved the "LOAD_GRAM_BLOCK" to ST_LVL_INIT, it started to work...

			   CALL	STOPALLTASKS					;   1. Stop all tasks
				CALL	RESET_CTRL.Force				;   2. Reset Input Controller values
				CALL	RESET_STIC					  ;   3. Reset the STIC (clone) registers
				CALL	CLRSCR						  ;   4. Clear the screen

		   LOAD_GRAM_BLOCK(LETTERS,font_belli)

				CLRR	R0
				MVII	#PLAYER_INFO.Score,	 R4
...



But I don't know why this made a difference...


First of all, in P-Machinery you should load GRAM on the initialization step of the state that you will use. This allows you to use different graphics characters for the title screen and for the game.

Second, it should have work in ST_TTL_INIT, but I think I just saw an error in P-Machinery. You need to remove the macro "ISR_ENABLE_DISPLAY" from the top of that procedure.

That's the problem. Let me explain.

Access to GRAM is restricted during what is called the VBLANK period, which is when the electron gun of the TV set is being realigned back to the top of the screen to draw a new frame. Also called vertical retrace. This period is rather short and is only available at the very beginning of an ISR, which is the handler of the hardware interrupt request for VBLANK.

Loading that many characters into GRAM takes so many cycles that there is not enough time to finish before VBLANK expires, and access to GRAM is locked out by the STIC (video chip). You don't get an error, but all reads or writes to GRAM will just be ignored.

However, the STIC only locks out the GRAM bus while the display is active (so that it can read graphics data to draw a frame for the video signal). Your code can take advantage of this fact and disable the display during an ISR routine, and then you have full and unrestricted access to GRAM--until the next VBLANK interrupt request arrives. It is then typical for initialization routines to not only disable the display, but to disable interrupts while loading data into GRAM.

By default, display will not be enabled until you write to a specific STIC register, so disabling display is as simple as not writing to that register during an ISR.

P-Machinery initialization routines are supposed to do this, except for one stupid error in the ST_TTL_INIT routine: the macro ISR_ENABLE_DISPLAY, which does what it says. That means that VBLANK will still expire as normal, and the STIC will assert control of the GRAM bus.

If you notice, ST_LVL_INIT doesn't have that macro, this is why it worked there.

I guess I didn't test custom GRAM graphics in the title screen in P-Machinery (for that matter, neither in Christmas Carol, which is why I didn't notice). Sorry about that.

-dZ.

Edited by DZ-Jay, Mon Feb 6, 2012 4:20 PM.


#56 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Mon Feb 6, 2012 4:13 PM

Catsfolly,

By the way, that explanation was intended for Valter. You probably already know about VBLANK and ISRs and enabling active display.

#57 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Mon Feb 6, 2012 4:22 PM

Below is the updated version of ST_TTL_INIT as it will appear in P-Machinery from now on. The only difference is the removal of the ISR_ENABLE_DISPLAY macro.

I also moved the state transition to the bottom, but this is inconsequential. It was just to be consistent with the other initialization routines.


;; ======================================================================== ;;
;;  ST_TTL_INIT:  ISR routine to initialize the game environment.           ;;
;; ======================================================================== ;;
ST_TTL_INIT     PROC
                DIS     ; Start Critical Section

                CLRR    R0                              ; \_ Reset horizontal delay to zero
                MVO     R0,     STIC.h_delay            ; /

                ; --------------------------------------
                ; This is a good point to clear the screen
                ; and initialize background colours if
                ; using a custom Title Screen.
                ;
                ; We don't really draw the title screen
                ; here, we just initialize the environment.
                ; This includes loading graphics into
                ; GRAM, setting colours, initializing
                ; the STIC and all that boring back-end
                ; stuff.
                ;
                ; Staggering the tasks this way allows us
                ; to separate initializing (which should
                ; only happen once) and actually engaging
                ; the title screen (which could recur).
                ; --------------------------------------
                                                        ; Initialize environment for new game state
                CALL    STOPALLTASKS                    ;   1. Reset the task queue
                CALL    RESET_CTRL.Force                ;   2. Reset Input Controller values
                CALL    RESET_STIC                      ;   3. Reset the STIC (clone) registers
                ; CALL    CLRSCR                          ;   4. Clear the screen.

                MVII    #(TASK.Delay + 1),      R0      ; \_ Activate the default task
                MVO     R0,     TSKACT                  ; /     (this is used for delay timers and such)

                ; Interrupts are enabled on return
                SET_GAME_STATE(TITLE, Start, cNormal)   ; Change states
                IRET
                ENDP


#58 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Tue Feb 7, 2012 3:41 AM

thanks as usual, it works now :-)

since I'm practising with gram, I'd like to tentativley introduce a graphic screen.
I have 2 pictures 160x72 to be used as welcome screen and final score screen...that means 180 tiles... what docs do I need to read to understand how to populate the screen? is there any developer tool to automatically convert a picture to decles?

Attached Files


Edited by vprette, Tue Feb 7, 2012 3:48 AM.


#59 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,938 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 7, 2012 4:46 AM

Large screens need to be made up from repeated tiles. For example, if you had bricks in the picture you would create one GRAM card of some bricks and use it several times. If you had a border like a picture frame you could use the same GRAM card for the left and right sides and another GRAM card for the top and bottom. There are also a selection of shapes in GROM. If you can use GROM cards you'll need less of the GRAM cards.

#60 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,938 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 7, 2012 4:50 AM

What are the XMP files in that *.zip? Can you convert them to *.bmp, *.gif or *.png format?

#61 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Tue Feb 7, 2012 5:18 AM

What are the XMP files in that *.zip? Can you convert them to *.bmp, *.gif or *.png format?


here

Attached Thumbnails

  • graphic_intro.gif
  • graphic_end.gif


#62 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,938 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 7, 2012 5:40 AM

When I zoom into the forest scene there are lots of artefacts (graphical junk). There are also 8x8 tiles that have more than 2 colours in them. so they would need MOB overlays. With quite a bit of work you could convert the images into Inty format. However, the conversions will lose some of the details so the images on the Inty wouldn't look exactly like those bitmaps.

#63 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 5:41 AM

thanks as usual, it works now :-)

since I'm practising with gram, I'd like to tentativley introduce a graphic screen.
I have 2 pictures 160x72 to be used as welcome screen and final score screen...that means 180 tiles... what docs do I need to read to understand how to populate the screen? is there any developer tool to automatically convert a picture to decles?


You should read the Wiki and the documentation on the BACKTAB. The document "stic.txt" included with the SDK-1600 should be a good start.

The basic thing to know is that you do not "draw" on the screen as in other computers, but use GRAM cards to make the pictures. So you'll have to design your graphics as "tiles," load them into GRAM, and then assign the tiles and their colours to the BACKTAB, or Background Table.

Another important thing to remember is that there is very limited colour. Each tile can only use two colours: a Foreground and a Background colour. One of the pictures you sent looks like it may be too colourful for the Intellivision.

I personally don't know of any automated tools for tiling pictures for the BACKTAB. In my games so far I've done it by hand. I "draw" the picture in an ASCII file with colour attributes as symbols, and wrote a Perl script to convert it into GRAM tiles and BACKTAB data words. However, these are rather specific to the requirements of my games.

-dZ.

Edited by DZ-Jay, Tue Feb 7, 2012 6:02 AM.


#64 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 5:42 AM

What are the XMP files in that *.zip? Can you convert them to *.bmp, *.gif or *.png format?


I think it's the native format for GIMP.

#65 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,938 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 7, 2012 5:45 AM

It would be much easier to have a forest that looked like the one in the first Smurf games :-

http://www.notmydesk...urf_rescue.html

#66 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 7,938 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 7, 2012 5:46 AM

I think it's the native format for GIMP.


Thanks for that. I'm not a GIMP user.

#67 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Tue Feb 7, 2012 5:57 AM

Update

- TITLE SCREEN: ok (custom screen)
- INTRO: ok (welcome message)
- INIT: ok (integrate tracker and start music)
- FONT: ok (custom)
- CONTENTS: insert all level message text descriptions 20%
- MUSIC: translate mod to decles
- PLAY ENGINE1: implement level to level to show several text description when pushing the disc or a key (like pages of a book)
- PLAY ENGINE2: implement inputs from keypad (8 directions, music pause and disc touch)
- PLAY ENGINE3: implement text input from keyboard
- PLAY ENGINE4 : implement level logic
- PLAY ENGINE5: implement the parser to reconnaise text commands inserted
- SCORE: implement scoring
- BOX: 80%
- OVERLAYS:
- MANUAL: 5%

Overall: 10%

this is the improvements thanks to the custom fonts :-) also I finalized the input interface bottom of the screen

Posted Image

Edited by vprette, Tue Feb 7, 2012 6:02 AM.


#68 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 6:11 AM

Update

- TITLE SCREEN: ok (custom screen)
- INTRO: ok (welcome message)
- INIT: ok (integrate tracker and start music)
- FONT: ok (custom)
- CONTENTS: insert all level message text descriptions 20%
- MUSIC: translate mod to decles
- PLAY ENGINE1: implement level to level to show several text description when pushing the disc or a key (like pages of a book)
- PLAY ENGINE2: implement inputs from keypad (8 directions, music pause and disc touch)
- PLAY ENGINE3: implement text input from keyboard
- PLAY ENGINE4 : implement level logic
- PLAY ENGINE5: implement the parser to reconnaise text commands inserted
- SCORE: implement scoring
- BOX: 80%
- OVERLAYS:
- MANUAL: 5%

Overall: 10%

this is the improvements thanks to the custom fonts :-) also I finalized the input interface bottom of the screen

Posted Image


Wow, it looks nice! Much more legible :)
They're a bit squashed, though. Those are a very old set I played with once. Let me see if I find the long ones.

-dZ.

Edited by DZ-Jay, Tue Feb 7, 2012 6:13 AM.


#69 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Tue Feb 7, 2012 6:57 AM

I start working on the user input: the simpliest one is catching the disc pressure on the joypad, this is used to move from a page to another when text description is more than one page.... I was thinking about study the handdemo.asm in the sdk1600, unless you suggest a better code to look at...

in p-machinery it seems I should use
SET_GAME_STATE(LEVEL, wait, cNormal) or similar....

Edited by vprette, Tue Feb 7, 2012 7:32 AM.


#70 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 7:40 AM

I start working on the user input: the simpliest one is catching the disc pressure on the joypad, this is used to move from a page to another when text description is more than one page.... I was thinking about study the handdemo.asm in the sdk1600, unless you suggest a better code to look at...


There's code already provided in P-Machinery. Just take a look at the demo.

There are three controller decoders provided in the framework.
  • CTRL_CHECKANY - Triggers an event when any input is received. Good for "Press any key" situations, like the title screen.
  • CTRL_CHECKKEY - Triggers an event for each type of input received, keypad, disc, or action button.
  • CTRL_GAMEPLAY - Triggers an event when disc input is received, treating the disc as a 4-way joystick.

In P-Machinery, you assign which decoder your want to use for each machine sub-state in the GAME_STATE_DISP dispatch table defined in "st_dispatch.asm". This table defines all sub-states (up to 8 per main state. Main states are by default "Title," "Level," and "Game-Over." Sub-states are, for instance, "Title-init," "Title-start," "Title-end.")

The States and Sub-States are defined in the "state.const" file. For the moment just leave the defaults and we'll discuss new states later.

Let's consider the "Level" (Game-Play) state. It has 6 sub-states:

                ; STATE: Level
DEFINE_ENUM(GST_LEVEL, <img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_cool.gif' class='bbc_emoticon' alt='8)' />
    ADD_ENUM_ELEMENT(Init   )
    ADD_ENUM_ELEMENT(Wait   )
    ADD_ENUM_ELEMENT(Play   )
    ADD_ENUM_ELEMENT(Retry  )
    ADD_ENUM_ELEMENT(Death  )
    ADD_ENUM_ELEMENT(Done   )
END_ENUM

If you check the default dispatch table for that state in "st_dispatch.asm" you'll see how each one is mapped to a handler routine in "st_level.asm":

                ; ------------------------------------------
                ; STATE: Level
                ; ------------------------------------------
                ;       State:                  Controller:     Dispatch:
                ;       --------------------    -----------     -----------
@@__level:      DECLE   ST_LVL_INIT,            CTRL_NONE,      NO_DISP
                DECLE   ST_WAIT_ENGINE,         CTRL_NONE,      NO_DISP
                DECLE   ST_LVL_PLAY,            CTRL_GAMEPLAY,  TEST_INPUT
                DECLE   ST_LVL_RETRY,           CTRL_NONE,      NO_DISP
                DECLE   ST_LVL_DEATH,           CTRL_NONE,      NO_DISP
                DECLE   ST_LVL_DONE,            CTRL_NONE,      NO_DISP
                DECLE   @@__dead,               CTRL_NONE,      NO_DISP
                DECLE   @@__dead,               CTRL_NONE,      NO_DISP


They are defined in order, so "Init" maps to "ST_LVL_INIT," "Wait" maps to ST_WAIT_ENGINE, "Play" maps to "ST_LVL_PLAY," etc.

Each record in the dispatch table is composed of three fields: The state handler routine, the controller decoder, and the decoder event handler required for the decoder. If no decoder is used for a state, it is mapped to "CTRL_NONE," which does nothing.

Notice that by default, the "Play" sub-state (ST_LVL_PLAY) is assigned the decoder CTRL_GAMEPLAY, with TEST_INPUT as the event handler. This means that during this state, P-Machinery will use the "joystick" disc decoder and call the TEST_INPUT when a disc event is detected.

The routine TEST_INPUT is the one that displays "up," "down," "right," and "left" in the demo.

That is a fine routine for arcade games like Pac-Man and Christmas Carol, but for your purpose you may want to change it to the general CTRL_CHECKKEY, which triggers and event for disc and other input.

So you would change it like this:


                ; ------------------------------------------
                ; STATE: Level
                ; ------------------------------------------
                ;       State:                  Controller:     Dispatch:
                ;       --------------------    -----------     -----------
@@__level:      DECLE   ST_LVL_INIT,            CTRL_NONE,      NO_DISP
                DECLE   ST_WAIT_ENGINE,         CTRL_NONE,      NO_DISP

                DECLE   ST_LVL_PLAY,            CTRL_CHECKKEY,  MY_INPUT    ; New decoder and event handler.

                DECLE   ST_LVL_RETRY,           CTRL_NONE,      NO_DISP
                DECLE   ST_LVL_DEATH,           CTRL_NONE,      NO_DISP
                DECLE   ST_LVL_DONE,            CTRL_NONE,      NO_DISP
                DECLE   @@__dead,               CTRL_NONE,      NO_DISP
                DECLE   @@__dead,               CTRL_NONE,      NO_DISP

Checking the documentation comments in CTRL_CHECKKEY, it says that instead of a straight event-handler, it expects a dispatch table defining the individual handlers for each of the input:

;;  DISPATCHER:                                                             ;;
;;  This routine expects a dispatch table of the following format:          ;;
;;                                                                          ;;
;;      DISP_TBL:   DECLE   keypad_handler                                  ;;
;;                  DECLE   action_handler                                  ;;
;;                  DECLE   disc_handler                                    ;;

So, you can implement "MY_INPUT" (or whatever you want to call it) like this:


;; ======================================================================== ;;
;;  Input Event Dispatch Table.                                             ;;
;; ======================================================================== ;;
MY_INPUT        PROC
                ; --------------------------------------
                ; Event Dispatch Table
                ; --------------------------------------
                DECLE   IN_KEYPAD                       ; Key pad
                DECLE   IN_ACTION                       ; Action buttons
                DECLE   IN_DISC                         ; Disc
                ENDP

;; ======================================================================== ;;
;;  Input Event Handlers.                                                   ;;
;; ======================================================================== ;;
IN_KEYPAD       PROC
                BEGIN

                ; Handle keypad input

                RETURN
                ENDP

IN_ACTION       PROC
                BEGIN

                ; Handle action button input

                RETURN
                ENDP

IN_DISC         PROC
                BEGIN

                ; Handle disc input

                RETURN
                ENDP

That's just an example, of course.

Furthermore, in the documentation comments of the CTRL_CHECKKEY decoder, it explains what to expect for each event:

;;  The dispatched function will receive the class-specific decoded value   ;;
;;  in R2.  Below is a list of the values grouped by input class:           ;;
;;                                                                          ;;
;;      KEYPAD:                                                             ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0 - 9   Digit 0 through Digit 9                                 ;;
;;          10      Clear                                                   ;;
;;          11      Enter                                                   ;;
;;                                                                          ;;
;;      ACTION BUTTON:                                                      ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0       Top action buttons                                      ;;
;;          1       Bottom-Left action button                               ;;
;;          2       Bottom-Right action button                              ;;
;;                                                                          ;;
;;      DISC:                                                               ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0       Up                                                      ;;
;;          1       Right                                                   ;;
;;          2       Down                                                    ;;
;;          3       Left                                                    ;;

Convenient symbols are defined in the "ctrl.const" file for each of these, so you can use labels instead of memorizing these codes. For instance, if you want to check whether the "Right" direction was pressed, you could do something like this:

IN_DISC         PROC
                BEGIN

                ; Handle disc input
                CMPI  #CTRL_DISC.Right, R2
                BEQ  @@right

                ; Not right..

@@right:     ; handle "right" direction

                RETURN
                ENDP

I hope this helps.

-dZ.

Edited by DZ-Jay, Tue Feb 7, 2012 7:58 AM.


#71 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 7:44 AM

Valter,

I just noticed that the CTRL_CHECKKEY decoder treats the disc as only 4-way. This is mainly because that's what I needed for the practice menu screen in Christmas Carol. I should offer another option for the full 16 directions. But I don't think you need that right now, right?

Also, as you may imagine, anybody can write their own decoder routines (as long as they follow the In/Out interface used by P-Machinery), and assign them in the state dispatch table. That way, P-Machinery is very extensible.

-dZ.

Edited by DZ-Jay, Tue Feb 7, 2012 7:45 AM.


#72 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 7:50 AM

Valter,

I just noticed that the CTRL_CHECKKEY decoder treats the disc as only 4-way. This is mainly because that's what I needed for the practice menu screen in Christmas Carol. I should offer another option for the full 16 directions. But I don't think you need that right now, right?

Also, as you may imagine, anybody can write their own decoder routines (as long as they follow the In/Out interface used by P-Machinery), and assign them in the state dispatch table. That way, P-Machinery is very extensible.

-dZ.


By the way, there is a difference between the disc event CTRL_CHECKEY and the one in CTRL_GAMEPLAY. The one in CTRL_CHECKKEY just assigns the cardinal points on the disc directly the directions, therefore it has "dead-zones" when you hit the disc diagonally. It also has "de-bouncing" and "de-noising" algorithms, based on those in SCANHAND in the SDK-1600.

CTRL_GAMEPLAY has heuristics to allow the player to roll his thumb across the disc and attempts to discern the intended direction. This is the decoder used in Christmas Carol during level game-play. It is also optimized to only detect disc input and work very fast by forgoing de-bouncing.

-dZ.

#73 vprette OFFLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,175 posts

Posted Tue Feb 7, 2012 10:22 AM

I try to put some order in my mind :-)

1- the state "Title" I do not touch
"Level" is there I have to define handlers
"Game-Over" is where maybe I have to put the final score, for the moment I do not care
So I work only on the "level state

2- in st_dispatch.asm I define sublevels of "level"
I do not need retry nor death since were is not a player death, so I would delete that, right?
; STATE: Level
DEFINE_ENUM(GST_LEVEL, 8 )
ADD_ENUM_ELEMENT(Init )
ADD_ENUM_ELEMENT(Wait )
ADD_ENUM_ELEMENT(Play )
ADD_ENUM_ELEMENT(Done )
END_ENUM


after I have to delete corresponding handlers map in st_dispatch.asm

; ------------------------------------------
; STATE: Level
; ------------------------------------------
; State: Controller: Dispatch:
; -------------------- ----------- -----------
@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP
DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP
DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT
DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP


now in st_level I erase old procedure TEST_INPUT and put this one:

;; ======================================================================== ;;
;; Input Event Dispatch Table. ;;
;; ======================================================================== ;;
MY_INPUT PROC
; --------------------------------------
; Event Dispatch Table
; --------------------------------------
DECLE IN_KEYPAD ; Key pad
DECLE IN_ACTION ; Action buttons
DECLE IN_DISC ; Disc
ENDP

;; ======================================================================== ;;
;; Input Event Handlers. ;;
;; ======================================================================== ;;
IN_KEYPAD PROC
BEGIN

; Handle keypad input

RETURN
ENDP

IN_ACTION PROC
BEGIN

; Handle action button input

RETURN
ENDP

IN_DISC PROC
BEGIN


; Handle disc input
CMPI #CTRL_DISC.Right, R2
BEQ @@right

; Not right..

@@right: ; handle "right" direction
CALL PRINT.FLS
DECLE C_YEL, $02DD+1
STRING 'Disc to the right'
BYTE 0


RETURN
ENDP


there is a code for testing the right disc pressure...

now the first issue:
If I understood the 3 decoders are
- CTRL_CHECKANY that I do not care during level state
- CTRL_CHECKKEY to define separately each key of the joypad
- CTRL_GAMEPLAY that only define the disc

in my case I need to use CTRL_CHECKKEY since I want to map: disc,1,2,3,4,6,7,8,9,clear

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!

Edited by vprette, Tue Feb 7, 2012 10:37 AM.


#74 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 11:25 AM

I try to put some order in my mind :-)

1- the state "Title" I do not touch
"Level" is there I have to define handlers
"Game-Over" is where maybe I have to put the final score, for the moment I do not care
So I work only on the "level state

2- in st_dispatch.asm I define sublevels of "level"
I do not need retry nor death since were is not a player death, so I would delete that, right?
; STATE: Level
DEFINE_ENUM(GST_LEVEL, 8 )
ADD_ENUM_ELEMENT(Init )
ADD_ENUM_ELEMENT(Wait )
ADD_ENUM_ELEMENT(Play )
ADD_ENUM_ELEMENT(Done )
END_ENUM


after I have to delete corresponding handlers map in st_dispatch.asm

; ------------------------------------------
; STATE: Level
; ------------------------------------------
; State: Controller: Dispatch:
; -------------------- ----------- -----------
@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP
DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP
DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT
DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP
DECLE @@__dead, CTRL_NONE, NO_DISP


now in st_level I erase old procedure TEST_INPUT and put this one:

;; ======================================================================== ;;
;; Input Event Dispatch Table. ;;
;; ======================================================================== ;;
MY_INPUT PROC
; --------------------------------------
; Event Dispatch Table
; --------------------------------------
DECLE IN_KEYPAD ; Key pad
DECLE IN_ACTION ; Action buttons
DECLE IN_DISC ; Disc
ENDP

;; ======================================================================== ;;
;; Input Event Handlers. ;;
;; ======================================================================== ;;
IN_KEYPAD PROC
BEGIN

; Handle keypad input

RETURN
ENDP

IN_ACTION PROC
BEGIN

; Handle action button input

RETURN
ENDP

IN_DISC PROC
BEGIN


; Handle disc input
CMPI #CTRL_DISC.Right, R2
BEQ @@right

; Not right..

@@right: ; handle "right" direction
CALL PRINT.FLS
DECLE C_YEL, $02DD+1
STRING 'Disc to the right'
BYTE 0


RETURN
ENDP


there is a code for testing the right disc pressure...

now the first issue:
If I understood the 3 decoders are
- CTRL_CHECKANY that I do not care during level state
- CTRL_CHECKKEY to define separately each key of the joypad
- CTRL_GAMEPLAY that only define the disc

in my case I need to use CTRL_CHECKKEY since I want to map: disc,1,2,3,4,6,7,8,9,clear

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!


Strange, the changes you described seem correct. Does it give an error when assembling, or does it just crash during execution? I'll test over here and see what I find.

-dZ.

#75 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 5,143 posts
  • Ranger Elf: Saviour of Christmas!
  • Location:NC, USA

Posted Tue Feb 7, 2012 11:41 AM

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!


Stranger still, it works when I tried it. There's only one stupid bug in the sample code I gave you: there is no code for pressing a direction other than "right," so it falls through to the same "Disc to the right" message.

But other than that, it worked here. Are you sure you made the changes in the right place?

-dZ.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users