Jump to content
IGNORED

GET PAPI ! Collision TILE/SPRITE in 8 directions problem.


Vetea

Recommended Posts

Hello,

Thanks for your post.

Honestly, I understand the principe :

 

But I don't success to do what I want, nevermind. I keep my Card monochrome.

And I use IntyColor for screen.

Sorry, I misunderstood your issue. I will try to post an example in code of what you want to do and how to do it.

Link to comment
Share on other sites

No, I give some code example that what I do.

 

1/ I Create and configure my Mode CS

MODE SCREEN_CS, CS_GREEN,CS_WHITE,CS_GREY,CS_BLUE ' BG 0 : Green, 1 : WHITE, 2 : GREY, 3 : BLUE

2/ I've build my Card, store them in GRAM and make some Constant.

CONST MUR_H=$0800+13*8 '--> FG BLACK
CONST MUR_B=$0800+14*8 '--> FG BLACK
CONST MUR_D=$0800+15*8 '--> FG BLACK
CONST MUR_G=$0800+16*8 '--> FG BLACK
CONST SOL = $0804+17*8 '--> FG DARKGREEN
CONST MUR = $0800+18*8 '--> FG BLACK
CONST PORT= $800+23*8  '--> FG BLACK

Then I want to use the BG I configure in 1/ :

'Tableau de jeu
restore Map
for i=0 to 239
	read value
	if value=9 then #backtab(i)=0
	if value=17 then #backtab(i)=SOL
	if value=13 then #backtab(i)=MUR_H 
	if value=14 then #backtab(i)=MUR_B 
	if value=15 then #backtab(i)=MUR_D 
	if value=16 then #backtab(i)=MUR_G 
	if value=18 then #backtab(i)=MUR 
next

What I supposed to to ?

 

Use CS_ADVANCE ?

Ok Then I can Create a special CONST :

#CD = CS_ADVANCE

Then I try to use if to, for exemple, make a GREY BG on my "MUR"

if value=18 then #backtab(i)=#CS+MUR '?!

But I want to reach the Grey .. So I add #CS x2 ?

 

I'm feel like a big Newbie ... And I dev game since ... many years. That funny. :D

Link to comment
Share on other sites

The first thing you must know is that in Color Stack Mode you do not set the background color for each individual card, you use the "color stack" array. Your original question suggests that you were not aware of this.

 

First, you need to define your "color stack" array. Right now, you have this:

MODE SCREEN_CS, CS_GREEN, GREEN, GREEN,GREEN

Which means that it is all GREEN (actually, you should use STACK_GREEN for the stack array; CS_GREEN is for Color Stack foreground colors). For grey, you need to do something like this:

MODE SCREEN_CS, STACK_GREEN, STACK_GREY, STACK_GREEN, STACK_GREY

Notice that I alternate between green and grey. You could use more colours, but since you only specified grey and you are already using green, this is the easiest way to use the color stack. The reason is that you can only advance the array in sequence, so if you are in the first colour (green), and advance it to the second colour (grey), then advancing it once more will bring it back to green in the third colour, and so on.

 

Then, if you want a BACKTAB tile to have a grey background, just set its "advance" flag by adding 0x2000 to its card value, or use the constant CS_ADVANCE. For example:

CONST MUR = $0800+18*8 + CS_ADVANCE

Notice that, as I explained in my previous post, that this will cause all BACKTAB tiles after this one to continue using grey as the background colour. Since you only want it to be in one card, then you must set the "advance" flag on the next card as well. What this will do is move the color stack array pointer to the third colour, which happens to be green again, like the first. This is why we made it green, grey, green, grey; so that you can just advance twice to get one card grey.

 

If you have multiple cards using the MUR constant consecutively, then you only add the CS_ADVANCE constant to the first one you want green again.

 

Does this make sense at all?

 

-dZ.

Link to comment
Share on other sites

OK, I started writing my message before you posted and just finished it, so I missed this comment. Let me respond to it.

 

 

No, I give some code example that what I do.

 

