Intellivision homebrew - Mystery Castle

[GroovyBee]

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.

 

 

As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

[+cmart604]

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.

 

 

As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

 

 

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

[iwan-iwanowitsch-goratschin]

HEY, that´s LINK!

[GroovyBee]

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

 

Thanks for the compliment. The next steps in the game are to add some collision detection and extend the world beyond the one room. The rooms are put together like lego bricks so there will be quite a bit of variety. Then I can add monsters and shooting. Only then does it start to become a real game .

[GroovyBee]

HEY, that´s LINK!

 

More like PINK! I might make the player's skin orange then it won't look like he's out of breath all the time.

[+cmart604]

Very cool looking Mark! I can't wait to see your progess on these 2 INTV games.

 

Thanks for the compliment. The next steps in the game are to add some collision detection and extend the world beyond the one room. The rooms are put together like lego bricks so there will be quite a bit of variety. Then I can add monsters and shooting. Only then does it start to become a real game .

 

Must...contain....excitement...

[Jess Ragan]

Looks kind of like the ColecoVision game Alcazar. Was that an inspiration?

[GroovyBee]

Looks kind of like the ColecoVision game Alcazar. Was that an inspiration?

 

Nope! It'll be similar to this game I'm developing on the 7800 :-

 

http://www.atariage.com/forums/topic/152901-7800-happy-halloween/

[intvnut]

 

As soon as I can test on real hardware and there is more of a game, binaries will be available. There's not much going on besides a moveable, animated, multi-colour player sprite at the moment.

 

Looks awesome! :-)

 

My CP1600 assembly language is getting up to speed so here's my 2nd WIP. Its provisionally called Mystery Castle.

Indeed it does! Since it seems you're no stranger to assembly code, I have to ask: What do you think of the CP-1600 so far?

[GroovyBee]

Looks awesome! :-)

 

Thanks for the compliment.

 

What do you think of the CP-1600 so far?

 

Its interesting. It sort of reminds me of hybrid THUMB/x86/C166/C167. I miss setting condition code register flags on indirect memory moves tho . Got caught out big time on that .

 

I'm also fighting as1600 quite a lot too. I'm too used to using things like "#~RANDOM_BIT_FLAG, r0" which has to be replaced with "#NOT(RANDOM_BIT_FLAG) AND $FFFF, r0" otherwise the assembler generates an error. The "NOT" I don't mind the "AND $FFFF" feels redundant because the assembler knows the size of the instruction's immediate field and it should just "do the right thing". The syntax of "#'0'-32, r0" isn't valid either . Not having a linker is taking some getting used to as well. Is there a way to switch off listings? I normally do that in included files so they don't clutter the place up. Sorry for all the gripes about the tools you maintain.

[LS_Dracon]

Looks promissing

 

More like PINK! I might make the player's skin orange then it won't look like he's out of breath all the time.

Yeah, for me color limit is worse than sprite limit.

[GroovyBee]

Looks promissing

 

Thanks for the compliment.

 

Yeah, for me color limit is worse than sprite limit.

 

You can have 16 colours on screen (with some restrictions) but the colours are just so 70's . You can also have 8 single colour sprites on screen at the same time (with hardware X/Y zoom, X/Y flipping and collision detection). To get the multi-colour player I have to overlay 3 of them.

[Rev]

groovybee......if i wasnt already married.....

[+cmart604]

groovybee......if i wasnt already married.....

 

 

That's just internet gold.

[intvnut]

Looks awesome! :-)

 

Thanks for the compliment.

 

What do you think of the CP-1600 so far?

 

Its interesting. It sort of reminds me of hybrid THUMB/x86/C166/C167. I miss setting condition code register flags on indirect memory moves tho . Got caught out big time on that .

 

I'm also fighting as1600 quite a lot too. I'm too used to using things like "#~RANDOM_BIT_FLAG, r0" which has to be replaced with "#NOT(RANDOM_BIT_FLAG) AND $FFFF, r0" otherwise the assembler generates an error. The "NOT" I don't mind the "AND $FFFF" feels redundant because the assembler knows the size of the instruction's immediate field and it should just "do the right thing". The syntax of "#'0'-32, r0" isn't valid either . Not having a linker is taking some getting used to as well. Is there a way to switch off listings? I normally do that in included files so they don't clutter the place up. Sorry for all the gripes about the tools you maintain.

 

Please let me get you the current build of the tools. They fix the "AND $FFFF" problem. Heck, I think even the jzIntv 1.0 beta3 release has this fixed. That drove me f'ing bonkers also.

 

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

 

MACRO idx(x)
   ASC('%x%',0)-32