1/ I Create and configure my Mode CS

MODE SCREEN_CS, CS_GREEN,CS_WHITE,CS_GREY,CS_BLUE ' BG 0 : Green, 1 : WHITE, 2 : GREY, 3 : BLUE

2/ I've build my Card, store them in GRAM and make some Constant.

CONST MUR_H=$0800+13*8 '--> FG BLACK
CONST MUR_B=$0800+14*8 '--> FG BLACK
CONST MUR_D=$0800+15*8 '--> FG BLACK
CONST MUR_G=$0800+16*8 '--> FG BLACK
CONST SOL = $0804+17*8 '--> FG DARKGREEN
CONST MUR = $0800+18*8 '--> FG BLACK
CONST PORT= $800+23*8  '--> FG BLACK

Then I want to use the BG I configure in 1/ :

'Tableau de jeu
restore Map
for i=0 to 239
	read value
	if value=9 then #backtab(i)=0
	if value=17 then #backtab(i)=SOL
	if value=13 then #backtab(i)=MUR_H 
	if value=14 then #backtab(i)=MUR_B 
	if value=15 then #backtab(i)=MUR_D 
	if value=16 then #backtab(i)=MUR_G 
	if value=18 then #backtab(i)=MUR 
next

What I supposed to to ?

 

Use CS_ADVANCE ?

Ok Then I can Create a special CONST :

#CD = CS_ADVANCE

Then I try to use if to, for exemple, make a GREY BG on my "MUR"

if value=18 then #backtab(i)=#CS+MUR '?!

But I want to reach the Grey .. So I add #CS x2 ?

 

I'm feel like a big Newbie ... And I dev game since ... many years. That funny. :D

 

No worries, Vetea, it's all good, you are cool. The Intellivision is very weird. :)

 

To advance the stack, you would do this:

if value=18 then #backtab(i)= MUR + CS_ADVANCE

However, that will advance from the first to the second color, which will make it white. Unfortunately, your color grey is on the third position in the stack array, so you need to advance it again on the next card. You can only advance the stack array in sequence. There are a few tricks you could do to fix this:

  • You can set your color stack with grey second, but you still have the same problem with the next color, unless you have only two, in which case you alternate (like I mentioned in my previous post).
  • you can use "reverse video" tricks to skip a stack array position.

 

To use "reverse video," consider it like this: Imagine you have a solid color background with green (stack color #0), now you want to skip white (stack color #1) to paint with grey (stack color #2).

  1. You set the CS_ADVANCE flag of the card before the one you want to change, which will turn its background white (stack color #1).
  2. Instead of leaving the card blank (solid background color) you use a GRAM card with all 8x8 pixels set (solid foreground color) and use green as the foreground color, essentially painting over the background and completely hiding the white.
  3. You set the CS_ADVANCE flag of the next card, which is the one you wanted, and now it will turn its background to grey (stack color #2).

After that you can do the whole thing again to switch back to green, or use blue (stack color #3), etc.

 

Does this help?

 

-dZ.

Link to comment
Share on other sites

I just have to say huge respect to you programmer guys that do these games,

 

I consider myself a fairly intelligent guy and decent at math, but I look at this stuff and my mind boggles.

 

And I think it's very cool how you all help each other here too.

 

My hat is off to you all, keep up the great work, the rest of us all appreciate it!

  • Like 1
Link to comment
Share on other sites

Ok you use a Buffer Card. I see ! ;)

That the tips to get the right BG color.

 

Yes, since you can only cycle the color stack array in order, using "reverse video" is the only way to "skip" cards. The Christmas Carol screen I posted earlier is full of those things. For instance, a couple of the letters in the title were actually complemented letter cards, where the 1s were 0s and vice versa, just to be able to reverse the background and foreground colours and allow me to skip ahead the stack to the next color. ;)

 

Lets test this tomorrow.

Thanks for your help and patience !

Cheers,

Vetea

 

Hey, now worries! It is my pleasure. :)

 

Bonne chance,

-dZ.

  • Like 1
Link to comment
Share on other sites

I just have to say huge respect to you programmer guys that do these games,

 

I consider myself a fairly intelligent guy and decent at math, but I look at this stuff and my mind boggles.

 

And I think it's very cool how you all help each other here too.

 

My hat is off to you all, keep up the great work, the rest of us all appreciate it!

 

Get Papi is a good game and Vetea seems to be a very good veteran programmer. What I've seen of the game seems very stable and well designed, and the source code is elegant and well organized. He just needs a little help getting past the Intellivision idiosyncratic quirks.

 

Since I already had my "baptism by fire" on Intellivision hardware quirks and limitations, I am only paying forward all the help I got from others. It's the least I can do. :)

 

Plus, now that all that crap is in my head, taking up precious space, and making me forget phone numbers and other stuff, what else am I going to do with it? :grin:

 

-dZ.

Link to comment
Share on other sites

Steve: Not all programmers are good at math on the other hand, so any skills in that area can be useful contributions even if you don't understand how to put it to code. In particular trigonometry and the various uses of it when it comes to jumps, bounces, gravity and much more, tends to be a black box to many of us programmers where help from someone with a math background helps. For instance the developer team behind the original Pinball Dreams had one guy solely on doing math and programming the engine for ball bounce at different angles and speeds, nothing else. Without it, the interest for that particular game would've faded quickly.

  • Like 1
Link to comment
Share on other sites

Vetea,

 

One last thing, please keep in mind that the color constants for the stack array is different from the color constants for the foreground colors, even if they are both for use in Color Stack mode.

REM -------------------------------------------------------------------------
REM COLORS - Mode 0 (Color Stack).
REM -------------------------------------------------------------------------
REM Stack
REM -------------------------------------------------------------------------
REM Note: For use as the last 4 parameters used in the "mode 1" command.
REM -------------------------------------------------------------------------
CONST STACK_BLACK                   = $0000
CONST STACK_BLUE                    = $0001
CONST STACK_RED                     = $0002
CONST STACK_TAN                     = $0003
CONST STACK_DARKGREEN               = $0004
CONST STACK_GREEN                   = $0005
CONST STACK_YELLOW                  = $0006
CONST STACK_WHITE                   = $0007
CONST STACK_GREY                    = $0008
CONST STACK_CYAN                    = $0009
CONST STACK_ORANGE                  = $000A
CONST STACK_BROWN                   = $000B
CONST STACK_PINK                    = $000C
CONST STACK_LIGHTBLUE               = $000D
CONST STACK_YELLOWGREEN             = $000E
CONST STACK_PURPLE                  = $000F

REM -------------------------------------------------------------------------
REM Foreground.
REM -------------------------------------------------------------------------
REM Notes:
REM - For use with "peek/poke" commands that access BACKTAB.
REM - Only one foreground colour permitted per background card.
REM -------------------------------------------------------------------------
CONST CS_BLACK                      = $0000
CONST CS_BLUE                       = $0001
CONST CS_RED                        = $0002
CONST CS_TAN                        = $0003
CONST CS_DARKGREEN                  = $0004
CONST CS_GREEN                      = $0005
CONST CS_YELLOW                     = $0006
CONST CS_WHITE                      = $0007
CONST CS_GREY                       = $1000
CONST CS_CYAN                       = $1001
CONST CS_ORANGE                     = $1002
CONST CS_BROWN                      = $1003
CONST CS_PINK                       = $1004
CONST CS_LIGHTBLUE                  = $1005
CONST CS_YELLOWGREEN                = $1006
CONST CS_PURPLE                     = $1007

Notice that the high colours for the CS_xxx constants (the ones for foreground) have the 0x1000 bit set, but not so for the STACK_xxx ones. This is because the BACKTAB word (like the MOB Attribute register) has the high colour bit separated.

 

Also, remember that grey is not part of the basic, lower 8 colours, so it can only work as the background on tiles with GRAM cards.

 

Yes, the Intellivision is very weird. Welcome! :dunce:

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

Hello,

Thanks dZ, your rescue help my friend who make "Maria" Rpg Nanochess talks in a topic ...

Yes the Hardware is weird, hehe. But its only the Hardware ...

 

Math and physics are everywhere, but there are many way to interpret an action, like bounce, gravity, etc ... The main goal is to reach the render you want even if you dont use classical equation.

That what I do when I dev my games. ;)

 

 