ENDM

 

You can modulate listings with the LISTING directive. See jzintv/doc/utilities/as1600.txt for details.

[intvnut]

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

 

Actually, I'm an idiot. I think I have an idea to make it work. I'll let you know what I come up with.

[GroovyBee]

Please let me get you the current build of the tools. They fix the "AND $FFFF" problem. Heck, I think even the jzIntv 1.0 beta3 release has this fixed. That drove me f'ing bonkers also.

 

That's the version I'm using.

 

As for characters as constants... yeah, that's an artifact of the Frankenstein assembler treating "string" and 'string' as identical. It's rather baked into its parser and I don't know how to get it out easily without breaking a bunch of stuff. ASC('0',0)-32 works, though, and if you want to make it shorter, you can use a macro:

 

MACRO idx(x)
   ASC('%x%',0)-32
ENDM

 

Thanks for that. I'll go back and adjust my code so its readable again.

 

You can modulate listings with the LISTING directive. See jzintv/doc/utilities/as1600.txt for details.

 

I thought the answer would be in the documentation some place. I did look but I was more interested in ploughing on with the game.

[GroovyBee]

groovybee......if i wasnt already married.....

 

We have incompatible connector ports so it'll never work .

[GroovyBee]

That's the version I'm using.

 

My mistake, I was using the one in SDK-1600, I've switched over to the jzintv one now.

[GroovyBee]

What's new in the latest version?

 

- 4 room styles

- 15 rooms to explore

- Collision detection with walls

 

 