Lets go to test this fuc.... CS mode now, I have to success. ;)

Cheers,

Vetea

 

( hope I'm clear when you read my message, I dont want to use Google translate ... )

Edited by Vetea
  • Like 2
Link to comment
Share on other sites

Hello,

Thanks dZ, your rescue help my friend who make "Maria" Rpg Nanochess talks in a topic ...

 

I'm glad I could help. :)

 

Yes the Hardware is weird, hehe. But its only the Hardware ...

 

Yes, the console is very cool and has some good features, specifically the 8 independent MOBs. Plus, I hear that IntyBASIC makes it very easy and fun to program.

 

Math and physics are everywhere, but there are many way to interpret an action, like bounce, gravity, etc ... The main goal is to reach the render you want even if you dont use classical equation.

That what I do when I dev my games. ;)

 

I completely agree. Physics and maths are very important, but the most important part is making it feel right for the environment and scale you are aiming.

 

In fact, since I am so stupid at math and physics, I "faked" all my physics simulations in my game by just using tables and complex frame animations. I just tweaked them until they felt right. Not a single trigonometry computation was used -- I just didn't know how to do it. :dunce:

 

Even the sinuous path that the score numbers take as they float up when you pick up an item was done by drawing a sine wave on graph paper and writing the integer offsets on a table.

                ; -------------------------------------------------------------
                ; Look-up table for ondulating path delta.
                ;
                ;   NOTE: This table represents half the period of a sine wave,
                ;         the second half is a reflection of the first.
                ; -------------------------------------------------------------
@@__curve_tbl:  DECLE   +1          ; . . . : # . .
                DECLE    0          ; . . . # . . .
                DECLE   +1          ; . . . # . . .
                DECLE    0          ; . . # : . . .
                DECLE    0          ; . . # : . . .
                DECLE    0          ; . . # : . . .
                DECLE   +1          ; . . # : . . .
                DECLE    0          ; . # . : . . .
                DECLE    0          ; . # . : . . .
                DECLE    0          ; . # . : . . .
                DECLE    0          ; . # . : . . .
                DECLE    0          ; . # . : . . .
                DECLE   -1          ; . # . : . . .
                DECLE    0          ; . . # : . . .
                DECLE    0          ; . . # : . . .
                DECLE   -1          ; . . # : . . .
                ENDP                ; . . . # . . .

The rest is just fancy animation (which apparently I am good at). :)

 

 

Lets go to test this fuc.... CS mode now, I have to success. ;)

( hope I'm clear when you read my message, I dont want to use Google translate ... )

 

I understand it all, no worries. :)

 

-dZ.

Link to comment
Share on other sites

Ok I definitely forget the CS Mode ! That official.

 

Welcome to the Mode F/G !

 

Sans_titre.png?width=390&height=301

 

... But my Collision Engine doesn't work ... :D :D

OMG ...

 

EDIT : That Ok now ! Youpi ! :)

 

LOL! you should have sent an IntyColor screenshot before. If that is all you wanted to do, that would have been brain-dead easy in Color Stack. :P There's only three background colors there. I thought you were aiming to do a much more complex thing.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Ahah !!

No no, juste to change some CARD design with 2 colors ... That's ALL !!! :D :D

I find my way with the FG/BG color, it's the main goal for me. ;)

 

Thanks for your patience, support, etc ... ;)

Cheers,

Vetea

 

No worries. For that simple screen, FG/BG works fine. :)

 