And... the ROM (you might need to rename it back to *.rom because I can't upload *.rom files to the forum).

 

castle_14_09_10.1.02.rom.bin

 

I haven't tested this version on real hardware so apologies in advance to the CC3 owners if it doesn't work correctly. However it works fine on jzintv and Bliss.

 

As always, comments and suggestions welcome.

[catsfolly]

I got 0 points! Has anyone beaten that yet?

 

So far so good! The screens look good and the transitions are smooth and quick.

 

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

 

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

 

The seems to be a tall stack of green plates on the right edge of the display - what's the deal with that?

 

Looks promising!! Thanks for letting us try it out!

[GroovyBee]

I got 0 points! Has anyone beaten that yet?

 

There isn't much to do in the game at the moment.

 

So far so good! The screens look good and the transitions are smooth and quick.

 

Have you tested it using a CC3?

 

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

 

I've implemented sliding so you can hold a diagonal direction and you'll move along the wall and then nip through the door. You don't have to be pixel perfect. When beasties start chasing you, sliding will come in very handy .

 

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

 

The player speed seemed too slow to me. I'll experiment when I get some time.

 

The seems to be a tall stack of green plates on the right edge of the display - what's the deal with that?

 

That's the player's energy bar. Most things are provisional at the moment, so I might replace it with the word "ENERGY" on a green background. One of the problems is that the Inty doesn't have a wide range of colours to choose from. Its also a trade off between available tile/sprite bitmaps (in that you can only have 64) and having more interesting items in the rooms.

 

Looks promising!! Thanks for letting us try it out!

 

Thanks for the compliment. The game will get better . Its only my 2nd week of Inty coding .

[intvnut]

So far so good! The screens look good and the transitions are smooth and quick.

Have you tested it using a CC3?

I have and it worked just fine. The thin green vertical lines show up a little weak, though, on my LCD CRT. Dunno if it's just the TV or possibly an artifact of the STIC's NTSC output.

 

(Aside: I did have to change the ROM to CC3 format to download it via serial. The two formats are identical save for the first byte, because they (annoyingly) use different autobaud schemes. "as1600 -c" will output the CC3 autobaud byte in the header. Otherwise it's trivial to change in a hex editor. First byte is 0xA8 for Intellicart, 0x41 for CC3. Or, you can use "rom_merge --cc3 foo.rom bar.rom". I forget which format .ROM Chad expects on the MicroSD and which format Chad's GUI front end expects. I vaguely recall that one or both want the Intellicart autobaud byte, but I can't remember for sure. Anyway, my tools make it easy to convert between to two.)

 

The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors.

I've implemented sliding so you can hold a diagonal direction and you'll move along the wall and then nip through the door. You don't have to be pixel perfect. When beasties start chasing you, sliding will come in very handy .

Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought.

The player speed seemed too slow to me. I'll experiment when I get some time.

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

 

Looks promising!! Thanks for letting us try it out!

Thanks for the compliment. The game will get better . Its only my 2nd week of Inty coding .

 

Allow me to throw a "me too" in there: I too think it looks promising!

[GroovyBee]

I have and it worked just fine. The thin green vertical lines show up a little weak, though, on my LCD CRT. Dunno if it's just the TV or possibly an artifact of the STIC's NTSC output.

 

Thanks for testing. The vertical lines are only a pixel wide. I'll see how they look on my PAL TV when I get my CC3. Maybe the shade of green isn't optimum. The rooms will be different colours in the final game just to add a bit of extra variety.

 

(Aside: I did have to change the ROM to CC3 format to download it via serial. The two formats are identical save for the first byte,

 

Points noted about the CC3 format. I'll add both in the next release.

 

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

 

Its moving two pixels in X at the moment. I'll have a play with frame delay and X step in the next version.

 

Allow me to throw a "me too" in there: I too think it looks promising!

 

I'm glad people like it. The next version will have much more of the real game in place.

[intvnut]

Vertical seemed fine to me, or maybe even a tad slow, but horizontally the character really hauls a**. I figured you might be trying make the transit time horizontally across the screen similar to vertically or something. It does seem asymmetric. Or was I imagining things?

Its moving two pixels in X at the moment. I'll have a play with frame delay and X step in the next version.

 

One trick I used in Space Patrol was to use a rotated 1s complement representation for X/Y position and X/Y velocity. By rotated, I mean the fractional portion was in the MSB and the integer portion was in the LSB. Velocity and position are both 8.8 values, allowing a wide range of velocity control. To add velocity to position, I do:

       ; assume velocity in R0, position in R1
       ADDR    R0,     R1     ; seemingly normal 2s complement ADD
       ADCR    R1             ; end-around carry for 1s complement

The reason I used a rotated format like this is twofold. The first is that when I go to merge X/Y into the MOB registers, I can just do:

       ; assume rotated X is in R0, other X-register bits in R1
       ANDI    #$FF,   R0
       ADDR    R0,     R1

The second is that I can do "SIMD" bounding box checks for collisions. The SDBD prefix tells the CPU to read the LSBs of two bytes. When used with an incrementing pointer, it's a handy way to read X and Y packed into a single register, provided the X and Y positions are in the LSB.

       ; assume R4 points to X, and that X/Y stored adjacently
       SDBD
       MVI@    R4,     R0    ; LSB holds X, MSB holds Y

Now with the packed X/Y, I can do a single subtract to see if the X/Y for the one object is greater than the X/Y for another. Here's a code excerpt from Space Patrol. In this excerpt, "GGB1" holds the already-packed Y/X upper-left coordinate of my bullet, and R4 points to the X/Y positions of a bad guy, and R3 points to a packed representation of the bad-guy's size, biased by the size of the bullet:

       SDBD                          
       MVI@    R4,     R1      ;   8  Get Y/X coordinate of bad guy
                                     
       MOVR    R1,     R2      ;   6  save it for comparing against the next bullet (GGB2)
                                     
       SUB     GGB1,   R1      ;  10  Check the lower right corner
       BNC     @@out1          ; 7/9  If Y went -ve, bullet's to the right
       SWAP    R1,     1       ;   6  
       SWAP    R1,     1       ;   6  
       BMI     @@out1          ; 7/9  If X went -ve, bullet's below

       ;;------------------------------------------------------------------;;
       ;;  At this point R1 contains our X distance to the right,          ;;
       ;;  and our Y distance to the right of the bullet's upper left      ;;
       ;;  corner vs. the lower right corner of the bad guy.  So, if       ;;
       ;;  we subtract the bad buy's width and we still end up positive,   ;;
       ;;  we're to the left or above.  (Note that we bias all bad-guy     ;;
       ;;  widths in our table by the width/height of the bullet.)         ;;
       ;;------------------------------------------------------------------;;
       SUB@    R3,     R1      ;   8  Compare to bad-guy's size.
       BPL     @@out1          ; 7/9  If Y still +ve, bullet's to the left
       SWAP    R1,     2       ;   8
       BPL     @@out1          ; 7/9  If X still +ve, bullet's above

       ;;------------------------------------------------------------------;;
       ;;  If we made it this far, it's a HIT.                             ;;
       ;;  Disable bullet 1 and then process the hit.                      ;;
       ;;------------------------------------------------------------------;;
       CLRR    R1              ;   6
       MVO     R1,     SPAT2+5 ;  11  disable the good-guy bullet #1

       B       @@hit           ;   9

In SP, since I have 3 active tank bullets and 12 things they can hit, anything I can save on the bounding box compare is huge.

 

The complete function is here: http://spacepatrol.info/src/engine/ckggb.asm

Edited September 15, 2010 by intvnut