Just so you know, some of the cards you are using exist in GROM. So if your scene was a lot more complex and required a lot more GRAM (which it doesn't seem it does now), the Color Stack could allow you to save some GRAM for more detail.

 

As it is, it is not necessary. I just don't want you to be afraid of Color Stack. Many people are and miss out on some very cool things that can be done. :)

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Hey !

 

I have one question :

When you create your assets/Gfx/Sprite

 

The use of DECLES can gain some space in ROM in regard of BITMAP ?

Thanks !

 

Perhaps I don't understand your question. Just in case, here's a brief explanation: "DECLE" is in Assembly Language like "DATA" is in BASIC, which is to say, a way of storing data in ROM. Both store a 16-bit word (the Intellivision is only word-addressible; when accessing 8-bit RAM, it just makes the high-order byte all zeros).

 

The difference between "BITMAP" and "DATA" in IntyBASIC is that "BITMAP" automatically packs two bytes in "little-endian" format. That is, the first byte goes on the lower-order half of the DECLE, and the second byte goes on the high-order half.

 

This is an exceedingly convenient format to pack graphics data to copy into GRAM in the most efficient way. The typical Assembly Language block-copy loop for GRAM is like this:

    ; Copies one card of data into GRAM
    ; packed in 4 16-bit words in ROM.
    ;   R4 = auto-increment register pointing to source data
    ;   R5 = auto-increment register pointing to destination
  REPEAT (4)
    MVI@  R4,  R0    ; Get word data
    MVO@  R0,  R5    ; Copy first byte into destination
    SWAP  R0         ; Flip word
    MVO@  R0,  R5    ; Copy second byte into destination
  ENDR

Thus, we pack the 8 bytes of a GRAM card into 4 16-bit words, where each DECLE packs two words: the odd-numbered bytes in the low-ordered half; the even-numbered bytes in the high-ordered half. For example:

                ; Animation Tile: 0  (ID: 0)
                ; --------------------------------
                            ; ..###... - %00111000
                DECLE $7C38 ; .#####.. - %01111100
                            ; #.#.###. - %10101110
                DECLE $AEAE ; #.#.###. - %10101110
                            ; #######. - %11111110
                DECLE $FEFE ; #######. - %11111110
                            ; #######. - %11111110
                DECLE $B6FE ; #.##.##. - %10110110
                ; --------------------------------

The "BITMAP" statement does this automatically for you by accepting as input a string describing an 8-bit graphic in either binary ("00110011") or symbolic ("..##..##"). The compiler will take a pair of BITMAP statements, decode the argument, and pack the two bytes into a DECLE as mentioned above.

 

Does this answer your question?

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

  • 2 weeks later...

Vetea,

 

I'm sure you are aware of it, but just in case, the jzIntv emulator comes with a very powerful interactive debugger. If you are using the IntyBASIC SDK, invoking the debugger is as simple as using the tool "INTYDBUG" to execute the game, and it will take care of initializing the debugger with a symbol table and source-to-listing mapping between IntyBASIC and Assembly.

 

If you are not using the SDK, you can add the "-d" option to the command line to invoke the debugger, but you'll have to read jzIntv debugger documentation for information on how to set the symbol table and other features.

 

Or just ask. ;)

 

-dZ.

Link to comment
Share on other sites

Are the cards 213-255 deterministic, or unusued ROM space that might be different for each chip/system? Is that perhaps some form of executable code?

It's part of the EXEC rom code. I think it never changes along Intellivision revisions. Except in minigrom.bin provided with jzintv

There are a few versions out there, mostly with minor differences.

 

There is the most common version that is in most original Intellivisions.

 

Rare Tutorvisions and Tutor Pro systems have another.

Link to comment
Share on other sites

There are a few versions out there, mostly with minor differences.

 

There is the most common version that is in most original Intellivisions.

 

Rare Tutorvisions and Tutor Pro systems have another.

 

Just to follow up, while I didn't perform a true GROM dump and then do a bit-by-bit compare, I did fire up a bunch of systems and check the text embedded in the upper-most GROM cards. All of them, except for the Tutor Pro, had the same text. This was done checking the original Intellivision, Sears Intellivision, Intellivision II, and Tutor Pro.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...